From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6187.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc6187.txt (limited to 'doc/rfc/rfc6187.txt') 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, + . + +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] + -- cgit v1.2.3