<?xml version='1.0' encoding='utf-8'?> 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.18 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" 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" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 --> version="3" xml:lang="en">

  <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="Internet-Draft" value="draft-ietf-lamps-cms-sphincs-plus-19"/> name="RFC" value="9814"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
      <organization>Cisco Systems</organization>
      <address>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
      <organization>Amazon Web Services</organization>
      <address>
        <email>kpanos@amazon.com</email>
      </address>
    </author>
    <author initials="B." surname="Westerbaan" fullname="Bas Westerbaan">
      <organization>Cloudflare</organization>
      <address>
        <email>bas@westerbaan.name</email>
      </address>
    </author>
    <date year="2025" month="January" day="13"/>
    <area>Security</area>
    <keyword>Internet-Draft</keyword> month="July"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
     the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<!--[rfced] We see the following similar sentences repeated throughout
     the document.  Please review and let us know if these should be
     made uniform.

Original:

SLH-DSA is a stateless hash-based signature scheme. (Abstract)

SLH-DSA is a stateless hash-based signature algorithm. (Intro)

SLH-DSA is a hash-based signature scheme. (Section 2)

SLH-DSA is a stateless hash-based signature algorithm.  (Section 2)
-->

    <abstract>
      <?line 125?>
<t>SLH-DSA is a stateless hash-based signature scheme.  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>
  </front>
  <middle>
    <?line 132?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document specifies the conventions for using the SLH-DSA hash-based
signature algorithm <xref target="FIPS205"/> with the Cryptographic Message
Syntax (CMS) <xref target="RFC5652"/> signed-data content type.</t>
      <t>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>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>SLH-DSA is a stateless hash-based signature algorithm.  Other hash-based
signature algorithms are stateful, including HSS/LMS Hierarchical Signature System (HSS) / Leighton-Micali Signatures (LMS) <xref target="RFC8554"/> and
XMSS
eXtended Merkle Signature Scheme (XMSS) <xref target="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">

<!--[rfced] Might we rephrase to avoid the repeated "using" in this
     sentence?

Original:

   CMS values are generated using ASN.1 [X680], using the Basic Encoding
   Rules (BER) and the Distinguished Encoding Rules (DER) [X690].

Perhaps:

   CMS values are generated with ASN.1 [X680] using the Basic Encoding
   Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
-->
        <name>ASN.1</name>
        <t>CMS values are generated using ASN.1 <xref target="X680"/>, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules
(DER) <xref target="X690"/>.</t>
      </section>
      <section anchor="motivation">
        <name>Motivation</name>
        <t>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>If cryptographically relevant quantum computers (CRQC) Cryptographically Relevant Quantum Computers (CRQCs) are ever built, they
will be able to break many of the public-key public key cryptosystems currently in use,
including RSA, DSA, ECDSA, Elliptic Curve Digital Signature Algorithm (ECDSA), and EdDSA. Edwards-curve Digital Signature Algorithm (EdDSA).  A post-quantum cryptosystem 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">
        <name>Terminology</name>
        <t>The
        <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?> here.
        </t>
      </section>
    </section>
    <section anchor="slh-dsa-hash-based-signature-algorithm-overview">
      <name>SLH-DSA Hash-based Hash-Based Signature Algorithm Overview</name>
      <t>SLH-DSA is a hash-based signature scheme.  SLH-DSA makes use of a few
time signature construction, constructions, namely 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 WOTS+. Winternitz One-Time Signature Plus (WOTS+).

<!--[rfced] As WOTS+ includes "one-time signature" in its expansion,
     would this update work?

Original:

The FORS tree roots are signed by a WOTS+ one-time signature private
key.

Perhaps:
The FORS tree roots are signed by a WOTS+ private key.
-->
The FORS
tree roots are signed by a WOTS+ one-time signature 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+. WOTS+.&nbsp; The root 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 next-level-up
subtree. Subtree roots are consequently signed by their corresponding
subtree layers until the top subtree is reached. The top layer top-layer subtree
forms the hypertree root root, which is trusted at the verifier.</t>
      <t>A
      <t>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>A

<!--[rfced] Please review our updates to this sentence to reduce
     redundancy to confirm we have maintained your intended meaning.

Original:
A SLH-DSA signature is verified by verifying the FORS signature, the
WOTS+ signatures and the path to the root of each subtree.

Current:
An SLH-DSA signature is verified using the FORS signature, the WOTS+
signatures, and the path to the root of each subtree.
-->

      <t>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>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) is never be reused or the scheme
loses it its security.

<!--[rfced] There may be text missing in this sentence.  If our
     suggested text does not convey your intended meaning, please let
     us know how we may rephrase.

Original:
Although its security decreases, FORS which is used at the bottom of
the SLH-DSA hypertree does not collapse if the same private key used
to sign two or more different messages like in stateful hash-based
signature schemes.

Perhaps:
Although its security decreases, FORS, which is used at the bottom of
the SLH-DSA hypertree, does not collapse if the same private key used
to sign two or more different messages is used (as is the case in
stateful hash-based signature schemes).
-->

Although its security decreases, FORS, which is
used at the bottom of the SLH-DSA hypertree, does not collapse if
the same private key used to sign two or more different messages
like in stateful hash-based signature schemes. Without the need for
state kept by the signer to ensure it is not reused, SLH-DSA is much
      less fragile.</t>

<!-- [rfced] FYI, we have used the <sup> element for superscript in
     this document.  Please review and let us know any objections.
-->

      <t>SLH-DSA was designed to sign up to 2^64 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">
      <name>SLH-DSA Public Key Identifier</name>
      <t>The

<!--[rfced] We note that "SHA2" does not appear in [FIPS180].  Please
     review and confirm this citation:

Original:

   The AlgorithmIdentifier for a SLH-DSA public key MUST 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 [FIPS180] or SHAKE
   [FIPS202].

-->
      <t>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"/> or
SHAKE <xref target="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><![CDATA[
   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>When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of
an X.509 certificate <xref target="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><![CDATA[
   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>No additional encoding of the SLH-DSA public key is applied in the
SubjectPublicKeyInfo field of an X.509 certificate <xref target="RFC5280"/>.</t>
      <t>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"/>.</t>
      <t>When a 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>When a 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">
      <name>Signed-data
      <name>Signed-Data Conventions</name>
      <t>As specified in CMS <xref target="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>When signed attributes are absent, the SLH-DSA (pure mode) signature is computed over
the content.  When signed attributes are present, a hash <bcp14>MUST</bcp14> be computed over
the content 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 signature-generation operation is called
slh_sign; see Section 10.2.1 of <xref target="FIPS205"/>.  In summary:</t>
      <artwork><![CDATA[
   IF (signed attributes are absent)
   THEN slh_sign(content)
   ELSE message-digest attribute = Hash(content);
        slh_sign(DER(SignedAttributes))
]]></artwork>
      <t>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"/> requires the
inclusion of the content-type attribute and the message-digest attribute. Other
attributes can also be included.</t>
      <t>When using SLH-DSA and signed attributes are present in the SignerInfo, the
digestAlgorithms
digestAlgorithm field in the SignedData <bcp14>MUST</bcp14> include the identifier for the
one-way hash function used to compute the message digest.</t>
      <t>When using SLH-DSA, the fields in the SignerInfo are used as follows:</t>
      <dl newline="true">
        <dt>digestAlgorithm:</dt>
        <dd>
          <t>The digestAlgorithm <bcp14>MUST</bcp14> identify a one-way hash function.  When signed
attributes are absent, the digestAlgorithm identifier <bcp14>MUST</bcp14> match the hash
function used in the SLH-DSA tree (as shown in the list below).  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"/> and <xref target="FIPS202"/> <bcp14>MUST</bcp14> be supported for use with the variants of SLH-DSA as shown below:</t>
        </dd>
      </dl>

      <artwork><![CDATA[
      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 256-bit output
      id-slh-dsa-shake-128f: SHAKE128 with 256 bit 256-bit output
      id-slh-dsa-shake-192s: SHAKE256 with 512 bit 512-bit output
      id-slh-dsa-shake-192f: SHAKE256 with 512 bit 512-bit output
      id-slh-dsa-shake-256s: SHAKE256 with 512 bit 512-bit output
      id-slh-dsa-shake-256f: SHAKE256 with 512 bit 512-bit output
]]></artwork>

     <t> The object identifiers for SHA-256 and SHA-512 are included
      in [RFC5754]. <xref target="RFC5754"/>.  The object identifiers for SHAKE128 and
      SHAKE256 are included in [RFC8702]. <xref target="RFC8702"/>.  In all four cases, the
      AlgorithmIdentifier SHOULD NOT <bcp14>SHOULD NOT</bcp14> include parameters.
]]></artwork>
      <dl newline="true"> parameters.</t>

   </dd>

        <dt>signatureAlgorithm:</dt>
        <dd>
          <t>The signatureAlgorithm <bcp14>MUST</bcp14> contain one of the 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>
        </dd>
      </dl>

      <artwork><![CDATA[
      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>
      <dl newline="true">
</dd>

        <dt>signature:</dt>
        <dd>
          <t>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 signature-generation
operation is specified in Section 10.2.1 of <xref target="FIPS205"/>, and the
SLH-DSA signature verification operation is specified in
Section 10.3 of <xref target="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">
      <name>Security Considerations</name>
      <t>Implementations <bcp14>MUST</bcp14> protect the private keys.  Compromise of the
private keys may result in the ability to forge signatures.</t>
      <t>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>A SLH-DSA tree <bcp14>MUST NOT</bcp14> be used for more than 2^64 2<sup>64</sup> signing operations.</t>
      <t>The generation of private keys relies on random numbers.  The use
of inadequate pseudo-random number generators 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 brute-force searching the whole key space.  The generation of
quality random numbers is difficult, and <xref target="RFC4086"/> offers
important guidance in this area.</t>
      <t>To avoid algorithm substitution algorithm-substitution attacks, the CMSAlgorithmProtection attribute
defined in <xref target="RFC6211"/> <bcp14>SHOULD</bcp14> be included in signed attributes.</t>
      <t>Implementers should consider their particular use cases and may
choose to implement optional fault attack fault-attack countermeasures
<xref target="CMP2018"/> <xref target="Ge2023"/>.  Verifying a signature before releasing the
signature value is a typical fault attack fault-attack countermeasure; however, this
countermeasure is not effective for SLH-DSA <xref target="Ge2023"/>.  Redundancy
by replicating the signature generation signature-generation process <bcp14>MAY</bcp14> be used as an
effective fault attack fault-attack countermeasure for SLH-DSA <xref target="Ge2023"/>;
however, the SLH-DSA signature generation is already considered slow.</t>
      <t>Likewise, Implementers implementers should consider their particular use cases and may
choose to implement protections against passive power and emissions
side-channel attacks <xref target="SLotH"/>.</t>
    </section>
    <section anchor="operational-considerations">
      <name>Operational Considerations</name>
      <t>If slh_sign is implemented in a hardware device such as hardware
security module 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"/>,
the much smaller set of signed attributes are sent to the device for signing.</t>
      <t>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>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">
      <name>IANA Considerations</name>
      <t>For the ASN.1 Module in the Appendix of this document, <xref target="appendix-asn1"/>, IANA
is requested to assign
has assigned an object identifier Object Identifier (OID) for the module
identifier (TBD1) (81) with a Description of "id-mod-slh-dsa-2024".
The OID for the module should be has been allocated in the
"SMI Security for S/MIME Module Identifier" (1.2.840.113549.1.9.16.0).</t> Identifier (1.2.840.113549.1.9.16.0)" registry.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

        <reference anchor="FIPS180">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="FIPS PUB" name="NIST FIPS" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>

        <reference anchor="FIPS202">
          <front>
            <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="FIPS PUB" name="NIST FIPS" value="202"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
        </reference>

        <reference anchor="FIPS205" target="https://doi.org/10.6028/NIST.FIPS.205"> anchor="FIPS205">
          <front>
            <title>Stateless Hash-Based Digital Signature Standard</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2024" month="August" day="13"/>
          </front>
          <seriesInfo name="FIPS PUB" name="NIST FIPS" value="205"/>
        </reference>
        <reference anchor="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>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">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t>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">
          <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>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">
          <front>
            <title>Asymmetric Key Packages</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="August" year="2010"/>
            <abstract>
              <t>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">
          <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>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="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>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"/> value="10.6028/NIST.FIPS.205"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6211.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8702.xml"/>

        <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>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">
          <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>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>
        <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>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="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>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>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">
          <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>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="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>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>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="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>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>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8554.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8391.xml"/>
<!-- [CMP2018] -->
        <reference anchor="CMP2018" target="https://link.springer.com/chapter/10.1007/978-3-319-79063-3_8">
          <front>
            <title>Grafting Trees: A Fault Attack Against the SPHINCS Framework</title>
            <author initials="L." surname="Castelnovi" fullname="Laurent Castelnovi">
              <organization/>
            </author>
            <author initials="A." surname="Martinelli" fullname="Ange Martinelli">
              <organization/>
            </author>
            <author initials="T." surname="Prest" fullname="Thomas Prest">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="Post-Quantum Cryptography" value="pp. 165-184"/>
          <seriesInfo name="PQCrypto" value="2018"/>
          <seriesInfo name="Lecture
          <refcontent>Post-Quantum Cryptography (PQCrypto 2018), Lecture Notes in Computer Science" value="vol 10786"/> Science, vol. 10786, pp. 165-184</refcontent>
          <seriesInfo name="DOI" value="10.1007/978-3-319-79063-3_8"/>
        </reference>
<!-- [SLoTH] -->
        <reference anchor="SLotH" target="https://eprint.iacr.org/2024/367.pdf">
          <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/>
            </author>
            <date year="2024"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2024/367</refcontent>
        </reference>
<!-- [Ge2023] -->
        <reference anchor="Ge2023" target="https://tches.iacr.org/index.php/TCHES/article/view/10278/9726">
          <front>
            <title>On Protecting SPHINCS+ Against Fault Attacks</title>
            <author initials="A." surname="Genêt" fullname="Aymeric Genêt">
              <organization/>
            </author>
            <date year="2023"/>
          </front>
          <seriesInfo name="TCHES" value="2023/02"/>
          <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>
      </references>
    </references>
    <?line 564?>

<section anchor="appendix-asn1">
      <name>ASN.1 Module</name>
      <t>This ASN.1 Module builds upon the conventions established in <xref target="RFC5911"/>.</t>
      <sourcecode type="asn.1" markers="true"><![CDATA[
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(TBD1) 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.&smimeCaps |
      sa-slh-dsa-sha2-128f.&smimeCaps |
      sa-slh-dsa-sha2-192s.&smimeCaps |
      sa-slh-dsa-sha2-192f.&smimeCaps |
      sa-slh-dsa-sha2-256s.&smimeCaps |
      sa-slh-dsa-sha2-256f.&smimeCaps |
      sa-slh-dsa-shake-128s.&smimeCaps |
      sa-slh-dsa-shake-128f.&smimeCaps |
      sa-slh-dsa-shake-192s.&smimeCaps |
      sa-slh-dsa-shake-192f.&smimeCaps |
      sa-slh-dsa-shake-256s.&smimeCaps |
      sa-slh-dsa-shake-256f.&smimeCaps,
      ... }

END
]]></sourcecode>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to
Mike Ounsworth,
Tomas Gustavsson,
Daniel
<contact fullname="Mike Ounsworth"/>,
<contact fullname="Tomas Gustavsson"/>,
<contact fullname="Daniel Van Geest,
Carl Wallace,
Phillip Hallam-Baker,
Dieter Bratko,
Vijay Gurbani,
Paul Wouters, and
Roman Danyliw 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>
  </back>

<!-- ##markdown-source:
H4sIAH51hWcAA909a3PjxpHf51fMyVVn6kJQIvVYSY5z5lLUirFeFrle+1K+
1BAciohAAMYA4tKb9W+5z/cz7v7YdffM4EGCFJeqXJVSldgUMI9+T3dPN+w4
DlOJCEZ/FX4YyDOexKlkXhTTL5W09vdP91tsFLqBmMLrUSzGiePJZOz4Yhop
x50qR0UTL3CVE/mpcpqnzBXJGVfJiLlhoGSgUnXGv8aFv2aRd8Y4T0IXnsyl
+hr+UGGcxHKsCk/m0+KDxEt82Prr90rycMyTieT9q0vnvN/mfe8hEEkaS972
H8LYSyZT7gU0pBPPoyR8iAUA5/JrqZR4gInzIBEfea1z3d/9monhMJZPsPQz
68Hor5lKh1NPKS8MBvMI4Ol1BxdMxFKc8b50Uxg8Z48zeB4kMg5k4pwjrdhI
JDC4td86cvabTvOAMZEmkzA+Yw7XNL1PleKXYap8OQfsw/jhjP/oPXh+tm6d
X1114JWFt/wWXsip8PwzPtGLfPeE75V0G244zbbpu2GS8As/ncQytvt0POWG
QBWVyKnKF1JjPew7F9+XlrkTQaj498B8EYhHT9mV2lPxWxjwD3IIgMVPnisL
6z1GOOs7QWNKy70VCubA9vFQiCADyw/T0dgH6uZrDIX6bpaNbOB0xrxgHMZT
kXhPEgXr/qJzuH9ybH4enTab5ufJ0dGh/XlwSk8713et/eYJ/gSJFPGDBKmd
JEmkzvb2fC94bKgo9oIHGSPAe+5ERLD3XnO/0dzff7N3+ubEOXAOmqfOm9P9
Y/j11xO9kpbWnXfIfZjOB7GUIMttfiFSP+HtJBHuI28/CC9QiZbmu8veTafP
L2LAaRbGjzu0kpUT/G3JdSVAOIOEdwQQwg/CJ49ec5BS2OOqsfjCzmsDHvxa
xACR9P3SpHZj8YWdNJiEU2DPXQxUL84YNArPrHw3NfpKxp5UyJYzM2XnLlSJ
80MqgiSdFtVyvgNkiqIGbx4fOc2Tw51swg96FL7HhbMXV9Il5bwJE6lIMcNp
lAJXQLg9GbgSZzyFPm/uvzk5xmn9qzC5rGaxRO4mDU+4cQOEbg9U9HDv4PhN
IxqNi5xsu670ZSyImdZQDOd8MAv5bTySsUKrdC0eAi9JR5LPwGpwAaYkePAl
vxRqwt/Dq5UsvXb+3OB9IQAaGRTJvPwisyWH8Oc7CT8OqnFL3IlUOWpeMJIf
G9Ek2ht0Lrv9PWS368u9J0/OQKBbb05AnFvHRaxvA+AxkNnVaGsJ/UMmtkVZ
VitRa8+nIA4ugBr8738nC0JXeJjhdbBChghskobWwd5+ywrE+W0PHoJGHh4f
nRwbrJ9wUMNrNU72nWYTpIoFRRNx0bvrN0/2z4rIkiU1vOrjaSjiEa/1L/u7
FaiRgbqB9cJA+GDtFSwCMohCYOcqDv/mA+lOgtAPH+a8dtPrD3bL+gLnwUqV
QSD53fu3KM8ArEO6gQ8BtxLkO/3LtnOQbQzmWcbTNCHoHLCtcqSxQni6HxMJ
o4a+dG7TBPSGX6SBiyNVlcH5/8azpfmqsTyqlutR6JFAA8uP91sne7hdA2c0
YEqZLkADUFs8WQF/Q4pzOBcTQCY/5i0m/0ACtA6BAHjwb0SDox1zdrW0jOLP
46OW/fkmO8aOTo9OzM/jVn7OvdEC8tNxJuILJJzNZg3AowG2by+W7t7Aue92
nJ8aMKFIwD8Z8Hr2gIWzPcnxBLdRv28PVRILN7GeFZhmPfg2kLzW7t80mrsW
1X4kXW/suXoAkBGOdLAOgZmyigW9wXtnUCZp0wGntJqeNJrfSzizpyjuuPIZ
z/GDEf3bvV63c8ZPToA3zTNcj0h2+qUkO92OZEgUDsdVOELbGqc++gdLxHlL
xOnaYfc4jNfedu9362ahDjhVAczwl0Z1YBSJ5rmn0ICnnpqA/C8OO4dh/2Cq
n1ZRHY57h6jOHMcBr1aLEGP2dPVAryCAsBo8QQ0ekgarTHMVGPupbMDZMIHh
EKCksHHClCYjYIeeFQQgT/AUTRwHpvBUIfbFCCJfUFiPn9EJvlkM0UB2czEa
ebhJHWcxkYcOI9wcoImJGVE69GGdRzmHEIfWAAeXRzE4ayM5amhqTL3RyAfP
9isMJOJwlJKFZqyEJv9SNHMSsgqM+adPxux+/szXY8+K2MM8Y59gHq4rRw7w
XiBACYKZQKTUyPkajsfoLiXgOeVQTMMRyn9kf2tSxdJBmOlJg1s8CsCHEflk
iDIEnz56Xmbfj0CeBD13LvAdHHQkJXLhLYP1YcpUfPSm4Jj6MngAxEHxWkdH
4N+BhwnT3s75SI7R2albShc38Ij+TE6jZG6eLUokDwN/vsCvVEeyOcraZww4
LcQWNkGOEj+u+19CZIjfQEtMjAjoPUlfGUJEAiONBIfh4lK4ExNZs4UJfCYB
RncSQhwPYbsVVt5snfChl5Drq7IotXnask9Z/hT52To6XhqPbJUISlIUxVxn
UPGfJBtK2FoojTnBazEVSRF0tYztl1mUDAYA7BYWjJ/RGkXqS4uOU79uxBA5
dtnv710Bt0g9MPQE9QAqsJ+u+/YhBKGfP8NGH2ClMNVxYCANgrQm2IkowUAD
XxH2cb2IzzQF1AmbcSwg3pcwUOjch4XpGTyRQF99pc8jxlC8noSfSo3XgwxQ
wWCmtib61Pr0CT2Lz5/rBRtDBxWrOqiI9Thk3THE6BiilU9hZQ3TdQj+urCW
D2UQZYGTLMARjGIvRk8CQj6KA100VQLctLnytE9WfItyPUKJCCOtkWP+qwlH
XRNAomZ0S7KULRCF+BdDfQKBAx2YgYj6aBciP5wDOiPjVa6gcG+swbOWVPgw
OQY5hPWTZUDAst7/0NklHgDMMR+mnrE+cziZfB+IwNGJR1CGANMjmLBgbjNj
+oxx8IzRuyqd2+GgGZg5gL2BImCA6iyX1/t+u87P8R/dDv2LwoUR/ASytJEC
iZMBWliV1+4QVE9pbQe4THi4jBXIZqJ5OA1jI6qCg4F78oB0QTodAqo5YxgZ
i9qvqYM/6JhNUOjB6pMdAtv3N5MMmE3gkZdwS5uxBHm09AHage6ipiyB9A2f
hDOkcB1nw9pRnI7InoZkoEtMYwWtJ1RizEoF3ODtjQEZ5Buu49FhDAd6dmxp
8wO0qjIjWuAHELd52lMkiScvYRZiiLFz/b4/2Knrf/ObW/p93/3hfe++e46/
IQa8usp+MDOif3n7/uo8/5XP7NxeX3dvzvVkeMpLj9jOdfvnHS0DO7d3g97t
TftqR+tR8VxDAUUSA/aY8YQTG42FUKBqyo29IfwBc9527v7nv5qHoN7/AmYP
ApVTsIX6j5PmGzSMyD+9G52U+k+SdhFFUsS4CugMd0WEaqbqeKwr4F3A0TAA
+f7tL0iZX874H4du1Dz8k3mACJceWpqVHhLNlp8sTdZErHhUsU1GzdLzBUqX
4W3/XPrb0r3w8I//7nsQUznNk3//E0P/0ArXZW7kq/LXt0+YjpWzhcNwvVNt
h07FI5hA468I0K0ZS7ypLEzBHH8Say+1TnkfYOJFiPlBnHMPjA2nvJ8OlUSN
vri97+8ystB8Ao4L5v5xQ3xOq5JPZjxtk0qLYjwLSCUa6L+AgwS2TEVhQNaL
pua+tT6+0Bb6EuwNnQCP4HwEIoazFJOxDVKwOAy1P6LtPb2hqUgZoAroviQv
AIQcAzoAhHbCeY2MlkAahDgMpLNAGE1LjvYeVvtwO+j/gaCnVRhuZ0AgL0J7
N3DaCz20akVDB2bpwMt00POKhCCwy5QYOb6Yg/VjmLOU8SPYSZUONfLm5iSL
GXL24GbDMEmAkzQdHTxt0e0Yw7vE4GdQIwYWUMen1tM06y0CYZgXWJLkS1hv
gn0p2uZoDNCnJs+QpxEzGzZQNBeYQddWv6b6tMw5A2t4cZnmdhVNFVAUcF19
2iwJI4sT6luMjioeCQPzTpPRjGAIsSZeTlCi1QzOngmFGXgbh/ZVu4qg0+Qj
g/VrV8SyiAG4XBnqMWmh95tOLui4op4zK5tYZ/hMUzRfDeSC/GyCuZ45dZHA
QDHUGxjG0jiLVU6NAt8LGBboUo0GDDCIEgPo99y6nQuQk2QsQK42hrXBP0zI
tYRnyNeVQNczd1yDaOBT+vACP8BLtAEBloW0DIaylnvFJSvUbOt4pW8cfrbG
qiOxf0097XxpKTKqk5tXVsvdfiC49vENIJxuEdDbA01CxzSWKe5jolO9CfND
NIhAhDzKa/sY4jyAGINAZiHaSLpAbRhc15y0ks5oUQOgsRGrKAbOCGwWAE3d
0PdFpNATI6IrOIeKiHFaNdF5B0pAANjkiY48jJfRoTGnjmK+90hCvz6MMlRt
VIZwbFUIhzDglThKN3mdCL2mZJ0vRHesGN0VgtkZOEDgZGnDZHFKI/zZ+s/j
wwwR7VQV0gGL0f1yOmAlpW2OpZQjyCZqraCEzdjcKehHNBfs5sPEJFAyT58Z
k4kJAWP79YgP5E4GXvJbvj6OImFdWCQ/SzWy+TmHivxstmMxYcAWsh0CzwsB
joxQ1tOnnBEpCZw2Qz90H7nrRRMNTbN1QkmQOoN9bMqjUfTV7vQx9T1IZC9L
dGiHP/PY8hcEr8gmF/KH5N+SWxbYogiWzKQP8ZU3cpQ/cUYKvJIhBkmllIrv
kSEaQjA8q3Mt02FQkfrJNMZahGrBMPZwih46ADsGajEwDsoksfFlZqfyo8M4
lOBpt0zusYlZBViBwbPvu1lCskVJkgtk20cxjXzYL8fPURNwTx0gtGKxBDsL
bEv0MQrPMHJcYHAR2DKQbC2Q33dhvQpp8qQ/sgusYl+RaosMpEgegQYZ+f33
3zFTHgB/2nmsefv2z93OgPfOuzeD3kWve8/Pzr7ln/jfQtASx1Oh4yWpk9Ra
u1zn2d0QTt14Xmse7wICtZPD/V3M54vAHP615i5/CJ9qzX344aowrh3s8kP+
meF0MCSw9+pdF4A7MNPKHGk5oAar17B7tPZXzx4/P7u5avZpa4O9W6tnb7D3
KrxREJ+ffbh69gZ7H1XOBi3YjOjHa6ZvsPubldM3IvvJmukb7H66avpGhD+o
Fjg9/fndD1DiUEkZeYqUC6nSeZ20yIOplGywtvtg9vFyMDMcEAfznxpH+6fc
BWuqb/+kuVRp6TQrXToUXmpfBoNjidf5ZMKu2z/TnQEmpEwysp/7xUEY3Mso
HXlCH8uwQgcWxBHa1rn3V/jHNzq2em4vk1jhdsOQYmSdOM7NWPRYYRLu3r+9
6nWc77s/a9qam8EizatMiR3mOBynBqHJRc9ioDU6qNnNKu907we4vvO+337X
tU85sPEL6WJoAizPN7+77/3YHnSdVUAY8apAfbwl6uPXjjpahW1Qh3mvH/Xt
uA7zXjnqZI23QJ38uFeP+lZcx3mvGnXrgHwx7mbiPwHyWzDeTHz1yG9l5s3E
fwLkt+T8a7f01vHeBvlXb+tt2LAl8q+N8yaD4WRxDGF72xl0B7w/uO/dvOO1
fu8/urx20OJ/54cn8I/jw91dxkuzdUJ23fTjQ5h5egz/AMsI8yniugmzEjvh
55WTC8nKQnYF0+dR5Hv6DhrjmrVxGH8uDmtsDEMh5bwMRI5/eXt9TZDRpvT8
NpBtNZ9OZRIT4AzLvQzM+QvKKN4J9xGjNQ346dEJAU7hamUS0YaqYZooLOqi
K95KQuGeDO/hA8D8yYvDgEoA6CKBbkDLNa31FXxhLiwwlHocFQvgiiUxyG4d
CisUpM7Uui3iVKB6FVKrKLU9SoUrk21xyvltkPqKru9tdV8nr+lkrK2yCsKR
aUgr1l5q4JbrkKioBUtI8VIiDqd0NWIv12E43tHbbKe+nvhaLd22l9cz5TMj
FuIVUH55YirHRjKS+lo2DLCUg5ID5qZCJED/YZqYS16d+cSUr8ncWr6uG15m
Qy2roNythpIjlCwr3AywEnTNHgaQuimPyJK0K5cr8JVunEo3IFqWPKUz6QuX
66bsAasZlmGhfReqWoPEIc3PhukyN8tOR7OTZa9Nurr8ujDb5G9UfnNDLLTp
7Jxeg8pq6UUi6zI/OO0WLaOSCdYaLCG5cmVz30C5eVvjS9tRIQWDo/SvitJV
Skrs3KH3zf1GC7QVNiqUMuvibJVOpyKen2W5qd4Fr62TMSqJH1x2b7jdq2ao
QW+6V/3uarJ+S+U42YRvsuM6WwuIVNOK3s52twcdghuCHHl41YH2SFc41zkQ
gpoKAhdYKuYolLgYHVW6qG+Kpbl0bUsCRRe3ICD5nXnlvrp6rijRQGkf+x9Q
90XCPNwcq29pPY4WKZZ6RGZJskLkMLMkVLds9UDfghRq30DSPN0jkA9CM0r1
gfBvQAZbSuBpAW9zRZ9UakxJez99smJx1DigIqSsSN1cgeuybdKw4k3VGkVL
1uhSQ5cLswI8iI3wlSmPI0UeWfumbUZWxByM1lujzHKQgcbjWNc6aCgK1zHa
bSiOHp3jSVKyJvjOW7qhYlhtNAO5KhswewVoNJ0vHx+VOGkjTeCoZegJN33J
jxeyvh/OFCjnpzP+pIDt8tud/Z3Pi9idsTMyFwuPDW4an7mpw1rCo2z02ZqD
ZXH5AqVop6lI3ElmMVmZUBUWnteyWkXzFu9f9e3r7nqwMmnOCwawyMEjeYV3
Hrbtu+b+NYNztAAYQW18AHuqaTtvD6fsjjuZea40Cvxbdg5UCMTKk6xMdXQG
xl5AE1jxkhclvnC/m52yKo2iME5MDTzevmatKE8i9kSgGwsyxbGUJWrm5p1X
X0iecbzJxdhr9aDx84NOW3alo2Zr9aDxs4MwAt5k0HMrmQTamb6nxr4Mopqp
PkA3GFR3zczxljOJEPZuXM8EEDebOd5upibZljOf29NMRTGuKJugthMtGSS/
hiOkqda+280D/hfTqvlL47kFNd2xN0RPzkAsLmyXxObOX0zHme/DEmkMB40y
hTO2u7DiTjIvVM7OgbyMoaFdjwX7mx3WSyZ4+Y3W4OxCMKtIKZmJvL2uQIa8
2CJvAFoqsFgoldBOc2WTnR1ZAEEfMHA4PWsg6tUmob7GElRNAeleNQXlt2IK
Cmf1FKPbFTUvqyEzulk1ZyVoRreqa2vGzwjIklyUQ4uS1wfnDhxdqU8fFcCI
VOdmCjEARQ6Z258dAAWhAGc0dD0qUbSvmZI+KFixPK9daOZ6Ls5gpTijFGiv
jS8y6WXLq+u6ULcijimuzwrrHyxHL/3q5YoOHXMn0n3UQagpmqxQUOMaWk1R
WT9lga4035Y/Y5VYkGgCFzJG1iE0Drxkpf10DsNWXHVwmZFt0oTYphzTZK4J
fmOimAGjGm5AHr/tARLiZV/9YcUBFAVpWbIOiRh6Pm6s6/UfCoAp66Zanutg
xnINMYuER6XNC6GXhtKWwDGqHbTDqSAW0x26UBwTTVgERykPO2axqJ7l1b7F
kmfyFbPSiqHxj8e2RpW6pai0c0lFEDWU72LUPC6REnvNdIGyKQM35ZM2Aoet
MED3AjGC4AhnRUqmo9ApjbYbhNihdnd/8w5ix0JxIAqCkjYLhNFPzhtgSuJL
jAKDsNj82Q4w4hHuI6wO3GTgLI6wKJYaG7GJS1fLYmWf9l+Rjrj1csLOZrlI
HhHpOmwkYqrl1jXfmdXR1X9KUh12FEJkS2Lj4SkKmEwowYMpvRgjHmCBKxfW
mk1CX+cayRwaMpYYwICQJItliqP6Y8rMc6mhWDvC5ptFWP1IpboMJBDcYGwO
fEhByzDkt81X+LkpZDgEUU+hNyqcmiod6u9TIACarKaetnPdzwyB/aSLHqPD
DZa76Roa/JwEQGOchmHZD1nO4xQ0G1EEnzwFW+Ma7TddExF9cib1hXbsyWsh
/JHx7iTEHkvgdaZ8IOAm007N1wYjXd0o4ylIB6o1hBXmK07UVKa/iEOW88cs
7SEKRnkox6hO2HwpbOKOLR5QVHqfzCP6sMKa3Qv9g8gbVn5rS7sl8NTFb8+U
OpdLsN7LURogn+dsiDYt8snQ27xiVWIM5N3F2vDr9s+ZtaDEMyvstxr0FbB8
wwoYPZOaQyr5II2jecZqPH7B1wKBuPIe5QwMd53/I0QjyoRYZQ2nlKICpCNA
QH9sQZqPtSmGmzku6HQgfasamCPCT0PpfmN+a80psHzp3BpnuTvq7swwIn3A
mDoezfDcHEn86hmnblOhsud5XfUUjBRYjtpl/xqLcjmpOXaqllpNAdlHbIFc
yAHSPYPWemVS7OTfptgaWU7AaUD01wvyJt+lNEPd9FwEEmUJImx/XkoTrcxx
YriyLl1G3Ql5C+jqdJxuNyJ7T2YZ7wq0Ya7OiKklJHW7vD4UgZMVCBfXqMik
YaiAlA2HFLwob+qBJDLqQRiDdecgOPhxErAnYF9d7OrJ2zSCpe9UfCCHqfiw
nqdRyllGup0BsdUeVbXCFRxHkHLQNusKEdsX8q/VDH8Gf8HAGtLHsbDXjc7G
JHSG0jGzM5v4DKi5D23q9em8wg4fvIbO780KlLEmMneITd6n8AGW634hkwkr
45ffVqwm/JkAb2eu044iv5tasvB0vue3k+YKqY7t9gG2cFHoWiRCzrGsuag6
mYsSka+XN/hoP0P3pCv6MJyD9LR2vHSlhO41nV70Ebksi2uZTf5Ooe8pMHK7
oNzolYT02QyF/UWuF3mmOQKmT7Efh3p7bZODAg9UTE2PU/uup+rMK5pu4wxY
87AsWsgyuk2dF1O92W1qKWtX1cHGz0OS2RCd6HCmjNdm4F4whiyxDtCjlFHx
pCwyKwCagfs8pyPWJclGcGab5FwntkXDEnj9LRxbZSuzEHFuSZgvWO2YFW7w
6CNA7Zv2wpHEP33liUB8ZuzC9Jfoq+prfbwYJW9HdBP7UVuMQuN+ndZknu4H
lNQOlITmCyucTOFCtorXbnvnu1k3iz7GWPH94O15c9e2a5+T8Y9sLLLjjRyY
kiUW8ItoO7oFG5ZdWNX6CJjuATlwRZJXT+z0r3t5eEkuzN5177prEc8TXju8
1oR4/eRwv9FsHhwdnjaaDfj/cWN/13xlaQhOAJK3RLlPXwlDNEeooPnZfHSp
NIa+KKF4GoXZtVn26SWgJRzn+hsn1pnGb5CSk/H7778DjYNG06qCo1d0zOcc
P4GtCLE7B4QWYgVnGI7m2NZjm3hiJUbKq2l8dnn06Cocjf8+rZ3qz3hh+mbq
TSV1/2iy1/btrxIDDMcAxfPuRe+mh18b6PPe9d1Vr9Mb8EH7XZ9KdN523/Vu
GOv+dHd7P+jz9tXVN+ARXdNfsGVe/QQ2vvfupj14f9912lfvbu97g8treIgM
cjrtuz4BeHF/e13IUOYfSnPwQ8NUkGTTp0C3X5guczKEyS85nFJH08EuyPao
hiibT+/CaJPnsr5X7QgJi06gp6YK/4oevY+1NwUy5ZkxJJaoAnK/VTs6Aarx
b1CK4H/8VutKLnoKX7AXdXFt38K1Tf/WC5q3XtC59YK2rRf0bL2gYesF3Vov
adV6SZ/WS5q0XtKh9ZL2rBf0ZhmNzHOm7bylM2+71QeyKb7CB6SvuN2SElQY
tEKN5yZNS3ft+zZ4sO37rrm80E8zo9kHHCo7pXSFZm48YVy23zl/+3N1y+Vn
sgHLqIxfhMr4JaiMt0JlvAIVlN/tUbHF5luhglt/OSo0awUqL+GKLR3fEpVt
uEKzqlAh7d4alawQfBtUaOsvRkXPWoHKC7iSlXVvicoWXNGzllGxh8yWuBSb
cr4cGbv5F2KTTVuFztasKbbZbIvOFzMnm1aNzgtMWbFxZjt0tjBm2bRV6LyI
O9vbM7v5Vuis4s5LTFqxuWUrdLYxatm0Vei8hDsvsGt2863QMdzZvJV8E5fs
uX6bymabF3babNhms3nj+CYO22tCdGX/4Cbu3OtCdAuOWuP4ihBd3Re4iSv4
uhD9co5mBvXVILq2vXsjN/KVofqlTC26mK8K1S83vUX385Whug1XX531XduW
vZHb+spQ3YKrr8ECv6Dl+gX91iaL2v0YFRtDF/97IVilQUVHwznd0ec3NphN
zciSZWD7MH5FAGLueCozsH+3tzhVOc2VL9GkrXm5eiapzZqXq2ba03Hd23Vz
VwNszdbKt2tANmJuK74bjUaeJC+w19yhuiISthDyOfZee1PZEZEqBnTrOdn4
V7qXpEnrmLrROCDXhuM2Wg9JuOG4DdYzsrDpwA1X3AhlIywbDdwMadsAkA8s
SxP9ZN2bc+oQ+HTGVZjGrsRGeGcq4kcZq2/1f/j1M122u49BOPPl6IFKORTO
0JWxcvTtThDu0I27CB7p28nX+BXe2zRQszBOJnU2oP8Y5btUJeJJYVUROxeB
J33+owj4OylVUmcdEfv8g/B94co6u5t4vu9F/BIfTJ23gE8Mszz6ouzbWCSP
YZ396P1NzGHZeAirwRyRwgoh/Rci6K6I3cO+AYe95r43Y6ZcAT8ELmL6OHAs
8ev6+kt62bfwn6hpnLBssP8D43zRfmV3AAA= [rfced] FYI - We have added expansions for abbreviations upon
     first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
     review each expansion in the document carefully to ensure
     correctness.
-->

  </back>
</rfc>