=================================================================== RCS file: /cvsrepo/anoncvs/cvs/src/usr.bin/ssh/PROTOCOL.certkeys,v retrieving revision 1.8 retrieving revision 1.10 diff -u -r1.8 -r1.10 --- src/usr.bin/ssh/PROTOCOL.certkeys 2010/08/31 11:54:45 1.8 +++ src/usr.bin/ssh/PROTOCOL.certkeys 2016/05/03 10:27:59 1.10 @@ -100,9 +100,9 @@ ECDSA certificate - string "ecdsa-sha2-nistp256@openssh.com" | - "ecdsa-sha2-nistp384@openssh.com" | - "ecdsa-sha2-nistp521@openssh.com" + string "ecdsa-sha2-nistp256-v01@openssh.com" | + "ecdsa-sha2-nistp384-v01@openssh.com" | + "ecdsa-sha2-nistp521-v01@openssh.com" string nonce string curve string public_key @@ -118,6 +118,23 @@ string signature key string signature +ED25519 certificate + + string "ssh-ed25519-cert-v01@openssh.com" + string nonce + string pk + uint64 serial + uint32 type + string key id + string valid principals + uint64 valid after + uint64 valid before + string critical options + string extensions + string reserved + string signature key + string signature + The nonce field is a CA-provided random bitstring of arbitrary length (but typically 16 or 32 bytes) included to make attacks that depend on inducing collisions in the signature hash infeasible. @@ -129,6 +146,9 @@ curve and public key are respectively the ECDSA "[identifier]" and "Q" defined in section 3.1 of RFC5656. +pk is the encoded Ed25519 public key as defined by +draft-josefsson-eddsa-ed25519-03. + serial is an optional certificate serial number set by the CA to provide an abbreviated way to refer to certificates from that CA. If a CA does not wish to number its certificates it must set this @@ -146,7 +166,7 @@ certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and usernames for SSH_CERT_TYPE_USER certificates. As a special case, a zero-length "valid principals" field means the certificate is valid for -any principal of the specified type. XXX DNS wildcards? +any principal of the specified type. "valid after" and "valid before" specify a validity period for the certificate. Each represents a time in seconds since 1970-01-01 @@ -162,6 +182,13 @@ are not critical, and an implementation that encounters one that it does not recognise may safely ignore it. +Generally, critical options are used to control features that restrict +access where extensions are used to enable features that grant access. +This ensures that certificates containing unknown restrictions do not +inadvertently grant access while allowing new protocol features to be +enabled via extensions without breaking certificates' backwards +compatibility. + The reserved field is currently unused and is ignored in this version of the protocol. @@ -176,7 +203,7 @@ up to, and including the signature key. Signatures are computed and encoded according to the rules defined for the CA's public key algorithm (RFC4253 section 6.6 for ssh-rsa and ssh-dss, RFC5656 for the ECDSA -types). +types), and draft-josefsson-eddsa-ed25519-03 for Ed25519. Critical options ---------------- @@ -189,15 +216,16 @@ string data Options must be lexically ordered by "name" if they appear in the -sequence. +sequence. Each named option may only appear once in a certificate. The name field identifies the option and the data field encodes option-specific information (see below). All options are "critical", if an implementation does not recognise a option then the validating party should refuse to accept the certificate. -The supported options and the contents and structure of their -data fields are: +No critical options are defined for host certificates at present. The +supported user certificate options and the contents and structure of +their data fields are: Name Format Description ----------------------------------------------------------------------------- @@ -220,12 +248,15 @@ The extensions section of the certificate specifies zero or more non-critical certificate extensions. The encoding and ordering of -extensions in this field is identical to that of the critical options. +extensions in this field is identical to that of the critical options, +as is the requirement that each name appear only once. + If an implementation does not recognise an extension, then it should ignore it. -The supported extensions and the contents and structure of their data -fields are: +No extensions are defined for host certificates at present. The +supported user certificate extensions and the contents and structure of +their data fields are: Name Format Description ----------------------------------------------------------------------------- @@ -253,4 +284,4 @@ of this script will not be permitted if this option is not present. -$OpenBSD: PROTOCOL.certkeys,v 1.8 2010/08/31 11:54:45 djm Exp $ +$OpenBSD: PROTOCOL.certkeys,v 1.10 2016/05/03 10:27:59 djm Exp $