=================================================================== RCS file: /cvsrepo/anoncvs/cvs/src/usr.bin/ssh/PROTOCOL.certkeys,v retrieving revision 1.8 retrieving revision 1.13 diff -u -r1.8 -r1.13 --- src/usr.bin/ssh/PROTOCOL.certkeys 2010/08/31 11:54:45 1.8 +++ src/usr.bin/ssh/PROTOCOL.certkeys 2017/11/03 02:32:19 1.13 @@ -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-cert-v01@openssh.com" | + "ecdsa-sha2-nistp384-cert-v01@openssh.com" | + "ecdsa-sha2-nistp521-cert-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,21 +182,29 @@ 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. -signature key contains the CA key used to sign the certificate. -The valid key types for CA keys are ssh-rsa, ssh-dss and the ECDSA types -ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. "Chained" -certificates, where the signature key type is a certificate type itself -are NOT supported. Note that it is possible for a RSA certificate key to -be signed by a DSS or ECDSA CA key and vice-versa. +The signature key field contains the CA key used to sign the +certificate. The valid key types for CA keys are ssh-rsa, +ssh-dss, ssh-ed25519 and the ECDSA types ecdsa-sha2-nistp256, +ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. "Chained" certificates, where +the signature key type is a certificate type itself are NOT supported. +Note that it is possible for a RSA certificate key to be signed by a +Ed25519 or ECDSA CA key and vice-versa. signature is computed over all preceding fields from the initial string 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,16 +217,20 @@ 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: +Custom options should append the originating author or organisation's +domain name to the option name, e.g. "my-option@example.com". +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 ----------------------------------------------------------------------------- force-command string Specifies a command that is executed @@ -220,13 +252,19 @@ 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: +Custom options should append the originating author or organisation's +domain name to the option name, e.g. "my-option@example.com". +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 ----------------------------------------------------------------------------- permit-X11-forwarding empty Flag indicating that X11 forwarding @@ -253,4 +291,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.13 2017/11/03 02:32:19 djm Exp $