Commit Graph

9 Commits

Author SHA1 Message Date
Damien Miller 48348fc3b4 - djm@cvs.openbsd.org 2012/03/28 07:23:22
[PROTOCOL.certkeys]
     explain certificate extensions/crit split rationale. Mention requirement
     that each appear at most once per cert.
2012-04-22 11:08:30 +10:00
Damien Miller eb8b60e320 - djm@cvs.openbsd.org 2010/08/31 11:54:45
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c]
     [authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c]
     [monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c]
     [ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c]
     [ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h]
     [ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5]
     [uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c]
     Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
     host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
     better performance than plain DH and DSA at the same equivalent symmetric
     key length, as well as much shorter keys.

     Only the mandatory sections of RFC5656 are implemented, specifically the
     three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and
     ECDSA. Point compression (optional in RFC5656 is NOT implemented).

     Certificate host and user keys using the new ECDSA key types are supported.

     Note that this code has not been tested for interoperability and may be
     subject to change.

     feedback and ok markus@
2010-08-31 22:41:14 +10:00
Damien Miller 1da6388959 - djm@cvs.openbsd.org 2010/08/04 05:40:39
[PROTOCOL.certkeys ssh-keygen.c]
     tighten the rules for certificate encoding by requiring that options
     appear in lexical order and make our ssh-keygen comply. ok markus@
2010-08-05 13:03:51 +10:00
Damien Miller d0e4a8e2e0 - djm@cvs.openbsd.org 2010/05/20 23:46:02
[PROTOCOL.certkeys auth-options.c ssh-keygen.c]
     Move the permit-* options to the non-critical "extensions" field for v01
     certificates. The logic is that if another implementation fails to
     implement them then the connection just loses features rather than fails
     outright.

     ok markus@
2010-05-21 14:58:32 +10:00
Damien Miller 2725c2193b - djm@cvs.openbsd.org 2010/05/01 02:50:50
[PROTOCOL.certkeys]
     typo; jmeltzer@
2010-05-10 11:56:14 +10:00
Damien Miller 4e270b05dd - djm@cvs.openbsd.org 2010/04/16 01:47:26
[PROTOCOL.certkeys auth-options.c auth-options.h auth-rsa.c]
     [auth2-pubkey.c authfd.c key.c key.h myproposal.h ssh-add.c]
     [ssh-agent.c ssh-dss.c ssh-keygen.1 ssh-keygen.c ssh-rsa.c]
     [sshconnect.c sshconnect2.c sshd.c]
     revised certificate format ssh-{dss,rsa}-cert-v01@openssh.com with the
     following changes:

     move the nonce field to the beginning of the certificate where it can
     better protect against chosen-prefix attacks on the signature hash

     Rename "constraints" field to "critical options"

     Add a new non-critical "extensions" field

     Add a serial number

     The older format is still support for authentication and cert generation
     (use "ssh-keygen -t v00 -s ca_key ..." to generate a v00 certificate)

     ok markus@
2010-04-16 15:56:21 +10:00
Damien Miller fe588e3c84 - djm@cvs.openbsd.org 2010/03/03 22:50:40
[PROTOCOL.certkeys]
     s/similar same/similar/; from imorgan AT nas.nasa.gov
2010-03-04 21:52:00 +11:00
Damien Miller 25b97dd454 - (djm) [PROTOCOL.certkeys] Add RCS Ident 2010-03-03 10:24:00 +11:00
Damien Miller 0a80ca190a - OpenBSD CVS Sync
- djm@cvs.openbsd.org 2010/02/26 20:29:54
     [PROTOCOL PROTOCOL.agent PROTOCOL.certkeys addrmatch.c auth-options.c]
     [auth-options.h auth.h auth2-pubkey.c authfd.c dns.c dns.h hostfile.c]
     [hostfile.h kex.h kexdhs.c kexgexs.c key.c key.h match.h monitor.c]
     [myproposal.h servconf.c servconf.h ssh-add.c ssh-agent.c ssh-dss.c]
     [ssh-keygen.1 ssh-keygen.c ssh-rsa.c ssh.1 ssh.c ssh2.h sshconnect.c]
     [sshconnect2.c sshd.8 sshd.c sshd_config.5]
     Add support for certificate key types for users and hosts.

     OpenSSH certificate key types are not X.509 certificates, but a much
     simpler format that encodes a public key, identity information and
     some validity constraints and signs it with a CA key. CA keys are
     regular SSH keys. This certificate style avoids the attack surface
     of X.509 certificates and is very easy to deploy.

     Certified host keys allow automatic acceptance of new host keys
     when a CA certificate is marked as sh/known_hosts.
     see VERIFYING HOST KEYS in ssh(1) for details.

     Certified user keys allow authentication of users when the signing
     CA key is marked as trusted in authorized_keys. See "AUTHORIZED_KEYS
     FILE FORMAT" in sshd(8) for details.

     Certificates are minted using ssh-keygen(1), documentation is in
     the "CERTIFICATES" section of that manpage.

     Documentation on the format of certificates is in the file
     PROTOCOL.certkeys

     feedback and ok markus@
2010-02-27 07:55:05 +11:00