[BACK]Return to PROTOCOL.certkeys CVS log [TXT][DIR] Up to [local] / src / usr.bin / ssh

Diff for /src/usr.bin/ssh/PROTOCOL.certkeys between version 1.8 and 1.11

version 1.8, 2010/08/31 11:54:45 version 1.11, 2017/05/16 16:54:05
Line 100 
Line 100 
   
 ECDSA certificate  ECDSA certificate
   
     string    "ecdsa-sha2-nistp256@openssh.com" |      string    "ecdsa-sha2-nistp256-v01@openssh.com" |
               "ecdsa-sha2-nistp384@openssh.com" |                "ecdsa-sha2-nistp384-v01@openssh.com" |
               "ecdsa-sha2-nistp521@openssh.com"                "ecdsa-sha2-nistp521-v01@openssh.com"
     string    nonce      string    nonce
     string    curve      string    curve
     string    public_key      string    public_key
Line 118 
Line 118 
     string    signature key      string    signature key
     string    signature      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  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  (but typically 16 or 32 bytes) included to make attacks that depend on
 inducing collisions in the signature hash infeasible.  inducing collisions in the signature hash infeasible.
Line 129 
Line 146 
 curve and public key are respectively the ECDSA "[identifier]" and "Q"  curve and public key are respectively the ECDSA "[identifier]" and "Q"
 defined in section 3.1 of RFC5656.  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  serial is an optional certificate serial number set by the CA to
 provide an abbreviated way to refer to certificates from that CA.  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  If a CA does not wish to number its certificates it must set this
Line 146 
Line 166 
 certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and  certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and
 usernames for SSH_CERT_TYPE_USER certificates. As a special case, a  usernames for SSH_CERT_TYPE_USER certificates. As a special case, a
 zero-length "valid principals" field means the certificate is valid for  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  "valid after" and "valid before" specify a validity period for the
 certificate. Each represents a time in seconds since 1970-01-01  certificate. Each represents a time in seconds since 1970-01-01
Line 162 
Line 182 
 are not critical, and an implementation that encounters one that it does  are not critical, and an implementation that encounters one that it does
 not recognise may safely ignore it.  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 reserved field is currently unused and is ignored in this version of
 the protocol.  the protocol.
   
 signature key contains the CA key used to sign the certificate.  The signature key field contains the CA key used to sign the
 The valid key types for CA keys are ssh-rsa, ssh-dss and the ECDSA types  certificate. The valid key types for CA keys are ssh-rsa,
 ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. "Chained"  ssh-dss, ssh-ed25519 and the ECDSA types ecdsa-sha2-nistp256,
 certificates, where the signature key type is a certificate type itself  ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. "Chained" certificates, where
 are NOT supported. Note that it is possible for a RSA certificate key to  the signature key type is a certificate type itself are NOT supported.
 be signed by a DSS or ECDSA CA key and vice-versa.  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  signature is computed over all preceding fields from the initial string
 up to, and including the signature key. Signatures are computed and  up to, and including the signature key. Signatures are computed and
 encoded according to the rules defined for the CA's public key algorithm  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  (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  Critical options
 ----------------  ----------------
Line 189 
Line 217 
     string       data      string       data
   
 Options must be lexically ordered by "name" if they appear in the  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  The name field identifies the option and the data field encodes
 option-specific information (see below). All options are  option-specific information (see below). All options are
 "critical", if an implementation does not recognise a option  "critical", if an implementation does not recognise a option
 then the validating party should refuse to accept the certificate.  then the validating party should refuse to accept the certificate.
   
 The supported options and the contents and structure of their  No critical options are defined for host certificates at present. The
 data fields are:  supported user certificate options and the contents and structure of
   their data fields are:
   
 Name                    Format        Description  Name                    Format        Description
 -----------------------------------------------------------------------------  -----------------------------------------------------------------------------
Line 220 
Line 249 
   
 The extensions section of the certificate specifies zero or more  The extensions section of the certificate specifies zero or more
 non-critical certificate extensions. The encoding and ordering of  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  If an implementation does not recognise an extension, then it should
 ignore it.  ignore it.
   
 The supported extensions and the contents and structure of their data  No extensions are defined for host certificates at present. The
 fields are:  supported user certificate extensions and the contents and structure of
   their data fields are:
   
 Name                    Format        Description  Name                    Format        Description
 -----------------------------------------------------------------------------  -----------------------------------------------------------------------------
Legend:
Removed from v.1.8  
changed lines
  Added in v.1.11