[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.9 and 1.18

version 1.9, 2012/03/28 07:23:22 version 1.18, 2021/06/04 04:02:21
Line 25 
Line 25 
 acceptance of certified host keys, by adding a similar ability to  acceptance of certified host keys, by adding a similar ability to
 specify CA keys in ~/.ssh/known_hosts.  specify CA keys in ~/.ssh/known_hosts.
   
   All certificate types include certification information along with the
   public key that is used to sign challenges. In OpenSSH, ssh-keygen
   performs the CA signing operation.
   
 Certified keys are represented using new key types:  Certified keys are represented using new key types:
   
     ssh-rsa-cert-v01@openssh.com      ssh-rsa-cert-v01@openssh.com
Line 32 
Line 36 
     ecdsa-sha2-nistp256-cert-v01@openssh.com      ecdsa-sha2-nistp256-cert-v01@openssh.com
     ecdsa-sha2-nistp384-cert-v01@openssh.com      ecdsa-sha2-nistp384-cert-v01@openssh.com
     ecdsa-sha2-nistp521-cert-v01@openssh.com      ecdsa-sha2-nistp521-cert-v01@openssh.com
       ssh-ed25519-cert-v01@openssh.com
   
 These include certification information along with the public key  Two additional types exist for RSA certificates to force use of
 that is used to sign challenges. ssh-keygen performs the CA signing  SHA-2 signatures (SHA-256 and SHA-512 respectively):
 operation.  
   
       rsa-sha2-256-cert-v01@openssh.com
       rsa-sha2-512-cert-v01@openssh.com
   
   These RSA/SHA-2 types should not appear in keys at rest or transmitted
   on their wire, but do appear in a SSH_MSG_KEXINIT's host-key algorithms
   field or in the "public key algorithm name" field of a "publickey"
   SSH_USERAUTH_REQUEST to indicate that the signature will use the
   specified algorithm.
   
 Protocol extensions  Protocol extensions
 -------------------  -------------------
   
Line 100 
Line 113 
   
 ECDSA certificate  ECDSA certificate
   
     string    "ecdsa-sha2-nistp256@openssh.com" |      string    "ecdsa-sha2-nistp256-cert-v01@openssh.com" |
               "ecdsa-sha2-nistp384@openssh.com" |                "ecdsa-sha2-nistp384-cert-v01@openssh.com" |
               "ecdsa-sha2-nistp521@openssh.com"                "ecdsa-sha2-nistp521-cert-v01@openssh.com"
     string    nonce      string    nonce
     string    curve      string    curve
     string    public_key      string    public_key
Line 118 
Line 131 
     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 159 
 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 179 
 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 154 
Line 187 
   
     valid after <= current time < valid before      valid after <= current time < valid before
   
 criticial options is a set of zero or more key options encoded as  critical options is a set of zero or more key options encoded as
 below. All such options are "critical" in the sense that an implementation  below. All such options are "critical" in the sense that an implementation
 must refuse to authorise a key that has an unrecognised option.  must refuse to authorise a key that has an unrecognised option.
   
Line 172 
Line 205 
 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 203 
Line 237 
 "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  Custom options should append the originating author or organisation's
 data fields are:  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  Name                    Format        Description
 -----------------------------------------------------------------------------  -----------------------------------------------------------------------------
 force-command           string        Specifies a command that is executed  force-command           string        Specifies a command that is executed
Line 222 
Line 260 
                                       certificates may be presented from any                                        certificates may be presented from any
                                       source address.                                        source address.
   
   verify-required         empty         Flag indicating that signatures made
                                         with this certificate must assert FIDO
                                         user verification (e.g. PIN or
                                         biometric). This option only make sense
                                         for the U2F/FIDO security key types that
                                         support this feature in their signature
                                         formats.
   
 Extensions  Extensions
 ----------  ----------
   
Line 233 
Line 279 
 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  Custom options should append the originating author or organisation's
 fields are:  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  Name                    Format        Description
 -----------------------------------------------------------------------------  -----------------------------------------------------------------------------
   no-touch-required       empty         Flag indicating that signatures made
                                         with this certificate need not assert
                                         FIDO user presence. This option only
                                         make sense for the U2F/FIDO security
                                         key types that support this feature in
                                         their signature formats.
   
 permit-X11-forwarding   empty         Flag indicating that X11 forwarding  permit-X11-forwarding   empty         Flag indicating that X11 forwarding
                                       should be permitted. X11 forwarding will                                        should be permitted. X11 forwarding will
                                       be refused if this option is absent.                                        be refused if this option is absent.
Legend:
Removed from v.1.9  
changed lines
  Added in v.1.18