<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-lamps-cms-sphincs-plus-19" number="9814" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2025-07-18T23:11:50" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-sphincs-plus-19" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9814" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SLH-DSA Signature Algorithm in CMS">Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)</title>
    <seriesInfo name="RFC" value="9814" stream="IETF"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security" showOnFrontPage="true">Vigil Security, LLC</organization>
      <address>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization showOnFrontPage="true">Amazon Web Services</organization>
      <address>
        <email>kpanos@amazon.com</email>
      </address>
    </author>
    <author initials="B." surname="Westerbaan" fullname="Bas Westerbaan">
      <organization showOnFrontPage="true">Cloudflare</organization>
      <address>
        <email>bas@westerbaan.name</email>
      </address>
    </author>
    <date month="07" year="2025"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">SLH-DSA is a stateless hash-based signature algorithm.  This document
specifies the conventions for using the SLH-DSA signature algorithm
with the Cryptographic Message Syntax (CMS).  In addition, the
algorithm identifier and public key syntax are provided.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9814" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1">ASN.1</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-motivation">Motivation</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-slh-dsa-hash-based-signatur">SLH-DSA Hash-Based Signature Algorithm Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-slh-dsa-public-key-identifi">SLH-DSA Public Key Identifier</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signed-data-conventions">Signed-Data Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1-module">ASN.1 Module</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document specifies the conventions for using the SLH-DSA hash-based
signature algorithm <xref target="FIPS205" format="default" sectionFormat="of" derivedContent="FIPS205"/> with the Cryptographic Message
Syntax (CMS) <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> signed-data content type.</t>
      <t indent="0" pn="section-1-2">SLH-DSA offers two signature modes: pure mode and pre-hash mode.  SLH-DSA
signature operations include a context string as input.  The context string
has a maximum length of 255 bytes.  By default, the context string is the
empty string.  This document only specifies the use of pure mode with an empty
context string for the CMS signed-data content type.</t>
      <t indent="0" pn="section-1-3">SLH-DSA offers three security levels.  The parameters for each of the
security levels were chosen to provide 128 bits of security, 192 bits of
security, and 256 bits of security.  Separate algorithm identifiers have
been assigned for SLH-DSA at each of these security levels.</t>
      <t indent="0" pn="section-1-4">SLH-DSA is a stateless hash-based signature algorithm.  Other hash-based
signature algorithms are stateful, including Hierarchical Signature System (HSS) / Leighton-Micali Signatures (LMS) <xref target="RFC8554" format="default" sectionFormat="of" derivedContent="RFC8554"/> and
eXtended Merkle Signature Scheme (XMSS) <xref target="RFC8391" format="default" sectionFormat="of" derivedContent="RFC8391"/>.  Without the need for state kept by the signer,
SLH-DSA is much less fragile than the stateful hash-based signature algorithms.</t>
      <section anchor="asn1" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-asn1">ASN.1</name>
        <t indent="0" pn="section-1.1-1">CMS values are generated with ASN.1 <xref target="X680" format="default" sectionFormat="of" derivedContent="X680"/> using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules
(DER) <xref target="X690" format="default" sectionFormat="of" derivedContent="X690"/>.</t>
      </section>
      <section anchor="motivation" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-motivation">Motivation</name>
        <t indent="0" pn="section-1.2-1">There have been recent advances in cryptanalysis and advances in the
development of quantum computers.  Each of these advances pose a
threat to widely deployed digital signature algorithms.</t>
        <t indent="0" pn="section-1.2-2">If Cryptographically Relevant Quantum Computers (CRQCs) are ever built, they
will be able to break many of the public key cryptosystems currently in use,
including RSA, DSA, Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (EdDSA).  A Post-Quantum Cryptosystem (PQC) is
secure against quantum computers that have more than a trivial number of quantum
bits (qu-bits).  It is open to conjecture when it will be feasible to build
such quantum computers; however, it is prudent to use cryptographic
algorithms that remain secure if a CRQC is invented.  SLH-DSA is a PQC
signature algorithm.</t>
      </section>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.3">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.3-1">
    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" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="slh-dsa-hash-based-signature-algorithm-overview" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-slh-dsa-hash-based-signatur">SLH-DSA Hash-Based Signature Algorithm Overview</name>
      <t indent="0" pn="section-2-1">SLH-DSA is a stateless hash-based signature algorithm.  SLH-DSA makes use of a few-time signature construction (Forest of Random Subsets (FORS))
and a hypertree.  FORS signs a message with a private key. The
corresponding FORS public keys are the leaves in k binary trees.
The roots of these trees are hashed together to form a FORS root.
SLH-DSA uses a one-time signature scheme called Winternitz One-Time Signature Plus (WOTS+).  The FORS
tree roots are signed by a WOTS+ private
key. The corresponding WOTS+ public keys form the leaves in d-layers
of Merkle subtrees in the SLH-DSA hypertree. The bottom layer of
that hypertree signs the FORS roots with WOTS+.  The roots of the
bottom Merkle subtrees are then signed with WOTS+ and the
corresponding WOTS+ public keys form the leaves of the next-level-up
subtree. Subtree roots are consequently signed by their corresponding
subtree layers until the top subtree is reached. The top-layer subtree
forms the hypertree root, which is trusted at the verifier.</t>
      <t indent="0" pn="section-2-2">An SLH-DSA signature consists of the randomization string, the FORS signature,
the WOTS+ signature in each layer, and the path to the root of each subtree
      until the root of the hypertree is reached.</t>
      <t indent="0" pn="section-2-3">An SLH-DSA signature is verified using the FORS signature, the
WOTS+ signatures, and the path to the root of each subtree. When reaching
the root of the hypertree, the signature verifies only if it hashes to
the pre-trusted root of the SLH-DSA hypertree.</t>
      <t indent="0" pn="section-2-4">SLH-DSA is a stateless hash-based signature algorithm. Stateful
hash-based signature schemes require that the WOTS+ private key
(generated by using a state index) never be reused or the scheme
loses its security.  FORS is used at the bottom of the SLH-DSA hypertree.  Security decreases 
if the same private key is used to sign two or more different messages, but
security does not collapse, as is the case in stateful hash-based signature
algorithms.  Without the need for
state kept by the signer to ensure it is not reused, SLH-DSA is much
      less fragile.</t>
      <t indent="0" pn="section-2-5">SLH-DSA was designed to sign up to 2<sup>64</sup> messages and offers three
security levels.  The parameters of the SLH-DSA hypertree include the
security parameter, the hash function, the tree height, the number of
layers of subtrees, the Winternitz parameter of WOTS+, and the number of FORS
trees and leaves in each.  The parameters for each of the security levels
were chosen to be at least as secure as a generic block cipher of 128, 192,
or 256 bits.</t>
    </section>
    <section anchor="slh-dsa-public-key-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-slh-dsa-public-key-identifi">SLH-DSA Public Key Identifier</name>
      <t indent="0" pn="section-3-1">The AlgorithmIdentifier for an SLH-DSA public key <bcp14>MUST</bcp14> use one of the
twelve id-slh-dsa object identifiers listed below, based on the
security level used to generate the SLH-DSA hypertree, the small or fast
version of the algorithm, and the use of SHA2 <xref target="FIPS180" format="default" sectionFormat="of" derivedContent="FIPS180"/> or
SHAKE <xref target="FIPS202" format="default" sectionFormat="of" derivedContent="FIPS202"/>.  For example, id-slh-dsa-shake-256s
represents the 256-bit security level, the small version of the
algorithm, and the use of SHAKE256.  The parameters field of the
AlgorithmIdentifier for the SLH-DSA public key <bcp14>MUST</bcp14> be absent.</t>
      <artwork align="left" pn="section-3-2">
   nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 
     country(16) us(840) organization(1) gov(101) csor(3) 4 }

   sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }

   id-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }

   id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }

   id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 }

   id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 }

   id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 }

   id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 }

   id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 }

   id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 }

   id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 }

   id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 }

   id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 }

   id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }
</artwork>
      <t indent="0" pn="section-3-3">When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of
an X.509 certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, the certificate key usage extension <bcp14>MAY</bcp14>
contain digitalSignature, nonRepudiation, keyCertSign, and cRLSign; the
certificate key usage extension <bcp14>MUST NOT</bcp14> contain other values.</t>
      <artwork align="left" pn="section-3-4">
   pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-sha2-128s
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-sha2-128f PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-sha2-128f
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-sha2-192s PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-sha2-192s
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-sha2-192f PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-sha2-192f
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-sha2-256s PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-sha2-256s
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-sha2-256f PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-sha2-256f
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-shake-128s PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-shake-128s
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-shake-128f PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-shake-128f
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-shake-192s PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-shake-192s
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-shake-192f PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-shake-192f
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-shake-256s PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-shake-256s
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-slh-dsa-shake-256f PUBLIC-KEY ::= {
       IDENTIFIER id-slh-dsa-shake-256f
       -- KEY no ASN.1 wrapping --
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       -- PRIVATE-KEY no ASN.1 wrapping -- }

   SLH-DSA-PublicKey ::= OCTET STRING (SIZE (32 | 48 | 64))
 
   SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))
</artwork>
      <t indent="0" pn="section-3-5">No additional encoding of the SLH-DSA public key is applied in the
SubjectPublicKeyInfo field of an X.509 certificate <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <t indent="0" pn="section-3-6">No additional encoding of the SLH-DSA private key is applied in the
PrivateKeyInfo field of the privateKey field of the OneAsymmetricKey
type of an Asymmetric Key Package <xref target="RFC5958" format="default" sectionFormat="of" derivedContent="RFC5958"/>.</t>
      <t indent="0" pn="section-3-7">When an SLH-DSA public key appears outside of a SubjectPublicKeyInfo type
in an environment that uses ASN.1 encoding, the SLH-DSA public key
can be encoded as an OCTET STRING by using the SLH-DSA-PublicKey type.</t>
      <t indent="0" pn="section-3-8">When an SLH-DSA private key appears outside of an Asymmetric Key Package
in an environment that uses ASN.1 encoding, the SLH-DSA private key
can be encoded as an OCTET STRING by using the SLH-DSA-PrivateKey type.</t>
    </section>
    <section anchor="signed-data-conventions" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-signed-data-conventions">Signed-Data Conventions</name>
      <t indent="0" pn="section-4-1">As specified in CMS <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, the digital signature is produced from
the message digest and the signer's private key. The signature is computed
over different values depending on whether signed attributes are absent or
present.</t>
      <t indent="0" pn="section-4-2">When signed attributes are absent, the SLH-DSA (pure mode) signature is computed over
the content.  When signed attributes are present, a hash <bcp14>SHOULD</bcp14> be computed over
the DER-encoded signed attributes using the same hash function that is used in the SLH-DSA tree.  The
signed attributes <bcp14>MUST</bcp14> include a content-type attribute and a message-digest
attribute.  The message-digest attribute contains the hash value of the
content.  The SLH-DSA signature is computed over the DER encoding of the set
of signed attributes.  The SLH-DSA signature-generation operation is called
slh_sign; see Section 10.2.1 of <xref target="FIPS205" format="default" sectionFormat="of" derivedContent="FIPS205"/>.  In summary:</t>
      <artwork align="left" pn="section-4-3">
   IF (signed attributes are absent)
   THEN slh_sign(content)
   ELSE signed attributes message-digest attribute = Hash(content);
        slh_sign(DER(SignedAttributes))
</artwork>
      <t indent="0" pn="section-4-4">In some implementations, performance may be significantly improved by
signing and verifying DER(SignedAttributes) when the content is large. That
is, passing an entire large message content to the signing function or the
signature validation function can have an impact on performance. When the
signed attributes are present, <xref section="5.3" sectionFormat="of" target="RFC5652" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-5.3" derivedContent="RFC5652"/> requires the
inclusion of the content-type attribute and the message-digest attribute. Other
attributes can also be included.</t>
      <t indent="0" pn="section-4-5">When using SLH-DSA and signed attributes are present in the SignerInfo, the
digestAlgorithms field in the SignedData <bcp14>MUST</bcp14> include the identifier for the
one-way hash function used to compute the message digest.</t>
      <t indent="0" pn="section-4-6">When using SLH-DSA, the fields in the SignerInfo are used as follows:</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-4-7">
        <dt pn="section-4-7.1">digestAlgorithm:</dt>
        <dd pn="section-4-7.2">
          <t indent="0" pn="section-4-7.2.1">The digestAlgorithm <bcp14>MUST</bcp14> identify a one-way hash function.  When signed
attributes are absent, the digestAlgorithm identifier <bcp14>SHOULD</bcp14> match the hash
function used in the SLH-DSA tree (as shown in the list below).  The digestAlgorithm does not have any significance when signed
attributes are absent as it is not used to pre-hash the message.  When there is a concern for failures with legacy implementations that
     do not support all hash functions, signers <bcp14>MAY</bcp14> choose to always use the
      SHA-256 algorithm identifier as the digestAlgorithm when signed
      attributes are absent. When signed attributes are present, to ensure collision resistance, the identified hash
function <bcp14>MUST</bcp14> produce a hash value that is at least twice the size of the
hash function used in the SLH-DSA tree.  The hash functions defined in
<xref target="FIPS180" format="default" sectionFormat="of" derivedContent="FIPS180"/> and <xref target="FIPS202" format="default" sectionFormat="of" derivedContent="FIPS202"/> <bcp14>MUST</bcp14> be supported for use with the variants of SLH-DSA as shown below:</t>
          <artwork align="left" pn="section-4-7.2.2">
      id-slh-dsa-sha2-128s:  SHA-256
      id-slh-dsa-sha2-128f:  SHA-256
      id-slh-dsa-sha2-192s:  SHA-512
      id-slh-dsa-sha2-192f:  SHA-512
      id-slh-dsa-sha2-256s:  SHA-512
      id-slh-dsa-sha2-256f:  SHA-512
      id-slh-dsa-shake-128s: SHAKE128 with 256-bit output
      id-slh-dsa-shake-128f: SHAKE128 with 256-bit output
      id-slh-dsa-shake-192s: SHAKE256 with 512-bit output
      id-slh-dsa-shake-192f: SHAKE256 with 512-bit output
      id-slh-dsa-shake-256s: SHAKE256 with 512-bit output
      id-slh-dsa-shake-256f: SHAKE256 with 512-bit output
</artwork>
          <t indent="0" pn="section-4-7.2.3"> The object identifiers for SHA-256 and SHA-512 are included
      in <xref target="RFC5754" format="default" sectionFormat="of" derivedContent="RFC5754"/>.  The object identifiers for SHAKE128 and
      SHAKE256 are included in <xref target="RFC8702" format="default" sectionFormat="of" derivedContent="RFC8702"/>.  In all four cases, the
      AlgorithmIdentifier <bcp14>SHOULD NOT</bcp14> include parameters.</t>
        </dd>
        <dt pn="section-4-7.3">signatureAlgorithm:</dt>
        <dd pn="section-4-7.4">
          <t indent="0" pn="section-4-7.4.1">The signatureAlgorithm <bcp14>MUST</bcp14> contain one of the SLH-DSA algorithm
identifiers, and the algorithm parameters field <bcp14>MUST</bcp14> be absent.  The
algorithm identifier <bcp14>MUST</bcp14> be one of the following:</t>
          <artwork align="left" pn="section-4-7.4.2">
      id-slh-dsa-sha2-128s,  id-slh-dsa-sha2-128f,
      id-slh-dsa-sha2-192s,  id-slh-dsa-sha2-192f,
      id-slh-dsa-sha2-256s,  id-slh-dsa-sha2-256f,
      id-slh-dsa-shake-128s, id-slh-dsa-shake-128f,
      id-slh-dsa-shake-192s, id-slh-dsa-shake-192f,
      id-slh-dsa-shake-256s, id-slh-dsa-shake-256f.
</artwork>
        </dd>
        <dt pn="section-4-7.5">signature:</dt>
        <dd pn="section-4-7.6">
          <t indent="0" pn="section-4-7.6.1">The signature contains the signature value resulting from the
SLH-DSA signing operation with the parameters associated with the
selected signatureAlgorithm.  The SLH-DSA signature-generation
operation is specified in Section 10.2.1 of <xref target="FIPS205" format="default" sectionFormat="of" derivedContent="FIPS205"/>, and the
SLH-DSA signature verification operation is specified in
Section 10.3 of <xref target="FIPS205" format="default" sectionFormat="of" derivedContent="FIPS205"/>.  Signature verification <bcp14>MUST</bcp14> include
checking that the signatureAlgorithm field identifies SLH-DSA
parameters that are consistent with public key used to validate
the signature.</t>
        </dd>
      </dl>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">Implementations <bcp14>MUST</bcp14> protect the private keys.  Compromise of the
private keys may result in the ability to forge signatures.</t>
      <t indent="0" pn="section-5-2">When generating an SLH-DSA key pair, an implementation <bcp14>MUST</bcp14> generate
each key pair independently of all other key pairs in the SLH-DSA
hypertree.</t>
      <t indent="0" pn="section-5-3">A SLH-DSA tree <bcp14>MUST NOT</bcp14> be used for more than 2<sup>64</sup> signing operations.</t>
      <t indent="0" pn="section-5-4">The generation of private keys relies on random numbers.  The use
of inadequate Pseudorandom Number Generators (PRNGs) to generate
these values can result in little or no security.  An attacker may
find it much easier to reproduce the PRNG environment that produced
the keys, searching the resulting small set of possibilities, rather
than brute-force searching the whole key space.  The generation of
quality random numbers is difficult, and <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> offers
important guidance in this area.</t>
      <t indent="0" pn="section-5-5">To avoid algorithm-substitution attacks, the CMSAlgorithmProtection attribute
defined in <xref target="RFC6211" format="default" sectionFormat="of" derivedContent="RFC6211"/> <bcp14>SHOULD</bcp14> be included in signed attributes.</t>
      <t indent="0" pn="section-5-6">Implementers should consider their particular use cases and may
choose to implement optional fault-attack countermeasures
<xref target="CMP2018" format="default" sectionFormat="of" derivedContent="CMP2018"/> <xref target="Ge2023" format="default" sectionFormat="of" derivedContent="Ge2023"/>.  Verifying a signature before releasing the
signature value is a typical fault-attack countermeasure; however, this
countermeasure is not effective for SLH-DSA <xref target="Ge2023" format="default" sectionFormat="of" derivedContent="Ge2023"/>.  Redundancy
by replicating the signature-generation process <bcp14>MAY</bcp14> be used as an
effective fault-attack countermeasure for SLH-DSA <xref target="Ge2023" format="default" sectionFormat="of" derivedContent="Ge2023"/>;
however, the SLH-DSA signature generation is already considered slow.</t>
      <t indent="0" pn="section-5-7">Likewise, implementers should consider their particular use cases and may
choose to implement protections against passive power and emissions
side-channel attacks <xref target="SLotH" format="default" sectionFormat="of" derivedContent="SLotH"/>.</t>
    </section>
    <section anchor="operational-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-6-1">If slh_sign is implemented in a hardware device such as Hardware
Security Module (HSM) or portable cryptographic token, implementations
can avoid sending the full content to the device.  By including signed
attributes, which necessarily include the message-digest attribute and
the content-type attribute as described in <xref section="5.3" sectionFormat="of" target="RFC5652" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5652#section-5.3" derivedContent="RFC5652"/>,
the much smaller set of signed attributes are sent to the device for signing.</t>
      <t indent="0" pn="section-6-2">By including signed attributes in the SignerInfo, one can obtain similar
interface characteristics to SLH-DSA in pre-hash mode.  With pre-hash mode, the
hash of the content is passed to the SLH-DSA signature operation instead of the
full message content.  By including signed attributes in the SignerInfo, a
relatively small to-be-signed value is passed to the SLH-DSA signature
operation.  For this reason, SLH-DSA pre-hash mode is not specified for use
with the CMS SignedData.  Note SLH-DSA pre-hash mode always yields a different
signature value than SLH-DSA pure mode, even if the to-be-signed content is
the same.</t>
      <t indent="0" pn="section-6-3">When using SLH-DSA in pure mode, it is not possible to single-pass process
the content to verify a SignedData message that does not contain signed
attributes.  To assist recipients that might make use of stream-based APIs,
implementers <bcp14>SHOULD</bcp14> include signed attributes within any SignerInfo that uses
SLH-DSA as signature algorithm.  Doing so allows the recipient implementation
to avoid keeping the signed content in memory.  Recall that when signed
attributes are present, they <bcp14>MUST</bcp14> contain a content-type attribute and a
message-digest attribute, and they <bcp14>SHOULD</bcp14> contain a CMSAlgorithmProtection
attribute.</t>
    </section>
    <section anchor="iana" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">For the ASN.1 Module in <xref target="appendix-asn1" format="default" sectionFormat="of" derivedContent="Appendix A"/>, IANA
has assigned an Object Identifier (OID) for the module
identifier (81) with a Description of "id-mod-slh-dsa-2024".
The OID for the module has been allocated in the
"SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="FIPS180" quoteTitle="true" target="https://doi.org/10.6028/NIST.FIPS.180-4" derivedAnchor="FIPS180">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="NIST FIPS" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>
        <reference anchor="FIPS202" quoteTitle="true" target="https://doi.org/10.6028/NIST.FIPS.202" derivedAnchor="FIPS202">
          <front>
            <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="NIST FIPS" value="202"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
        </reference>
        <reference anchor="FIPS205" quoteTitle="true" target="https://doi.org/10.6028/NIST.FIPS.205" derivedAnchor="FIPS205">
          <front>
            <title>Stateless Hash-Based Digital Signature Standard</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2024" month="August" day="13"/>
          </front>
          <seriesInfo name="NIST FIPS" value="205"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.205"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="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 indent="0">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="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC5754" target="https://www.rfc-editor.org/info/rfc5754" quoteTitle="true" derivedAnchor="RFC5754">
          <front>
            <title>Using SHA2 Algorithms with Cryptographic Message Syntax</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2010"/>
            <abstract>
              <t indent="0">This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5754"/>
          <seriesInfo name="DOI" value="10.17487/RFC5754"/>
        </reference>
        <reference anchor="RFC5958" target="https://www.rfc-editor.org/info/rfc5958" quoteTitle="true" derivedAnchor="RFC5958">
          <front>
            <title>Asymmetric Key Packages</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="August" year="2010"/>
            <abstract>
              <t indent="0">This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5958"/>
          <seriesInfo name="DOI" value="10.17487/RFC5958"/>
        </reference>
        <reference anchor="RFC6211" target="https://www.rfc-editor.org/info/rfc6211" quoteTitle="true" derivedAnchor="RFC6211">
          <front>
            <title>Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="April" year="2011"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6211"/>
          <seriesInfo name="DOI" value="10.17487/RFC6211"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="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 indent="0">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>
        <reference anchor="RFC8702" target="https://www.rfc-editor.org/info/rfc8702" quoteTitle="true" derivedAnchor="RFC8702">
          <front>
            <title>Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title>
            <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
            <author fullname="Q. Dang" initials="Q." surname="Dang"/>
            <date month="January" year="2020"/>
            <abstract>
              <t indent="0">This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8702"/>
          <seriesInfo name="DOI" value="10.17487/RFC8702"/>
        </reference>
        <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680" quoteTitle="true" derivedAnchor="X680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
        <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690" quoteTitle="true" derivedAnchor="X690">
          <front>
            <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1-2021"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CMP2018" target="https://link.springer.com/chapter/10.1007/978-3-319-79063-3_8" quoteTitle="true" derivedAnchor="CMP2018">
          <front>
            <title>Grafting Trees: A Fault Attack Against the SPHINCS Framework</title>
            <author initials="L." surname="Castelnovi" fullname="Laurent Castelnovi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Martinelli" fullname="Ange Martinelli">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Prest" fullname="Thomas Prest">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018"/>
          </front>
          <refcontent>Post-Quantum Cryptography (PQCrypto 2018), Lecture Notes in Computer Science, vol. 10786, pp. 165-184</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-79063-3_8"/>
        </reference>
        <reference anchor="Ge2023" target="https://tches.iacr.org/index.php/TCHES/article/view/10278/9726" quoteTitle="true" derivedAnchor="Ge2023">
          <front>
            <title>On Protecting SPHINCS+ Against Fault Attacks</title>
            <author initials="A." surname="Genêt" fullname="Aymeric Genêt">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023"/>
          </front>
          <refcontent>IACR Transactions on Cryptographic Hardware and Embedded Systems, vol. 2023, no. 2, pp. 80-114</refcontent>
          <seriesInfo name="DOI" value="10.46586/tches.v2023.i2.80-114"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. 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="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC5911" target="https://www.rfc-editor.org/info/rfc5911" quoteTitle="true" derivedAnchor="RFC5911">
          <front>
            <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5911"/>
          <seriesInfo name="DOI" value="10.17487/RFC5911"/>
        </reference>
        <reference anchor="RFC8391" target="https://www.rfc-editor.org/info/rfc8391" quoteTitle="true" derivedAnchor="RFC8391">
          <front>
            <title>XMSS: eXtended Merkle Signature Scheme</title>
            <author fullname="A. Huelsing" initials="A." surname="Huelsing"/>
            <author fullname="D. Butin" initials="D." surname="Butin"/>
            <author fullname="S. Gazdag" initials="S." surname="Gazdag"/>
            <author fullname="J. Rijneveld" initials="J." surname="Rijneveld"/>
            <author fullname="A. Mohaisen" initials="A." surname="Mohaisen"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8391"/>
          <seriesInfo name="DOI" value="10.17487/RFC8391"/>
        </reference>
        <reference anchor="RFC8554" target="https://www.rfc-editor.org/info/rfc8554" quoteTitle="true" derivedAnchor="RFC8554">
          <front>
            <title>Leighton-Micali Hash-Based Signatures</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="M. Curcio" initials="M." surname="Curcio"/>
            <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.</t>
              <t indent="0">This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8554"/>
          <seriesInfo name="DOI" value="10.17487/RFC8554"/>
        </reference>
        <reference anchor="SLotH" target="https://eprint.iacr.org/2024/367.pdf" quoteTitle="true" derivedAnchor="SLotH">
          <front>
            <title>Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit</title>
            <author initials="M.-J." surname="Saarinen" fullname="M-J. Saarinen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2024"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2024/367</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="appendix-asn1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-asn1-module">ASN.1 Module</name>
      <t indent="0" pn="section-appendix.a-1">This ASN.1 Module builds upon the conventions established in <xref target="RFC5911" format="default" sectionFormat="of" derivedContent="RFC5911"/>.</t>
      <sourcecode type="asn.1" markers="true" pn="section-appendix.a-2">
SLH-DSA-Module-2024
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    id-smime(16) id-mod(0) id-mod-slh-dsa-2024(81) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS ALL;

IMPORTS
  PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
    FROM AlgorithmInformation-2009  -- in [RFC5911]
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58) } ;

--
-- Object Identifiers
--

nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
  country(16) us(840) organization(1) gov(101) csor(3) 4 }

sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }

id-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }

id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }

id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 }

id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 }

id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 }

id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 }

id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 }

id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 }

id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 }

id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 }

id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 }

id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }

--
-- Signature Algorithm, Public Key, and Private Key
--

sa-slh-dsa-sha2-128s SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-sha2-128s
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-sha2-128s }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-128s } }

sa-slh-dsa-sha2-128f SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-sha2-128f
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-sha2-128f }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-128f } }

sa-slh-dsa-sha2-192s SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-sha2-192s
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-sha2-192s }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-192s } }

sa-slh-dsa-sha2-192f SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-sha2-192f
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-sha2-192f }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-192f } }

sa-slh-dsa-sha2-256s SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-sha2-256s
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-sha2-256s }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-256s } }

sa-slh-dsa-sha2-256f SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-sha2-256f
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-sha2-256f }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-256f } }

sa-slh-dsa-shake-128s SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-shake-128s
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-shake-128s }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-128s } }

sa-slh-dsa-shake-128f SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-shake-128f
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-shake-128f }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-128f } }

sa-slh-dsa-shake-192s SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-shake-192s
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-shake-192s }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-192s } }

sa-slh-dsa-shake-192f SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-shake-192f
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-shake-192f }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-192f } }

sa-slh-dsa-shake-256s SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-shake-256s
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-shake-256s }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-256s } }

sa-slh-dsa-shake-256f SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-slh-dsa-shake-256f
    PARAMS ARE absent
    PUBLIC-KEYS { pk-slh-dsa-shake-256f }
    SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-256f } }

pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-sha2-128s
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-sha2-128f PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-sha2-128f
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-sha2-192s PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-sha2-192s
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-sha2-192f PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-sha2-192f
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-sha2-256s PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-sha2-256s
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-sha2-256f PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-sha2-256f
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-shake-128s PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-shake-128s
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-shake-128f PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-shake-128f
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-shake-192s PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-shake-192s
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-shake-192f PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-shake-192f
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-shake-256s PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-shake-256s
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

pk-slh-dsa-shake-256f PUBLIC-KEY ::= {
    IDENTIFIER id-slh-dsa-shake-256f
    -- KEY no ASN.1 wrapping --
    CERT-KEY-USAGE
      { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
    -- PRIVATE-KEY no ASN.1 wrapping -- }

SLH-DSA-PublicKey ::= OCTET STRING (SIZE (32 | 48 | 64))

SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))

--
-- Expand the signature algorithm set used by CMS [RFC5911]
--

SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
    { sa-slh-dsa-sha2-128s |
      sa-slh-dsa-sha2-128f |
      sa-slh-dsa-sha2-192s |
      sa-slh-dsa-sha2-192f |
      sa-slh-dsa-sha2-256s |
      sa-slh-dsa-sha2-256f |
      sa-slh-dsa-shake-128s |
      sa-slh-dsa-shake-128f |
      sa-slh-dsa-shake-192s |
      sa-slh-dsa-shake-192f |
      sa-slh-dsa-shake-256s |
      sa-slh-dsa-shake-256f,
      ... }

--
-- Expand the S/MIME capabilities set used by CMS [RFC5911]
--

SMimeCaps SMIME-CAPS ::=
    { sa-slh-dsa-sha2-128s.&amp;smimeCaps |
      sa-slh-dsa-sha2-128f.&amp;smimeCaps |
      sa-slh-dsa-sha2-192s.&amp;smimeCaps |
      sa-slh-dsa-sha2-192f.&amp;smimeCaps |
      sa-slh-dsa-sha2-256s.&amp;smimeCaps |
      sa-slh-dsa-sha2-256f.&amp;smimeCaps |
      sa-slh-dsa-shake-128s.&amp;smimeCaps |
      sa-slh-dsa-shake-128f.&amp;smimeCaps |
      sa-slh-dsa-shake-192s.&amp;smimeCaps |
      sa-slh-dsa-shake-192f.&amp;smimeCaps |
      sa-slh-dsa-shake-256s.&amp;smimeCaps |
      sa-slh-dsa-shake-256f.&amp;smimeCaps,
      ... }

END
</sourcecode>
    </section>
    <section numbered="false" anchor="acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">Thanks to
<contact fullname="Mike Ounsworth"/>,
<contact fullname="Tomas Gustavsson"/>,
<contact fullname="Daniel Van Geest"/>,
<contact fullname="Carl Wallace"/>,
<contact fullname="Phillip Hallam-Baker"/>,
<contact fullname="Dieter Bratko"/>,
<contact fullname="Vijay Gurbani"/>,
<contact fullname="Paul Wouters"/>, and
<contact fullname="Roman Danyliw"/>
for their careful review and constructive comments.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="R." surname="Housley" fullname="Russ Housley">
        <organization abbrev="Vigil Security" showOnFrontPage="true">Vigil Security, LLC</organization>
        <address>
          <email>housley@vigilsec.com</email>
        </address>
      </author>
      <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <email>sfluhrer@cisco.com</email>
        </address>
      </author>
      <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
        <organization showOnFrontPage="true">Amazon Web Services</organization>
        <address>
          <email>kpanos@amazon.com</email>
        </address>
      </author>
      <author initials="B." surname="Westerbaan" fullname="Bas Westerbaan">
        <organization showOnFrontPage="true">Cloudflare</organization>
        <address>
          <email>bas@westerbaan.name</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
