summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6187.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6187.txt')
-rw-r--r--doc/rfc/rfc6187.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc6187.txt b/doc/rfc/rfc6187.txt
new file mode 100644
index 0000000..bfcad24
--- /dev/null
+++ b/doc/rfc/rfc6187.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Igoe
+Request for Comments: 6187 National Security Agency
+Category: Standards Track D. Stebila
+ISSN: 2070-1721 Queensland University of Technology
+ March 2011
+
+
+ X.509v3 Certificates for Secure Shell Authentication
+
+Abstract
+
+ X.509 public key certificates use a signature by a trusted
+ certification authority to bind a given public key to a given digital
+ identity. This document specifies how to use X.509 version 3 public
+ key certificates in public key algorithms in the Secure Shell
+ protocol.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6187.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 1]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Public Key Algorithms Using X.509 Version 3 Certificates . . . 4
+ 2.1. Public Key Format . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. Certificate Extensions . . . . . . . . . . . . . . . . . . 6
+ 2.2.1. KeyUsage . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.2.2. ExtendedKeyUsage . . . . . . . . . . . . . . . . . . . 7
+ 3. Signature Encoding . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. x509v3-ssh-dss . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. x509v3-ssh-rsa . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.3. x509v3-rsa2048-sha256 . . . . . . . . . . . . . . . . . . 9
+ 3.4. x509v3-ecdsa-sha2-* . . . . . . . . . . . . . . . . . . . 9
+ 4. Use in Public Key Algorithms . . . . . . . . . . . . . . . . . 10
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 14
+ Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 15
+ Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15
+
+1. Introduction
+
+ There are two Secure Shell (SSH) protocols that use public key
+ cryptography for authentication. The Transport Layer Protocol,
+ described in [RFC4253], requires that a digital signature algorithm
+ (called the "public key algorithm") MUST be used to authenticate the
+ server to the client. Additionally, the User Authentication Protocol
+ described in [RFC4252] allows for the use of a digital signature to
+ authenticate the client to the server ("publickey" authentication).
+
+ In both cases, the validity of the authentication depends upon the
+ strength of the linkage between the public signing key and the
+ identity of the signer. Digital certificates, such as those in X.509
+ version 3 (X.509v3) format [RFC5280], are used in many corporate and
+ government environments to provide identity management. They use a
+ chain of signatures by a trusted root certification authority and its
+ intermediate certificate authorities to bind a given public signing
+ key to a given digital identity.
+
+
+
+
+
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 2]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ The following public key authentication algorithms are currently
+ available for use in SSH:
+
+ +--------------+-----------+
+ | Algorithm | Reference |
+ +--------------+-----------+
+ | ssh-dss | [RFC4253] |
+ | | |
+ | ssh-rsa | [RFC4253] |
+ | | |
+ | pgp-sign-dss | [RFC4253] |
+ | | |
+ | pgp-sign-rsa | [RFC4253] |
+ | | |
+ | ecdsa-sha2-* | [RFC5656] |
+ +--------------+-----------+
+
+ Since Pretty Good Privacy (PGP) has its own method for binding a
+ public key to a digital identity, this document focuses solely upon
+ the non-PGP methods. In particular, this document defines the
+ following public key algorithms, which differ from the above solely
+ in their use of X.509v3 certificates to convey the signer's public
+ key.
+
+ +-----------------------+
+ | Algorithm |
+ +-----------------------+
+ | x509v3-ssh-dss |
+ | |
+ | x509v3-ssh-rsa |
+ | |
+ | x509v3-rsa2048-sha256 |
+ | |
+ | x509v3-ecdsa-sha2-* |
+ +-----------------------+
+
+ Public keys conveyed using the x509v3-ecdsa-sha2-* public key
+ algorithms can be used with the ecmqv-sha2 key exchange method.
+
+ Implementation of this specification requires familiarity with the
+ Secure Shell protocol [RFC4251] [RFC4253] and X.509v3 certificates
+ [RFC5280]. Data types used in describing protocol messages are
+ defined in Section 5 of [RFC4251].
+
+ This document is concerned with SSH implementation details;
+ specification of the underlying cryptographic algorithms and the
+ handling and structure of X.509v3 certificates is left to other
+
+
+
+
+Igoe & Stebila Standards Track [Page 3]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ standards documents, particularly [RFC3447], [FIPS-186-3],
+ [FIPS-180-2], [FIPS-180-3], [SEC1], and [RFC5280].
+
+ An earlier proposal for the use of X.509v3 certificates in the Secure
+ Shell protocol was introduced by O. Saarenmaa and J. Galbraith; while
+ this document is informed in part by that earlier proposal, it does
+ not maintain strict compatibility.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Public Key Algorithms Using X.509 Version 3 Certificates
+
+ This document defines the following new public key algorithms for use
+ in the Secure Shell protocol: x509v3-ssh-dss, x509v3-ssh-rsa,
+ x509v3-rsa2048-sha256, and the family of algorithms given by
+ x509v3-ecdsa-sha2-*. In these algorithms, a public key is stored in
+ an X.509v3 certificate. This certificate, a chain of certificates
+ leading to a trusted certificate authority, and optional messages
+ giving the revocation status of the certificates are sent as the
+ public key data in the Secure Shell protocol according to the format
+ in this section.
+
+2.1. Public Key Format
+
+ The reader is referred to [RFC5280] for a general description of
+ X.509 version 3 certificates. For the purposes of this document, it
+ suffices to know that in X.509 a chain or sequence of certificates
+ (possibly of length one) allows a trusted root certificate authority
+ and its intermediate certificate authorities to cryptographically
+ bind a given public key to a given digital identity using public key
+ signatures.
+
+ For all of the public key algorithms specified in this document, the
+ key format consists of a sequence of one or more X.509v3 certificates
+ followed by a sequence of 0 or more Online Certificate Status
+ Protocol (OCSP) responses as in Section 4.2 of [RFC2560]. Providing
+ OCSP responses directly in this data structure can reduce the number
+ of communication rounds required (saving the implementation from
+ needing to perform OCSP checking out-of-band) and can also allow a
+ client outside of a private network to receive OCSP responses from a
+ server behind a firewall. As with any use of OCSP data,
+ implementations SHOULD check that the production time of the OCSP
+ response is acceptable. It is RECOMMENDED, but not REQUIRED, that
+ implementations reject certificates for which the certificate status
+ is revoked.
+
+
+
+
+Igoe & Stebila Standards Track [Page 4]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ The key format has the following specific encoding:
+
+ string "x509v3-ssh-dss" / "x509v3-ssh-rsa" /
+ "x509v3-rsa2048-sha256" / "x509v3-ecdsa-sha2-[identifier]"
+ uint32 certificate-count
+ string certificate[1..certificate-count]
+ uint32 ocsp-response-count
+ string ocsp-response[0..ocsp-response-count]
+
+ In the figure above, the string [identifier] is the identifier of the
+ elliptic curve domain parameters. The format of this string is
+ specified in Section 6.1 of [RFC5656]. Information on the REQUIRED
+ and RECOMMENDED sets of elliptic curve domain parameters for use with
+ this algorithm can be found in Section 10 of [RFC5656].
+
+ Each certificate and ocsp-response MUST be encoded as a string of
+ octets using the Distinguished Encoding Rules (DER) encoding of
+ Abstract Syntax Notation One (ASN.1) [ASN1]. An example of an SSH
+ key exchange involving one of these public key algorithms is given in
+ Appendix A.
+
+ Additionally, the following constraints apply:
+
+ o The sender's certificate MUST be the first certificate and the
+ public key conveyed by this certificate MUST be consistent with
+ the public key algorithm being employed to authenticate the
+ sender.
+
+ o Each following certificate MUST certify the one preceding it.
+
+ o The self-signed certificate specifying the root authority MAY be
+ omitted. All other intermediate certificates in the chain leading
+ to a root authority MUST be included.
+
+ o To improve the chances that a peer can verify certificate chains
+ and OCSP responses, individual certificates and OCSP responses
+ SHOULD be signed using only signature algorithms corresponding to
+ public key algorithms supported by the peer, as indicated in the
+ server_host_key_algorithms field of the SSH_MSG_KEXINIT packet
+ (see Section 7.1 of [RFC4253]). However, other algorithms MAY be
+ used. The choice of signature algorithm used by any given
+ certificate or OCSP response is independent of the signature
+ algorithms chosen by other elements in the chain.
+
+ o Verifiers MUST be prepared to receive certificate chains and OCSP
+ responses that use algorithms not listed in the
+ server_host_key_algorithms field of the SSH_MSG_KEXINIT packet,
+ including algorithms that potentially have no Secure Shell
+
+
+
+Igoe & Stebila Standards Track [Page 5]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ equivalent. However, peers sending such chains should recognize
+ that such chains are more likely to be unverifiable than chains
+ that use only algorithms listed in the server_host_key_algorithms
+ field.
+
+ o There is no requirement on the ordering of OCSP responses. The
+ number of OCSP responses MUST NOT exceed the number of
+ certificates.
+
+ Upon receipt of a certificate chain, implementations MUST verify the
+ certificate chain according to Section 6.1 of [RFC5280] based on a
+ root of trust configured by the system administrator or user.
+
+ Issues associated with the use of certificates (such as expiration of
+ certificates and revocation of compromised certificates) are
+ addressed in [RFC5280] and are outside the scope of this document.
+ However, compliant implementations MUST comply with [RFC5280].
+ Implementations providing and processing OCSP responses MUST comply
+ with [RFC2560].
+
+ When no OCSP responses are provided, it is up to the implementation
+ and system administrator to decide whether or not to accept the
+ certificate. It may be possible for the implementation to retrieve
+ OCSP responses based on the id-ad-ocsp access description in the
+ certificate's Authority Information Access data (Section 4.2.2.1 of
+ [RFC5280]). However, if the id-ad-ocsp access description indicates
+ that the certificate authority employs OCSP, and no OCSP response
+ information is available, it is RECOMMENDED that the certificate be
+ rejected.
+
+ [RFC5480] and [RFC5758] describe the structure of X.509v3
+ certificates to be used with Elliptic Curve Digital Signature
+ Algorithm (ECDSA) public keys. [RFC3279] and [RFC5280] describe the
+ structure of X.509v3 certificates to be used with RSA and Digital
+ Signature Algorithm (DSA) public keys. [RFC5759] provides additional
+ guidance for ECDSA keys in Suite B X.509v3 certificate and
+ certificate revocation list profiles.
+
+2.2. Certificate Extensions
+
+ Certificate extensions allow for the specification of additional
+ attributes associated with a public key in an X.509v3 certificate
+ (see Section 4.2 of [RFC5280]). The KeyUsage and ExtendedKeyUsage
+ extensions may be used to restrict the use of X.509v3 certificates in
+ the context of the Secure Shell protocol as specified in the
+ following sections.
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 6]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+2.2.1. KeyUsage
+
+ The KeyUsage extension MAY be used to restrict a certificate's use.
+ In accordance with Section 4.2.1.3 of [RFC5280], if the KeyUsage
+ extension is present, then the certificate MUST be used only for one
+ of the purposes indicated. There are two relevant keyUsage
+ identifiers for the certificate corresponding to the public key
+ algorithm in use:
+
+ o If the KeyUsage extension is present in a certificate for the
+ x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, or x509v3-
+ ecdsa-sha2-* public key algorithms, then the digitalSignature bit
+ MUST be set.
+
+ o If the KeyUsage extension is present in a certificate for the
+ ecmqv-sha2 key exchange method, then the keyAgreement bit MUST be
+ set.
+
+ For the remaining certificates in the certificate chain,
+ implementations MUST comply with existing conventions on KeyUsage
+ identifiers and certificates as in Section 4.2.1.3 of [RFC5280].
+
+2.2.2. ExtendedKeyUsage
+
+ This document defines two ExtendedKeyUsage key purpose IDs that MAY
+ be used to restrict a certificate's use: id-kp-secureShellClient,
+ which indicates that the key can be used for a Secure Shell client,
+ and id-kp-secureShellServer, which indicates that the key can be used
+ for a Secure Shell server. In accordance with Section 4.2.1.12 of
+ [RFC5280], if the ExtendedKeyUsage extension is present, then the
+ certificate MUST be used only for one of the purposes indicated. The
+ object identifiers of the two key purpose IDs defined in this
+ document are as follows:
+
+ o id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+ o id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose
+ identifiers
+
+ o id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 }
+
+ o id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 }
+
+
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 7]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+3. Signature Encoding
+
+ Signing and verifying using the X.509v3-based public key algorithms
+ specified in this document (x509v3-ssh-dss, x509v3-ssh-rsa,
+ x509v3-ecdsa-sha2-*) is done in the analogous way for the
+ corresponding non-X.509v3-based public key algorithms (ssh-dss,
+ ssh-rsa, ecdsa-sha2-*, respectively); the x509v3-rsa2048-sha256
+ public key algorithm provides a new mechanism, similar to ssh-rsa,
+ but has a different hash function and additional key size
+ constraints. For concreteness, we specify this explicitly below.
+
+3.1. x509v3-ssh-dss
+
+ Signing and verifying using the x509v3-ssh-dss key format is done
+ according to the Digital Signature Standard [FIPS-186-3] using the
+ SHA-1 hash [FIPS-180-2].
+
+ The resulting signature is encoded as follows:
+
+ string "ssh-dss"
+ string dss_signature_blob
+
+ The value for dss_signature_blob is encoded as a string containing r,
+ followed by s (which are fixed-length 160-bit integers, without
+ lengths or padding, unsigned, and in network byte order).
+
+ This format is the same as for ssh-dss signatures in Section 6.6 of
+ [RFC4253].
+
+3.2. x509v3-ssh-rsa
+
+ Signing and verifying using the x509v3-ssh-rsa key format is
+ performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447]
+ using the SHA-1 hash [FIPS-180-2].
+
+ The resulting signature is encoded as follows:
+
+ string "ssh-rsa"
+ string rsa_signature_blob
+
+ The value for rsa_signature_blob is encoded as a string containing s
+ (which is an integer, without lengths or padding, unsigned, and in
+ network byte order).
+
+ This format is the same as for ssh-rsa signatures in Section 6.6 of
+ [RFC4253].
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 8]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+3.3. x509v3-rsa2048-sha256
+
+ Signing and verifying using the x509v3-rsa2048-sha256 key format is
+ performed according to the RSASSA-PKCS1-v1_5 scheme in [RFC3447]
+ using the SHA-256 hash [FIPS-180-3]; RSA keys conveyed using this
+ format MUST have a modulus of at least 2048 bits.
+
+ The resulting signature is encoded as follows:
+
+ string "rsa2048-sha256"
+ string rsa_signature_blob
+
+ The value for rsa_signature_blob is encoded as a string containing s
+ (which is an integer, without lengths or padding, unsigned, and in
+ network byte order).
+
+ Unlike the other public key formats specified in this document, the
+ x509v3-rsa2048-sha256 public key format does not correspond to any
+ previously existing SSH non-certificate public key format. The main
+ purpose of introducing this public key format is to provide an RSA-
+ based public key format that is compatible with current
+ recommendations on key size and hash functions. For example,
+ National Institute of Standards and Technology's (NIST's) draft
+ recommendations on cryptographic algorithms and key lengths
+ [SP-800-131] specify that digital signature generation using an RSA
+ key with modulus less than 2048 bits or with the SHA-1 hash function
+ is acceptable through 2010 and deprecated from 2011 through 2013,
+ whereas an RSA key with modulus at least 2048 bits and SHA-256 is
+ acceptable for the indefinite future. The introduction of other non-
+ certificate-based SSH public key formats compatible with the above
+ recommendations is outside the scope of this document.
+
+3.4. x509v3-ecdsa-sha2-*
+
+ Signing and verifying using the x509v3-ecdsa-sha2-* key formats is
+ performed according to the ECDSA algorithm in [FIPS-186-3] using the
+ SHA2 hash function family [FIPS-180-3]. The choice of hash function
+ from the SHA2 hash function family is based on the key size of the
+ ECDSA key as specified in Section 6.2.1 of [RFC5656].
+
+ The resulting signature is encoded as follows:
+
+ string "ecdsa-sha2-[identifier]"
+ string ecdsa_signature_blob
+
+ The string [identifier] is the identifier of the elliptic curve
+ domain parameters. The format of this string is specified in Section
+ 6.1 of [RFC5656].
+
+
+
+Igoe & Stebila Standards Track [Page 9]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ The ecdsa_signature_blob value has the following specific encoding:
+
+ mpint r
+ mpint s
+
+ The integers r and s are the output of the ECDSA algorithm.
+
+ This format is the same as for ecdsa-sha2-* signatures in Section
+ 3.1.2 of [RFC5656].
+
+4. Use in Public Key Algorithms
+
+ The public key algorithms and encodings defined in this document
+ SHOULD be accepted any place in the Secure Shell protocol suite where
+ public keys are used, including, but not limited to, the following
+ protocol messages for server authentication and user authentication:
+
+ o in the SSH_MSG_USERAUTH_REQUEST message when "publickey"
+ authentication is used [RFC4252]
+
+ o in the SSH_MSG_USERAUTH_REQUEST message when "hostbased"
+ authentication is used [RFC4252]
+
+ o in the SSH_MSG_KEXDH_REPLY message [RFC4253]
+
+ o in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]
+
+ o in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]
+
+ o in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]
+
+ o in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]
+
+ When a public key from this specification is included in the input to
+ a hash algorithm, the exact bytes that are transmitted on the wire
+ must be used as input to the hash functions. In particular,
+ implementations MUST NOT omit any of the chain certificates or OCSP
+ responses that were included on the wire, nor change encoding of the
+ certificate or OCSP data. Otherwise, hashes that are meant to be
+ computed in parallel by both peers will have differing values.
+
+ For the purposes of user authentication, the mapping between
+ certificates and user names is left as an implementation and
+ configuration issue for implementers and system administrators.
+
+ For the purposes of server authentication, it is RECOMMENDED that
+ implementations support the following mechanism mapping host names to
+ certificates. However, local policy MAY disable the mechanism or MAY
+
+
+
+Igoe & Stebila Standards Track [Page 10]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ impose additional constraints before considering a matching
+ successful. Furthermore, additional mechanisms mapping host names to
+ certificates MAY be used and are left as implementation and
+ configuration issues for implementers and system administrators.
+
+ The RECOMMENDED server authentication mechanism is as follows. The
+ subjectAlternativeName X.509v3 extension, as described in Section
+ 4.2.1.6 of [RFC5280], SHOULD be used to convey the server host name,
+ using either dNSName entries or iPAddress entries to convey domain
+ names or IP addresses as appropriate. Multiple entries MAY be
+ specified. The following rules apply:
+
+ o If the client's reference identifier (e.g., the host name typed by
+ the client) is a DNS domain name, the server's identity SHOULD be
+ checked using the rules specified in [RFC6125]. Support for the
+ DNS-ID identifier type is RECOMMENDED in client and server
+ software implementations. Certification authorities that issue
+ certificates for use by Secure Shell servers SHOULD support the
+ DNS-ID identifier type. Service providers SHOULD include the
+ DNS-ID identifier type in certificate requests. The DNS-ID MAY
+ contain the wildcard character '*' as the complete left-most label
+ within the identifier.
+
+ o If the client's reference identifier is an IP address as defined
+ by [RFC0791] or [RFC2460], the client SHOULD convert that address
+ to the "network byte order" octet string representation and
+ compare it against a subjectAltName entry of type iPAddress. A
+ match occurs if the octet strings are identical for the reference
+ identifier and any presented identifier.
+
+5. Security Considerations
+
+ This document provides new public key algorithms for the Secure Shell
+ protocol that convey public keys using X.509v3 certificates. For the
+ most part, the security considerations involved in using the Secure
+ Shell protocol apply, since all of the public key algorithms
+ introduced in this document are based on existing algorithms in the
+ Secure Shell protocol. However, implementers should be aware of
+ security considerations specific to the use of X.509v3 certificates
+ in a public key infrastructure, including considerations related to
+ expired certificates and certificate revocation lists.
+
+ The reader is directed to the security considerations sections of
+ [RFC5280] for the use of X.509v3 certificates, [RFC2560] for the use
+ of OCSP response, [RFC4253] for server authentication, and [RFC4252]
+ for user authentication. Implementations SHOULD NOT use revoked
+ certificates because many causes of certificate revocation mean that
+ the critical authentication properties needed are no longer true.
+
+
+
+Igoe & Stebila Standards Track [Page 11]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ For example, compromise of a certificate's private key or issuance of
+ a certificate to the wrong party are common reasons to revoke a
+ certificate.
+
+ If a party to the SSH exchange attempts to use a revoked X.509v3
+ certificate, this attempt along with the date, time, certificate
+ identity, and apparent origin IP address of the attempt SHOULD be
+ logged as a security event in the system's audit logs or the system's
+ general event logs. Similarly, if a certificate indicates that OCSP
+ is used and there is no response to the OCSP query, the absence of a
+ response along with the details of the attempted certificate use (as
+ before) SHOULD be logged.
+
+ As with all specifications involving cryptographic algorithms, the
+ quality of security provided by this specification depends on the
+ strength of the cryptographic algorithms in use, the security of the
+ keys, the correctness of the implementation, and the security of the
+ public key infrastructure and the certificate authorities.
+ Accordingly, implementers are encouraged to use high-assurance
+ methods when implementing this specification and other parts of the
+ Secure Shell protocol suite.
+
+6. IANA Considerations
+
+ Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
+ this document makes the following registrations:
+
+ In the Public Key Algorithm Names registry:
+
+ o The SSH public key algorithm "x509v3-ssh-dss".
+
+ o The SSH public key algorithm "x509v3-ssh-rsa".
+
+ o The SSH public key algorithm "x509v3-rsa2048-sha256".
+
+ o The family of SSH public key algorithm names beginning with
+ "x509v3-ecdsa-sha2-" and not containing the at-sign ('@').
+
+ The two object identifiers used in Section 2.2.2 were assigned from
+ an arc delegated by IANA to the PKIX Working Group.
+
+7. References
+
+7.1. Normative References
+
+ [ASN1] International Telecommunications Union, "Abstract
+ Syntax Notation One (ASN.1): Specification of basic
+ notation", X.680, July 2002.
+
+
+
+Igoe & Stebila Standards Track [Page 12]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ [FIPS-180-2] National Institute of Standards and Technology, "Secure
+ Hash Standard", FIPS 180-2, August 2002.
+
+ [FIPS-180-3] National Institute of Standards and Technology, "Secure
+ Hash Standard", FIPS 180-3, October 2008.
+
+ [FIPS-186-3] National Institute of Standards and Technology,
+ "Digital Signature Standard (DSS)", FIPS 186-3,
+ June 2009.
+
+ [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
+ 6 (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
+ C. Adams, "X.509 Internet Public Key Infrastructure
+ Online Certificate Status Protocol - OCSP", RFC 2560,
+ June 1999.
+
+ [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+ Identifiers for the Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 3279, April 2002.
+
+ [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, February 2003.
+
+ [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
+ Protocol Assigned Numbers", RFC 4250, January 2006.
+
+ [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+ Protocol Architecture", RFC 4251, January 2006.
+
+ [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+ Authentication Protocol", RFC 4252, January 2006.
+
+ [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+ Transport Layer Protocol", RFC 4253, January 2006.
+
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 13]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 5280, May 2008.
+
+ [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T.
+ Polk, "Elliptic Curve Cryptography Subject Public Key
+ Information", RFC 5480, March 2009.
+
+ [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
+ Integration in the Secure Shell Transport Layer",
+ RFC 5656, December 2009.
+
+ [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and
+ T. Polk, "Internet X.509 Public Key Infrastructure:
+ Additional Algorithms and Identifiers for DSA and
+ ECDSA", RFC 5758, January 2010.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service
+ Identity within Internet Public Key Infrastructure
+ Using X.509 (PKIX) Certificates in the Context of
+ Transport Layer Security (TLS)", RFC 6125, March 2011.
+
+ [SEC1] Standards for Efficient Cryptography Group, "Elliptic
+ Curve Cryptography", SEC 1, September 2000,
+ <http://www.secg.org/download/aid-780/sec1-v2.pdf>.
+
+7.2. Informative References
+
+ [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell
+ (SSH) Transport Layer Protocol", RFC 4432, March 2006.
+
+ [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V.
+ Welch, "Generic Security Service Application Program
+ Interface (GSS-API) Authentication and Key Exchange for
+ the Secure Shell (SSH) Protocol", RFC 4462, May 2006.
+
+ [RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 5759,
+ January 2010.
+
+ [SP-800-131] Barker, E. and A. Roginsky, "DRAFT Recommendation for
+ the Transitioning of Cryptographic Algorithms and Key
+ Lengths", NIST Special Publication 800-131, June 2010.
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 14]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+Appendix A. Example
+
+ The following example illustrates the use of an X.509v3 certificate
+ for a public key for the Digital Signature Algorithm when used in a
+ Diffie-Hellman key exchange method. In the example, there is a chain
+ of certificates of length 2, and a single OCSP response is provided.
+
+ byte SSH_MSG_KEXDH_REPLY
+ string 0x00 0x00 0xXX 0xXX -- length of the remaining data in
+ this string
+ 0x00 0x00 0x00 0x0D -- length of string "x509v3-ssh-dss"
+ "x509v3-ssh-dss"
+ 0x00 0x00 0x00 0x02 -- there are 2 certificates
+ 0x00 0x00 0xXX 0xXX -- length of sender certificate
+ DER-encoded sender certificate
+ 0x00 0x00 0xXX 0xXX -- length of issuer certificate
+ DER-encoded issuer certificate
+ 0x00 0x00 0x00 0x01 -- there is 1 OCSP response
+ 0x00 0x00 0xXX 0xXX -- length of OCSP response
+ DER-encoded OCSP response
+ mpint f
+ string signature of H
+
+Appendix B. Acknowledgements
+
+ The authors gratefully acknowledge helpful comments from Ran
+ Atkinson, Samuel Edoho-Eket, Joseph Galbraith, Russ Housley, Jeffrey
+ Hutzelman, Jan Pechanec, Peter Saint-Andre, Sean Turner, and Nicolas
+ Williams.
+
+ O. Saarenmaa and J. Galbraith previously drafted a document on a
+ similar topic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 15]
+
+RFC 6187 X.509v3 Certificates for SSH March 2011
+
+
+Authors' Addresses
+
+ Kevin M. Igoe
+ National Security Agency
+ NSA/CSS Commercial Solutions Center
+ United States of America
+
+ EMail: kmigoe@nsa.gov
+
+
+ Douglas Stebila
+ Queensland University of Technology
+ Information Security Institute
+ Level 7, 126 Margaret St
+ Brisbane, Queensland 4000
+ Australia
+
+ EMail: douglas@stebila.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Igoe & Stebila Standards Track [Page 16]
+