X.509v3 Certificates for Secure Shell Authentication
Extracted elements (22)
OCSP responses are embedded directly in the public key data structure to reduce communication round trips and to allow clients outside a private network to receive OCSP responses from a server behind a firewall, avoiding the need for out-of-band OCSP checking.
x509v3-rsa2048-sha256 was introduced as a new format (with no non-certificate SSH counterpart) to provide an RSA-based algorithm meeting NIST SP-800-131 recommendations: modulus ≥ 2048 bits and SHA-256, which are acceptable indefinitely, whereas RSA with < 2048 bits or SHA-1 was deprecated after 2010.
This document is informed by but does not maintain strict compatibility with an earlier proposal for X.509v3 certificates in SSH by O. Saarenmaa and J. Galbraith. Signing and verification for x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-ecdsa-sha2-* use the same encoding as their non-certificate SSH counterparts (ssh-dss, ssh-rsa, ecdsa-sha2-*).
Each certificate and OCSP response MUST be encoded as a DER-encoded ASN.1 octet string. The sender's certificate MUST be first, and the public key it conveys MUST be consistent with the public key algorithm used to authenticate the sender.
Each following certificate in the chain MUST certify the one preceding it. All intermediate certificates leading to a root authority MUST be included; the self-signed root MAY be omitted.
For server authentication, it is RECOMMENDED that the subjectAlternativeName extension SHOULD convey the server host name using dNSName or iPAddress entries. DNS-ID checking SHOULD follow RFC 6125; DNS-ID MAY contain a wildcard '*' as the complete left-most label.
If the KeyUsage extension is present in a certificate for x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, or x509v3-ecdsa-sha2-*, the digitalSignature bit MUST be set. For ecmqv-sha2 key exchange, the keyAgreement bit MUST be set.
Implementations SHOULD check that the production time of an OCSP response is acceptable. It is RECOMMENDED (but not REQUIRED) that implementations reject certificates whose status is revoked. If OCSP is indicated but no response is available, the certificate is RECOMMENDED to be rejected.
The public key algorithms defined in this document SHOULD be accepted anywhere in the SSH protocol suite where public keys are used, including SSH_MSG_USERAUTH_REQUEST (publickey and hostbased), SSH_MSG_KEXDH_REPLY, SSH_MSG_KEXRSA_PUBKEY, SSH_MSG_KEXGSS_HOSTKEY, SSH_MSG_KEX_ECDH_REPLY, and SSH_MSG_KEX_ECMQV_REPLY.
Upon receipt of a certificate chain, implementations MUST verify the chain per RFC 5280 Section 6.1 based on a root of trust configured by the system administrator or user. Compliant implementations MUST comply with RFC 5280.
Verifiers MUST be prepared to receive certificate chains and OCSP responses using algorithms not listed in the SSH_MSG_KEXINIT server_host_key_algorithms field, including algorithms with no SSH equivalent. The number of OCSP responses MUST NOT exceed the number of certificates.
When a public key from this specification is included in a hash algorithm input, implementations MUST NOT omit any chain certificates or OCSP responses that were transmitted on the wire, nor change their encoding; both peers must hash identical bytes.
Four new SSH public key algorithms are defined: x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, and the x509v3-ecdsa-sha2-* family. Each uses an X.509v3 certificate chain to convey the signer's public key instead of a raw key.
Two ExtendedKeyUsage key purpose IDs are defined: id-kp-secureShellClient (OID { id-kp 21 }) and id-kp-secureShellServer (OID { id-kp 22 }). If the ExtendedKeyUsage extension is present, the certificate MUST be used only for one of the indicated purposes.
Four entries are added to the SSH Public Key Algorithm Names registry: 'x509v3-ssh-dss', 'x509v3-ssh-rsa', 'x509v3-rsa2048-sha256', and the family 'x509v3-ecdsa-sha2-*' (not containing '@'). Two OIDs (id-kp-secureShellClient and id-kp-secureShellServer) are assigned from the PKIX arc.
If a certificate indicates OCSP is used but no OCSP response is available, the absence of a response along with details of the attempted certificate use SHOULD be logged as a security event. Security quality depends on algorithm strength, key security, implementation correctness, and PKI/CA security.
Implementations SHOULD NOT use revoked certificates because revocation typically means critical authentication properties are no longer valid (e.g., private key compromise or mis-issuance). Attempted use of a revoked certificate SHOULD be logged with date, time, certificate identity, and apparent origin IP.
The public key format encodes an algorithm name string, a uint32 certificate-count, that many DER-encoded certificate strings, a uint32 ocsp-response-count, and that many DER-encoded OCSP response strings. Both certificates and OCSP responses use DER/ASN.1 encoding.
The x509v3-ecdsa-sha2-* signature is encoded as a string 'ecdsa-sha2-[identifier]' followed by an ecdsa_signature_blob containing mpint r and mpint s, which are the raw ECDSA algorithm outputs. Hash function is chosen based on key size per RFC 5656 Section 6.2.1.
The x509v3-rsa2048-sha256 signature is encoded as a string 'rsa2048-sha256' followed by rsa_signature_blob. Uses RSASSA-PKCS1-v1_5 with SHA-256; RSA keys MUST have a modulus of at least 2048 bits.
The x509v3-ssh-dss signature is encoded as a string 'ssh-dss' followed by a dss_signature_blob string containing r concatenated with s, each a fixed-length 160-bit unsigned integer in network byte order with no length prefix or padding.
The x509v3-ssh-rsa signature is encoded as a string 'ssh-rsa' followed by an rsa_signature_blob string containing s, an unsigned integer in network byte order without length or padding. Uses RSASSA-PKCS1-v1_5 with SHA-1.