<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sun-ssh-composite-sigs-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="SSH Composite Signatures">Composite ML-DSA Signatures for SSH</title>
    <seriesInfo name="Internet-Draft" value="draft-sun-ssh-composite-sigs-03"/>
    <author initials="S." surname="Sun" fullname="Sun Shuzhou">
      <organization>Huawei</organization>
      <address>
        <email>sunshuzhou@huawei.com</email>
      </address>
    </author>
    <author initials="L." surname="Prabel" fullname="Lucas Prabel">
      <organization>Huawei</organization>
      <address>
        <email>lucas.prabel@huawei.com</email>
      </address>
    </author>
    <date year="2026" month="July" day="06"/>
    <area>Security</area>
    <workgroup>sshm</workgroup>
    <keyword>ssh</keyword>
    <keyword>Composite Signatures</keyword>
    <keyword>ML-DSA</keyword>
    <abstract>
      <?line 63?>

<t>This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://example.com/LATEST"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-sun-ssh-composite-sigs/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Secure Shell Maintenance (sshm) Working Group mailing list (<eref target="mailto:ssh@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ssh/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ssh/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/USER/REPO"/>.</t>
    </note>
  </front>
  <middle>
    <?line 67?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The development of quantum computers has raised concern towards traditional asymmetric cryptographic algorithms. A Cryptographically Relevant Quantum Computer (CRQC) will break RSA and elliptic curve signature schemes. There is a need to migrate to quantum-resistant signature schemes.</t>
      <t>Recently, NIST published the ML-DSA <xref target="FIPS204"/> algorithm, which is a post-quantum signature scheme. However, when using relatively new cryptographic schemes, the lack of maturing time makes people worry. Many hybrid solutions are thus proposed, which combine a traditional algorithm with a post-quantum algorithm.</t>
      <t><xref target="FIPS204"/> defines both pure ML-DSA and pre-hash ML-DSA. This document only uses pure ML-DSA.</t>
      <t>This document describes how to combine ML-DSA with the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 for authentication in the SSH <xref target="RFC4251"/> protocol.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>This document is consistent with the terminology for hybrid signatures defined in <xref target="I-D.draft-ietf-pquip-pqt-hybrid-terminology"/>.</t>
      <t>The key and signature formats follow the notation introduced in <xref target="RFC4251"/>, Section 3, and the string data type format follows the notation from <xref target="RFC4251"/>, Section 5.</t>
    </section>
    <section anchor="composite-algorithms">
      <name>Composite Algorithms</name>
      <t>A composite algorithm has one post-quantum algorithm, and one traditional algorithm.</t>
      <section anchor="composite-kg">
        <name>Composite Key Generation</name>
        <t>Composite public and private keys are generated by calling the key generation functions of the two component algorithms and concatenating the keys in an order given by the registered composite algorithm.</t>
        <t>For the composite algorithms described in this document, the Key Generation process is as follows:</t>
        <artwork><![CDATA[
1. Generate component keys

    mldsaSeed = Random(32)
    (mldsaPK, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed)
    (tradPK, tradSK) = ECCSigAlg.KeyGen()

2. Check for component key generation failure

    if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK):
        output "Key generation error"

3. Serialize keys into composite form

    Composite Public Key  pk <- SerializePublicKey(mldsaPK, tradPK)
    Composite Private Key sk <- SerializePrivateKey(mldsaSeed, tradSK)

4. Output the composite public and private keys

    return (pk, sk)
]]></artwork>
        <t>This Key Generation algorithm uses the seed-based ML-DSA.KeyGen_internal defined in Algorithm 6 of <xref target="FIPS204"/>.</t>
        <t>It also makes use of the serialization routines from <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>, adapted to use raw fixed-length encodings for the classical components, to obtain the byte string encodings of the composite public and private keys.</t>
        <t>ECCSigAlg is an elliptic curve signature scheme, i.e., ECDSA, Ed25519 or Ed448.</t>
      </section>
      <section anchor="composite-sign">
        <name>Composite Sign</name>
        <t>A composite signature's value <bcp14>MUST</bcp14> include two signature components and <bcp14>MUST</bcp14> be in the same order as the components from the corresponding signing key.</t>
        <t>For the composite algorithms described in this document, the signature process of a message M follows Section 4.2 of <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>, with an empty application context string:</t>
        <artwork><![CDATA[
1. Compute the Message representative M'

  M' <- Prefix || Label || 0x00 || PH(M)

2. Get the component keys

  (mldsaSeed, tradSK) = DeserializePrivateKey(sk)
  (_, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed)

3. Generate the two component signatures

  sig_1 <- ML-DSA.Sign(mldsaSK, M', ctx=Label)
  sig_2 <- ECCSigAlg.Sign(tradSK, M')

4. If either ML-DSA.Sign() or ECCSigAlg.Sign() return an error, then this process MUST return an error.

    if NOT sig_1 or NOT sig_2:
      output "Signature generation error"

5. Output the encoded composite signature value.

    CompositeSignature <- SerializeSignatureValue(sig_1, sig_2)
    return CompositeSignature
]]></artwork>
        <t>It makes use of the serialization routines from <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>, adapted to use raw fixed-length encodings for the classical component, to obtain the byte string encodings of the composite signature.</t>
        <t>The prefix "Prefix" string is defined as in <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> as the byte encoding of the string "CompositeAlgorithmSignatures2025", which in hex is 436F6D706F73697465416C676F726974686D5369676E61747572657332303235. It can be used by a traditional verifier to detect if the composite signature has been stripped apart.</t>
        <t>The label "Label" is defined in the same way as <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> and is passed as a context argument into the underlying ML-DSA component algorithm. The label values, specific to each composite algorithm, can be found in <xref target="tab-sig-alg-label"/>.</t>
        <table anchor="tab-sig-alg-label">
          <name>Composite Label Values</name>
          <thead>
            <tr>
              <th align="left">Key Format identifier</th>
              <th align="left">Label (in ASCII)</th>
              <th align="left">Label (in Hex encoding)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ssh-mldsa44-es256</td>
              <td align="left">COMPSIG-MLDSA44-ECDSA-P256-SHA256</td>
              <td align="left">434F4D505349472D4D4C44534134342D45434453412D503235362D534841323536</td>
            </tr>
            <tr>
              <td align="left">ssh-mldsa65-es256</td>
              <td align="left">COMPSIG-MLDSA65-ECDSA-P256-SHA512</td>
              <td align="left">434F4D505349472D4D4C44534136352D45434453412D503235362D534841353132</td>
            </tr>
            <tr>
              <td align="left">ssh-mldsa87-es384</td>
              <td align="left">COMPSIG-MLDSA87-ECDSA-P384-SHA512</td>
              <td align="left">434F4D505349472D4D4C44534138372D45434453412D503338342D534841353132</td>
            </tr>
            <tr>
              <td align="left">ssh-mldsa44-ed25519</td>
              <td align="left">COMPSIG-MLDSA44-Ed25519-SHA512</td>
              <td align="left">434F4D505349472D4D4C44534134342D456432353531392D534841353132</td>
            </tr>
            <tr>
              <td align="left">ssh-mldsa65-ed25519</td>
              <td align="left">COMPSIG-MLDSA65-Ed25519-SHA512</td>
              <td align="left">434F4D505349472D4D4C44534136352D456432353531392D534841353132</td>
            </tr>
            <tr>
              <td align="left">ssh-mldsa87-ed448</td>
              <td align="left">COMPSIG-MLDSA87-Ed448-SHAKE256</td>
              <td align="left">434F4D505349472D4D4C44534138372D45643434382D5348414B45323536</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="composite-verify">
        <name>Composite Verify</name>
        <t>The Verify algorithm <bcp14>MUST</bcp14> validate a signature only if all component signatures are successfully validated.</t>
        <artwork><![CDATA[
1. Get the component keys and signatures

    (mldsaPK, tradPK) <- DeserializePublicKey(pk)
    (sig_1, sig_2) <- DeserializeSignatureValue(sig)

2. Compute the message representative M'

    M' <- Prefix || Label || 0x00 || PH(M)

3. Check each component signature individually, according to its algorithm specification.

    if NOT ML-DSA.Verify(mldsaPK, M', ctx=Label)
        output "Invalid signature"
    if NOT ECCSigAlg.Verify(tradPK, M')
        output "Invalid signature"
    if all succeeded, then
        output "Valid signature"
]]></artwork>
        <t>It makes use of the serialization routines from <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/> to obtain the component public keys and the component signatures.</t>
      </section>
    </section>
    <section anchor="pk-algos">
      <name>Public Key Algorithm</name>
      <t>This section gives the concrete composite signature algorithms and their component algorithms. Their usage within SSH follows Section 6.6 of <xref target="RFC4253"/>.</t>
      <t>The following table defines a list of algorithms associated with specific PQ/T combinations.</t>
      <table anchor="tab-ssh-algs">
        <name>Composite ML-DSA Signature Algorithms for SSH</name>
        <thead>
          <tr>
            <th align="left">Key Format Identifier</th>
            <th align="left">First Algorithm</th>
            <th align="left">Second Algorithm</th>
            <th align="left">Pre-Hash</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">ssh-mldsa44-es256</td>
            <td align="left">ML-DSA-44</td>
            <td align="left">ecdsa-with-SHA256 with secp256r1</td>
            <td align="left">SHA256</td>
            <td align="left">Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA-256</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa65-es256</td>
            <td align="left">ML-DSA-65</td>
            <td align="left">ecdsa-with-SHA256 with secp256r1</td>
            <td align="left">SHA512</td>
            <td align="left">Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA-256</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa87-es384</td>
            <td align="left">ML-DSA-87</td>
            <td align="left">ecdsa-with-SHA384 with secp384r1</td>
            <td align="left">SHA512</td>
            <td align="left">Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA-384</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa44-ed25519</td>
            <td align="left">ML-DSA-44</td>
            <td align="left">Ed25519</td>
            <td align="left">SHA512</td>
            <td align="left">Composite Signature with ML-DSA-44 and Ed25519</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa65-ed25519</td>
            <td align="left">ML-DSA-65</td>
            <td align="left">Ed25519</td>
            <td align="left">SHA512</td>
            <td align="left">Composite Signature with ML-DSA-65 and Ed25519</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa87-ed448</td>
            <td align="left">ML-DSA-87</td>
            <td align="left">Ed448</td>
            <td align="left">SHAKE256</td>
            <td align="left">Composite Signature with ML-DSA-87 and Ed448</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="public-key-format">
      <name>Public Key Format</name>
      <t>The key format for all parameter sets defined in this document follows the encoding pattern from <xref target="RFC4253"/>, Section 6.6.</t>
      <t><strong>string</strong> identifier</t>
      <t><strong>string</strong> key</t>
      <t>The 'identifier' is the key format identifier given in <xref target="tab-ssh-algs"/>.</t>
      <t>The 'key' is the composite public key generated as defined in <xref target="composite-kg"/>. It is the concatenation of the public keys of the component schemes.</t>
      <t>For ML-DSA, the public keys are defined in <xref target="FIPS204"/>.</t>
      <t>For ECDSA with curves secp256r1 or secp384r1, the public keys are defined in <xref target="RFC5656"/>, Section 3.1. The public key is encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of <xref target="SEC1"/>; point compression <bcp14>MAY</bcp14> be used.</t>
      <t>For Ed25519 and Ed448, the public keys are defined in <xref target="RFC8709"/>, Section 6.</t>
      <t>The "ssh-mldsa44-es256" key format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa44-es256</t>
      <t><strong>string</strong> key</t>
      <t>Here, 'key' is the concatenation of the 1312-octet ML-DSA-44 public key and the ECDSA public key using the secp256r1 curve.</t>
      <t>The "ssh-mldsa65-es256" key format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa65-es256</t>
      <t><strong>string</strong> key</t>
      <t>Here, 'key' is the concatenation of the 1952-octet ML-DSA-65 public key and the ECDSA public key using the secp256r1 curve.</t>
      <t>The "ssh-mldsa87-es384" key format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa87-es384</t>
      <t><strong>string</strong> key</t>
      <t>Here, 'key' is the concatenation of the 2592-octet ML-DSA-87 public key and the ECDSA public key using the secp384r1 curve.</t>
      <t>The "ssh-mldsa44-ed25519" key format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa44-ed25519</t>
      <t><strong>string</strong> key</t>
      <t>Here, 'key' is the concatenation of the 1312-octet ML-DSA-44 public key and the 32-octet Ed25519 public key.</t>
      <t>The "ssh-mldsa65-ed25519" key format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa65-ed25519</t>
      <t><strong>string</strong> key</t>
      <t>Here, 'key' is the concatenation of the 1952-octet ML-DSA-65 public key and the 32-octet Ed25519 public key.</t>
      <t>The "ssh-mldsa87-ed448" key format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa87-ed448</t>
      <t><strong>string</strong> key</t>
      <t>Here, 'key' is the concatenation of the 2592-octet ML-DSA-87 public key and the 57-octet Ed448 public key.</t>
    </section>
    <section anchor="signature-format">
      <name>Signature Format</name>
      <t>The signature format for all parameter sets defined in this document follows the encoding pattern defined in Section 6.6 of <xref target="RFC4253"/>.</t>
      <t><strong>string</strong> identifier</t>
      <t><strong>string</strong> signature</t>
      <t>The 'identifier' is the key format identifier given in <xref target="pk-algos"/>.</t>
      <t>The 'signature' is the composite signature generated as defined in <xref target="composite-sign"/>. It is the concatenation of the signatures of the component schemes.</t>
      <t>For ML-DSA, the signatures are defined in <xref target="FIPS204"/>.</t>
      <t>For ECDSA with curves secp256r1 and secp384r1, the signatures and their encodings are defined in <xref target="RFC5656"/>, Section 3.1.2.</t>
      <t>For Ed25519 and Ed448, the signature are defined in <xref target="RFC8709"/>, Section 6.</t>
      <t>The "ssh-mldsa44-es256" signature format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa44-es256</t>
      <t><strong>string</strong> signature</t>
      <t>Here, 'signature' is the concatenation of the 2420-octet ML-DSA-44 signature and the ECDSA signature using the secp256r1 curve.</t>
      <t>The "ssh-mldsa65-es256" signature format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa65-es256</t>
      <t><strong>string</strong> signature</t>
      <t>Here, 'signature' is the concatenation of the 3309-octet ML-DSA-65 signature and the ECDSA signature using the secp256r1 curve.</t>
      <t>The "ssh-mldsa87-es384" signature format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa87-es384</t>
      <t><strong>string</strong> signature</t>
      <t>Here, 'signature' is the concatenation of the 4627-octet ML-DSA-87 signature and the ECDSA signature using the secp384r1 curve.</t>
      <t>The "ssh-mldsa44-ed25519" signature format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa44-ed25519</t>
      <t><strong>string</strong> signature</t>
      <t>Here, 'signature' is the concatenation of the 2420-octet ML-DSA-44 signature and the 64-octet Ed25519 signature.</t>
      <t>The "ssh-mldsa65-ed25519" signature format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa65-ed25519</t>
      <t><strong>string</strong> signature</t>
      <t>Here, 'signature' is the concatenation of the 3309-octet ML-DSA-65 signature and the 64-octet Ed25519 signature.</t>
      <t>The "ssh-mldsa87-ed448" signature format has the following encoding:</t>
      <t><strong>string</strong> ssh-mldsa87-ed448</t>
      <t><strong>string</strong> signature</t>
      <t>Here, 'signature' is the concatenation of the 4627-octet ML-DSA-87 signature and the 114-octet Ed448 signature.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The Security Considerations section of <xref target="RFC4251"/> also applies to this document.</t>
      <t>The user can refer to <xref target="FIPS204"/> for security issues related to the ML-DSA post-quantum component of the composite algorithm and to the Security Considerations sections of <xref target="RFC5656"/> and <xref target="RFC8709"/> for the traditional component.</t>
      <t>For the specific security issues raising from the use of a hybrid composite signature scheme, the user can refer to <xref target="I-D.draft-ietf-pquip-hybrid-signature-spectrums"/>.</t>
      <t>For more information about hybrid composite signature schemes and the different hybrid combinations that appear in this document, the user can read <xref target="I-D.draft-ietf-lamps-pq-composite-sigs"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to add the following entries to "Public Key Algorithm Names" in the "Secure Shell (SSH) Protocol Parameters" registry <xref target="IANA.SSH"/>:</t>
      <table anchor="tab-pub-key-algo-name">
        <name>SSH Public Key Code Points</name>
        <thead>
          <tr>
            <th align="left">Public Key Algorithm Name</th>
            <th align="left">Key Format</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">ssh-mldsa44-es256</td>
            <td align="left">ssh-mldsa44-es256</td>
            <td align="left">THIS-RFC</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa65-es256</td>
            <td align="left">ssh-mldsa65-es256</td>
            <td align="left">THIS-RFC</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa87-es384</td>
            <td align="left">ssh-mldsa87-es384</td>
            <td align="left">THIS-RFC</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa44-ed25519</td>
            <td align="left">ssh-mldsa44-ed25519</td>
            <td align="left">THIS-RFC</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa65-ed25519</td>
            <td align="left">ssh-mldsa65-ed25519</td>
            <td align="left">THIS-RFC</td>
          </tr>
          <tr>
            <td align="left">ssh-mldsa87-ed448</td>
            <td align="left">ssh-mldsa87-ed448</td>
            <td align="left">THIS-RFC</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC4251">
          <front>
            <title>The Secure Shell (SSH) Protocol Architecture</title>
            <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
            <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4251"/>
          <seriesInfo name="DOI" value="10.17487/RFC4251"/>
        </reference>
        <reference anchor="RFC5656">
          <front>
            <title>Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer</title>
            <author fullname="D. Stebila" initials="D." surname="Stebila"/>
            <author fullname="J. Green" initials="J." surname="Green"/>
            <date month="December" year="2009"/>
            <abstract>
              <t>This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5656"/>
          <seriesInfo name="DOI" value="10.17487/RFC5656"/>
        </reference>
        <reference anchor="RFC4253">
          <front>
            <title>The Secure Shell (SSH) Transport Layer Protocol</title>
            <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
            <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</t>
              <t>This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.</t>
              <t>Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.</t>
              <t>This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4253"/>
          <seriesInfo name="DOI" value="10.17487/RFC4253"/>
        </reference>
        <reference anchor="RFC8709">
          <front>
            <title>Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol</title>
            <author fullname="B. Harris" initials="B." surname="Harris"/>
            <author fullname="L. Velvindron" initials="L." surname="Velvindron"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8709"/>
          <seriesInfo name="DOI" value="10.17487/RFC8709"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.draft-ietf-lamps-pq-composite-sigs">
          <front>
            <title>Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure</title>
            <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
              <organization>Entrust Limited</organization>
            </author>
            <author fullname="John Gray" initials="J." surname="Gray">
              <organization>Entrust Limited</organization>
            </author>
            <author fullname="Massimiliano Pala" initials="M." surname="Pala">
              <organization>OpenCA Labs</organization>
            </author>
            <author fullname="Jan Klaußner" initials="J." surname="Klaußner">
              <organization>Bundesdruckerei GmbH</organization>
            </author>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <date day="21" month="April" year="2026"/>
            <abstract>
              <t>   This document defines combinations of US NIST Module-Lattice-Based
   Digital Signature Algorithm (ML-DSA) in hybrid with traditional
   algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448.
   These combinations are tailored to meet regulatory guidelines in
   certain regions.  Composite ML-DSA is applicable in applications that
   use X.509 or PKIX data structures that accept ML-DSA, but where the
   operator wants extra protection against breaks or catastrophic bugs
   in ML-DSA, and where existential unforgeability (EUF-CMA) level
   security is acceptable.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-19"/>
        </reference>
        <reference anchor="IANA.SSH" target="https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml">
          <front>
            <title>Secure Shell (SSH) Protocol Parameters</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="I-D.draft-ietf-pquip-pqt-hybrid-terminology">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="Flo D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Michael P" initials="M." surname="P">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <author fullname="Britta Hale" initials="B." surname="Hale">
              <organization>Naval Postgraduate School</organization>
            </author>
            <date day="10" month="January" year="2025"/>
            <abstract>
              <t>   One aspect of the transition to post-quantum algorithms in
   cryptographic protocols is the development of hybrid schemes that
   incorporate both post-quantum and traditional asymmetric algorithms.
   This document defines terminology for such schemes.  It is intended
   to be used as a reference and, hopefully, to ensure consistency and
   clarity across different protocols, standards, and organisations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-06"/>
        </reference>
        <reference anchor="I-D.draft-ietf-pquip-hybrid-signature-spectrums">
          <front>
            <title>Hybrid signature spectrums</title>
            <author fullname="Nina Bindel" initials="N." surname="Bindel">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Britta Hale" initials="B." surname="Hale">
              <organization>Naval Postgraduate School</organization>
            </author>
            <author fullname="Deirdre Connolly" initials="D." surname="Connolly">
              <organization>SandboxAQ</organization>
            </author>
            <author fullname="Flo D" initials="F." surname="D">
              <organization>UK National Cyber Security Centre</organization>
            </author>
            <date day="20" month="June" year="2025"/>
            <abstract>
              <t>   This document describes classification of design goals and security
   considerations for hybrid digital signature schemes, including proof
   composability, non-separability of the component signatures given a
   hybrid signature, backwards/forwards compatibility, hybrid
   generality, and simultaneous verification.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-hybrid-signature-spectrums-07"/>
        </reference>
        <reference anchor="FIPS204" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf">
          <front>
            <title>Module-Lattice-Based Digital Signature Standard</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2024" month="August"/>
          </front>
        </reference>
        <reference anchor="SEC1" target="http://www.secg.org/download/aid-780/sec1-v2.pdf">
          <front>
            <title>Elliptic Curve Cryptography</title>
            <author>
              <organization>Standards for Efficient Cryptography Group</organization>
            </author>
            <date year="2009" month="May"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81b+1LjRrr/X0/R6/ljIIUMvgI+ye4SYwZqYCCY5NTU1lZK
ltq2CllS1BKMA+RZ9lnOk53f1926iwEGpmpJZWz15evvfmvZNE0jdmOPj1hr
HKzCQLgxZ2en5uH0gE3dhW/FScQFmwcRm06PW4Y1m0X8BqvxxPId+dKWYVsx
XwTResRE7BiGE9i+tcIBTmTNY1MkvinE0rTTvaZwF8Lc6Rkima1cIdzAj9ch
1p9Mro4MP1nNeDQyHAAdGXbgC+6LRIxYHCXcACI9w4q4NWJTbieRG6+N2yC6
XkRBEuJ8sVwZ13yNIWdkMJMG6KMJbxpXdBs33E9wGGMajASNtUvueezMcv2Y
+5Zvc7ZBB2xioUL4f3Gy6y/YB9qG0ZXleiOW/mHtP10ez9tBtMCkFdnLEVvG
cShG29u0lEbcG95OF23TwPYsCm4F38bubcLIjZfJbMR+nU4uty8nF+cY88Aa
Eeew+BdrFXq8DQ5vnx5cTaZXhpXEyyCSLGCuD+5N22ya+AbhNU88TwkIIyAy
+XMZJHIGOFi++6cVQyQjdpxYt9yVE1xRBlEKtfyfSzlJR+ZnnLbZRWTNuFc5
5jSxLVGceuocjza0Q7mheJLhB9EKu25IWJdH43530FHfBsPBMBvrqW97uzv7
I8Nw/Xlh14l52FZ6SVw3PXBOmOEfFe0csfH52cX59ORqYp4enF1MsfHg00Eb
NjCSiKYmVNKUDUxvgs4gDuzAYxdWBPJjHsFE5B4rWvCC2G5vb9uu5VtK9LCD
hb/ifixI9GaYba48tr8s45VXIyT8I3FD/Buby/Usch0Ta1euH3jBAnZ5/Pnn
y5ND82pyeXby6fz0/MPnRwDozSK1ElOE3IblrUQGZHoxGRsGOzq5mHZ3+mV2
nAVO4nHz1Ipj1+bmz5bgDjt0ocSWl5sem8aW71iRo/giLZ0dJItExKy70+3L
0UyDmdYYgP8kNQagTnyBIxPYczDPoAmGT3bF7aUim218OplebTYz37/xwmQm
2r4r4vYiuNmmLzSyTYRt0842fWuDxnbozEHxdDLulMmdeJ4bglI2TqIbzsbR
OoyDRWSFy3WRtDNrDbp29h+lK6eA3O5kPndtF5pQAqicTJ0YrUiC2wupSE5w
63uB5WxbkOPu3s42ZjrmTVcRYZoms2Yijiw7NoyrpSsY3HVCesccLuzIncH5
x0vOEiGZe/HL9hXLjIOJcoSghQ0mEGoTaLMrLGjcnR7m0PTM9bMYZKnjsSM2
/0gsP05WDNofS+HSDE+ZbkumZzCZsJd8BdCTMeBssYnTHQw6+3LfxOn391LQ
IN5xtSIR5LZiy8p1HI8bxjtoVxxBkW1aQ0ziwPaGe0Eo2QSmpHgRZQkZJVsC
dmS5QtKDSBH5LA5upUiLx1livYIZR4R9Lls8WR4CKFz9SrTZQVHurm153ppd
co/f4FD2iz56rI9mG+PLX8ab7NYF9xGprWt2SVwE0U8xSkoHj9ABi/kcqMcB
uIBjISp81VSaEBdsgw6vgzCMS26DK956i5HNMJiQ54olV7LSMr27097i4SGn
dIvdgrqlOr4k7uoxbXYc3EICEW3hPlSTgm7EPenUwR2f31b4qfHbklh4ln1N
YlsRUNoauyuOp2soS8gDhE6GhCFat2Gp/popH8hE4CUkNqAHTBCFBek1EOVO
inqqulZZyCmFEEq8rBKXzYJ3Rb44fA5Qgs0C7AmJ+NQgIMoQnhgqttRjJLmi
5QY+mACDFcWN7cftexnckoArliexfZ2FkU8gB4fjoLjED2QGyksge7y70zEb
5GYuggxuHPg3tEUyG8AOiReSnULZH1I6EhGsqXX26/SqtaU+2adz+f1y8suv
J5eTQ/o+PT44Pc2+GHrF9Pj819PD/Fu+E4H+bPLpUG3GKCsNGa2zg8+YIaxa
5xdXJ+efDk5biqgib6WKBGwGa0KyGEFeMUzAEkbu57Dn5/HF//2n0wcj/gZO
dDudfXBCPex1dkkLSL/VaVKm6hH8WxtWGHIrIihwCMy2QoqpUHA4HgF5+oxs
Gdz84V/EmX+P2I8zO+z0/64HiODSYMqz0qDkWX2ktlkxsWGo4ZiMm6XxCqfL
+B58Lj2nfC8M/vgPjzTX7Oz94+9GVdHxneoGOC16ytS6kBFJRU3tvBiUyAal
qO7uzHrS9PDQzvWRhJSbhsoxKSp6HlkXFvlBnJqAiicp5MwKtih4yiW9rSy+
ITiTj0LqYMkyQ4PWkEUZ9DwKVs0QB9qy0th7kEUY46AQknNnRSEs8Pkj3ipV
St7s6uiw4mkfwaAP3OeRQvPuXZ5fXy8eDCNfKQOGrb2ce0OxB9xVTnehIIBv
szWjQCidt+b/Igc/T3xbeQ94eSnq20DR6EvjzEiXx1CAtqiiiwvghLQsHwmZ
g6C6QFzx6VCajfiCVClSuUqVb6D8SGdCDbPFRKfqNFRwqnAKftHmQsiomGqT
QBXz119/GZ12upIXqCPkDZkWrjxHWFMK5D+xS1AarDZ63U05tSHnLj5u6UUf
N7FGxwlgALC/S8cFoW5kYPRWEjjtpE+1cTIeI5mHRum9G5uG0W2z8ZIj0JJp
lbArSQr1HcxF4evOyV004QYQcqZydJo1I29OkKzHrPWxDJ5HURC1DKOHapdH
ruW5f2bSjYOCgMimFBK5Jl4oTSSQLLxmP5o5DDWFmRxXhdpmFYZWYQIiKjDU
VAaEOJxRZhj9NjtXRJVV6RH7UMgjzCRINTfC6y0ctym1RDnDilrlZi7TBOln
cL45kxVasyIU3WHmPdiQbKyQuED/T8jERKAzKl04qCMU7QoH1C+xTHG00zIr
NTZ5L8uxwlhlogQnsm7Z3P0CRD3uL+DHuW8HDsw2Lz9sj0pnOIdc6SjtC1gw
iy2dfMzWceZXcwgaySdZDQozhZd26T+VIW0xt83bW9U8iWo7SpOqzpIK45KL
JHhwkgdNpdN7wW4sL0HWRlHd9W0vcZTDy7HIOSGJkStlaqKkYiH7VX5OV0SF
9VI2aixCSMQwMUvCpk/w47UOL0cz9XUQhMWQVwprAbKyQJdGsn67q3SuSWFU
ig2JrMIYMTkMvTTxhJuP+ZdYyz13obpyUvWJPjTiyNgEUJQVBTt7T+Z19p7s
9yKCFXxh9/fslNpR9GXny84OfV4cb5wpz/eBx2VGZjbaYOtwoIdcNLgFsmDs
+P2FTpq8XRYX6tEvz28IHzz93iG6NFzSPQ0MTu3s/Raz4y8/SVI39fIuLc9d
vtyhSKENynWdzBmHJKBSRbjSkVd2bqZOy9LuWmqF1pRUI6TGVta1S0FD0aHj
hMQya6no0JC3mxoCxKDkbaVPKIX3XEmlsbUrsSKHXfTw2ehvtGdDorilkNss
uus6GOW44Uf/W1zoN3rQjG06Tw6V8bSUEbVSCG6ealtCZ9s1SlLnJI9Oz8zY
ogDlVxhZgMob/N2d7qCVdRmoQPpCJ/d7w6Ph4e7O8Gi3N9zf7Q8H/c5wPNzF
c1c+7w0PB5jByGSIqmx3gPHBbq/X7e3gf2gO5GRDK2eySSZz03ID4AYym7uw
BfDQQSFox6S1j3BK5t0zDgsgmlDkgSe6K3UlexfkdFrSIFtFxhWd+a21Jm41
cxEBgCwLIlbstjLPaEULXTBRciSbfj6igrcm1uqmQEMWrbp6CjFpHYi31CYG
zTaRzC3VGqmGhq2Ua/Mg8XUpFFszinYmFpkSokwo7mX6cqTqHteh1oDkZ+qD
NygjmY5PTjZLQ8cQcKoomAEYM/9j1aevTn7lCWCpIy99Zr9vQs8GQ9j2vbwy
mJ58MM9OwTjMyOhvXmDaRBVNq+6hfP2j/uFgZ9Dr7/d3u4f9w/6438dTp4cp
PA/wIZ+7WEXq1hviW6+/hxXyqYzAcPAYApgpIzDodL+OwLA3eAKBQQ9IlBHY
2wUCvb1+HQHMaAQw/SwE9nq7NQR6GO1/DQESgc6vGkSgZtLTJZJPi2DYl3TT
YfuVo9VfTQTNCJAIXoaAFsHLECARyO5bowhoho7/OFFq8iwRAAH6by89vP8z
ppX6pQjcjdi7mvWqm5GfCjfLyjplQBSth0ri+xs5yrVydOp7oVCROQD8i0uX
KPBauceUrTF4VNkIa8hzZO9AJDalEnQLuc7AOO1CJd2UspW7OrrKqhV9FPWL
KVxWHYbXumYuxf7K8nqaoMvnQmK6+lpi+vzUtJcW5blPLvMKXthxb1wnoVsG
5A420n4ZZ+HHXSofMnGkHl4mIuVcTKd8SoI5s2rJZDk/O/GlVHJcWkWYedao
waatAMo4nw+KVERqAndkBo5Ms7b7t+reN0vGKklUzn9daWYaV57N9a/NqIlX
aEzkdfjdu/CaDC8QD7rkF7peouZVWtf5NnWiG/OOSlcM692osWkm4z3mEqmR
VHCBHurnVwu1YVs3B/Q1fNYuVQulWlkzj2d3HRbzXCFv1IrICBHYruz6yeIu
Sy3Sq8iZ60sBiGqmcFLMFI7cCKBzft0TmqhmS0OwIPOY7lXuyUBRtoaSkDfL
HBpzhXttMGa/T96Y25g0idQ0TVBkczvEQ9QhzNP0oeE9FrU6hygvYyju6muy
C5O2qj4FzQGWHHkkjciQGw6ejZsK7E/hBoDfhFueYWS47e3WcKMFGW54eBlu
AFjHjUCWcaORx5KPkljvs57PC5BIhZfufCTJqIjoGw5KJdF0UJ5MlLmt7vfk
ISqTeD5T1c48YcBRMHdRzxWqb6EV7iyy99EeKg5RmX5+K5NdlkTS92fvzUAv
4krxVLwyKl6uZLVmaMXUbSlfsvSKlyzweHTl9oMqR3/4oVCslIaBmULxfb7g
PZVlcRntQq2jriDyIklzLfOp77EtA1HrYRba7qrqK11tlS5jHmRB6+YRQ9+N
gDwd9orRqljyq2CVvQlAXUElwq3aNsrISigU+8dHskuUXUFLmxMFJxNEuVU/
A7R+Hax0vdbuqKq1wB5QnPZ9pIDrbd0wcNPimG6G7Jin3cQKR9Njuu1eu6dC
IL0s9PDwPxoGsQvhnF51ZGcHn9PWQUp79R79eUTS+21lZVSa0aqFnFZRx5a6
r5IH5VThRyWdrUGpa/Qxj/hWVRMbFKjT63RNxb/c1xVEkaZASgkKE8oVq9Qr
1QYpm7ZRpTUNYa+jNYXyClr3BxVa4W7fmNY0JL6O1hTKt9PaHexXaIXPfzmt
Klw/QmseYl+vxQrO99fjXroqtex8TbPivgWBOZzvr7wvIjBNKV6vrQTl+2vr
YDcjjjKXEmnvCtlJMfWovgjytglIQ6hprLWeTkQyPF+RjmR1Z5aK5JeT9YRE
VK9hvpqPyJvPpzOSQq/nBQlJpUP0zfmI7BGVE5Ii6KyYzi9KnpujdL+eERSK
91fmAzV9fZusoKBe2iqbVKPJNvvdnZpnLZBbCiT5+DflB6+nvTFL+Gbae72d
/ZrTfVPa83zh9bQ3Zg3fTHt/2N2t+eSX0v7s/OFttL4hyH5vvR/2K/G2eNH6
lXzibVT9LQl+prK/hOA8v3gb7a5lGd9buzudfinjKNH6LvuhG70mLRCS1asM
+s3oRyazZnAhR+jIt+9FoN6SoRZxUE5CdLxAZRrJq9qIz9UldvE99bmqxtWh
rhAJAMlX8dUrB/KtGtXHKb1Imsfn2ksD+R2DZIiC8QRdIiNMhVG5tRAFs3cb
ivfyGQ6FV5iy7nKNJsuVTiZ7IUrfA1jpe8NNKU76+lf8CBvNwm+oslRjFch7
GP0rNXpZbxYk8dPH5FcHjjvHEcTcfFPWJccKWEL++njDK1kFVC2n8SZDpr70
E7iaEspBl3TgD7BNa4HlODW7gzUpnWs13md8QposWulrDc/9YZ1+OTdaA+v0
F3oPDyO6GHj0FFa6NLhnl1wyz+ZPvjLwnN5+09jV8cnUhG4+0nRvHmvelHXD
m8eaN5XuyJtHH0exvrE0+jiaumPcNFbYlLaFUWaZKD1kaWHS70bT/jDdNBVk
OQ4czi6oqybvk0kUM8u+Nv4fe7mpNtk8AAA=

-->

</rfc>
