<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-cose-sphincs-plus-06" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.2 -->
  <front>
    <title>SLH-DSA for JOSE and COSE</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-cose-sphincs-plus-06"/>
    <author fullname="Michael Prorock">
      <organization>mesur.io</organization>
      <address>
        <email>mprorock@mesur.io</email>
      </address>
    </author>
    <author fullname="Orie Steele">
      <organization>Tradeverifyd</organization>
      <address>
        <email>orie@or13.io</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig">
      <organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sieg</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>hannes.tschofenig@gmx.net</email>
      </address>
    </author>
    <date year="2025" month="October" day="12"/>
    <area>Security</area>
    <workgroup>CBOR Object Signing and Encryption</workgroup>
    <keyword>JOSE</keyword>
    <keyword>COSE</keyword>
    <keyword>PQC</keyword>
    <keyword>SPHINCS+</keyword>
    <keyword>SLH-DSA</keyword>
    <abstract>
      <?line 76?>

<t>This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://cose-wg.github.io/draft-ietf-cose-sphincs-plus/draft-ietf-cose-sphincs-plus.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        CBOR Object Signing and Encryption Working Group mailing list (<eref target="mailto:cose@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/cose/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/cose/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/cose-wg/draft-ietf-cose-sphincs-plus"/>.</t>
    </note>
  </front>
  <middle>
    <?line 81?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document specifies JSON Object Signing and Encryption (JOSE) <xref target="RFC7515"/> and CBOR Object Signing and Encryption (COSE) <xref target="RFC9052"/> serializations for the Stateless Hash-Based Digital Signature Standard (SLH-DSA), which was derived from Version 3.1 of SPHINCS+, a Post-Quantum Cryptography (PQC) based digital signature scheme standardized in <xref target="FIPS-205"/>.</t>
      <t>This document builds on the Algorithm Key Pair (AKP) type, as defined in <xref target="I-D.ietf-cose-dilithium"/>. The AKP type enables flexible representation of keys used across different post-quantum cryptographic algorithms, including SLH-DSA.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="the-slh-dsa-algorithm-family">
      <name>The SLH-DSA Algorithm Family</name>
      <t>The SLH-DSA Signature Scheme is parameterized to support different security levels.</t>
      <t>This document introduces the registration of the following algorithms in <xref target="IANA.jose"/>:</t>
      <table align="left" anchor="jose-algorithms">
        <name>JOSE Algorithms for SLH-DSA</name>
        <thead>
          <tr>
            <th align="left">Name</th>
            <th align="left">alg</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">SLH-DSA-SHA2-128s</td>
            <td align="left">SLH-DSA-SHA2-128s</td>
            <td align="left">JSON Web Signature Algorithm for SLH-DSA-SHA2-128s</td>
          </tr>
          <tr>
            <td align="left">SLH-DSA-SHAKE-128s</td>
            <td align="left">SLH-DSA-SHAKE-128s</td>
            <td align="left">JSON Web Signature Algorithm for SLH-DSA-SHAKE-128s</td>
          </tr>
          <tr>
            <td align="left">SLH-DSA-SHA2-128f</td>
            <td align="left">SLH-DSA-SHA2-128f</td>
            <td align="left">JSON Web Signature Algorithm for SLH-DSA-SHA2-128f</td>
          </tr>
        </tbody>
      </table>
      <t>This document introduces the registration of the following algorithms in <xref target="IANA.cose"/>:</t>
      <table align="left" anchor="cose-algorithms">
        <name>COSE Algorithms for SLH-DSA</name>
        <thead>
          <tr>
            <th align="left">Name</th>
            <th align="left">alg</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">SLH-DSA-SHA2-128s</td>
            <td align="left">TBD1 (-51)</td>
            <td align="left">CBOR Object Signing Algorithm for SLH-DSA-SHA2-128s</td>
          </tr>
          <tr>
            <td align="left">SLH-DSA-SHAKE-128s</td>
            <td align="left">TBD2 (-52)</td>
            <td align="left">CBOR Object Signing Algorithm for SLH-DSA-SHAKE-128s</td>
          </tr>
          <tr>
            <td align="left">SLH-DSA-SHA2-128f</td>
            <td align="left">TBD3 (-53)</td>
            <td align="left">CBOR Object Signing Algorithm for SLH-DSA-SHA2-128f</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="slh-dsa-keys">
      <name>SLH-DSA Keys</name>
      <t>Private and public keys are produced to enable the sign and verify operations for each of the SLH-DSA algorithms.</t>
      <t>The SLH-DSA Algorithm Family uses the Algorithm Key Pair (AKP) key type, as defined in <xref target="I-D.ietf-cose-dilithium"/>. This ensures compatibility across different cryptographic algorithms that use AKP for key representation.</t>
      <t>The specific algorithms for SLH-DSA, such as SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, and SLH-DSA-SHA2-128f, are defined in this document and are used in the <tt>alg</tt> value of an AKP key representation to specify the corresponding algorithm.</t>
      <t>Thumbprints for SLH-DSA keys are computed according to the process described in <xref target="I-D.ietf-cose-dilithium"/>.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations of <xref target="RFC7515"/>, <xref target="RFC7517"/> and <xref target="RFC9053"/> apply to this specification as well.</t>
      <t>A detailed security analysis of SLH-DSA is beyond the scope of this specification; see <xref target="FIPS-205"/> for additional details.</t>
      <t>The following considerations apply to all parameter sets described in this specification.</t>
      <section anchor="validating-public-keys">
        <name>Validating Public Keys</name>
        <t>All algorithms that operate on public keys require validation before use. For sign, verify and proof schemes, the use of <tt>KeyValidate</tt> is <bcp14>REQUIRED</bcp14>.</t>
      </section>
      <section anchor="side-channel-attacks">
        <name>Side-Channel Attacks</name>
        <t>Implementations of the signing algorithm <bcp14>SHOULD</bcp14> protect the secret key from side-channel attacks. Any implementation of SLH-DSA signing algorithms <bcp14>SHOULD</bcp14> employ at least the following best practices:</t>
        <ul spacing="normal">
          <li>
            <t>Constant-time operation</t>
          </li>
          <li>
            <t>Consistent instruction sequence and memory access</t>
          </li>
          <li>
            <t>Uniform sampling without information leakage</t>
          </li>
        </ul>
      </section>
      <section anchor="randomness-considerations">
        <name>Randomness considerations</name>
        <t>All nonces <bcp14>MUST</bcp14> originate from a trusted and cryptographically secure source of randomness.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="new-cose-algorithms">
        <name>New COSE Algorithms</name>
        <t>IANA is requested to add the following entries to the COSE Algorithms Registry.</t>
        <t>The following registration templates are provided in accordance with the procedures described in <xref target="RFC9053"/> and <xref target="RFC9054"/>.</t>
        <section anchor="slh-dsa-sha2-128s">
          <name>SLH-DSA-SHA2-128s</name>
          <ul spacing="normal">
            <li>
              <t>Name: SLH-DSA-SHA2-128s</t>
            </li>
            <li>
              <t>Value: TBD1 (requested assignment -51)</t>
            </li>
            <li>
              <t>Description: CBOR Object Signing Algorithm for SLH-DSA-SHA2-128s</t>
            </li>
            <li>
              <t>Capabilities: <tt>[kty]</tt></t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Reference: RFC XXXX</t>
            </li>
            <li>
              <t>Recommended: Yes</t>
            </li>
          </ul>
        </section>
        <section anchor="slh-dsa-shake-128s">
          <name>SLH-DSA-SHAKE-128s</name>
          <ul spacing="normal">
            <li>
              <t>Name: SLH-DSA-SHAKE-128s</t>
            </li>
            <li>
              <t>Value: TBD2 (requested assignment -52)</t>
            </li>
            <li>
              <t>Description: CBOR Object Signing Algorithm for SLH-DSA-SHAKE-128s</t>
            </li>
            <li>
              <t>Capabilities: <tt>[kty]</tt></t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Reference: RFC XXXX</t>
            </li>
            <li>
              <t>Recommended: Yes</t>
            </li>
          </ul>
        </section>
        <section anchor="slh-dsa-sha2-128f">
          <name>SLH-DSA-SHA2-128f</name>
          <ul spacing="normal">
            <li>
              <t>Name: SLH-DSA-SHA2-128f</t>
            </li>
            <li>
              <t>Value: TBD3 (requested assignment -53)</t>
            </li>
            <li>
              <t>Description: CBOR Object Signing Algorithm for SLH-DSA-SHA2-128f</t>
            </li>
            <li>
              <t>Capabilities: <tt>[kty]</tt></t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Reference: RFC XXXX</t>
            </li>
            <li>
              <t>Recommended: Yes</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="new-jose-algorithms">
        <name>New JOSE Algorithms</name>
        <t>IANA is requested to add the following entries to the JSON Web Signature and Encryption Algorithms Registry.</t>
        <t>The following completed registration templates are provided as described in <xref target="RFC7518"/>.</t>
        <section anchor="slh-dsa-sha2-128s-1">
          <name>SLH-DSA-SHA2-128s</name>
          <ul spacing="normal">
            <li>
              <t>Algorithm Name: SLH-DSA-SHA2-128s</t>
            </li>
            <li>
              <t>Algorithm Description: SLH-DSA-SHA2-128s as described in FIPS 205.</t>
            </li>
            <li>
              <t>Algorithm Usage Location(s): alg</t>
            </li>
            <li>
              <t>JOSE Implementation Requirements: Optional</t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Specification Document(s): RFC XXXX</t>
            </li>
            <li>
              <t>Algorithm Analysis Documents(s): <xref target="FIPS-205"/></t>
            </li>
          </ul>
        </section>
        <section anchor="slh-dsa-shake-128s-1">
          <name>SLH-DSA-SHAKE-128s</name>
          <ul spacing="normal">
            <li>
              <t>Algorithm Name: SLH-DSA-SHAKE-128s</t>
            </li>
            <li>
              <t>Algorithm Description: SLH-DSA-SHAKE-128s as described in FIPS 205.</t>
            </li>
            <li>
              <t>Algorithm Usage Location(s): alg</t>
            </li>
            <li>
              <t>JOSE Implementation Requirements: Optional</t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Specification Document(s): RFC XXXX</t>
            </li>
            <li>
              <t>Algorithm Analysis Documents(s): <xref target="FIPS-205"/></t>
            </li>
          </ul>
        </section>
        <section anchor="slh-dsa-sha2-128f-1">
          <name>SLH-DSA-SHA2-128f</name>
          <ul spacing="normal">
            <li>
              <t>Algorithm Name: SLH-DSA-SHA2-128f</t>
            </li>
            <li>
              <t>Algorithm Description: SLH-DSA-SHA2-128f as described in FIPS 205.</t>
            </li>
            <li>
              <t>Algorithm Usage Location(s): alg</t>
            </li>
            <li>
              <t>JOSE Implementation Requirements: Optional</t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Specification Document(s): RFC XXXX</t>
            </li>
            <li>
              <t>Algorithm Analysis Documents(s): <xref target="FIPS-205"/></t>
            </li>
          </ul>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC7515">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC7517">
          <front>
            <title>JSON Web Key (JWK)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7517"/>
          <seriesInfo name="DOI" value="10.17487/RFC7517"/>
        </reference>
        <reference anchor="RFC7518">
          <front>
            <title>JSON Web Algorithms (JWA)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7518"/>
          <seriesInfo name="DOI" value="10.17487/RFC7518"/>
        </reference>
        <reference anchor="RFC9052">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.</t>
              <t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="96"/>
          <seriesInfo name="RFC" value="9052"/>
          <seriesInfo name="DOI" value="10.17487/RFC9052"/>
        </reference>
        <reference anchor="RFC9053">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t>
              <t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9053"/>
          <seriesInfo name="DOI" value="10.17487/RFC9053"/>
        </reference>
        <reference anchor="RFC9054">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Hash Algorithms</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9054"/>
          <seriesInfo name="DOI" value="10.17487/RFC9054"/>
        </reference>
        <reference anchor="I-D.ietf-cose-dilithium">
          <front>
            <title>ML-DSA for JOSE and COSE</title>
            <author fullname="Michael Prorock" initials="M." surname="Prorock">
              <organization>Tradeverifyd</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization>Tradeverifyd</organization>
            </author>
            <date day="12" month="September" year="2025"/>
            <abstract>
              <t>   This document describes JSON Object Signing and Encryption (JOSE) and
   CBOR Object Signing and Encryption (COSE) serializations for Module-
   Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum
   Cryptography (PQC) digital signature scheme defined in FIPS 204.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-dilithium-09"/>
        </reference>
        <reference anchor="FIPS-205" target="https://doi.org/10.6028/NIST.FIPS.205">
          <front>
            <title>Stateless Hash-Based Digital Signature Standard</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="IANA.jose" target="https://www.iana.org/assignments/jose">
          <front>
            <title>JSON Object Signing and Encryption (JOSE)</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IANA.cose" target="https://www.iana.org/assignments/cose">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>
    </references>
    <?line 241?>

<section anchor="examples">
      <name>Examples</name>
      <section anchor="jose">
        <name>JOSE</name>
        <section anchor="key-pair">
          <name>Key Pair</name>
          <figure anchor="SLH-DSA-SHA2-128s-private-jwk">
            <name>Example SLH-DSA-SHA2-128s Private JSON Web Key</name>
            <sourcecode type="json"><![CDATA[
{
  "kty": "AKP",
  "alg": "SLH-DSA-SHA2-128s",
  "pub": "V53SIdVF...uvw2nuCQ",
  "priv": "V53SIdVF...cDKLbsBY"
}
]]></sourcecode>
          </figure>
          <figure anchor="SLH-DSA-SHA2-128s-public-jwk">
            <name>Example SLH-DSA-SHA2-128s Public JSON Web Key</name>
            <sourcecode type="json"><![CDATA[
{
  "kty": "AKP",
  "alg": "SLH-DSA-SHA2-128s",
  "pub": "V53SIdVF...uvw2nuCQ"
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="json-web-signature">
          <name>JSON Web Signature</name>
          <figure anchor="SLH-DSA-SHA2-128s-jose-jws">
            <name>Example SLH-DSA-SHA2-128s Compact JSON Web Signature</name>
            <artwork><![CDATA[
eyJhbGciOiJ...LCJraWQiOiI0MiJ9\
.\
eyJpc3MiOiJ1cm46d...XVpZDo0NTYifQ\
.\
5MSEgQ0dZB4SeLC...AAAAAABIhMUE
]]></artwork>
          </figure>
        </section>
      </section>
      <section anchor="cose">
        <name>COSE</name>
        <section anchor="key-pair-1">
          <name>Key Pair</name>
          <figure anchor="SLH-DSA-SHA2-128s-private-cose-key">
            <name>Example SLH-DSA-SHA2-128s Private COSE Key</name>
            <sourcecode type="cbor-diag"><![CDATA[
{
  1: 7,
  3: -51,
  -1: h'7803c0f9...3f6e2c70',
  -2: h'7803c0f9...3bba7abd'
}
]]></sourcecode>
          </figure>
          <figure anchor="SLH-DSA-SHA2-128s-public-cose-key">
            <name>Example SLH-DSA-SHA2-128s Public COSE Key</name>
            <sourcecode type="cbor-diag"><![CDATA[
{
  1: 7,
  3: -51,
  -2: h'7803c0f9...3bba7abd'
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="cosesign1-example">
          <name>COSE_Sign1 Example</name>
          <figure anchor="SLH-DSA-SHA2-128s-cose-sign-1-diagnostic">
            <name>Example SLH-DSA-SHA2-128s COSE Sign1</name>
            <sourcecode type="cbor-diag"><![CDATA[
18([
  <<{1: -51}>>,
  {},
  h'66616b65',
  h'53e855e8...0f263549'
])
]]></sourcecode>
          </figure>
        </section>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank Roy Williams, Cedric Fournet, Simo Sorce, Ilari Liusvaara, Neil Madden, Anders Rundgren, David Waite, and Russ Housley for their review feedback.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact fullname="Rafael Misoczki">
        <organization>Google</organization>
        <address>
          <email>rafaelmisoczki@google.com</email>
        </address>
      </contact>
      <contact fullname="Michael Osborne">
        <organization>IBM</organization>
        <address>
          <email>osb@zurich.ibm.com</email>
        </address>
      </contact>
      <contact fullname="Christine Cloostermans">
        <organization>NXP</organization>
        <address>
          <email>christine.cloostermans@nxp.com</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va2VrbSBa+11PUmItANzLYZosnnY4xEMwOhtDp5ZuUpJJd
QVKpq0o4DiHPMs8yTzbnVEm2ZRtC0svFjC+wVMtZ/rNWGdd1Hc11xJqk0j3a
d3e6LRIKSQ5Ou7uEJgFpw0PF8almPSGHTaJ04DiB8BMaw55A0lC7nOnQ9YVi
rkr7PPGVm0aZclc3HJV5MVeKi0QPU1jf2b3cc5Is9phsOgEQbTq+SBRLVKaa
RMuMObdN0nCoZBQlYn4muR5WnIGQNz0pshRG29unF+TUe898Tbq8l/CkZ0Td
TXw5TDUwqzg3bAhbgqZDXKMLfrfz77PzNn51z/Y7J+3u9+bZqu44tyzJQChC
voYZIVa7yjVIiQte42YcjymPYByxeYUoVYXs4TiVfh/G+1qnqrmygstwiN+y
arFsBQdWPCkGiq0ggRXc2OO6n3k5SXfQW3nMArghApCVnuCVb6xaSlUuHiXx
6GS1r+Oo4jg0030hEWtgSEiYRZF1j8ox9/uUReRMCin8m4qZB+Vowj9SBK9J
YqYyCWKYKZYDFqd2w6titjKH+KnkjHQ1YxGbR/hS0oDdMsnDYVAiLmDfKyFr
jQfo7tMkYYpcKr8vQpbw3jzqVwkYSypwTiJC0krTiLOAdH3OEh82b4skcS/6
jCdul7OeIUA9T7JbZOBuX3QtUV9kica4es1kTJNhSdC+EaSqR4K86sUfqgnT
gDmEjZbcy/R84C9oiLgfcyX8jzd8ngavhehFrMRQml1xvulVz6yo+iKeB1Nh
21PlCZnMNUFn+7iMvPJefYSI9vtV7sUPEW73JVeaJ4y0IyGUNsioefRPfjor
0feLnVV/Yuer5ENqeTmJgBENlsMQv9hrb67X1pvk4Lo7et3E18PR6xa+tuzr
89X1ejPPIvl7w767rag3GlvLx/YZ+J90z6gEtUAUBSs67k51HEsBjyAIeRY3
yfGRyT+E7HXOum59db1pFBulZg1hHDGlyD5VfXebKnC2HQ4xTCOTlqjOJAYD
pCYqA4uVprLHIPSLyA8EN4mltlrdWK1vrZx0updV5FcFfo7Dk3ASnU7rpFV9
D2I2x4/FsD8exkfHcaGM4B/wcaUl9bXjXPa5IlAospglmqiU+TzkEBkH3dOT
xxMqWcSMvWTLzxfTL1lsm9UKIp1GuWsoU8S+EjWymJeBpWVCyRn4j3ue0URn
MWkjM9GTNO0PySIUkCUS5HTUiA6EKYsZCVgIHhgQnpCrLkGQjVEJgFx1LEox
DwIIPWeBdCCKRZD5KPSfgdndnQvefH//leDBNnyAfXNg1H32R6Ac9CHeyYCC
ZkD7FvaFUsTkDWZPkKBRrWEGLarxU6D3DPcHDaByIfhHa4W7uyKo7u+r0yB7
GY8CRUAQVBPiGKqD7sfkkA3JGeWSLLYOz5ZMgQfR1KR1ATQbtkCWXOLuwzOz
kLCEegAWCSP2gcMTkSyVDNocbWBFfaFBUSRDPagvBeAa8DBkEkVKUf3fc/X9
sfrcJ7SQTy2DBH6UBWjTHOsqOtQl5DyeiEj0hqgqQ0YEWyEFGfuqe1lZtt/k
5NQ8X+yeX3UudnfwubvfOjoaPTj5iu7+6dXRzvhpvLN9eny8e7JjN8MoKQ05
lePWW5hBj6ucnl12Tk9aRxUETpcsAL0e0YJ4DKYgTQJQGlFRTsCUDyXOgr3d
PvvPv2trAPo/IM3Wa7Xn4Kz2Zau2uQYvgz5LLDeRRMP8FYw6dGiaMiqRCo0i
4tMU/UYZc6q+GCSkD8ADet/9gsj81iQvPD+trb3MB1Dh0mCBWWnQYDY7MrPZ
gjhnaA6bEZql8Smky/K23pbeC9wnBl/8GGFtdWtbP750jMtgfOe9/zgA9mjM
o9yHitmJQLehBnZMi/pmwg0MqbI0FVJPOLTK23gSQT8WqZkY5HkShIjBIJSs
x7GKFKGCY6GIIjEwCWwUAnkMjqrT/X3TcT6RExCH2M8nXA1/d4wn2Yz3yfnk
Tn4+lb6KQaCTK+2CGeturb6lkN6cQcPHZOhr5k1ANIbS1KKZjVM8Dnfz4XmD
X81jRG2OIuE8RcJvVSQEHndNsoAWcCeMA0Wkl/xQiVioK7aP+aFiTpWt8ZoJ
epX7v8Ar/L/JKy63d2pk0V2vLcHLvKr7zb4AlOtIuf7VlL/oAUC6gaQb3yZ0
YXf/CXZvP273hVGCgaqrHOcM2gRoN0wuTzMvgsJnyiVWitT6hMk0tswaT8Am
wKy3Bz4iUiYnWhhGoQXJnabgNZa5Ws5y0zkQy7R6vD3AIvuEFgHcG686oBWA
g1+cgoAeHgGGsz3AQ2UfxKAaBTLNBqqGrMvtRa5O3j6Wdk8AvwyJGkABeWfc
cXmOH9nKOuMEy8YoExpP1XbYgwtMo8Ntj/UO5HlHbmmUMTQJTYwqs2qYWmJ0
GJp9vpAwm4okKAW80TaLvVRCwihpOHYaBDszXYUPVMx+II5EwZ187GpLvcak
1Yx3FvWrDf7Eg8KzcpiLSb80iaoVzfiyfTrM2/K82cZDI46kKbiYEQeQK4xm
EQDjDFgUgRAtkFDDIRcEHDGkCY2GihtWhcrw5rEhYGSjwoc4sH4/TfufQIeV
WmMDHQ0CjtPQV1uGRXCMU+2UniP5sbcaNQNAXU+hOisDgrtA3kDGCOAdSJ/Z
YLdZoAX0ph3fhjXDdn0yMUj2e8bBzrc5KZj2GKhjHK9K9kAxTBDLRXYwiUUK
AMYeGZRpFE1Ywdg74J8Lxd4hokW/Z+XtgvJu29zNRKSlNfVvQNpOnEYsLnxX
FclGFceuUebImz1grzHZautC0PSaEDBHI4TX9XMO1HKoklYyJLzEZdLwM4xU
wYnBHgE6a2i/qNJThdNjMJTikZ1DIECpdI2XwxFKu5pDzRxl0nwGirCtzlCM
7bkV5P89w2svg2vMYiExo2FcwZ6rhOO9AlEU5ECOA5BOZEghv28ACiDZDe0x
g+8FUBFxglHpT8UbukQizAWbacxB0x5P0CEMbhRvkJWJcxCklELBOYc2cgBu
kUnfWFqOWJk4x55hJsZBohM2IFMlDAyOi7n1PWaYYgwEwRS+DK/psHzYfDNd
CS9sVzOcibJSu6PRhniRW5TAW5DQBJVNaBTBR1zHOS0wVWY6rU3mnYlMNHNV
ZRPfwsJsbYBTkumlmnOmvsNYzmDK9kNjZKhC9zQVAZskWDjRezW/pWMCEm2a
UlM+Ad4meffLjR7+9g7HIXB6DO0I/WMUMZn/7PAdgG2qqw8SwrGR/AQfMwrl
AWQDRJvkLVMziucVcK7mxdyk6vUHVa//MdXHzP423W2Vf9joYUnzxoOaN/4E
o4d/seImzg/+nDifc4yaunl7ShLAviUy1yFPSQd0Nt4PrluPh/IY8YeDerym
ZMDZU8y0AONrz0kiVwoyPTkStgdYVEtNLFqwxEBfrqMAjansOAD2Pk1tb/Ko
wbulFmonb0UNnwkHGMvTKtqoYqkyaydbo8dSwiMIjuP1yxAWx7X/HwzHqeVL
Thg+3QnD/2UA8acDD5pB7FV2P2A/lScu8wu3wbc4lzrO58+f3yvo2u4cQiqQ
JitNUoGDVmUZ30HXyvgX/3EI21lorXH2zXqj2wne7FWr1ex2UE+y9nk+D+fz
qQX+zuGRp7bfVpx75GxuBmaou6k92LvvBzfF1UCux5xsUtwCjFIp6Ia3BX+N
Yo/Lbc4aTxTbnkumpUbjzBYFo43Dhgd977XPT/kBiHTUPpD0+hzeOqvH/OD5
r071V1yS+o1jXFLz47WNABb+9Cb9eUesnly+5eG5WbV+3N3tna8GP2+vddlR
G9a0zGe70z++2n1EQXN5936gvqxeG+8toGTP6mK1tL+PzvriZ+J7QroBpz1j
uVqTbKJNGk1sCfHJhaH+s82t1Ya/Gj4H2RvhBqv7m6vPzGx9etbz6Cb1gmfW
cl9yOXNNZa5pnup3plUf+9wTFPhWEa13fYWE1sUmBVzIkf8XmqNWZIcZwWtb
i7+ApC9e3NWM2PcvX6Lkd/f4t/9sY2OjtuFtrD+zr+sNtrW+zrZAldWwvtFY
X3v+zPlt6TFd7P+IgAxuzXBMhIKD5RPcCnUxstsLwZZ/k4hBxIKeSYbAzf7X
EAt+qIQ0UsbbruHQI7IoIBG/YbbzoskNuYDT7jWPIk7xZ7I2CyRIsAeHvoTp
ZWASC9IVcAJcJp2ISk6OeKZuKZx9lqED5BE5hu4OfztqQXcooTvLkqAncWCH
QqNFrinXzF6HXWT4g6jIVIRHd/tTKZfQrN1yaCVDxgJM11Xnv1zJw8tmJQAA

-->

</rfc>
