RFC 6187

X.509v3 Certificates for Secure Shell Authentication

📅 published March 2011, from ietf

RFC 6187: X.509v3 Certificates for Secure Shell Authentication 🔐✨

Authors: K. Igoe (National Security Agency) and D. Stebila (Queensland University of Technology) 💖 Category: Standards Track 🎀 ISSN: 2070-1721 Date: March 2011 📅 Obsoletes/Updates: Nothing. This title block doesn't list any RFCs it obsoletes or updates 🙈

Abstract

okay so X.509 public key certificates use a signature from a trusted certification authority to bind a public key to a digital identity 🪪. this document explains how to use X.509 version 3 certificates with public key algorithms in the Secure Shell protocol 🐚🔥

Status of This Memo ✨

this is an Internet Standards Track document 🌸

it's a product of the Internet Engineering Task Force (IETF) 💅 and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). you can find more on Internet Standards in Section 2 of RFC 5741 📚

info about this doc's current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6187 🦋

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) as in effect on the publication date. please read these carefully, bestie, because they explain your rights and restrictions for this document 📜 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚

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 ✨

okay so there are two Secure Shell (SSH) protocols that use public key cryptography for authentication 🔑 First, the Transport Layer Protocol, described in [RFC4253], says a digital signature algorithm (called the "public key algorithm") MUST be used to authenticate the server to the client 🛡️ Then the User Authentication Protocol described in [RFC4252] lets the client prove itself to the server with a digital signature ("publickey" authentication) 🫶

in both cases, the authentication is only as trustworthy as the link between the public signing key and the signer's identity 🥹 X.509 version 3 (X.509v3) certificates [RFC5280] show up a lot in corporate and government environments for identity management 🏢 They use a chain of signatures from a trusted root certification authority and its intermediate certificate authorities to tie a public signing key to a digital identity 🔗

these public key authentication algorithms are already available for SSH 💅

                   +--------------+-----------+
                   |   Algorithm  | Reference |
                   +--------------+-----------+
                   |    ssh-dss   | [RFC4253] |
                   |              |           |
                   |    ssh-rsa   | [RFC4253] |
                   |              |           |
                   | pgp-sign-dss | [RFC4253] |
                   |              |           |
                   | pgp-sign-rsa | [RFC4253] |
                   |              |           |
                   | ecdsa-sha2-* | [RFC5656] |
                   +--------------+-----------+

Pretty Good Privacy (PGP) has its own way of binding a public key to a digital identity, so this document focuses only on the non-PGP methods 🙌 Specifically, it defines the following public key algorithms, which differ from the ones above only in using X.509v3 certificates to carry the signer's public key 🎀

                     +-----------------------+
                     |       Algorithm       |
                     +-----------------------+
                     |     x509v3-ssh-dss    |
                     |                       |
                     |     x509v3-ssh-rsa    |
                     |                       |
                     | x509v3-rsa2048-sha256 |
                     |                       |
                     |  x509v3-ecdsa-sha2-*  |
                     +-----------------------+

public keys sent with the x509v3-ecdsa-sha2-* public key algorithms can be used with the ecmqv-sha2 key exchange method 🦋

to implement this spec you need to be familiar with the Secure Shell protocol [RFC4251] [RFC4253] and X.509v3 certificates [RFC5280] 🧠 Data types used to describe protocol messages are defined in Section 5 of [RFC4251] 📝

this doc is all about SSH implementation details 🐚 The underlying crypto algorithms and the handling and structure of X.509v3 certificates are covered by other standards documents, especially [RFC3447], [FIPS-186-3], [FIPS-180-2], [FIPS-180-3], [SEC1], and [RFC5280] 📚

an earlier proposal for using X.509v3 certificates in the Secure Shell protocol came from O. Saarenmaa and J. Galbraith 🌷 This document is partly inspired by that earlier proposal, but it doesn't keep strict compatibility with it 🫠

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 doc defines these new public key algorithms for use in the Secure Shell protocol: x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, and the whole family given by x509v3-ecdsa-sha2-* 🌸 In these algorithms, the public key lives inside an X.509v3 certificate 🪪 That certificate, a chain of certificates leading back to a trusted certificate authority, and optional messages giving the revocation status of the certificates all get sent as the public key data in the Secure Shell protocol, following the format in this section 🎁 iykyk, it's giving packaging 📦✨

2.1. Public Key Format 📜✨

Okay bestie, if you want the full X.509 v3 certificate lore, go read [RFC5280]. For this doc you only need the gist 💅: a chain of certificates (it can be just one) lets a trusted root certificate authority and its intermediate certificate authorities cryptographically bind a public key to a digital identity using public key signatures. It's giving trust chain 🔗🫶

For every public key algorithm in this doc, the key format is a sequence of one or more X.509v3 certificates, followed by a sequence of 0 or more Online Certificate Status Protocol (OCSP) responses, as described in Section 4.2 of [RFC2560]. Putting OCSP responses right in this structure can cut down on communication rounds (so the implementation doesn't have to do OCSP checking out-of-band 🙌), and a client outside a private network can get OCSP responses from a server behind a firewall. Iconic. As with any 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 whose status is revoked. Not gonna lie, that's a lowkey big deal 💀

The key format has this 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]. For the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for use with this algorithm, check out 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]. There's an example of an SSH key exchange using one of these public key algorithms in Appendix A, so go look if you want to see it in action 👀

Now the extra constraints, which are super important 🚨

  • 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.
  • Each following certificate MUST certify the one preceding it.
  • 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.
  • 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.
  • 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 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.
  • 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 tied to using certificates (like expiration and revocation of compromised certificates) are handled in [RFC5280] and are outside the scope of this doc. However, compliant implementations MUST comply with [RFC5280]. Implementations providing and processing OCSP responses MUST comply with [RFC2560]. No skipping these, periodt 💅

When no OCSP responses are provided, it's up to the implementation and the system administrator to decide whether or not to accept the certificate. 🤷‍♀️ The implementation might be able to fetch 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 says the certificate authority employs OCSP, and no OCSP response information is available, it is RECOMMENDED that the certificate be rejected. Red flag 🚩

[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] gives extra guidance for ECDSA keys in Suite B X.509v3 certificate and certificate revocation list profiles. 📚✨

2.2. Certificate Extensions 🎀

Certificate extensions let you attach additional attributes to a public key in an X.509v3 certificate (see Section 4.2 of [RFC5280]). The KeyUsage and ExtendedKeyUsage extensions may be used to restrict how X.509v3 certificates get used in the context of the Secure Shell protocol, as laid out in the following sections. Restrictions are giving main character energy 👑

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:

  • 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.
  • 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 says the key can be used for a Secure Shell client, and id-kp-secureShellServer, which says 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:

  • id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
  • id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } -- extended key purpose identifiers
  • id-kp-secureShellClient OBJECT IDENTIFIER ::= { id-kp 21 }
  • id-kp-secureShellServer OBJECT IDENTIFIER ::= { id-kp 22 }

3. Signature Encoding ✍️🌈

Signing and verifying with the X.509v3-based public key algorithms in this doc (x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-ecdsa-sha2-) works the same way as for the matching non-X.509v3-based public key algorithms (ssh-dss, ssh-rsa, ecdsa-sha2-, respectively). The x509v3-rsa2048-sha256 public key algorithm is a new mechanism, similar to ssh-rsa, but it has a different hash function and extra key size constraints. For concreteness, we spell that out explicitly below 💖

3.1. x509v3-ssh-dss 🌸

Signing and verifying with 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 with 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]. 🍓

3.3. x509v3-rsa2048-sha256 🛡️💜

Signing and verifying with 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 in this document, the x509v3-rsa2048-sha256 public key format doesn't correspond to any previously existing SSH non-certificate public key format. The main purpose of introducing it is to provide an RSA-based public key format that is compatible with current recommendations on key size and hash functions. 🙌 For example, the National Institute of Standards and Technology's (NIST's) draft recommendations on cryptographic algorithms and key lengths [SP-800-131] say 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. Meanwhile, an RSA key with modulus at least 2048 bits and SHA-256 is acceptable for the indefinite future. Main character energy, no cap 👑 Introducing other non-certificate-based SSH public key formats that are compatible with the above recommendations is outside the scope of this document.

3.4. x509v3-ecdsa-sha2-* 🦋

okay so signing and verifying with the x509v3-ecdsa-sha2-* key formats is done with ECDSA from [FIPS-186-3], and it uses the SHA2 hash family from [FIPS-180-3] 🔥. which hash you get depends on the key size of your ECDSA key, as spelled out in Section 6.2.1 of [RFC5656]. literally that's the whole vibe ✨

the signature gets encoded like this 💅:

string  "ecdsa-sha2-[identifier]"
string  ecdsa_signature_blob

the [identifier] part is the identifier of the elliptic curve domain parameters. the format of that string is in Section 6.1 of [RFC5656] 🫶

the ecdsa_signature_blob has its own tiny encoding 🍓:

mpint   r
mpint   s

r and s are just the outputs of the ECDSA algorithm, bestie 💜

and yep, this is the same format as the ecdsa-sha2-* signatures in Section 3.1.2 of [RFC5656] 🌸

4. Use in Public Key Algorithms 🎀

okay this part is about where these public key algorithms and encodings actually show up. the public key algorithms and encodings defined in this document SHOULD be accepted anywhere the Secure Shell protocol suite uses public keys 🔑. that includes, but isn't limited to, these protocol messages for server and user authentication:

  • in the SSH_MSG_USERAUTH_REQUEST message when "publickey" authentication is used [RFC4252]
  • in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" authentication is used [RFC4252]
  • in the SSH_MSG_KEXDH_REPLY message [RFC4253]
  • in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]
  • in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]
  • in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]
  • in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]

now the hashing part, which is kind of a big deal 🙈 when a public key from this spec gets fed into a hash algorithm, the exact bytes that went over the wire have to be the ones used as input. implementations MUST NOT omit any of the chain certificates or OCSP responses that were included on the wire, and they can't change the encoding of the certificate or OCSP data either 🚫. otherwise, hashes that both peers are supposed to compute in parallel end up with different values, and that's a whole mess 💀

for user authentication, mapping certificates to user names is left up to implementers and system administrators to figure out 🧚.

for server authentication, it is RECOMMENDED that implementations support the following mechanism for mapping host names to certificates. however, local policy MAY disable the mechanism, and local policy MAY impose additional constraints before a match counts as successful 🛑. furthermore, additional mechanisms for mapping host names to certificates MAY be used, and those are left to implementers and system administrators too ✨.

the RECOMMENDED server authentication mechanism goes like this 👑. the subjectAlternativeName X.509v3 extension, described in Section 4.2.1.6 of [RFC5280], SHOULD be used to carry the server host name. you use dNSName entries or iPAddress entries to carry domain names or IP addresses, whichever fits. multiple entries MAY be specified. the following rules apply:

  • if the client's reference identifier (for example, the host name the client typed in) is a DNS domain name, the server's identity SHOULD be checked using the rules in [RFC6125]. support for the DNS-ID identifier type is RECOMMENDED in client and server software implementations. certification authorities that issue certificates for 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 🌈.
  • 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 happens if the octet strings are identical for the reference identifier and any presented identifier 🎯.

5. Security Considerations 🚨

okay this section is serious, so buckle up 😭. this document provides new public key algorithms for the Secure Shell protocol that carry public keys inside X.509v3 certificates. for the most part, the security considerations for Secure Shell still apply, since every public key algorithm introduced here is built on algorithms that already exist in Secure Shell 🔐. however, implementers need to be aware of security considerations that are specific to using X.509v3 certificates in a public key infrastructure, including things related to expired certificates and certificate revocation lists.

the big one: the reader is pointed to the security considerations sections of [RFC5280] for X.509v3 certificates, [RFC2560] for OCSP responses, [RFC4253] for server authentication, and [RFC4252] for user authentication. implementations SHOULD NOT use revoked certificates, because lots of causes of revocation mean the critical authentication properties needed are no longer true 🙅‍♀️.

for example, a compromised certificate private key or a certificate issued to the wrong party are common reasons to revoke a certificate 💔.

if a party to the SSH exchange tries to use a revoked X.509v3 certificate, that attempt SHOULD be logged as a security event in the system's audit logs or general event logs, along with the date, time, certificate identity, and apparent origin IP address of the attempt 🗂️. likewise, if a certificate says OCSP is used and there's no response to the OCSP query, that absence of a response SHOULD be logged, along with the details of the attempted certificate use (same as before) 📝.

as with all specs involving cryptographic algorithms, the quality of security this spec gives you 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 🧠. so implementers are encouraged to use high-assurance methods when implementing this spec and the rest 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:

  • the SSH public key algorithm "x509v3-ssh-dss".
  • the SSH public key algorithm "x509v3-ssh-rsa".
  • the SSH public key algorithm "x509v3-rsa2048-sha256".
  • 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 came from an arc that IANA delegated 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.

[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.

[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.

Appendix A. Example ✨

okay so this one is my favourite bit 🦋 it's a worked example showing how an X.509v3 certificate can be used for a public key with the Digital Signature Algorithm, when that key is being used in a Diffie-Hellman key exchange method. the vibe is very "let me show you the actual bytes" 💅 and it's giving a chain of certificates of length 2, plus one single OCSP response tucked in there 🫶

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 gave a huge thank you 🙏💖 to Ran Atkinson, Samuel Edoho-Eket, Joseph Galbraith, Russ Housley, Jeffrey Hutzelman, Jan Pechanec, Peter Saint-Andre, Sean Turner, and Nicolas Williams for their helpful comments. the squad is so supportive 🥹

O. Saarenmaa and J. Galbraith had already drafted a document on a similar topic earlier, so shoutout to them too ✨

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

📦 where this page comes from