[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.11 and 1.19

version 1.11, 2017/05/16 16:54:05 version 1.19, 2021/06/05 13:47:00
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 the 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-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 146 
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  pk is the encoded Ed25519 public key as defined by RFC8032.
 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
 field to zero.  field to zero.
   
 type specifies whether this certificate is for identification of a user  type specifies whether this certificate is for identification of a user
Line 174 
Line 186 
   
     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 204 
Line 216 
 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), and draft-josefsson-eddsa-ed25519-03 for Ed25519.  types, and RFC8032 for Ed25519).
   
 Critical options  Critical options
 ----------------  ----------------
   
 The critical options section of the certificate specifies zero or more  The critical options section of the certificate specifies zero or more
 options on the certificates validity. The format of this field  options on the certificate's validity. The format of this field
 is a sequence of zero or more tuples:  is a sequence of zero or more tuples:
   
     string       name      string       name
Line 221 
Line 233 
   
 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.
   
   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 240 
Line 255 
                                       for authentication. Addresses are                                        for authentication. Addresses are
                                       specified in CIDR format (nn.nn.nn.nn/nn                                        specified in CIDR format (nn.nn.nn.nn/nn
                                       or hhhh::hhhh/nn).                                        or hhhh::hhhh/nn).
                                       If this option is not present then                                        If this option is not present, then
                                       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 makes sense
                                         for the U2F/FIDO security key types that
                                         support this feature in their signature
                                         formats.
   
 Extensions  Extensions
 ----------  ----------
   
Line 255 
Line 278 
 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
 their data fields are:  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
                                         makes 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.
Line 272 
Line 305 
   
 permit-port-forwarding  empty         Flag indicating that port-forwarding  permit-port-forwarding  empty         Flag indicating that port-forwarding
                                       should be allowed. If this option is                                        should be allowed. If this option is
                                       not present then no port forwarding will                                        not present, then no port forwarding will
                                       be allowed.                                        be allowed.
   
 permit-pty              empty         Flag indicating that PTY allocation  permit-pty              empty         Flag indicating that PTY allocation
Legend:
Removed from v.1.11  
changed lines
  Added in v.1.19