<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-lamps-cms-kyber-13" number="9936" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2026-03-06T15:20:31" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber-13" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9936" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ML-KEM in the CMS">Use of ML-KEM in the Cryptographic Message Syntax (CMS)</title>
    <seriesInfo name="RFC" value="9936" stream="IETF"/>
    <author initials="J." surname="Prat" fullname="Julien Prat">
      <organization showOnFrontPage="true">CryptoNext Security</organization>
      <address>
        <postal>
          <street>16, Boulevard Saint-Germain</street>
          <city>Paris</city>
          <code>75005</code>
          <country>France</country>
        </postal>
        <email>julien.prat@cryptonext-security.com</email>
      </address>
    </author>
    <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
      <organization abbrev="Entrust" showOnFrontPage="true">Entrust Limited</organization>
      <address>
        <postal>
          <street>2500 Solandt Road -- Suite 100</street>
          <city>Ottawa</city>
          <region>Ontario</region>
          <code>K2K 3G5</code>
          <country>Canada</country>
        </postal>
        <email>mike.ounsworth@entrust.com</email>
      </address>
    </author>
    <author initials="D." surname="Van Geest" fullname="Daniel Van Geest">
      <organization showOnFrontPage="true">CryptoNext Security</organization>
      <address>
        <postal>
          <street>16, Boulevard Saint-Germain</street>
          <city>Paris</city>
          <code>75005</code>
          <country>France</country>
        </postal>
        <email>daniel.vangeest@cryptonext-security.com</email>
      </address>
    </author>
    <date month="03" year="2026"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>
    <keyword>Key Encapsulation Mechanism (KEM)</keyword>
    <keyword>KEMRecipientInfo</keyword>
    <keyword>ML-KEM</keyword>
    <keyword>Kyber</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US National Institute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation
Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629).</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9936" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-terminology">Conventions and Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ml-kem">ML-KEM</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-the-ml-kem-algorithm">Use of the ML-KEM Algorithm in the CMS</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recipientinfo-conventions">RecipientInfo Conventions</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-underlying-components">Underlying Components</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2">
                  <li pn="section-toc.1-1.2.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.1.1"><xref derivedContent="2.2.1" format="counter" sectionFormat="of" target="section-2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-the-hkdf-based-key-d">Use of the HKDF-Based Key Derivation Function</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificate-conventions">Certificate Conventions</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-smime-capabilities-attribut">SMIME Capabilities Attribute Conventions</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identifiers">Identifiers</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-asn1-module">ASN.1 Module</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-parameter-set-security-and-">Parameter Set Security and Sizes</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ml-kem-cms-authenticated-en">ML-KEM CMS Authenticated-Enveloped-Data Example</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="C.1" format="counter" sectionFormat="of" target="section-appendix.c.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-originator-cms-processing">Originator CMS Processing</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="C.2" format="counter" sectionFormat="of" target="section-appendix.c.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recipient-cms-processing">Recipient CMS Processing</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec-introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> by the NIST PQC Project <xref target="NIST-PQ" format="default" sectionFormat="of" derivedContent="NIST-PQ"/>. ML-KEM is the name given to the final standardized version and is incompatible with pre-standards versions, often called "Kyber".</t>
      <t indent="0" pn="section-1-2"><xref target="RFC9629" format="default" sectionFormat="of" derivedContent="RFC9629"/> defines the KEMRecipientInfo structure for the use of KEM algorithms for the CMS enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document specifies the direct use of ML-KEM in the KEMRecipientInfo structure using each of the three parameter sets from <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/>, namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024.  It does not address or preclude the use of ML-KEM as part of any hybrid scheme.</t>
      <section anchor="sec-intro-terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-conventions-and-terminology">Conventions and Terminology</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
      <section anchor="sec-intro-ml-kem" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-ml-kem">ML-KEM</name>
        <t indent="0" pn="section-1.2-1">ML-KEM is a lattice-based KEM using Module Learning with Errors as its underlying primitive, which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. 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, respectively.
<xref target="arnold" format="default" sectionFormat="of" derivedContent="Appendix B"/> provides more information on ML-KEM security levels and sizes.</t>
        <t indent="0" pn="section-1.2-2">All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate().</t>
        <t indent="0" pn="section-1.2-3">The following summarizes these three functions for the ML-KEM algorithm, referencing corresponding functions in <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/>:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-1.2-4">
          <dt pn="section-1.2-4.1">KeyGen() -&gt; (ek, dk):</dt>
          <dd pn="section-1.2-4.2">
            <t indent="0" pn="section-1.2-4.2.1">Generate the public encapsulation key (ek) and a private decapsulation key (dk).  <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> specifies two formats for an ML-KEM private key: a 64-octet seed (d,z) and an (expanded) private decapsulation key (dk). Algorithm 19 (<tt>ML-KEM.KeyGen()</tt>) from <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> generates the public encapsulation key (ek) and the private decapsulation key (dk). As an alternative, when a seed (d,z) is generated first and then the seed is expanded to get the keys, algorithm 16 (<tt>ML-KEM.KeyGen_internal(d,z)</tt>) from <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> expands the seed to ek and dk. See <xref section="6" sectionFormat="of" target="RFC9935" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9935#section-6" derivedContent="RFC9935"/> for private key encoding considerations.</t>
          </dd>
          <dt pn="section-1.2-4.3">Encapsulate(ek) -&gt; (c, ss):</dt>
          <dd pn="section-1.2-4.4">
            <t indent="0" pn="section-1.2-4.4.1">Given the recipient's public key (ek), produce both a ciphertext (c) to be passed to the recipient and a shared secret (ss) for use by the originator. Algorithm 20 (<tt>ML-KEM.Encaps(ek)</tt>) from <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> is the encapsulation function for ML-KEM.</t>
          </dd>
          <dt pn="section-1.2-4.5">Decapsulate(dk, c) -&gt; ss:</dt>
          <dd pn="section-1.2-4.6">
            <t indent="0" pn="section-1.2-4.6.1">Given the private key (dk) and the ciphertext (c), produce the shared secret (ss) for the recipient.  Algorithm 21 (<tt>ML-KEM.Decaps(dk,c)</tt>) from <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> is the decapsulation function for ML-KEM. If the private key is stored in seed form, <tt>ML-KEM.KeyGen_internal(d,z)</tt> may be needed as a first step to compute dk. See <xref section="8" sectionFormat="of" target="RFC9935" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9935#section-8" derivedContent="RFC9935"/> for consistency considerations if the private key was stored in both seed and expanded formats.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-1.2-5">All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE128, and SHAKE256 internally.</t>
      </section>
    </section>
    <section anchor="sec-using" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-use-of-the-ml-kem-algorithm">Use of the ML-KEM Algorithm in the CMS</name>
      <t indent="0" pn="section-2-1">The ML-KEM algorithm <bcp14>MAY</bcp14> be employed for one or more recipients in the CMS enveloped-data content type <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, the CMS authenticated-data content type <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, or the CMS authenticated-enveloped-data content type <xref target="RFC5083" format="default" sectionFormat="of" derivedContent="RFC5083"/>. In each case, the KEMRecipientInfo <xref target="RFC9629" format="default" sectionFormat="of" derivedContent="RFC9629"/> is used with the ML-KEM algorithm to securely transfer the content-encryption key from the originator to the recipient.</t>
      <t indent="0" pn="section-2-2">Processing ML-KEM with KEMRecipientInfo follows the same steps as <xref section="2" sectionFormat="of" target="RFC9629" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9629#section-2" derivedContent="RFC9629"/>. To support the ML-KEM algorithm, a CMS originator <bcp14>MUST</bcp14> implement the Encapsulate() function and a CMS recipient <bcp14>MUST</bcp14> implement the Decapsulate() function.</t>
      <section anchor="sec-using-recipientInfo" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-recipientinfo-conventions">RecipientInfo Conventions</name>
        <t indent="0" pn="section-2.1-1">When the ML-KEM algorithm is employed for a recipient, the RecipientInfo alternative for that recipient <bcp14>MUST</bcp14> be OtherRecipientInfo using the KEMRecipientInfo structure as defined in <xref target="RFC9629" format="default" sectionFormat="of" derivedContent="RFC9629"/>.</t>
        <t indent="0" pn="section-2.1-2">The fields of the KEMRecipientInfo have the following meanings:</t>
        <dl spacing="normal" newline="true" indent="3" pn="section-2.1-3">
          <dt pn="section-2.1-3.1">version</dt>
          <dd pn="section-2.1-3.2">The syntax version number; it <bcp14>MUST</bcp14> be 0.</dd>
          <dt pn="section-2.1-3.3">rid</dt>
          <dd pn="section-2.1-3.4">Identifies the recipient's certificate or public key.</dd>
          <dt pn="section-2.1-3.5">kem</dt>
          <dd pn="section-2.1-3.6">Identifies the KEM algorithm; it <bcp14>MUST</bcp14> contain one of id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These identifiers are reproduced in <xref target="sec-identifiers" format="default" sectionFormat="of" derivedContent="Section 3"/>.</dd>
          <dt pn="section-2.1-3.7">kemct</dt>
          <dd pn="section-2.1-3.8">The ciphertext produced for this recipient.</dd>
          <dt pn="section-2.1-3.9">kdf</dt>
          <dd pn="section-2.1-3.10">Identifies the key derivation algorithm. Note that the Key Derivation Function (KDF) used for CMS RecipientInfo process <bcp14>MAY</bcp14> be different than the KDF used within the ML-KEM algorithm. Implementations <bcp14>MUST</bcp14> support the HMAC-based Key Derivation Function (HKDF) <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/> with SHA-256 <xref target="FIPS180" format="default" sectionFormat="of" derivedContent="FIPS180"/> using the id-alg-hkdf-with-sha256 KDF object identifier (OID) <xref target="RFC8619" format="default" sectionFormat="of" derivedContent="RFC8619"/>. As specified in <xref target="RFC8619" format="default" sectionFormat="of" derivedContent="RFC8619"/>, the parameter field <bcp14>MUST</bcp14> be absent when this OID appears within the ASN.1 type AlgorithmIdentifier. Implementations <bcp14>MAY</bcp14> support other KDFs as well.</dd>
          <dt pn="section-2.1-3.11">kekLength</dt>
          <dd pn="section-2.1-3.12">The size of the key-encryption key in octets.</dd>
          <dt pn="section-2.1-3.13">ukm</dt>
          <dd pn="section-2.1-3.14">Optional input to the KDF. The secure use of ML-KEM in CMS does not depend on the use of a ukm value, so this document does not place any requirements on this value.  See <xref section="3" sectionFormat="of" target="RFC9629" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9629#section-3" derivedContent="RFC9629"/> for more information about the ukm parameter.</dd>
          <dt pn="section-2.1-3.15">wrap</dt>
          <dd pn="section-2.1-3.16">Identifies a key-encryption algorithm used to encrypt the content-encryption key. Implementations supporting ML-KEM-512 <bcp14>MUST</bcp14> support the AES-Wrap-128 <xref target="RFC3394" format="default" sectionFormat="of" derivedContent="RFC3394"/> key-encryption algorithm using the id-aes128-wrap key-encryption algorithm OID <xref target="RFC3565" format="default" sectionFormat="of" derivedContent="RFC3565"/>. Implementations supporting ML-KEM-768 or ML-KEM-1024 <bcp14>MUST</bcp14> support the AES-Wrap-256 <xref target="RFC3394" format="default" sectionFormat="of" derivedContent="RFC3394"/> key-encryption algorithm using the id-aes256-wrap key-encryption algorithm OID <xref target="RFC3565" format="default" sectionFormat="of" derivedContent="RFC3565"/>. Implementations <bcp14>MAY</bcp14> support other key-encryption algorithms as well.</dd>
        </dl>
        <t indent="0" pn="section-2.1-4"><xref target="example" format="default" sectionFormat="of" derivedContent="Appendix C"/> contains an example of establishing a content-encryption key using ML-KEM in the KEMRecipientInfo type.</t>
      </section>
      <section anchor="sec-using-components" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-underlying-components">Underlying Components</name>
        <t indent="0" pn="section-2.2-1">When ML-KEM is employed in the CMS, the underlying components used within the KEMRecipientInfo structure <bcp14>SHOULD</bcp14> be consistent with a minimum desired security level.
Several security levels have been identified in <xref target="NIST.SP.800-57pt1r5" format="default" sectionFormat="of" derivedContent="NIST.SP.800-57pt1r5"/>.</t>
        <t indent="0" pn="section-2.2-2">If underlying components other than those specified in <xref target="sec-using-recipientInfo" format="default" sectionFormat="of" derivedContent="Section 2.1"/> are used, then the following table gives the minimum requirements on the components used with ML-KEM in the KEMRecipientInfo type in order to satisfy the KDF and key wrapping algorithm requirements from <xref section="7" sectionFormat="of" target="RFC9629" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9629#section-7" derivedContent="RFC9629"/>:</t>
        <table anchor="tab-strong" align="center" pn="table-1">
          <name slugifiedName="name-ml-kem-kemrecipientinfo-com">ML-KEM KEMRecipientInfo Component Security Levels</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Security Strength</th>
              <th align="left" colspan="1" rowspan="1">Algorithm</th>
              <th align="left" colspan="1" rowspan="1">KDF Preimage Strength</th>
              <th align="left" colspan="1" rowspan="1">Symmetric Key-Encryption Strength</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">128-bit</td>
              <td align="left" colspan="1" rowspan="1">ML-KEM-512</td>
              <td align="left" colspan="1" rowspan="1">128-bit</td>
              <td align="left" colspan="1" rowspan="1">128-bit</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">192-bit</td>
              <td align="left" colspan="1" rowspan="1">ML-KEM-768</td>
              <td align="left" colspan="1" rowspan="1">192-bit</td>
              <td align="left" colspan="1" rowspan="1">192-bit (*)</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">256-bit</td>
              <td align="left" colspan="1" rowspan="1">ML-KEM-1024</td>
              <td align="left" colspan="1" rowspan="1">256-bit</td>
              <td align="left" colspan="1" rowspan="1">256-bit</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-2.2-4">(*) In the case of AES Key Wrap, a 256-bit key is typically used because AES-192 is not as commonly deployed.</t>
        <section anchor="use-of-the-hkdf-based-key-derivation-function" numbered="true" removeInRFC="false" toc="include" pn="section-2.2.1">
          <name slugifiedName="name-use-of-the-hkdf-based-key-d">Use of the HKDF-Based Key Derivation Function</name>
          <t indent="0" pn="section-2.2.1-1">The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions.</t>
          <sourcecode type="pseudocode" markers="false" pn="section-2.2.1-2">
HKDF(salt, IKM, info, L)
  = HKDF-Expand(HKDF-Extract(salt, IKM), info, L)</sourcecode>
          <t indent="0" pn="section-2.2.1-3">When used with KEMRecipientInfo, the salt parameter is unused; that is, it is the zero-length string "". The IKM, info, and L parameters correspond to the same KDF inputs from <xref section="5" sectionFormat="of" target="RFC9629" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9629#section-5" derivedContent="RFC9629"/>. The info parameter is independently generated by the originator and recipient. Implementations <bcp14>MUST</bcp14> confirm that L is consistent with the key size of the key-encryption algorithm.</t>
        </section>
      </section>
      <section anchor="sec-using-certs" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-certificate-conventions">Certificate Conventions</name>
        <t indent="0" pn="section-2.3-1"><xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> specifies the profile for using X.509 certificates in Internet applications.  A recipient static public key is needed
for ML-KEM and the originator obtains that public key from the recipient's certificate.  The conventions for carrying ML-KEM public keys are specified in <xref target="RFC9935" format="default" sectionFormat="of" derivedContent="RFC9935"/>.</t>
      </section>
      <section anchor="sec-using-smime-caps" numbered="true" removeInRFC="false" toc="include" pn="section-2.4">
        <name slugifiedName="name-smime-capabilities-attribut">SMIME Capabilities Attribute Conventions</name>
        <t indent="0" pn="section-2.4-1"><xref section="2.5.2" sectionFormat="of" target="RFC8551" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8551#section-2.5.2" derivedContent="RFC8551"/> defines the SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content type <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/>, a compliant implementation <bcp14>MAY</bcp14> include the SMIMECapabilities attribute that announces support for one or more of the ML-KEM algorithm identifiers.</t>
        <t indent="0" pn="section-2.4-2">The SMIMECapability SEQUENCE representing the ML-KEM algorithm <bcp14>MUST</bcp14> include one of the ML-KEM OIDs in the capabilityID field. When one of the ML-KEM OIDs appears in the capabilityID field, the parameters <bcp14>MUST NOT</bcp14> be present.</t>
      </section>
    </section>
    <section anchor="sec-identifiers" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-identifiers">Identifiers</name>
      <t indent="0" pn="section-3-1">All identifiers used to indicate ML-KEM within the CMS are defined in <xref target="CSOR" format="default" sectionFormat="of" derivedContent="CSOR"/> and <xref target="RFC8619" format="default" sectionFormat="of" derivedContent="RFC8619"/>; they are reproduced here for convenience:</t>
      <sourcecode type="asn.1" markers="false" pn="section-3-2">
  nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
      country(16) us(840) organization(1) gov(101) csor(3)
      nistAlgorithm(4) }
  kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 }

  id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }

  id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }

  id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { kems 3 }

  id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) alg(3) 28 }

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

  id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
  id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }</sourcecode>
    </section>
    <section anchor="sec-security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-4-1">The Security Considerations sections of <xref target="RFC9935" format="default" sectionFormat="of" derivedContent="RFC9935"/> and <xref target="RFC9629" format="default" sectionFormat="of" derivedContent="RFC9629"/> apply to this specification as well.</t>
      <t indent="0" pn="section-4-2">For ongoing discussions of ML-KEM-specific security considerations, refer to <xref target="I-D.sfluhrer-cfrg-ml-kem-security-considerations" format="default" sectionFormat="of" derivedContent="MLKEM-SEC-CONS"/>.</t>
      <t indent="0" pn="section-4-3">Implementations <bcp14>MUST</bcp14> protect the ML-KEM private key, the key-encryption key, the content-encryption key, message-authentication key, and the content-authenticated-encryption key. Of these keys, all but the private key are ephemeral and <bcp14>MUST</bcp14> be wiped after use. Disclosure of the ML-KEM private key could result in the compromise of all messages protected with that key. Disclosure of the key-encryption key, the content-encryption key, or the content-authenticated-encryption key could result in the compromise of the associated encrypted content. Disclosure of the key-encryption key, the message-authentication key, or the content-authenticated-encryption key could allow modification of the associated authenticated content.</t>
      <t indent="0" pn="section-4-4">Additional considerations related to key management may be found in <xref target="NIST.SP.800-57pt1r5" format="default" sectionFormat="of" derivedContent="NIST.SP.800-57pt1r5"/>.</t>
      <t indent="0" pn="section-4-5">The generation of private keys relies on random numbers, as does the encapsulation function of ML-KEM.  The use of inadequate pseudorandom number generators (PRNGs) to generate these values can result in little or no security.  In the case of key generation, a random 32-byte seed is used to deterministically derive the key (with an additional 32 bytes reserved as a rejection value). In the case of encapsulation, a KEM is derived from the underlying ML-KEM public key encryption algorithm by deterministically encrypting a random 32-byte message for the public key.  If the random value is weakly chosen, then an attacker may find it much easier to reproduce the PRNG environment that produced the keys or ciphertext, searching the resulting small set of possibilities for a matching public key or ciphertext value, rather than performing a more complex algorithmic attack against ML-KEM.  The generation of quality random numbers is difficult; see Section 3.3 of <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/> for some additional information.</t>
      <t indent="0" pn="section-4-6">ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations <bcp14>MUST NOT</bcp14> use intermediate values directly for any purpose.</t>
      <t indent="0" pn="section-4-7">Implementations <bcp14>SHOULD NOT</bcp14> reveal information about intermediate values or calculations, whether by timing or other "side channels"; otherwise, an opponent may be able to determine information about the keying data and/or the recipient's private key. Although not all intermediate information may be useful to an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically indicates that the information would not be useful to an opponent.</t>
      <t indent="0" pn="section-4-8">Generally, good cryptographic practice employs a given ML-KEM key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other and may be essential to maintain provable security.</t>
      <t indent="0" pn="section-4-9">Parties can gain assurance that implementations are correct through formal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) <xref target="CMVP" format="default" sectionFormat="of" derivedContent="CMVP"/>.</t>
    </section>
    <section anchor="sec-iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">For the ASN.1 Module in <xref target="asn1" format="default" sectionFormat="of" derivedContent="Appendix A"/>, IANA has assigned an OID for the module identifier (84) with a description of "id-mod-cms-ml-kem-2024" in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.sfluhrer-cfrg-ml-kem-security-considerations" to="MLKEM-SEC-CONS"/>
    <displayreference target="I-D.ietf-ipsecme-ikev2-mlkem" to="IKEv2-MLKEM"/>
    <references anchor="sec-combined-references" pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="CSOR" target="https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration" quoteTitle="true" derivedAnchor="CSOR">
          <front>
            <title>Computer Security Objects Register (CSOR)</title>
            <author initials="" surname="NIST" fullname="National Institute of Standards and Technology">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2025" month="June" day="13"/>
          </front>
        </reference>
        <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf" quoteTitle="true" derivedAnchor="FIPS180">
          <front>
            <title>Secure Hash Standard</title>
            <author>
              <organization abbrev="NIST" showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="NIST FIPS" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>
        <reference anchor="FIPS203" quoteTitle="true" target="https://doi.org/10.6028/NIST.FIPS.203" derivedAnchor="FIPS203">
          <front>
            <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
            <author>
              <organization abbrev="NIST" showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2024"/>
          </front>
          <seriesInfo name="NIST FIPS" value="203"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.203"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3394" target="https://www.rfc-editor.org/info/rfc3394" quoteTitle="true" derivedAnchor="RFC3394">
          <front>
            <title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2002"/>
          </front>
          <seriesInfo name="RFC" value="3394"/>
          <seriesInfo name="DOI" value="10.17487/RFC3394"/>
        </reference>
        <reference anchor="RFC3565" target="https://www.rfc-editor.org/info/rfc3565" quoteTitle="true" derivedAnchor="RFC3565">
          <front>
            <title>Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="July" year="2003"/>
            <abstract>
              <t indent="0">This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3565"/>
          <seriesInfo name="DOI" value="10.17487/RFC3565"/>
        </reference>
        <reference anchor="RFC5083" target="https://www.rfc-editor.org/info/rfc5083" quoteTitle="true" derivedAnchor="RFC5083">
          <front>
            <title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="November" year="2007"/>
            <abstract>
              <t indent="0">This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5083"/>
          <seriesInfo name="DOI" value="10.17487/RFC5083"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869" quoteTitle="true" derivedAnchor="RFC5869">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <date month="May" year="2010"/>
            <abstract>
              <t indent="0">This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5869"/>
          <seriesInfo name="DOI" value="10.17487/RFC5869"/>
        </reference>
        <reference anchor="RFC5911" target="https://www.rfc-editor.org/info/rfc5911" quoteTitle="true" derivedAnchor="RFC5911">
          <front>
            <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5911"/>
          <seriesInfo name="DOI" value="10.17487/RFC5911"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8411" target="https://www.rfc-editor.org/info/rfc8411" quoteTitle="true" derivedAnchor="RFC8411">
          <front>
            <title>IANA Registration for the Cryptographic Algorithm Object Identifier Range</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="R. Andrews" initials="R." surname="Andrews"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8411"/>
          <seriesInfo name="DOI" value="10.17487/RFC8411"/>
        </reference>
        <reference anchor="RFC8551" target="https://www.rfc-editor.org/info/rfc8551" quoteTitle="true" derivedAnchor="RFC8551">
          <front>
            <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="B. Ramsdell" initials="B." surname="Ramsdell"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8551"/>
          <seriesInfo name="DOI" value="10.17487/RFC8551"/>
        </reference>
        <reference anchor="RFC8619" target="https://www.rfc-editor.org/info/rfc8619" quoteTitle="true" derivedAnchor="RFC8619">
          <front>
            <title>Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8619"/>
          <seriesInfo name="DOI" value="10.17487/RFC8619"/>
        </reference>
        <reference anchor="RFC9629" target="https://www.rfc-editor.org/info/rfc9629" quoteTitle="true" derivedAnchor="RFC9629">
          <front>
            <title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="J. Gray" initials="J." surname="Gray"/>
            <author fullname="T. Okubo" initials="T." surname="Okubo"/>
            <date month="August" year="2024"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9629"/>
          <seriesInfo name="DOI" value="10.17487/RFC9629"/>
        </reference>
        <reference anchor="RFC9935" target="https://www.rfc-editor.org/info/rfc9935" quoteTitle="true" derivedAnchor="RFC9935">
          <front>
            <title>Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)</title>
            <author initials="S." surname="Turner" fullname="Sean Turner">
              <organization showOnFrontPage="true">sn3rd</organization>
            </author>
            <author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
              <organization showOnFrontPage="true">AWS</organization>
            </author>
            <author initials="J." surname="Massimo" fullname="Jake Massimo">
              <organization showOnFrontPage="true">AWS</organization>
            </author>
            <author initials="B. E." surname="Westerbaan" fullname="Bas Westerbaan">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date month="March" year="2026"/>
          </front>
          <seriesInfo name="RFC" value="9935"/>
          <seriesInfo name="DOI" value="10.17487/RFC9935"/>
        </reference>
        <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680" quoteTitle="true" derivedAnchor="X680">
          <front>
            <title>Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CMVP" target="https://csrc.nist.gov/projects/cryptographic-module-validation-program" quoteTitle="true" derivedAnchor="CMVP">
          <front>
            <title>Cryptographic Module Validation Program (CMVP)</title>
            <author>
              <organization showOnFrontPage="true">NIST</organization>
            </author>
            <date day="3" month="9" year="2025"/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-ipsecme-ikev2-mlkem" target="https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-mlkem-04" quoteTitle="true" derivedAnchor="IKEv2-MLKEM">
          <front>
            <title>Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
              <organization showOnFrontPage="true">Amazon Web Services</organization>
            </author>
            <date day="26" month="February" year="2026"/>
            <abstract>
              <t indent="0">NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are safe against cryptographically relevant quantum computers.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-ikev2-mlkem-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.sfluhrer-cfrg-ml-kem-security-considerations" target="https://datatracker.ietf.org/doc/html/draft-sfluhrer-cfrg-ml-kem-security-considerations-04" quoteTitle="true" derivedAnchor="MLKEM-SEC-CONS">
          <front>
            <title>ML-KEM Security Considerations</title>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Quynh Dang" initials="Q." surname="Dang">
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson">
              <organization showOnFrontPage="true">Ericsson</organization>
            </author>
            <author fullname="Kevin Milner" initials="K." surname="Milner">
              <organization showOnFrontPage="true">Quantinuum</organization>
            </author>
            <author fullname="Daniel Shiu" initials="D." surname="Shiu">
              <organization showOnFrontPage="true">Arqit Quantum Inc</organization>
            </author>
            <date day="17" month="November" year="2025"/>
            <abstract>
              <t indent="0">NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-sfluhrer-cfrg-ml-kem-security-considerations-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="NIST-PQ" target="https://csrc.nist.gov/projects/post-quantum-cryptography" quoteTitle="true" derivedAnchor="NIST-PQ">
          <front>
            <title>Post-Quantum Cryptography (PQC)</title>
            <author>
              <organization showOnFrontPage="true">NIST</organization>
            </author>
            <date year="2025" month="September" day="30"/>
          </front>
        </reference>
        <reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf" quoteTitle="true" derivedAnchor="NIST.SP.800-57pt1r5">
          <front>
            <title>Recommendation for Key Management: Part 1 - General</title>
            <author fullname="Elaine Barker" surname="Barker">
              <organization showOnFrontPage="true">Information Technology Laboratory</organization>
            </author>
            <date month="May" year="2020"/>
          </front>
          <seriesInfo name="NIST SP" value="800-57pt1r5"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
        </reference>
        <reference anchor="RFC9690" target="https://www.rfc-editor.org/info/rfc9690" quoteTitle="true" derivedAnchor="RFC9690">
          <front>
            <title>Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="February" year="2025"/>
            <abstract>
              <t indent="0">The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. This document obsoletes RFC 5990.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9690"/>
          <seriesInfo name="DOI" value="10.17487/RFC9690"/>
        </reference>
      </references>
    </references>
    <section anchor="asn1" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-asn1-module">ASN.1 Module</name>
      <t indent="0" pn="section-appendix.a-1">This appendix includes the ASN.1 module <xref target="X680" format="default" sectionFormat="of" derivedContent="X680"/> for ML-KEM. This module imports objects from <xref target="RFC5911" format="default" sectionFormat="of" derivedContent="RFC5911"/>, <xref target="RFC9629" format="default" sectionFormat="of" derivedContent="RFC9629"/>, <xref target="RFC8619" format="default" sectionFormat="of" derivedContent="RFC8619"/>, and <xref target="RFC9935" format="default" sectionFormat="of" derivedContent="RFC9935"/>.</t>
      <sourcecode markers="true" type="asn.1" pn="section-appendix.a-2">
CMS-ML-KEM-2024
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
  pkcs-9(9) smime(16) modules(0) id-mod-cms-ml-kem-2024(84) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS ALL;

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

  KEM-ALGORITHM
    FROM KEMAlgorithmInformation-2023  -- [RFC9629]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-kemAlgorithmInformation-2023(109) }

  kda-hkdf-with-sha256
    FROM HKDF-OID-2019  -- [RFC8619]
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) }

  kwa-aes128-wrap, kwa-aes256-wrap
    FROM CMSAesRsaesOaep-2009  -- [RFC5911]
       { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0)
       id-mod-cms-aes-02(38) }

  id-alg-ml-kem-512, id-alg-ml-kem-768, id-alg-ml-kem-1024,
  pk-ml-kem-512, pk-ml-kem-768, pk-ml-kem-1024
    FROM X509-ML-KEM-2024 -- [RFC9935]
       { iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-x509-ml-kem-2025(121) };

--
-- ML-KEM Key Encapsulation Mechanism Algorithms
--

kema-ml-kem-512 KEM-ALGORITHM ::= {
   IDENTIFIER id-alg-ml-kem-512
   PARAMS ARE absent
   PUBLIC-KEYS { pk-ml-kem-512 }
   UKM ARE optional
   SMIME-CAPS { IDENTIFIED BY id-alg-ml-kem-512 } }

kema-ml-kem-768 KEM-ALGORITHM ::= {
   IDENTIFIER id-alg-ml-kem-768
   PARAMS ARE absent
   PUBLIC-KEYS { pk-ml-kem-768 }
   UKM ARE optional
   SMIME-CAPS { IDENTIFIED BY id-alg-ml-kem-768 } }

kema-ml-kem-1024 KEM-ALGORITHM ::= {
   IDENTIFIER id-alg-ml-kem-1024
   PARAMS ARE absent
   PUBLIC-KEYS { pk-ml-kem-1024 }
   UKM ARE optional
   SMIME-CAPS { IDENTIFIED BY id-alg-ml-kem-1024 } }

-- Updates for the SMIME-CAPS Set from RFC 5911

SMimeCapsSet SMIME-CAPS ::=
   { kema-ml-kem-512.&amp;smimeCaps |
     kema-ml-kem-768.&amp;smimeCaps |
     kema-ml-kem-1024.&amp;smimeCaps |
     kda-hkdf-with-sha256.&amp;smimeCaps |
     kwa-aes128-wrap.&amp;smimeCaps |
     kwa-aes256-wrap.&amp;smimeCaps,
     ... }

END</sourcecode>
    </section>
    <section anchor="arnold" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-parameter-set-security-and-">Parameter Set Security and Sizes</name>
      <t indent="0" pn="section-appendix.b-1"> Instead of defining the strength of a quantum algorithm using the
   imprecise notion of bits of security, NIST has
defined security levels by picking a reference scheme, which
is expected to offer notable levels of resistance to both quantum and
classical attacks.  To wit, a KEM algorithm that achieves NIST Post-Quantum Cryptography (PQC)
security must require computational resources to break IND-CCA2
security comparable or greater than that required for key search
on AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively.
Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference.</t>
      <table anchor="tab-strengths" align="center" pn="table-2">
        <name slugifiedName="name-ml-kem-parameter-sets-nist-">ML-KEM parameter Sets, NIST Security Level, and Sizes in Bytes</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Parameter Set</th>
            <th align="left" colspan="1" rowspan="1">Level</th>
            <th align="left" colspan="1" rowspan="1">Encap. Key Size</th>
            <th align="left" colspan="1" rowspan="1">Decap. Key Size</th>
            <th align="left" colspan="1" rowspan="1">Ciphertext Size</th>
            <th align="left" colspan="1" rowspan="1">Shared Secret Size</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">ML-KEM-512</td>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">800</td>
            <td align="left" colspan="1" rowspan="1">1632</td>
            <td align="left" colspan="1" rowspan="1">768</td>
            <td align="left" colspan="1" rowspan="1">32</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ML-KEM-768</td>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">1184</td>
            <td align="left" colspan="1" rowspan="1">2400</td>
            <td align="left" colspan="1" rowspan="1">1088</td>
            <td align="left" colspan="1" rowspan="1">32</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ML-KEM-1024</td>
            <td align="left" colspan="1" rowspan="1">5</td>
            <td align="left" colspan="1" rowspan="1">1568</td>
            <td align="left" colspan="1" rowspan="1">3168</td>
            <td align="left" colspan="1" rowspan="1">1568</td>
            <td align="left" colspan="1" rowspan="1">32</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="example" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-ml-kem-cms-authenticated-en">ML-KEM CMS Authenticated-Enveloped-Data Example</name>
      <t indent="0" pn="section-appendix.c-1">This example shows the establishment of an AES-128 content-encryption
key using:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.c-2">
        <li pn="section-appendix.c-2.1">
          <t indent="0" pn="section-appendix.c-2.1.1">ML-KEM-512;</t>
        </li>
        <li pn="section-appendix.c-2.2">
          <t indent="0" pn="section-appendix.c-2.2.1">KEMRecipientInfo key derivation using HKDF with SHA-256; and</t>
        </li>
        <li pn="section-appendix.c-2.3">
          <t indent="0" pn="section-appendix.c-2.3.1">KEMRecipientInfo key wrap using AES-128-KEYWRAP.</t>
        </li>
      </ul>
      <t indent="0" pn="section-appendix.c-3">In real-world use, the originator would encrypt the content-
encryption key in a manner that would allow decryption with their own
private key as well as the recipient's private key.  This is omitted
in an attempt to simplify the example.</t>
      <section anchor="originator-cms-processing" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c.1">
        <name slugifiedName="name-originator-cms-processing">Originator CMS Processing</name>
        <t indent="0" pn="section-appendix.c.1-1">Alice obtains Bob's ML-KEM-512 public key:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-2">
-----BEGIN PUBLIC KEY-----
MIIDMjALBglghkgBZQMEBAEDggMhADmVgV5ZfRBDVc8pqlMzyTJRhp1bzb5IcST2
Ari2pmwWxHYWSK12XPXYAGtRXpBafwrAdrDGLvoygVPnylcBaZ8TBfHmvG+QsOSb
aTUSts6ZKouAFt38GmYsfj+WGcvYad13GvMIlszVkYrGy3dGbF53mZbWf/mqvJdQ
Pyx7fi0ADYZFD7GAfKTKvaRlgloxx4mht6SRqzhydl0yDQtxkg+iE8lAk0Frg7gS
Tmn2XmLLUADcw3qpoP/3OXDEdy81fSQYnKb1MFVowOI3ajdipoxgXlY8XSCVcuD8
dTLKKUcpU1VntfxBPF6HktJGRTbMgI+YrddGZPFBVm+QFqkKVBgpqYoEZM5BqLtE
wtT6PCwglGByjvFKGnxMm5jRIgO0zDUpFgqasteDj3/2tTrgWqMafWRrevpsRZMl
JqPDdVYZvplMIRwqMcBbNEeDbLIVC+GCna5rBMVTXP9Ubjkrp5dBFyD5JPSQpaxU
lfITVtVQt4KmTBaItrZVvMeEIZekNML2Vjtbfwmni8xIgjJ4NWHRb0y6tnVUAAUH
gVcMZmBLgXrRJSKUc26LAYYaS1p0UZuLb+UUiaUHI5Llh2JscTd2V10zgGocjicy
r5fCaA9RZmMxxOuLvAQxxPloMtrxs8RVKPuhU/bHixwZhwKUfM0zdyekb7U7oR3l
y0GRNGhZUWy2rXJADzzyCbI2rvNaWArIfrPjD6/WaXPKin3SZ1r0H3oXthQzzRr4
D3cIhp9mVIhJeYCxrBCgzctjagDthoGzXkKRJMqANQcluF+DperDpKPMFgCQPmUp
NWC5szblrw1SnawaBIEZMCy3qbzBELlIUb8CEX8ZncSFqFK3Rz8JuDGmgx1bVMC3
kNIlz2u5LZRiomzbM92lEjx6rw4moLg2Ve6ii/OoB0clAY/WuuS2Ac9huqtxp6PT
UZejQ+dLSicsEl1UCJZCbYW3lY07OKa6mH7DciXHtEzbEt3kU5tKsII2NoPwS/eg
nMXEHf6DChsWLgsyQzQ2LwhKFEZ3IzRLrdAA+NjFN8SPmY8FMHzr0e3guBw7xZoG
WhttY7Js
-----END PUBLIC KEY-----</sourcecode>
        <t indent="0" pn="section-appendix.c.1-3">Bob's ML-KEM-512 public key has the following key identifier:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-4">
599788C37AED400EE405D1B2A3366AB17D824A51</sourcecode>
        <t indent="0" pn="section-appendix.c.1-5">Alice generates a shared secret and ciphertext using Bob's ML-KEM-512 public key:</t>
        <t indent="0" pn="section-appendix.c.1-6">Shared secret:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-7">
7DF12D412AE299A24FDE6D7C3BB8E3194C80AD3C733DCF2775E09FE8BEDB86D8</sourcecode>
        <t indent="0" pn="section-appendix.c.1-8">Ciphertext:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-9">
3EA40FC6CA090E2C8AF76E2727AB38E0652D9515986FE186827FE84E596E421B
85FD459CC78997372C9DE31D191B39C1D5A3EB6DDB56AADEDE765CC390FDBBC2
F88CB175681D4201B81CCDFCB24FEF13AF2F5A1ABCF8D8AF384F02A010A6E919
F1987A5E9B1C0E2D3F07F58A9FA539CE86CC149910A1692C0CA4CE0ECE4EEED2
E6699CB976332452DE4A2EB5CA61F7B081330C34798EF712A24E59C33CEA1F1F
9E6D4FBF3743A38467430011336F62D870792B866BEFCD1D1B365BED1952673D
3A5B0C20B386B4EFD1CF63FD376BD47CCC46AC4DD8EC66B047C4C95ACFF1CFD0
28A419B002FDA1B617CBA61D2E91CFE8FFFBCB8FFD4D5F6AD8B158C219E36DC5
1405DC0C0B234979AC658E72BDDF1B6773B96B2AE3E4D07BE86048040C016743
6FA839E7529B00CC9AB55A2F25DB63CC9F557594E691C11E553D4A3EBC760F5F
19E5FE144838B4C7D1591DA9B5D467494FD9CAC52CC5504060399DBDB72298EB
9A4C017B00786FDC7D9D7AA57ADBB8B61C34DE1E288B2AB728171DCE143CD169
53F984C1AED559E56BAA0CE658D32CCE42F4407504CD7A579AD0EF9B77135EAA
39B6F93A3A2E5997807F06361C83F4E67F8E3F9CF68316011514F5D85A181CEA
D714CD4940E4EBAC01D66528DA32F89CEA0428E8EBCADCF8AA188C9F62E85B19
57655B7FE2B8D7973B7A7226B66D93BF7B232F3DCF653C84B4ECF1A9920DB194
9AD750B546A5552A20E54909719B8C0C07056FCB7E574AD2A32EC95001DDE844
81BE77D039ED5BF74262ECF3981F1B00D3366A9C2E061C47E241A061C6249560
D2B8446A480C38C28BA989D9F68ADC4BBAF2A20B47E4923128C72342D597FDA2
59DE0B83C2056D6B77E799B319324AA50B1D659C2A56029B7453C5F3BA5243D9
FA749D917C40D9D101E453BC8B10E42A7C089323C026F783E100B9FA6E701442
4DA6FA3792BC957EE8219D016B773F28FEDCC962A485ABAFFEC023281971E29A
A689839ECFD2619E92287CD230DB26A2507CC500EB1C7A5293B5FE917AE29BF1
AD350124F8A311635214B411DB9F67D3B85BD715018537EA45B41F41B4C66051</sourcecode>
        <t indent="0" pn="section-appendix.c.1-10">Alice encodes the CMSORIforKEMOtherInfo:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-11">
3010300B0609608648016503040105020110</sourcecode>
        <t indent="0" pn="section-appendix.c.1-12">Alice derives the key-encryption key from the shared secret and CMSORIforKEMOtherInfo using HKDF with SHA-256:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-13">
CF453A3E2BAE0A78701B8206C185A008</sourcecode>
        <t indent="0" pn="section-appendix.c.1-14">Alice randomly generates a 128-bit content-encryption key:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-15">
C5153005588269A0A59F3C01943FDD56</sourcecode>
        <t indent="0" pn="section-appendix.c.1-16">Alice uses AES-128-KEYWRAP to encrypt the content-encryption key with the key-encryption key:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-17">
C050E4392F9C14DD0AC2220203F317D701F94F9DD92778F5</sourcecode>
        <t indent="0" pn="section-appendix.c.1-18">Alice encrypts the padded content using AES-128-GCM with the content-encryption key and encodes the AuthEnvelopedData (using KEMRecipientInfo) and ContentInfo, and then sends the result to Bob.</t>
        <t indent="0" pn="section-appendix.c.1-19">The Base64-encoded result is:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-20">
-----BEGIN CMS-----
MIID4gYLKoZIhvcNAQkQARegggPRMIIDzQIBADGCA3ikggN0BgsqhkiG9w0BCRAN
AzCCA2MCAQCAFFmXiMN67UAO5AXRsqM2arF9gkpRMAsGCWCGSAFlAwQEAQSCAwA+
pA/GygkOLIr3bicnqzjgZS2VFZhv4YaCf+hOWW5CG4X9RZzHiZc3LJ3jHRkbOcHV
o+tt21aq3t52XMOQ/bvC+IyxdWgdQgG4HM38sk/vE68vWhq8+NivOE8CoBCm6Rnx
mHpemxwOLT8H9YqfpTnOhswUmRChaSwMpM4Ozk7u0uZpnLl2MyRS3koutcph97CB
Mww0eY73EqJOWcM86h8fnm1PvzdDo4RnQwARM29i2HB5K4Zr780dGzZb7RlSZz06
Wwwgs4a079HPY/03a9R8zEasTdjsZrBHxMlaz/HP0CikGbAC/aG2F8umHS6Rz+j/
+8uP/U1fatixWMIZ423FFAXcDAsjSXmsZY5yvd8bZ3O5ayrj5NB76GBIBAwBZ0Nv
qDnnUpsAzJq1Wi8l22PMn1V1lOaRwR5VPUo+vHYPXxnl/hRIOLTH0VkdqbXUZ0lP
2crFLMVQQGA5nb23IpjrmkwBewB4b9x9nXqletu4thw03h4oiyq3KBcdzhQ80WlT
+YTBrtVZ5WuqDOZY0yzOQvRAdQTNelea0O+bdxNeqjm2+To6LlmXgH8GNhyD9OZ/
jj+c9oMWARUU9dhaGBzq1xTNSUDk66wB1mUo2jL4nOoEKOjrytz4qhiMn2LoWxlX
ZVt/4rjXlzt6cia2bZO/eyMvPc9lPIS07PGpkg2xlJrXULVGpVUqIOVJCXGbjAwH
BW/LfldK0qMuyVAB3ehEgb530DntW/dCYuzzmB8bANM2apwuBhxH4kGgYcYklWDS
uERqSAw4woupidn2itxLuvKiC0fkkjEoxyNC1Zf9olneC4PCBW1rd+eZsxkySqUL
HWWcKlYCm3RTxfO6UkPZ+nSdkXxA2dEB5FO8ixDkKnwIkyPAJveD4QC5+m5wFEJN
pvo3kryVfughnQFrdz8o/tzJYqSFq6/+wCMoGXHimqaJg57P0mGekih80jDbJqJQ
fMUA6xx6UpO1/pF64pvxrTUBJPijEWNSFLQR259n07hb1xUBhTfqRbQfQbTGYFEw
DQYLKoZIhvcNAQkQAxwCARAwCwYJYIZIAWUDBAEFBBjAUOQ5L5wU3QrCIgID8xfX
AflPndknePUwOgYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBBjARBAxcpXRouBvwO42n
GGwCARCADZTIaJqZ0sOOGS+muggEEFzxeGxXx0ArVPyTwwpKRTM=
-----END CMS-----</sourcecode>
        <t indent="0" pn="section-appendix.c.1-21">This result decodes to:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.1-22">
     0 994: SEQUENCE {
     4  11:  OBJECT IDENTIFIER
          :   authEnvelopedData (1 2 840 113549 1 9 16 1 23)
    17 977:  [0] {
    21 973:   SEQUENCE {
    25   1:    INTEGER 0
    28 888:    SET {
    32 884:     [4] {
    36  11:      OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3'
    49 867:      SEQUENCE {
    53   1:       INTEGER 0
    56  20:       [0]
          :    59 97 88 C3 7A ED 40 0E E4 05 D1 B2 A3 36 6A B1
          :    7D 82 4A 51
    78  11:       SEQUENCE {
    80   9:        OBJECT IDENTIFIER '2 16 840 1 101 3 4 4 1'
          :         }
    91 768:       OCTET STRING
          :    3E A4 0F C6 CA 09 0E 2C 8A F7 6E 27 27 AB 38 E0
          :    65 2D 95 15 98 6F E1 86 82 7F E8 4E 59 6E 42 1B
          :    85 FD 45 9C C7 89 97 37 2C 9D E3 1D 19 1B 39 C1
          :    D5 A3 EB 6D DB 56 AA DE DE 76 5C C3 90 FD BB C2
          :    F8 8C B1 75 68 1D 42 01 B8 1C CD FC B2 4F EF 13
          :    AF 2F 5A 1A BC F8 D8 AF 38 4F 02 A0 10 A6 E9 19
          :    F1 98 7A 5E 9B 1C 0E 2D 3F 07 F5 8A 9F A5 39 CE
          :    86 CC 14 99 10 A1 69 2C 0C A4 CE 0E CE 4E EE D2
          :    E6 69 9C B9 76 33 24 52 DE 4A 2E B5 CA 61 F7 B0
          :    81 33 0C 34 79 8E F7 12 A2 4E 59 C3 3C EA 1F 1F
          :    9E 6D 4F BF 37 43 A3 84 67 43 00 11 33 6F 62 D8
          :    70 79 2B 86 6B EF CD 1D 1B 36 5B ED 19 52 67 3D
          :    3A 5B 0C 20 B3 86 B4 EF D1 CF 63 FD 37 6B D4 7C
          :    CC 46 AC 4D D8 EC 66 B0 47 C4 C9 5A CF F1 CF D0
          :    28 A4 19 B0 02 FD A1 B6 17 CB A6 1D 2E 91 CF E8
          :    FF FB CB 8F FD 4D 5F 6A D8 B1 58 C2 19 E3 6D C5
          :    14 05 DC 0C 0B 23 49 79 AC 65 8E 72 BD DF 1B 67
          :    73 B9 6B 2A E3 E4 D0 7B E8 60 48 04 0C 01 67 43
          :    6F A8 39 E7 52 9B 00 CC 9A B5 5A 2F 25 DB 63 CC
          :    9F 55 75 94 E6 91 C1 1E 55 3D 4A 3E BC 76 0F 5F
          :    19 E5 FE 14 48 38 B4 C7 D1 59 1D A9 B5 D4 67 49
          :    4F D9 CA C5 2C C5 50 40 60 39 9D BD B7 22 98 EB
          :    9A 4C 01 7B 00 78 6F DC 7D 9D 7A A5 7A DB B8 B6
          :    1C 34 DE 1E 28 8B 2A B7 28 17 1D CE 14 3C D1 69
          :    53 F9 84 C1 AE D5 59 E5 6B AA 0C E6 58 D3 2C CE
          :    42 F4 40 75 04 CD 7A 57 9A D0 EF 9B 77 13 5E AA
          :    39 B6 F9 3A 3A 2E 59 97 80 7F 06 36 1C 83 F4 E6
          :    7F 8E 3F 9C F6 83 16 01 15 14 F5 D8 5A 18 1C EA
          :    D7 14 CD 49 40 E4 EB AC 01 D6 65 28 DA 32 F8 9C
          :    EA 04 28 E8 EB CA DC F8 AA 18 8C 9F 62 E8 5B 19
          :    57 65 5B 7F E2 B8 D7 97 3B 7A 72 26 B6 6D 93 BF
          :    7B 23 2F 3D CF 65 3C 84 B4 EC F1 A9 92 0D B1 94
          :    9A D7 50 B5 46 A5 55 2A 20 E5 49 09 71 9B 8C 0C
          :    07 05 6F CB 7E 57 4A D2 A3 2E C9 50 01 DD E8 44
          :    81 BE 77 D0 39 ED 5B F7 42 62 EC F3 98 1F 1B 00
          :    D3 36 6A 9C 2E 06 1C 47 E2 41 A0 61 C6 24 95 60
          :    D2 B8 44 6A 48 0C 38 C2 8B A9 89 D9 F6 8A DC 4B
          :    BA F2 A2 0B 47 E4 92 31 28 C7 23 42 D5 97 FD A2
          :    59 DE 0B 83 C2 05 6D 6B 77 E7 99 B3 19 32 4A A5
          :    0B 1D 65 9C 2A 56 02 9B 74 53 C5 F3 BA 52 43 D9
          :    FA 74 9D 91 7C 40 D9 D1 01 E4 53 BC 8B 10 E4 2A
          :    7C 08 93 23 C0 26 F7 83 E1 00 B9 FA 6E 70 14 42
          :    4D A6 FA 37 92 BC 95 7E E8 21 9D 01 6B 77 3F 28
          :    FE DC C9 62 A4 85 AB AF FE C0 23 28 19 71 E2 9A
          :    A6 89 83 9E CF D2 61 9E 92 28 7C D2 30 DB 26 A2
          :    50 7C C5 00 EB 1C 7A 52 93 B5 FE 91 7A E2 9B F1
          :    AD 35 01 24 F8 A3 11 63 52 14 B4 11 DB 9F 67 D3
          :    B8 5B D7 15 01 85 37 EA 45 B4 1F 41 B4 C6 60 51
   863  13:       SEQUENCE {
   865  11:        OBJECT IDENTIFIER
          :         hkdfWithSha256 (1 2 840 113549 1 9 16 3 28)
          :         }
   878   1:       INTEGER 16
   881  11:       SEQUENCE {
   883   9:        OBJECT IDENTIFIER
          :         aes128-wrap (2 16 840 1 101 3 4 1 5)
          :         }
   894  24:       OCTET STRING
          :    C0 50 E4 39 2F 9C 14 DD 0A C2 22 02 03 F3 17 D7
          :    01 F9 4F 9D D9 27 78 F5
          :        }
          :       }
          :      }
   920  58:    SEQUENCE {
   922   9:     OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
   933  30:     SEQUENCE {
   935   9:      OBJECT IDENTIFIER
          :       aes128-GCM (2 16 840 1 101 3 4 1 6)
   946  17:      SEQUENCE {
   948  12:       OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C
   962   1:       INTEGER 16
          :        }
          :       }
   965  13:     [0] 94 C8 68 9A 99 D2 C3 8E 19 2F A6 BA 08
          :      }
   980  16:    OCTET STRING
          :    5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33
          :     }
          :    }
          :   }</sourcecode>
      </section>
      <section anchor="recipient-cms-processing" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.c.2">
        <name slugifiedName="name-recipient-cms-processing">Recipient CMS Processing</name>
        <t indent="0" pn="section-appendix.c.2-1">Bob's ML-KEM-512 private key:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.2-2">
-----BEGIN PRIVATE KEY-----
MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8=
-----END PRIVATE KEY-----</sourcecode>
        <t indent="0" pn="section-appendix.c.2-3">Bob decapsulates the ciphertext in the KEMRecipientInfo to get the ML-KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives the key-encryption key from the shared secret and the DER-encoded CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-128-KEYWRAP to decrypt the content-encryption key with the key-encryption key, and decrypts the encrypted contents with the content-encryption key, revealing the plaintext content:</t>
        <sourcecode type="test-vectors" markers="false" pn="section-appendix.c.2-4">
Hello, world!</sourcecode>
      </section>
    </section>
    <section anchor="sec-acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.d-1">This document borrows heavily from <xref target="RFC9690" format="default" sectionFormat="of" derivedContent="RFC9690"/>, <xref target="FIPS203" format="default" sectionFormat="of" derivedContent="FIPS203"/>, <xref target="RFC9935" format="default" sectionFormat="of" derivedContent="RFC9935"/>, and <xref target="I-D.ietf-ipsecme-ikev2-mlkem" format="default" sectionFormat="of" derivedContent="IKEv2-MLKEM"/>. Thanks go to the authors of
      those documents. "Copying always makes things easier and less error
      prone." - <xref target="RFC8411" format="default" sectionFormat="of" derivedContent="RFC8411"/>.</t>
      <t indent="0" pn="section-appendix.d-2">Thanks to <contact fullname="Carl Wallace"/>, <contact fullname="Jonathan Hammel"/>, and <contact fullname="Sean Turner"/> for
      the detailed review and <contact fullname="Carl Wallace"/> and <contact fullname="Philippe Cece"/> for interoperability testing for the
      examples.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="J." surname="Prat" fullname="Julien Prat">
        <organization showOnFrontPage="true">CryptoNext Security</organization>
        <address>
          <postal>
            <street>16, Boulevard Saint-Germain</street>
            <city>Paris</city>
            <code>75005</code>
            <country>France</country>
          </postal>
          <email>julien.prat@cryptonext-security.com</email>
        </address>
      </author>
      <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
        <organization abbrev="Entrust" showOnFrontPage="true">Entrust Limited</organization>
        <address>
          <postal>
            <street>2500 Solandt Road -- Suite 100</street>
            <city>Ottawa</city>
            <region>Ontario</region>
            <code>K2K 3G5</code>
            <country>Canada</country>
          </postal>
          <email>mike.ounsworth@entrust.com</email>
        </address>
      </author>
      <author initials="D." surname="Van Geest" fullname="Daniel Van Geest">
        <organization showOnFrontPage="true">CryptoNext Security</organization>
        <address>
          <postal>
            <street>16, Boulevard Saint-Germain</street>
            <city>Paris</city>
            <code>75005</code>
            <country>France</country>
          </postal>
          <email>daniel.vangeest@cryptonext-security.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
