[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.10 and 1.13

version 1.10, 2016/05/03 10:27:59 version 1.13, 2017/11/03 02:32:19
Line 100 
Line 100 
   
 ECDSA certificate  ECDSA certificate
   
     string    "ecdsa-sha2-nistp256-v01@openssh.com" |      string    "ecdsa-sha2-nistp256-cert-v01@openssh.com" |
               "ecdsa-sha2-nistp384-v01@openssh.com" |                "ecdsa-sha2-nistp384-cert-v01@openssh.com" |
               "ecdsa-sha2-nistp521-v01@openssh.com"                "ecdsa-sha2-nistp521-cert-v01@openssh.com"
     string    nonce      string    nonce
     string    curve      string    curve
     string    public_key      string    public_key
Line 192 
Line 192 
 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
Line 223 
Line 224 
 "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.
   
   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  No critical options are defined for host certificates at present. The
 supported user certificate options and the contents and structure of  supported user certificate options and the contents and structure of
 their data fields are:  their data fields are:
Line 253 
Line 257 
   
 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.
   
   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  No extensions are defined for host certificates at present. The
 supported user certificate extensions and the contents and structure of  supported user certificate extensions and the contents and structure of
Legend:
Removed from v.1.10  
changed lines
  Added in v.1.13