Internet-Draft SSH Certificate Format March 2025
Miller Expires 20 September 2025 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-miller-ssh-cert-00
Published:
Intended Status:
Informational
Expires:
Author:
D. Miller
OpenSSH

SSH Certificate Format

Abstract

This document presents a simple certificate format that may be used in the context of the Secure Shell (SSH) protocol for user and host authentication.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 September 2025.

▲

Table of Contents

1. Introduction

Secure Shell (SSH) is a protocol for secure remote connections and login over untrusted networks. SSH uses public key signatures for host authentication and commonly uses them for user authentication. This document describes a lightweight certificate format for use in these contexts. It may be used for server authentication as part of key exchange (Section 7 of [RFC4253]) and for user public key authentication (Section 7 of [RFC4252]).

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Certificate Format

All values in a certificate are encoded using the SSH wire representations specified by [RFC4251].

2.1. Public certificate format

2.1.1. General structure and common fields

Certificates have the following general structure:

    string              key type
    string              nonce
    byte[]              public key fields
    uint64              serial number
    uint32              certificate role
    string              identifier
    string              principals
    uint64              valid after
    uint64              valid before
    string              critical options
    string              extensions
    string              reserved
    string              signature key
    string              signature

The "key type" string identifies the certificate type, e.g. "ssh-ed25519-cert" identifies an ED25519 certificate. The valid certificate types are listed below.

The "nonce" field contains a random nonce. This value MUST be at least 16 bytes in length. 32 bytes is typical.

The "public key fields" section contains the actual public key material. These are specified below for each certificate type.

The "certificate role" field indicates the role of the certificate, either SSH2_CERT_TYPE_USER for user authentication certificates or SSH2_CERT_TYPE_HOST authentication certificates.

The "identifier" field contains a UTF-8 encoded, human-readable identifier for the certificate, suitable for display to the user, recording in logs, etc.

The "principals" field contains one or more UTF-8 encoded names, separated by commas. These names identify the principals the certificate is intended to authenticate. In the case of user certificates, these will typically be user names, whereas for host certificates they will be host names and/or numerical addresses.

The "valid after" and "valid before" field represent a validity interval for the certificate with each field being interpreted as a number of seconds since the Unix epoch (00:00:00 UTC on 1 January 1970) except for two special values. A zero value in the "valid after" field indicates that the certificate is valid from any time to the "valid after" date. A all-1s (i.e. 0xFFFFFFFFFFFFFFFF) value in the "valid after" field indicates that the certificate has no end expiry date.

The "critical options" field contains zero or more of the certificate options described in Section 2.4 and encoded as described in Section 2.2. If an implementation does not recognise or support a particular option contained in a certificate, then it MUST refuse to accept the certificate for authentication.

The "extensions" field similarly contains zero or more of the certificate extensions described in Section 2.3 and encoded as described in Section 2.2. An implementation that does not recognise or support an extension present in a certificate extension section MUST ignore the extension.

The "reserved" field is reserved for future use. Implementations MUST ignore the contents of this field if it is not empty.

The "signature key" field contains the CA key used to sign the certificate, encoded as a SSH public key blob. Implementations MUST NOT accept certificate keys as CA keys.

The "signature" field contains a signature, made using the CA signature key over the entire certificate excluding the "signature" field itself (i.e. everything from the "key type" up to and including the "signature key"). The signature is encoded using the standard SSH signature encoding for the CA key type in question, e.g. Section 3.1.2 of [RFC5656] for ECDSA CA keys.

2.1.2. DSA certificates

DSA certificates have key type "ssh-dss-cert" and certify DSA keys as defined in Section 6.6 of [RFC4253]. This format is equivalent to the vendor extension "ssh-dss-cert-v01@openssh.com".

    string              "ssh-dss-cert"
    string              nonce
    mpint               p
    mpint               q
    mpint               g
    mpint               y
    byte[]              public key fields
    uint64              serial number
    uint32              certificate role
    string              identifier
    string              principals
    uint64              valid after
    uint64              valid before
    string              critical options
    string              extensions
    string              reserved
    string              signature key
    string              signature

The "p", "q", "g" values are the DSA domain parameters. "y" is the public key value. These values are as defined by Section 4.1 of [FIPS.186-4].

2.1.3. ECDSA certificates

ECDSA certificates are represented by the key types "ecdsa-sha2-nistp256-cert", "ecdsa-sha2-nistp384-cert" and "ecdsa-sha2-nistp521-cert". They respectively certify "ecdsa-sha2-nistp256", "ecdsa-sha2-nistp384" and "ecdsa-sha2-nistp521" respectively, as defined by Section 3.1 of [RFC5656]. This format is equivalent to the vendor extensions "ecdsa-sha2-nistp256-cert-v01@openssh.com", "ecdsa-sha2-nistp384-cert-v01@openssh.com" and "ecdsa-sha2-nistp521-cert-v01@openssh.com".

    string              "ecdsa-sha2-nistp256-cert" |
                        "ecdsa-sha2-nistp384-cert" |
                        "ecdsa-sha2-nistp521-cert"
    string              nonce
    string              ecdsa_curve_name
    string              Q
    byte[]              public key fields
    uint64              serial number
    uint32              certificate role
    string              identifier
    string              principals
    uint64              valid after
    uint64              valid before
    string              critical options
    string              extensions
    string              reserved
    string              signature key
    string              signature

The value "Q" is the ECDSA public value as defined by Section 6.2 of [FIPS.186-5].

2.1.4. EDDSA certificates

EDDSA certificates have key type "ssh-ed25519-cert" or "ssh-ed448-cert" and certify Ed25519 and Ed448 keys (respectively) as defined by [RFC8709]. This format is equivalent to the vendor extension "ssh-ed25519-cert-v01@openssh.com".

    string              "ssh-ed25519-cert" | "ssh-ed448-cert"
    string              nonce
    string              ENC(A)
    byte[]              public key fields
    uint64              serial number
    uint32              certificate role
    string              identifier
    string              principals
    uint64              valid after
    uint64              valid before
    string              critical options
    string              extensions
    string              reserved
    string              signature key
    string              signature

The value ENC(A) is the EDDSA public key, the contents and interpretation of which are defined by Section 3.2 of [RFC8032].

2.1.5. RSA certificates

RSA certificates have type "ssh-rsa-cert". These certify RSA, as defined in Section 6.6 of [RFC4253]. This format is equivalent to the vendor extension "ssh-rsa-cert-v01@openssh.com".

    string              "ssh-rsa-cert"
    string              nonce
    mpint               e
    mpint               n
    byte[]              public key fields
    uint64              serial number
    uint32              certificate role
    string              identifier
    string              principals
    uint64              valid after
    uint64              valid before
    string              critical options
    string              extensions
    string              reserved
    string              signature key
    string              signature

"n" is the public composite modulus and "e" is the public exponent. These values are defined by Section 5.1 of [FIPS.186-4].

2.1.6. Other certificate formats

SSH clients and server clients MAY support additional key types not documented here. Vendor-specific key types should use the domain-qualified naming convention defined in Section 4.2 of [RFC4251].

2.2. Option / extension encoding

The "critical options" and "extensions" certificate sections use the same format for encoding, though they differ in how unsupported options are handled.

Both sections consist of zero or more key/value pairs, encoded as a pair of strings:

    string              key
    string              value

"key" should be a UTF-8 encoded string that identifies the option being encoded. Available keys for extensions and for critical options sections are listed below, but implementations may add their own options using the domain-qualified naming convention defined in Section 4.2 of [RFC4251].

The contents and format of "value" are specific to each option or extension. Key/value pairs MUST be ordered lexically by key name.

A common patten for flag-type options is for the value to be the empty string. For example, this is a complete extensions section that encodes a single flag value "permit-user-rc".

  00000016                           # Extensions section len=22
    0000000e                         # 1st key string len=14
      7065726d69742d757365722d7263   #   "permit-user-rc"
    00000000                         # 1st value string len=0

For options whose values encode textual values, it is common for the value to contain a nested string. For example, the following is a complete criticial options section that sets a string-values option "force-command" to the value "sftp".

  0000001d                           # Criticial options len=29
    0000000d                         # 1st key string len=13
      666f7263652d636f6d6d616e64     #   "force-command"
    00000008                         # 1st value string len=8
      00000004                       #   value body string len=4
        73667470                     #     "sftp"

Finally, the following is an example of a critical options section that contains a flag option "foo@example.com" and a string-valued option "force-command" with a the value "sftp".

  00000038                           # Criticial options len=56
    0000000f                         # 1st key string len=15
      666f6f406578616d706c652e636f6d #   "foo@example.com"
    00000000                         # 1st value string len=0
    0000000d                         # 2nd key string len=13
      666f7263652d636f6d6d616e64     #   "force-command"
    00000008                         # 2nd value string len=8
      00000004                       #   value body string len=4
        73667470                     #     "sftp"

2.3. Certificate extensions

Certificate extensions are encoded using the rules in Section 2.2. When an implementation encounters an extension it does not recognise or support, it MUST ignore it and continue processing the certificate without error.

There are no defined certificate extensions for host certificates.

The initially defined certificate extensions for user certificates are:

no-touch-required

Valid for key types that support user-presence assertions in their signatures (such as FIDO-backed keys). This option indicates that signatures made with this certificate that do not assert user-presence should be accepted, reversing the default behaviour of refusing such signatures. Note that no such key types are currently standardised, but some SSH implementation support them as vendor extensions.

This is a flag-type option. Its value is the empty string.

permit-agent-forwarding

Indicates that sessions authenticated with this certificate may request authentication agent forwarding [I-D.ietf-sshm-ssh-agent]. Certificates that lack this extension MUST not permit this protocol feature be enabled on SSH server implementations that support it.

This is a flag-type option. Its value is the empty string.

permit-port-forwarding

Indicates that sessions authenticated with this certificate may request authentication TCP forwarding using the "tcpip-forward" and/or "direct-tcpip" SSH channel requests defined in Section 7 of [RFC4254]. Certificates that lack this extension MUST not permit these protocol features be enabled on SSH server implementations that support them.

This is a flag-type option. Its value is the empty string.

permit-pty

Indicates that sessions authenticated with this certificate may request pseudo-terminal allocation using the "pty-req" SSH channel request defined in Section 6.2 of [RFC4254]. Certificates that lack this extension MUST not permit this protocol feature be enabled on SSH server implementations that support it.

This is a flag-type option. Its value is the empty string.

permit-user-rc

Indicates that sessions authenticated with this certificate may execute optional SSH-specific user initialisation scripts (e.g. "~/.ssh/rc"). Certificates that lack this extension MUST not process these scripts on SSH server implementations that support them.

This is a flag-type option. Its value is the empty string.

permit-X11-forwarding

Indicates that sessions authenticated with this certificate may request X11 protocol forwarding using the "x11-req" SSH channel request defined in Section 6.3 of [RFC4254]. Certificates that lack this extension MUST not permit this protocol feature be enabled on SSH server implementations that support it.

This is a flag-type option. Its value is the empty string.

SSH implementations may define additional vendor extensions using the domain-qualified naming convention defined in Section 4.2 of [RFC4251].

2.4. Critical options

Certificate critical options are encoded using the rules in Section 2.2. When an implementation encounters an option it does not recognise or support, it MUST refuse to accept the certificate for authorisation decisions.

There are no defined critical options for host certificates.

The initially defined critical options for user certificates are:

force-command

Forces the execution of the specified command for any session (Section 6.5 of [RFC4254]) of type "exec" or "shell" and overrides the subsystem name for sessions of type "subsystem".

This is a string-type option. Its value contains a nested string which holds the command string.

source-address

Provides an allow-list of source addresses from which the certificate is valid. The address list consists of zero or more CIDR ranges (e.g. "192.0.2.0/29") or wildcard addresses (e.g. "192.0.2.*") separated by commas. If this option is present, servers MUST refuse connections from sources that are not listed.

This is a string-type option. Its value contains a nested string which holds the allow-list.

verify-required

Valid for key types that support user verification assertions in their signatures (such as FIDO-backed keys). This option indicates that signatures made with this certificate that must require this assertion to be present in the signature and that servers MUST refuse authentication if it is absent. Note that no such key types are currently standardised, but some SSH implementation support them as vendor extensions.

This is a flag-type option. Its value is the empty string.

SSH implementations may define additional vendor extensions using the domain-qualified naming convention defined in Section 4.2 of [RFC4251].

2.5. Private certificate format

For cases where a certificate and its associated private key must be serialised, such as adding one to a SSH authentication agent [I-D.ietf-sshm-ssh-agent], the following format is used;

    string              key type
    string              certificate blob
    byte[]              private key fields

Where "key type" is the type of the certificate being encoded (e.g. "ssh-rsa-cert"), "certificate blob" is the entire encoded certificate as described in Section 2.1 and "private key fields" contain the encoded private key values as described in the following sections.

2.5.1. DSA certificates

DSA certificates with private keys use the following encoding format.

    string              "ssh-dss-cert"
    string              certificate blob
    byte[]              private key fields
    mpint               x

The "y" parameters is defined as per Section 4.1 of [FIPS.186-4].

2.5.2. ECDSA certificates

ECDSA certificates with private keys use the following encoding format.

    string              "ecdsa-sha2-nistp256-cert" |
                        "ecdsa-sha2-nistp384-cert" |
                        "ecdsa-sha2-nistp521-cert"
    string              certificate blob
    byte[]              private key fields
    mpint               d

The "d" value is defined by Section 6.2 of [FIPS.186-5].

2.5.3. EDDSA certificates

EDDSA certificates with private keys use the following encoding format.

    string              "ssh-ed25519-cert" | "ssh-ed448-cert"
    string              certificate blob
    byte[]              private key fields
    string              k || ENC(A)

The encoded value is a concatenation of the private key k and the public ENC(A) key. The contents and interpretation of the ENC(A) and k values are defined by Section 3.2 of [RFC8032].

2.5.4. RSA certificates

EDDSA certificates with private keys use the following encoding format.

    string              "ssh-dss-cert"
    string              certificate blob
    byte[]              private key fields
    mpint               d
    mpint               iqmp
    mpint               p
    mpint               q

"p" and "q" are its constituent private prime factors. "iqmp" is the inverse of "q" modulo "p". All these values except "iqmp" (which can be calculated from the others) are defined by Section 5.1 of [FIPS.186-4].

3. Using certificates

Certificates may be appear and be used any place in the SSH protocol where plain keys are used. In particular, they may be used for server authentication or for user public-key authentication. For each of these cases, the certificate, encoded as per Section 2.1 appears in place of the encoded key.

3.1. Accepting certificates

Implementations that accept a certificate MUST verify the CA signature over the certificate contents prior to making any authentication or authorisation decisions. Implementations MAY elect to verify the certificate signature as soon as the certificate is received.

When making authentication or authorisation decisions with a certificate, implementations:

3.2. Certificate signatures

When signatures are required, they are made and formatted using the same rules for the underlying plain key type. For example, a "ssh-rsa-cert" could produce signatures of types "ssh-rsa" using the rules from Section 6.6 of [RFC4253], or "rsa-sha2-256" or "rsa-sha2-512" using the rules from Section 3 of [RFC8332].

3.3. Use in host authentication

Certificate host keys may be used for server authentication as part of the initial key exchange or for subsequent re-exchange. To use a certificate host key, its key type name (e.g. "ssh-ed25519-cert") must appear in the server_host_key_algorithms of the SSH_MSG_KEXINIT (Section 7.1 of [RFC5656]). If negotiated by both the server and the client, then a certificate of the agreed type may take the place of the plain host key in the final reply message. For example in ECDH host authentication (Section 4 of [RFC5656]), host authentication occurs in the final SSH_MSG_KEX_ECDH_REPLY message:

    byte                SSH_MSG_KEX_ECDH_REPLY
    string              K_S, server's certificate
    string              Q_S, server's ephemeral ECDH public key
    string              the signature on the exchange hash

Certificates used for host authentication MUST have "certificate role" of SSH2_CERT_TYPE_HOST. Other certificate types MUST not be accepted.

Certificate host keys list hostnames and/or IP addresses for the host in their "principals" section. Clients MUST match the hostname or address thay are using for the host against the principals in this list and refuse to authorise the certificate if it is absent.

Clients that accept certified host keys MAY downgrade the certificate to a plain public key and process it accordingly, if they are unable to verify the certificate. This allows recovery from the situation where the endpoints negotiate use of a cerificate host key but the client is not able to authorise the certificate contents, perhaps because the CA is not trusted or because the host name the client is using does not match any in the certificate.

3.4. Use in user authentication

For user public key authentication No prior negotiation is needed to send a user authentication attempt that contains a certificate, though clients may wish to filter the ones they send against the server's list of accepted publickey authentication signature algorithms if one was provided via the [RFC8308]SSH_MSG_EXT_INFO mechanism.

Certificates used for user authentication MUST have "certificate role" of SSH2_CERT_TYPE_USER. Other certificate types MUST not be accepted.

Certificate keys for user authentication list one or more user principal names in their "principals" section. Interpretation and authorisation of principal names for a given target user name is fully determined by the server. In the trivial case, a certificate may list user names directly and the server merely matches the user name in the SSH_MSG_USERAUTH_REQUEST (Section 7 of [RFC4252]) to one of the principals in the certificate.

To make a user authentication attempt using a certificate host key, the certificate takes the place of the plain public key in a SSH_MSG_USERAUTH_REQUEST message. For example:

    byte                SSH_MSG_USERAUTH_REQUEST
    string              user name
    string              service name
    string              "publickey"
    boolean             TRUE
    string              certificate key algorithm name
    string              encoded certificate
    string              signature

4. Protocol numbers

4.1. Certificate types

The following numbers are used for certificate types:

    SSH2_CERT_TYPE_USER                1
    SSH2_CERT_TYPE_HOST                2

5. IANA Considerations

This format requires creation of one new registry and additions to an existing registry.

5.1. Additions to SSH key type registry

IANA is requested to insert the following entries into the table Public Key Algorithm Names [IANA-SSH-KEYTYPES] under Secure Shell (SSH) Protocol Parameters [RFC4250].

Table 1
Key type name Reference
ssh-dss-cert Section 2.1.2
ecdsa-sha2-nistp256-cert Section 2.1.3
ecdsa-sha2-nistp384-cert Section 2.1.3
ecdsa-sha2-nistp521-cert Section 2.1.3
ssh-ed25519-cert Section 2.1.4
ssh-ed448-cert Section 2.1.4
ssh-rsa-cert Section 2.1.5

5.2. New registry: Certificate Extension Identifiers

This registry, titled "Certificate Extension Identifiers" records identifiers for certificate extensions. Its initial state should consist of the following names. Future name allocations shall occur via EXPERT REVIEW as per [RFC8126].

Table 2
Extension name Reference
no-touch-required Section 2.3
permit-agent-forwarding Section 2.3
permit-port-forwarding Section 2.3
permit-pty Section 2.3
permit-user-rc Section 2.3
permit-X11-forwarding Section 2.3

5.3. New registry: Certificate Criticial Option Identifiers

This registry, titled "Certificate Critical Option Identifiers" records identifiers for certificate criticial options. Its initial state should consist of the following names. Future names allocations shall occur via EXPERT REVIEW as per [RFC8126].

Table 3
Option name Reference
force-command Section 2.4
source-address Section 2.4
verify-required Section 2.4

5.4. New registry: Certificate Type Numbers

This registry, titled "Certificate Type Numbers" records the numbers used to indicate the types of certificates. Its initial state should consist of the following numbers. Future message number allocations shall occur via EXPERT REVIEW as per [RFC8126].

Table 4
Number Identifier Reference
1 SSH2_CERT_TYPE_USER Section 4.1
2 SSH2_CERT_TYPE_HOST Section 4.1

6. Security Considerations

XXX TODO XXX

7. Implementation Status

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

The following example projects maintain implementations of SSH certificates. All have implemented them in the vendor extension namespace, e.g. "ssh-rsa-cert-v01@openssh.com".

OpenSSH

OpenSSH is the originating implementation of this protocol and has supported it since 2010.

Website: https://www.openssh.com/

libssh

libssh has supported this format since 2011.

Website: https://www.libssh.org/

Golang x/crypto/ssh

The Go programming language project has supported an implementation of this format in its external "x" repository since 2012.

Website: https://pkg.go.dev/golang.org/x/crypto/ssh

Net::SSH

The Net::SSH library has supported this format since 2014.

Website: https://net-ssh.github.io/net-ssh/

AsyncSSH

The AsyncSSH library has supported this format since 2015.

Website: https://github.com/ronf/asyncssh

Paramiko

The Paramiko library has supported this format since 2017

Website: https://www.paramiko.org/

Apache MINA SSHD

The Apache MINA SSHD server library has supported this format since 2020.

Website: https://mina.apache.org/sshd-project/

PuTTY

The PuTTY SSH client has supported this format since 2022.

Website: https://www.chiark.greenend.org.uk/~sgtatham/putty/

russh

The russh library has supported this format since 2024.

Website: https://github.com/Eugeny/russh

Additionally, Google's HIBA system [HIBA] builds on top of the OpenSSH certificate format to perform centralised authorisation for pool of target hosts.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4250]
Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, , <https://www.rfc-editor.org/info/rfc4250>.
[RFC4251]
Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, , <https://www.rfc-editor.org/info/rfc4251>.
[RFC4252]
Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, , <https://www.rfc-editor.org/info/rfc4252>.
[RFC4253]
Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, , <https://www.rfc-editor.org/info/rfc4253>.
[RFC4254]
Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, , <https://www.rfc-editor.org/info/rfc4254>.
[RFC5656]
Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, , <https://www.rfc-editor.org/info/rfc5656>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/info/rfc8032>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8332]
Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol", RFC 8332, DOI 10.17487/RFC8332, , <https://www.rfc-editor.org/info/rfc8332>.
[RFC8308]
Bider, D., "Extension Negotiation in the Secure Shell (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, , <https://www.rfc-editor.org/info/rfc8308>.
[RFC8709]
Harris, B. and L. Velvindron, "Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol", RFC 8709, DOI 10.17487/RFC8709, , <https://www.rfc-editor.org/info/rfc8709>.
[I-D.ietf-sshm-ssh-agent]
Miller, D., "SSH Agent Protocol", Work in Progress, Internet-Draft, draft-ietf-sshm-ssh-agent-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-sshm-ssh-agent-02>.
[FIPS.186-4]
National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, , <https://doi.org/10.6028/NIST.FIPS.186-4>.
[FIPS.186-5]
National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-5, DOI 10.6028/NIST.FIPS.186-5, , <https://doi.org/10.6028/NIST.FIPS.186-5>.

8.2. Informative References

[IANA-SSH-KEYTYPES]
IANA, "Public Key Algorithm Names", <https://www.iana.org/assignments/ssh-parameters/>.
[HIBA]
Google, "HIBA: Host Identity Based Authorization", <https://github.com/google/hiba>.

Acknowledgements

XXX YOUR NAME HERE XXX

Author's Address

Damien Miller
OpenSSH
URI: https://www.openssh.com/