rfc9936.original.xml   rfc9936.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-lamps-cms-kyber-13" number="9936" updates="" obsoletes="" xml:lang="en" ca
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft tegory="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="
-ietf-lamps-cms-kyber-13" category="std" consensus="true" submissionType="IETF" true" symRefs="true" version="3">
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.30.2 -->
<front> <front>
<title abbrev="ML-KEM in the CMS">Use of ML-KEM in the Cryptographic Message Syntax (CMS)</title> <title abbrev="ML-KEM in the CMS">Use of ML-KEM in the Cryptographic Message Syntax (CMS)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-kyber-13"/> <seriesInfo name="RFC" value="9936"/>
<author initials="J." surname="Prat" fullname="Julien Prat"> <author initials="J." surname="Prat" fullname="Julien Prat">
<organization>CryptoNext Security</organization> <organization>CryptoNext Security</organization>
<address> <address>
<postal> <postal>
<street>16, Boulevard Saint-Germain</street> <street>16, Boulevard Saint-Germain</street>
<city>Paris</city> <city>Paris</city>
<code>75005</code> <code>75005</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>julien.prat@cryptonext-security.com</email> <email>julien.prat@cryptonext-security.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Ounsworth" fullname="Mike Ounsworth"> <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
<organization abbrev="Entrust">Entrust Limited</organization> <organization abbrev="Entrust">Entrust Limited</organization>
<address> <address>
<postal> <postal>
<street>2500 Solandt Road -- Suite 100</street> <street>2500 Solandt Road -- Suite 100</street>
<city>Ottawa, Ontario</city> <city>Ottawa</city><region>Ontario</region>
<code>K2K 3G5</code> <code>K2K 3G5</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>mike.ounsworth@entrust.com</email> <email>mike.ounsworth@entrust.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Van Geest" fullname="Daniel Van Geest"> <author initials="D." surname="Van Geest" fullname="Daniel Van Geest">
<organization>CryptoNext Security</organization> <organization>CryptoNext Security</organization>
<address> <address>
<postal> <postal>
<street>16, Boulevard Saint-Germain</street> <street>16, Boulevard Saint-Germain</street>
<city>Paris</city> <city>Paris</city>
<code>75005</code> <code>75005</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>daniel.vangeest@cryptonext-security.com</email> <email>daniel.vangeest@cryptonext-security.com</email>
</address> </address>
</author> </author>
<date year="2025" month="September" day="23"/> <date year="2026" month="February"/>
<area>Security</area> <area>SEC</area>
<workgroup>LAMPS</workgroup> <workgroup>lamps</workgroup>
<keyword>Key Encapsulation Mechanism (KEM)</keyword> <keyword>Key Encapsulation Mechanism (KEM)</keyword>
<keyword>KEMRecipientInfo</keyword> <keyword>KEMRecipientInfo</keyword>
<keyword>ML-KEM</keyword> <keyword>ML-KEM</keyword>
<keyword>Kyber</keyword> <keyword>Kyber</keyword>
<abstract>
<?line 105?>
<t>Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resist <abstract>
ant key-encapsulation mechanism (KEM). Three parameter sets for the ML-KEM algor <t>Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resist
ithm are specified by the US National Institute of Standards and Technology (NIS ant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algor
T) in FIPS 203. In order of increasing security strength (and decreasing perform ithm are specified by the US National Institute of Standards and Technology (NIS
ance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This do T) in FIPS 203. In order of increasing security strength (and decreasing perform
cument specifies the conventions for using ML-KEM with the Cryptographic Message ance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This do
Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsu cument specifies the conventions for using ML-KEM with the Cryptographic Message
lation Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsu
lation
Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629) .</t> Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629) .</t>
<!-- End of Abstract -->
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber/"/>.
</t>
<t>
Discussion of this document takes place on the
Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group m
ailing list (<eref target="mailto:spasm@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/spasm/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/spasm/"
/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/lamps-wg/cms-kyber"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 112?>
<section anchor="sec-introduction"> <section anchor="sec-introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Module Lattice Key Encapsulation Mechanism (ML-KEM) is an IND-CCA2- <!-- [rfced] FYI: We have updated "Module Lattice Key Encapsulation Mechanism"
secure Key Encapsulation Mechanism (KEM) standardized in <xref target="FIPS203"/ to "Module-Lattice-Based Key-Encapsulation Mechanism" to match its use in
> by the NIST PQC Project <xref target="NIST-PQ"/>. ML-KEM is the name given to NIST FIPS 203 and draft-ietf-lamps-kyber-certificates (and for consistency with
the final standardized version and is incompatible with pre-standards versions, the Abstract). Please let us know any objections.
often called "Kyber".</t>
<t><xref target="RFC9629"/> defines the KEMRecipientInfo structure for the
use of KEM algorithms for the CMS enveloped-data content type, the CMS authenti
cated-data content type, and the CMS authenticated-enveloped-data content type.
This document specifies the direct use of ML-KEM in the KEMRecipientInfo structu
re using each of the three parameter sets from <xref target="FIPS203"/>, namely
MK-KEM-512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude the us
e of ML-KEM as part of any hybrid scheme.</t>
<section anchor="sec-intro-terminology">
<name>Conventions and Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and o
nly when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<!-- End of terminology section --> Original:
The Module Lattice Key Encapsulation Mechanism (ML-KEM) is an
IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in
[FIPS203] by the NIST PQC Project [NIST-PQ].
</section> Current:
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an
IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in [FIPS203]
by the NIST PQC Project [NIST-PQ].
-->
<t>The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an IND-CCA2-
secure Key Encapsulation Mechanism (KEM) standardized in <xref target="FIPS203"/
> by the NIST PQC Project <xref target="NIST-PQ"/>. ML-KEM is the name given to
the final standardized version and is incompatible with pre-standards versions,
often called "Kyber".</t>
<!-- [rfced] FYI: We believe "MK-KEM-512" should be "ML-KEM-512". We have
corrected as follows.
Original:
This document specifies the direct use of ML-KEM in the
KEMRecipientInfo structure using each of the three parameter sets from
[FIPS203], namely MK-KEM-512, ML-KEM-768, and ML-KEM-1024.
Current:
This document specifies the direct use of ML-KEM
in the KEMRecipientInfo structure using each of the three parameter
sets from [FIPS203], namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
-->
<t><xref target="RFC9629"/> defines the KEMRecipientInfo structure for the use o
f KEM algorithms for the CMS enveloped-data content type, the CMS authenticated-
data content type, and the CMS authenticated-enveloped-data content type. This d
ocument specifies the direct use of ML-KEM in the KEMRecipientInfo structure usi
ng each of the three parameter sets from <xref target="FIPS203"/>, namely ML-KEM
-512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude the use of M
L-KEM as part of any hybrid scheme.</t>
<section anchor="sec-intro-terminology">
<name>Conventions and 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&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
<section anchor="sec-intro-ml-kem"> <section anchor="sec-intro-ml-kem">
<name>ML-KEM</name> <name>ML-KEM</name>
<t>ML-KEM is a lattice-based key encapsulation mechanism using Module Le arning with Errors as its underlying primitive, which is a structured lattices v ariant that offers good performance and relatively small and balanced key and ci phertext sizes. ML-KEM was standardized with three parameter sets: ML-KEM-512, M L-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 bi ts, respectively. <t>ML-KEM is a lattice-based KEM using Module Learning with Errors as it s underlying primitive, which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM w as standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-10 24. 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"/> provides more information on ML-KEM security levels and sizes.</t> <xref target="arnold"/> provides more information on ML-KEM security levels and sizes.</t>
<t>All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate().</t> <t>All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate().</t>
<t>The following summarizes these three functions for the ML-KEM algorit hm, referencing corresponding functions in <xref target="FIPS203"/>:</t> <t>The following summarizes these three functions for the ML-KEM algorit hm, referencing corresponding functions in <xref target="FIPS203"/>:</t>
<dl> <dl>
<dt>KeyGen() -&gt; (ek, dk):</dt> <dt>KeyGen() -&gt; (ek, dk):</dt>
<dd> <dd>
<t>Generate the public encapsulation key (ek) and a private decapsul ation key (dk). <xref target="FIPS203"/> specifies two formats for an ML-KEM pr ivate 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"/> generat es 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 expand ed to get the keys, algorithm 16 (<tt>ML-KEM.KeyGen_internal(d,z)</tt>) from <xr ef target="FIPS203"/> expands the seed to ek and dk. See <xref section="6" secti onFormat="of" target="I-D.ietf-lamps-kyber-certificates"/> for private key encod ing considerations.</t> <t>Generate the public encapsulation key (ek) and a private decapsul ation key (dk). <xref target="FIPS203"/> specifies two formats for an ML-KEM pr ivate 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"/> generat es 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 expand ed to get the keys, algorithm 16 (<tt>ML-KEM.KeyGen_internal(d,z)</tt>) from <xr ef target="FIPS203"/> expands the seed to ek and dk. See <xref section="6" secti onFormat="of" target="RFC9935"/> for private key encoding considerations.</t>
</dd> </dd>
<dt>Encapsulate(ek) -&gt; (c, ss):</dt> <dt>Encapsulate(ek) -&gt; (c, ss):</dt>
<dd> <dd>
<t>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 origin ator. Algorithm 20 (<tt>ML-KEM.Encaps(ek)</tt>) from <xref target="FIPS203"/> is the encapsulation function for ML-KEM.</t> <t>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 origin ator. Algorithm 20 (<tt>ML-KEM.Encaps(ek)</tt>) from <xref target="FIPS203"/> is the encapsulation function for ML-KEM.</t>
</dd> </dd>
<dt>Decapsulate(dk, c) -&gt; ss:</dt> <dt>Decapsulate(dk, c) -&gt; ss:</dt>
<dd> <dd>
<t>Given the private key (dk) and the ciphertext (c), produce the sh ared secret (ss) for the recipient. Algorithm 21 (<tt>ML-KEM.Decaps(dk,c)</tt>) from <xref target="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" t arget="I-D.ietf-lamps-kyber-certificates"/> for consistency considerations if th e private key was stored in both seed and expanded formats.</t> <t>Given the private key (dk) and the ciphertext (c), produce the sh ared secret (ss) for the recipient. Algorithm 21 (<tt>ML-KEM.Decaps(dk,c)</tt>) from <xref target="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" t arget="RFC9935"/> for consistency considerations if the private key was stored i n both seed and expanded formats.</t>
</dd> </dd>
</dl> </dl>
<t>All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE128, and S HAKE256 internally.</t> <t>All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE128, and S HAKE256 internally.</t>
<!-- End of ML-KEM section -->
<!-- End of introduction section -->
</section> </section>
</section> </section>
<section anchor="sec-using"> <section anchor="sec-using">
<name>Use of the ML-KEM Algorithm in the CMS</name> <name>Use of the ML-KEM Algorithm in the CMS</name>
<t>The ML-KEM algorithm <bcp14>MAY</bcp14> be employed for one or more rec ipients in the CMS enveloped-data content type <xref target="RFC5652"/>, the CMS authenticated-data content type <xref target="RFC5652"/>, or the CMS authentica ted-enveloped-data content type <xref target="RFC5083"/>. In each case, the KEMR ecipientInfo <xref target="RFC9629"/> is used with the ML-KEM algorithm to secur ely transfer the content-encryption key from the originator to the recipient.</t > <t>The ML-KEM algorithm <bcp14>MAY</bcp14> be employed for one or more rec ipients in the CMS enveloped-data content type <xref target="RFC5652"/>, the CMS authenticated-data content type <xref target="RFC5652"/>, or the CMS authentica ted-enveloped-data content type <xref target="RFC5083"/>. In each case, the KEMR ecipientInfo <xref target="RFC9629"/> is used with the ML-KEM algorithm to secur ely transfer the content-encryption key from the originator to the recipient.</t >
<t>Processing ML-KEM with KEMRecipientInfo follows the same steps as <xref section="2" sectionFormat="of" target="RFC9629"/>. To support the ML-KEM algori thm, a CMS originator <bcp14>MUST</bcp14> implement the Encapsulate() function a nd a CMS recipient <bcp14>MUST</bcp14> implement the Decapsulate() function.</t> <t>Processing ML-KEM with KEMRecipientInfo follows the same steps as <xref section="2" sectionFormat="of" target="RFC9629"/>. To support the ML-KEM algori thm, a CMS originator <bcp14>MUST</bcp14> implement the Encapsulate() function a nd a CMS recipient <bcp14>MUST</bcp14> implement the Decapsulate() function.</t>
<section anchor="sec-using-recipientInfo"> <section anchor="sec-using-recipientInfo">
<name>RecipientInfo Conventions</name> <name>RecipientInfo Conventions</name>
<t>When the ML-KEM algorithm is employed for a recipient, the RecipientI nfo alternative for that recipient <bcp14>MUST</bcp14> be OtherRecipientInfo usi ng the KEMRecipientInfo structure as defined in <xref target="RFC9629"/>.</t> <t>When the ML-KEM algorithm is employed for a recipient, the RecipientI nfo alternative for that recipient <bcp14>MUST</bcp14> be OtherRecipientInfo usi ng the KEMRecipientInfo structure as defined in <xref target="RFC9629"/>.</t>
<t>The fields of the KEMRecipientInfo have the following meanings:</t> <t>The fields of the KEMRecipientInfo have the following meanings:</t>
<ul empty="true">
<li> <dl spacing="normal" newline="true">
<t>version is the syntax version number; it <bcp14>MUST</bcp14> be 0 <dt>version</dt><dd>The syntax version number; it <bcp14>MUST</bcp14> be 0.</d
.</t> d>
</li> <dt>rid</dt><dd>Identifies the recipient's certificate or public key.</dd>
</ul> <dt>kem</dt><dd>Identifies the KEM algorithm; it <bcp14>MUST</bcp14> contain o
<ul empty="true"> ne of id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These identif
<li> iers are reproduced in <xref target="sec-identifiers"/>.</dd>
<t>rid identifies the recipient's certificate or public key.</t> <dt>kemct</dt><dd>The ciphertext produced for this recipient.</dd>
</li> <!-- [rfced] We have updated the following sentence since we fully expanded
</ul> HKDF. Please let us know any objections.
<ul empty="true">
<li> Original:
<t>kem identifies the KEM algorithm; it <bcp14>MUST</bcp14> contain Implementations MUST support HKDF [RFC5869] with SHA-256 [FIPS180],
one of id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These identi using the id-alg-hkdf-with-sha256 KDF object identifier [RFC8619].
fiers are reproduced in <xref target="sec-identifiers"/>.</t>
</li> Current:
</ul> Implementations MUST support the HMAC-based Key Derivation Function
<ul empty="true"> (HKDF) [RFC5869] with SHA-256 [FIPS180] using the id- alg-hkdf-with-sha256 KDF
<li> object identifier [RFC8619].
<t>kemct is the ciphertext produced for this recipient.</t> -->
</li> <dt>kdf</dt><dd>Identifies the key derivation algorithm. Note that the Key Der
</ul> ivation Function (KDF) used for CMS RecipientInfo process <bcp14>MAY</bcp14> be
<ul empty="true"> different than the KDF used within the ML-KEM algorithm. Implementations <bcp14>
<li> MUST</bcp14> support the HMAC-based Key Derivation Function (HKDF) <xref target=
<t>kdf identifies the key-derivation algorithm. Note that the Key De "RFC5869"/> with SHA-256 <xref target="FIPS180"/> using the id-alg-hkdf-with-sha
rivation Function (KDF) used for CMS RecipientInfo process <bcp14>MAY</bcp14> be 256 KDF object identifier (OID) <xref target="RFC8619"/>. As specified in <xref
different than the KDF used within the ML-KEM algorithm. Implementations <bcp14 target="RFC8619"/>, the parameter field <bcp14>MUST</bcp14> be absent when this
>MUST</bcp14> support HKDF <xref target="RFC5869"/> with SHA-256 <xref target="F OID appears within the ASN.1 type AlgorithmIdentifier. Implementations <bcp14>MA
IPS180"/>, using the id-alg-hkdf-with-sha256 KDF object identifier <xref target= Y</bcp14> support other KDFs as well.</dd>
"RFC8619"/>. As specified in <xref target="RFC8619"/>, the parameter field <bcp1 <dt>kekLength</dt><dd>The size of the key-encryption key in octets.</dd>
4>MUST</bcp14> be absent when this object identifier appears within the ASN.1 ty <dt>ukm</dt><dd>Optional input to the KDF. The secure use of ML-KEM in CMS doe
pe AlgorithmIdentifier. Implementations <bcp14>MAY</bcp14> support other KDFs as s not depend on the use of a ukm value, so this document does not place any requ
well.</t> irements on this value. See <xref section="3" sectionFormat="of" target="RFC962
</li> 9"/> for more information about the ukm parameter.</dd>
</ul> <dt>wrap</dt><dd>Identifies a key-encryption algorithm used to encrypt the con
<ul empty="true"> tent-encryption key. Implementations supporting ML-KEM-512 <bcp14>MUST</bcp14> s
<li> upport the AES-Wrap-128 <xref target="RFC3394"/> key-encryption algorithm using
<t>kekLength is the size of the key-encryption key in octets.</t> the id-aes128-wrap key-encryption algorithm OID <xref target="RFC3565"/>. Implem
</li> entations supporting ML-KEM-768 or ML-KEM-1024 <bcp14>MUST</bcp14> support the A
</ul> ES-Wrap-256 <xref target="RFC3394"/> key-encryption algorithm using the id-aes25
<ul empty="true"> 6-wrap key-encryption algorithm OID <xref target="RFC3565"/>. Implementations <b
<li> cp14>MAY</bcp14> support other key-encryption algorithms as well.</dd>
<t>ukm is optional input to the key-derivation function. The secure </dl>
use of ML-KEM in CMS does not depend on the use of a ukm value, so this document <t><xref target="example"/> contains an example of establishing a content-encr
does not place any requirements on this value. See <xref section="3" sectionFo yption key using ML-KEM in the KEMRecipientInfo type.</t>
rmat="of" target="RFC9629"/> for more information about the ukm parameter.</t>
</li>
</ul>
<ul empty="true">
<li>
<t>wrap identifies a key-encryption algorithm used to encrypt the co
ntent-encryption key. Implementations supporting ML-KEM-512 <bcp14>MUST</bcp14>
support the AES-Wrap-128 <xref target="RFC3394"/> key-encryption algorithm using
the id-aes128-wrap key-encryption algorithm object identifier <xref target="RFC
3565"/>. Implementations supporting ML-KEM-768 or ML-KEM-1024 <bcp14>MUST</bcp14
> support the AES-Wrap-256 <xref target="RFC3394"/> key-encryption algorithm usi
ng the id-aes256-wrap key-encryption algorithm object identifier <xref target="R
FC3565"/>. Implementations <bcp14>MAY</bcp14> support other key-encryption algor
ithms as well.</t>
</li>
</ul>
<t><xref target="example"/> contains an example of establishing a conten
t-encryption key using ML-KEM in the KEMRecipientInfo type.</t>
<!-- End of recipientinfo conventions section -->
</section> </section>
<section anchor="sec-using-components"> <section anchor="sec-using-components">
<name>Underlying Components</name> <name>Underlying Components</name>
<t>When ML-KEM is employed in the CMS, the underlying components used wi thin the KEMRecipientInfo structure <bcp14>SHOULD</bcp14> be consistent with a m inimum desired security level. <t>When ML-KEM is employed in the CMS, the underlying components used wi thin the KEMRecipientInfo structure <bcp14>SHOULD</bcp14> be consistent with a m inimum desired security level.
Several security levels have been identified in NIST SP 800-57 Part 1 <xref targ et="NIST.SP.800-57pt1r5"/>.</t> Several security levels have been identified in <xref target="NIST.SP.800-57pt1r 5"/>.</t>
<t>If underlying components other than those specified in <xref target=" sec-using-recipientInfo"/> 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 sect ion="7" sectionFormat="of" target="RFC9629"/>:</t> <t>If underlying components other than those specified in <xref target=" sec-using-recipientInfo"/> 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 sect ion="7" sectionFormat="of" target="RFC9629"/>:</t>
<table anchor="tab-strong"> <table anchor="tab-strong">
<name>ML-KEM KEMRecipientInfo component security levels</name> <name>ML-KEM KEMRecipientInfo Component Security Levels</name>
<thead> <thead>
<tr> <tr>
<th align="left">Security Strength</th> <th align="left">Security Strength</th>
<th align="left">Algorithm</th> <th align="left">Algorithm</th>
<th align="left">KDF preimage strength</th> <th align="left">KDF Preimage Strength</th>
<th align="left">Symmetric key-encryption strength</th> <th align="left">Symmetric Key-Encryption Strength</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">128-bit</td> <td align="left">128-bit</td>
<td align="left">ML-KEM-512</td> <td align="left">ML-KEM-512</td>
<td align="left">128-bit</td> <td align="left">128-bit</td>
<td align="left">128-bit</td> <td align="left">128-bit</td>
</tr> </tr>
<tr> <tr>
skipping to change at line 217 skipping to change at line 209
<tr> <tr>
<td align="left">256-bit</td> <td align="left">256-bit</td>
<td align="left">ML-KEM-1024</td> <td align="left">ML-KEM-1024</td>
<td align="left">256-bit</td> <td align="left">256-bit</td>
<td align="left">256-bit</td> <td align="left">256-bit</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>(*) In the case of AES Key Wrap, a 256-bit key is typically used beca use AES-192 is not as commonly deployed.</t> <t>(*) In the case of AES Key Wrap, a 256-bit key is typically used beca use AES-192 is not as commonly deployed.</t>
<section anchor="use-of-the-hkdf-based-key-derivation-function"> <section anchor="use-of-the-hkdf-based-key-derivation-function">
<name>Use of the HKDF-based Key Derivation Function</name> <name>Use of the HKDF-Based Key Derivation Function</name>
<t>The HKDF function is a composition of the HKDF-Extract and HKDF-Exp and functions.</t> <t>The HKDF function is a composition of the HKDF-Extract and HKDF-Exp and functions.</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
HKDF(salt, IKM, info, L) HKDF(salt, IKM, info, L)
= HKDF-Expand(HKDF-Extract(salt, IKM), info, L) = HKDF-Expand(HKDF-Extract(salt, IKM), info, L)]]></sourcecode>
]]></artwork> <t>When used with KEMRecipientInfo, the salt parameter is unused; that
<t>When used with KEMRecipientInfo, the salt parameter is unused, that is, it is the zero-length string "". The IKM, info, and L parameters correspond
is it is the zero-length string "". The IKM, info and L parameters correspond t to the same KDF inputs from <xref section="5" sectionFormat="of" target="RFC962
o the same KDF inputs from <xref section="5" sectionFormat="of" target="RFC9629" 9"/>. The info parameter is independently generated by the originator and recipi
/>. The info parameter is independently generated by the originator and recipien ent. Implementations <bcp14>MUST</bcp14> confirm that L is consistent with the k
t. Implementations <bcp14>MUST</bcp14> confirm that L is consistent with the key ey size of the key-encryption algorithm.</t>
size of the key-encryption algorithm.</t> </section>
<!-- End of Underlying Components section -->
</section>
</section> </section>
<section anchor="sec-using-certs"> <section anchor="sec-using-certs">
<name>Certificate Conventions</name> <name>Certificate Conventions</name>
<t>RFC 5280 <xref target="RFC5280"/> specifies the profile for using X.5 <t><xref target="RFC5280"/> specifies the profile for using X.509 certif
09 Certificates in Internet applications. A recipient static public key is need icates in Internet applications. A recipient static public key is needed
ed for ML-KEM and the originator obtains that public key from the recipient's certi
for ML-KEM, and the originator obtains that public key from the recipient's cert ficate. The conventions for carrying ML-KEM public keys are specified in <xref
ificate. The conventions for carrying ML-KEM public keys are specified in <xref target="RFC9935"/>.</t>
target="I-D.ietf-lamps-kyber-certificates"/>.</t>
</section> </section>
<section anchor="sec-using-smime-caps"> <section anchor="sec-using-smime-caps">
<name>SMIME Capabilities Attribute Conventions</name> <name>SMIME Capabilities Attribute Conventions</name>
<t><xref section="2.5.2" sectionFormat="of" target="RFC8551"/> defines t he SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content t ype <xref target="RFC5652"/>, a compliant implementation <bcp14>MAY</bcp14> incl ude the SMIMECapabilities attribute that announces support for one or more of th e ML-KEM algorithm identifiers.</t> <t><xref section="2.5.2" sectionFormat="of" target="RFC8551"/> defines t he SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content t ype <xref target="RFC5652"/>, a compliant implementation <bcp14>MAY</bcp14> incl ude the SMIMECapabilities attribute that announces support for one or more of th e ML-KEM algorithm identifiers.</t>
<t>The SMIMECapability SEQUENCE representing the ML-KEM algorithm <bcp14 <t>The SMIMECapability SEQUENCE representing the ML-KEM algorithm <bcp14
>MUST</bcp14> include one of the ML-KEM object identifiers in the capabilityID f >MUST</bcp14> include one of the ML-KEM OIDs in the capabilityID field. When one
ield. When one of the ML-KEM object identifiers appears in the capabilityID fiel of the ML-KEM OIDs appears in the capabilityID field, the parameters <bcp14>MUS
d, the parameters <bcp14>MUST NOT</bcp14> be present.</t> T NOT</bcp14> be present.</t>
<!-- End of smime-capabilities-attribute-conventions section -->
<!-- End of use-in-cms section -->
</section> </section>
</section> </section>
<section anchor="sec-identifiers"> <section anchor="sec-identifiers">
<name>Identifiers</name> <name>Identifiers</name>
<t>All identifiers used to indicate ML-KEM within the CMS are defined in < <t>All identifiers used to indicate ML-KEM within the CMS are defined in <
xref target="CSOR"/> and <xref target="RFC8619"/> but reproduced here for conven xref target="CSOR"/> and <xref target="RFC8619"/>; they are reproduced here for
ience:</t> convenience:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) country(16) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) } nistAlgorithm(4) }
kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 } kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 }
id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 } id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }
id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 } id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }
id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { kems 3 } id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { kems 3 }
id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1) id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 28 } smime(16) alg(3) 28 }
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
organization(1) gov(101) csor(3) nistAlgorithms(4) 1 } organization(1) gov(101) csor(3) nistAlgorithms(4) 1 }
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="sec-security-considerations"> <section anchor="sec-security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Considerations sections of <xref target="I-D.ietf-lamps-ky ber-certificates"/> and <xref target="RFC9629"/> apply to this specification as well.</t> <t>The Security Considerations sections of <xref target="RFC9935"/> and <x ref target="RFC9629"/> apply to this specification as well.</t>
<t>For ongoing discussions of ML-KEM-specific security considerations, ref er to <xref target="I-D.sfluhrer-cfrg-ml-kem-security-considerations"/>.</t> <t>For ongoing discussions of ML-KEM-specific security considerations, ref er to <xref target="I-D.sfluhrer-cfrg-ml-kem-security-considerations"/>.</t>
<t>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 ke y 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 t hat key. Disclosure of the key-encryption key, the content-encryption key, or th e content-authenticated-encryption key could result in compromise of the associa ted encrypted content. Disclosure of the key-encryption key, the message-authent ication key, or the content-authenticated-encryption key could allow modificatio n of the associated authenticated content.</t> <t>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 ke y 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 t hat key. Disclosure of the key-encryption key, the content-encryption key, or th e content-authenticated-encryption key could result in the compromise of the ass ociated encrypted content. Disclosure of the key-encryption key, the message-aut hentication key, or the content-authenticated-encryption key could allow modific ation of the associated authenticated content.</t>
<t>Additional considerations related to key management may be found in <xr ef target="NIST.SP.800-57pt1r5"/>.</t> <t>Additional considerations related to key management may be found in <xr ef target="NIST.SP.800-57pt1r5"/>.</t>
<t>The generation of private keys relies on random numbers, as does the en capsulation function of ML-KEM. The use of inadequate pseudo-random number gene rators (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 t he case of encapsulation, a KEM is derived from the underlying ML-KEM public key encryption algorithm by deterministically encrypting a random 32-byte message f or the public key. If the random value is weakly-chosen, then an attacker may f ind it much easier to reproduce the PRNG environment that produced the keys or c iphertext, searching the resulting small set of possibilities for a matching pub lic key or ciphertext value, rather than performing a more complex algorithmic a ttack against ML-KEM. The generation of quality random numbers is difficult; se e Section 3.3 of <xref target="FIPS203"/> for some additional information.</t> <t>The generation of private keys relies on random numbers, as does the en capsulation function of ML-KEM. The use of inadequate pseudorandom number gener ators (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 d erive the key (with an additional 32 bytes reserved as a rejection value). In th e case of encapsulation, a KEM is derived from the underlying ML-KEM public key encryption algorithm by deterministically encrypting a random 32-byte message fo r the public key. If the random value is weakly chosen, then an attacker may fi nd it much easier to reproduce the PRNG environment that produced the keys or ci phertext, searching the resulting small set of possibilities for a matching publ ic key or ciphertext value, rather than performing a more complex algorithmic at tack against ML-KEM. The generation of quality random numbers is difficult; see Section 3.3 of <xref target="FIPS203"/> for some additional information.</t>
<t>ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations <bcp14>MUST NOT</bcp14> use intermediate values dir ectly for any purpose.</t> <t>ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations <bcp14>MUST NOT</bcp14> use intermediate values dir ectly for any purpose.</t>
<t>Implementations <bcp14>SHOULD NOT</bcp14> reveal information about inte <t>Implementations <bcp14>SHOULD NOT</bcp14> reveal information about inte
rmediate values or calculations, whether by timing or other "side channels", oth rmediate values or calculations, whether by timing or other "side channels"; oth
erwise an opponent may be able to determine information about the keying data an erwise, an opponent may be able to determine information about the keying data a
d/or the recipient's private key. Although not all intermediate information may nd/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 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 practical, unless analysis specifically indicates that the information would no
be useful to an opponent.</t> t be useful to an opponent.</t>
<t>Generally, good cryptographic practice employs a given ML-KEM key pair <t>Generally, good cryptographic practice employs a given ML-KEM key pair
in only one scheme. This practice avoids the risk that vulnerability in one sche in only one scheme. This practice avoids the risk that vulnerability in one sche
me may compromise the security of the other, and may be essential to maintain pr me may compromise the security of the other and may be essential to maintain pro
ovable security.</t> vable security.</t>
<t>Parties can gain assurance that implementations are correct through for mal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) <xref target="CMVP"/>.</t> <t>Parties can gain assurance that implementations are correct through for mal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) <xref target="CMVP"/>.</t>
<!-- End of security-considerations section -->
</section> </section>
<section anchor="sec-iana-considerations"> <section anchor="sec-iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>For the ASN.1 Module in <xref target="asn1"/>, IANA is requested to ass <t>For the ASN.1 Module in <xref target="asn1"/>, IANA has assigned an OID
ign an object identifier (OID) for the module identifier (TBD1) with a Descripti for the module identifier (84) with a description of "id-mod-cms-ml-kem-2024" i
on of "id-mod-cms-ml-kem-2024". The OID for the module should be allocated in th n the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" regi
e "SMI Security for S/MIME Module Identifier" registry (1.2.840.113549.1.9.16.0) stry.</t>
.</t>
<!-- End of iana-considerations section -->
</section> </section>
<section anchor="sec-acknowledgements">
<name>Acknowledgements</name>
<t>This document borrows heavily from <xref target="RFC9690"/>, <xref targ
et="FIPS203"/>, and <xref target="I-D.kampanakis-ml-kem-ikev2"/>. Thanks go to t
he authors of those documents. "Copying always makes things easier and less erro
r prone" - RFC8411.</t>
<t>Thanks to Carl Wallace, Jonathan Hammel, and Sean Turner for the detail
ed review and Carl Wallace and Philippe Cece for interoperability testing for th
e examples.</t>
<!-- End of acknowledgements section -->
</section>
</middle> </middle>
<back> <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"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="FIPS203">
<front> <reference anchor="FIPS203">
<title>Module-lattice-based key-encapsulation mechanism standard</ti <front>
tle> <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
<author> <author>
<organization/> <organization abbrev="NIST">National Institute of Standards and Technology
</author> </organization>
<date month="August" year="2024"/> </author>
</front> <date month="August" year="2024"/>
<seriesInfo name="DOI" value="10.6028/nist.fips.203"/> </front>
<refcontent>National Institute of Standards and Technology (U.S.)</ref <seriesInfo name="NIST FIPS" value="203"/>
content> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.203"/>
</reference> </reference>
<reference anchor="RFC8551">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 551.xml"/>
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>This document defines Secure/Multipurpose Internet Mail Extensi
ons (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive s
ecure MIME data. Digital signatures provide authentication, message integrity, a
nd non-repudiation with proof of origin. Encryption provides data confidentialit
y. 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="X680" target="https://www.itu.int/rec/T-REC-X.680"> <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
<front> <front>
<title>Information technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title> <title>Information technology - Abstract Syntax Notation One (ASN.1) : Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference> </reference>
<reference anchor="RFC5911"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 911.xml"/>
<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and
S/MIME</title> <!-- [rfced] References
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="J. Schaad" initials="J." surname="Schaad"/> a) FYI: We updated the date for [CSOR] from "20 August 2024" to "13
<date month="June" year="2010"/> June 2025" to match the most current date provided at the URL.
<abstract>
<t>The Cryptographic Message Syntax (CMS) format, and many associa Original:
ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the [CSOR] NIST, "Computer Security Objects Register", 20 August
1988 version of ASN.1. This document updates those ASN.1 modules to conform to 2024, <https://csrc.nist.gov/projects/computer-security-
the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the f objects-register/algorithm-registration>.
ormats; this is simply a change to the syntax. This document is not an Internet
Standards Track specification; it is published for informational purposes.</t> Current:
</abstract> [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June
</front> 2025, <https://csrc.nist.gov/projects/computer-security-
<seriesInfo name="RFC" value="5911"/> objects-register/algorithm-registration>.
<seriesInfo name="DOI" value="10.17487/RFC5911"/>
</reference> b) FYI: We've updated the date for [NIST-PQ] from "20 December 2016" to "30
September 2025" to match the most current date provided at the URL.
Original:
[NIST-PQ] National Institute of Standards and Technology, "Post-
Quantum Cryptography Project", 20 December 2016,
<https://csrc.nist.gov/projects/post-quantum-
cryptography>.
Current:
[NIST-PQ] NIST, "Post-Quantum Cryptography (PQC)", 30 September
2025, <https://csrc.nist.gov/projects/post-quantum-
cryptography>.
c) FYI: We've updated the date for [CMVP] from "2016" to "3 September
2025" to match the most current date provided at the URL.
Original:
[CMVP] National Institute of Standards and Technology,
"Cryptographic Module Validation Program", 2016,
<https://csrc.nist.gov/projects/cryptographic-module-
validation-program>.
Current:
[CMVP] NIST, "Cryptographic Module Validation Program (CMVP)", 3
September 2025, <https://csrc.nist.gov/projects/
cryptographic-module-validation-program>.
d) We note that draft-kampanakis-ml-kem-ikev2-09 has been replaced with
draft-ietf-ipsecme-ikev2-mlkem-03. We have updated the reference accordingly. P
lease let us know if this is incorrect.
-->
<reference anchor="CSOR" target="https://csrc.nist.gov/projects/computer -security-objects-register/algorithm-registration"> <reference anchor="CSOR" target="https://csrc.nist.gov/projects/computer -security-objects-register/algorithm-registration">
<front> <front>
<title>Computer Security Objects Register</title> <title>Computer Security Objects Register (CSOR)</title>
<author initials="" surname="NIST" fullname="National Institute of S tandards and Technology"> <author initials="" surname="NIST" fullname="National Institute of S tandards and Technology">
<organization/> <organization/>
</author> </author>
<date year="2024" month="August" day="20"/> <date year="2025" month="June" day="13"/>
</front>
</reference>
<reference anchor="RFC9629">
<front>
<title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cry
ptographic 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>The Cryptographic Message Syntax (CMS) supports key transport a
nd key agreement algorithms. In recent years, cryptographers have been specifyin
g Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM alg
orithms. This document defines conventions for the use of KEM algorithms by the
originator and recipients to encrypt and decrypt CMS content. This document upda
tes RFC 5652.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9629"/>
<seriesInfo name="DOI" value="10.17487/RFC9629"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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="RFC5652">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS).
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
ry 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="RFC5083">
<front>
<title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Da
ta Content Type</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="November" year="2007"/>
<abstract>
<t>This document describes an additional content type for the Cryp
tographic Message Syntax (CMS). The authenticated-enveloped-data content type is
intended for use with authenticated encryption modes. All of the various key ma
nagement techniques that are supported in the CMS enveloped-data content type ar
e also supported by the CMS authenticated-enveloped-data content type. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5083"/>
<seriesInfo name="DOI" value="10.17487/RFC5083"/>
</reference>
<reference anchor="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>This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
g block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is co
nservative in its use of cryptographic hash functions. This document is not an I
nternet Standards Track specification; it is published for informational purpose
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FI
PS/NIST.FIPS.180-4.pdf">
<front>
<title>Secure Hash Standard</title>
<author fullname="Quynh H. Dang" surname="Dang">
<organization>Information Technology Laboratory</organization>
</author>
<author>
<organization abbrev="NIST">National Institute of Standards and Te
chnology</organization>
<address>
<postal>
<country>US</country>
<city>Gaithersburg</city>
</postal>
</address>
</author>
<date month="July" year="2015"/>
</front>
<seriesInfo name="NIST Federal Information Processing Standards Public
ations" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<reference anchor="RFC8619">
<front>
<title>Algorithm Identifiers for the HMAC-based Extract-and-Expand K
ey Derivation Function (HKDF)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="June" year="2019"/>
<abstract>
<t>RFC 5869 specifies the HMAC-based Extract-and-Expand Key Deriva
tion Function (HKDF) algorithm. This document assigns algorithm identifiers to t
he 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="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">
<front>
<title>Use of the Advanced Encryption Standard (AES) Encryption Algo
rithm in Cryptographic Message Syntax (CMS)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="July" year="2003"/>
<abstract>
<t>This document specifies the conventions for using the Advanced
Encryption Standard (AES) algorithm for encryption with the Cryptographic Messag
e Syntax (CMS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3565"/>
<seriesInfo name="DOI" value="10.17487/RFC3565"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference> </reference>
<reference anchor="I-D.ietf-lamps-kyber-certificates"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 629.xml"/>
<title>Internet X.509 Public Key Infrastructure - Algorithm Identifi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
ers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)</title> 119.xml"/>
<author fullname="Sean Turner" initials="S." surname="Turner"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<organization>sn3rd</organization> 174.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="Panos Kampanakis" initials="P." surname="Kampanaki 652.xml"/>
s"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<organization>AWS</organization> 083.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="Jake Massimo" initials="J." surname="Massimo"> 869.xml"/>
<organization>AWS</organization>
</author> <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.
<author fullname="Bas Westerbaan" initials="B." surname="Westerbaan" FIPS.180-4.pdf">
> <front>
<organization>Cloudflare</organization> <title>Secure Hash Standard</title>
</author> <author>
<date day="22" month="July" year="2025"/> <organization abbrev="NIST">National Institute of Standards and Technology
<abstract> </organization>
<t> The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM </author>
) is a <date month="August" year="2015"/>
quantum-resistant key-encapsulation mechanism (KEM). This document </front>
specifies the conventions for using the ML-KEM in X.509 Public Key <seriesInfo name="NIST FIPS" value="180-4"/>
Infrastructure. The conventions for the subject public keys and <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
private keys are also specified. </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
619.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
394.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
411.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
565.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<!-- RFC 9935 draft-ietf-lamps-kyber-certificates-11 -->
<reference anchor="RFC9935" target="https://www.rfc-editor.org/info/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>sn3rd</organization>
</author>
<author initials="P." surname="Kampanakis" fullname="Panos Kampanakis">
<organization>AWS</organization>
</author>
<author initials="J." surname="Massimo" fullname="Jake Massimo">
<organization>AWS</organization>
</author>
<author initials="B. E." surname="Westerbaan" fullname="Bas Westerbaan">
<organization>Cloudflare</organization>
</author>
<date month="February" year="2026"/>
</front>
<seriesInfo name="RFC" value="9935"/>
<seriesInfo name="DOI" value="10.17487/RFC9935"/>
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-kyber-certif
icates-11"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="NIST-PQ" target="https://csrc.nist.gov/projects/post- quantum-cryptography"> <reference anchor="NIST-PQ" target="https://csrc.nist.gov/projects/post- quantum-cryptography">
<front> <front>
<title>Post-Quantum Cryptography Project</title> <title>Post-Quantum Cryptography (PQC)</title>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>NIST</organization>
</author> </author>
<date year="2016" month="December" day="20"/> <date year="2025" month="September" day="30"/>
</front> </front>
</reference> </reference>
<reference anchor="CMVP" target="https://csrc.nist.gov/projects/cryptogr aphic-module-validation-program"> <reference anchor="CMVP" target="https://csrc.nist.gov/projects/cryptogr aphic-module-validation-program">
<front> <front>
<title>Cryptographic Module Validation Program</title> <title>Cryptographic Module Validation Program (CMVP)</title>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>NIST</organization>
</author> </author>
<date year="2016"/> <date day="3" month="9" year="2025"/>
</front> </front>
</reference> </reference>
<reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov /nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf"> <reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov /nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf">
<front> <front>
<title>Recommendation for key management:part 1 - general</title> <title>Recommendation for Key Management: Part 1 - General</title>
<author fullname="Elaine Barker" surname="Barker"> <author fullname="Elaine Barker" surname="Barker">
<organization>Information Technology Laboratory</organization> <organization>Information Technology Laboratory</organization>
</author> </author>
<author>
<organization abbrev="NIST">National Institute of Standards and Te
chnology</organization>
<address>
<postal>
<country>US</country>
<city>Gaithersburg</city>
</postal>
</address>
</author>
<date month="May" year="2020"/> <date month="May" year="2020"/>
</front> </front>
<seriesInfo name="NIST Special Publications (General)" value="800-57pt 1r5"/> <seriesInfo name="NIST SP" value="800-57pt1r5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference> </reference>
<reference anchor="I-D.sfluhrer-cfrg-ml-kem-security-considerations">
<front>
<title>ML-KEM Security Considerations</title>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Quynh Dang" initials="Q." surname="Dang">
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<author fullname="John Preuss Mattsson" initials="J. P." surname="Ma
ttsson">
<organization>Ericsson</organization>
</author>
<author fullname="Kevin Milner" initials="K." surname="Milner">
<organization>Quantinuum</organization>
</author>
<author fullname="Daniel Shiu" initials="D." surname="Shiu">
<organization>Arqit Quantum Inc</organization>
</author>
<date day="15" month="May" year="2025"/>
<abstract>
<t> NIST standardized ML-KEM as FIPS 203 in August 2024. This d
ocument
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> <!-- I-D.sfluhrer-cfrg-ml-kem-security-considerations
</abstract> draft-sfluhrer-cfrg-ml-kem-security-considerations-03
</front> IESG State: I-D Exists as of 10/24/25
<seriesInfo name="Internet-Draft" value="draft-sfluhrer-cfrg-ml-kem-se -->
curity-considerations-03"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</reference> sfluhrer-cfrg-ml-kem-security-considerations.xml"/>
<reference anchor="RFC9690"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 690.xml"/>
<title>Use of the RSA-KEM Algorithm in the Cryptographic Message Syn
tax (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>The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a on
e-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 R
SA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This docu
ment specifies the conventions for using the RSA-KEM algorithm as a standalone K
EM algorithm and the conventions for using the RSA-KEM algorithm with the Crypto
graphic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. Th
is document obsoletes RFC 5990.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9690"/>
<seriesInfo name="DOI" value="10.17487/RFC9690"/>
</reference>
<reference anchor="I-D.kampanakis-ml-kem-ikev2">
<front>
<title>Post-quantum Hybrid Key Exchange with ML-KEM in the Internet
Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="Panos Kampanakis" initials="P." surname="Kampanaki
s">
<organization>Amazon Web Services</organization>
</author>
<author fullname="Gerardo Ravago" initials="G." surname="Ravago">
<organization>Amazon Web Services</organization>
</author>
<date day="4" month="November" year="2024"/>
<abstract>
<t> NIST recently standardized ML-KEM, a new key encapsulation m
echanism,
which can be used for quantum-resistant key establishment. This
draft specifies how to use ML-KEM as an additional key exchange in
IKEv2 along with traditional key exchanges. This Post-Quantum
Traditional Hybrid Key Encapsulation Mechanism approach allows for
negotiating IKE and Child SA keys which are safe against
cryptanalytically-relevant quantum computers and theoretical
weaknesses in ML-KEM.
</t> <!-- I-D.kampanakis-ml-kem-ikev2
</abstract> draft-kampanakis-ml-kem-ikev2-09
</front> IESG State: Replaced by draft-ietf-ipsecme-ikev2-mlkem
<seriesInfo name="Internet-Draft" value="draft-kampanakis-ml-kem-ikev2 -->
-09"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</reference> ietf-ipsecme-ikev2-mlkem.xml"/>
</references> </references>
</references> </references>
<?line 308?>
<section anchor="asn1"> <section anchor="asn1">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t>This appendix includes the ASN.1 module <xref target="X680"/> for ML-KE <t>This appendix includes the ASN.1 module <xref target="X680"/> for ML-KE
M. This module imports objects from <xref target="RFC5911"/>, <xref target="RFC9 M. This module imports objects from <xref target="RFC5911"/>, <xref target="RFC9
629"/>, <xref target="RFC8619"/>, <xref target="I-D.ietf-lamps-kyber-certificate 629"/>, <xref target="RFC8619"/>, and <xref target="RFC9935"/>.</t>
s"/>.</t> <sourcecode markers="true" type="asn.1"><![CDATA[
<sourcecode markers="true"><![CDATA[
CMS-ML-KEM-2024 CMS-ML-KEM-2024
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-ml-kem-2024(TBD1) } pkcs-9(9) smime(16) modules(0) id-mod-cms-ml-kem-2024(84) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
SMIME-CAPS SMIME-CAPS
FROM AlgorithmInformation-2009 -- [RFC5911] FROM AlgorithmInformation-2009 -- [RFC5911]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
skipping to change at line 688 skipping to change at line 500
pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) } pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) }
kwa-aes128-wrap, kwa-aes256-wrap kwa-aes128-wrap, kwa-aes256-wrap
FROM CMSAesRsaesOaep-2009 -- [RFC5911] FROM CMSAesRsaesOaep-2009 -- [RFC5911]
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-aes-02(38) } id-mod-cms-aes-02(38) }
id-alg-ml-kem-512, id-alg-ml-kem-768, id-alg-ml-kem-1024, 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 pk-ml-kem-512, pk-ml-kem-768, pk-ml-kem-1024
FROM X509-ML-KEM-2024 -- [I-D.ietf-lamps-kyber-certificates] FROM X509-ML-KEM-2024 -- [RFC9935]
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-x509-ml-kem-2025(121) }; id-mod-x509-ml-kem-2025(121) };
-- --
-- ML-KEM Key Encapsulation Mechanism Algorithms -- ML-KEM Key Encapsulation Mechanism Algorithms
-- --
kema-ml-kem-512 KEM-ALGORITHM ::= { kema-ml-kem-512 KEM-ALGORITHM ::= {
IDENTIFIER id-alg-ml-kem-512 IDENTIFIER id-alg-ml-kem-512
skipping to change at line 729 skipping to change at line 541
SMimeCapsSet SMIME-CAPS ::= SMimeCapsSet SMIME-CAPS ::=
{ kema-ml-kem-512.&smimeCaps | { kema-ml-kem-512.&smimeCaps |
kema-ml-kem-768.&smimeCaps | kema-ml-kem-768.&smimeCaps |
kema-ml-kem-1024.&smimeCaps | kema-ml-kem-1024.&smimeCaps |
kda-hkdf-with-sha256.&smimeCaps | kda-hkdf-with-sha256.&smimeCaps |
kwa-aes128-wrap.&smimeCaps | kwa-aes128-wrap.&smimeCaps |
kwa-aes256-wrap.&smimeCaps, kwa-aes256-wrap.&smimeCaps,
... } ... }
END END]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="arnold"> <section anchor="arnold">
<name>Parameter Set Security and Sizes</name> <name>Parameter Set Security and Sizes</name>
<t>Instead of defining the strength of a quantum algorithm in a traditiona l <t>Instead of defining the strength of a quantum algorithm in a traditiona l
manner using the imprecise notion of bits of security, NIST has manner using the imprecise notion of bits of security, NIST has
defined security levels by picking a reference scheme, which defined security levels by picking a reference scheme, which
NIST expects to offer notable levels of resistance to both quantum and is expected to offer notable levels of resistance to both quantum and
classical attack. To wit, a KEM algorithm that achieves NIST PQC classical attacks. To wit, a KEM algorithm that achieves NIST Post-Quantum Cryp
tography (PQC)
security must require computational resources to break IND-CCA2 security must require computational resources to break IND-CCA2
security comparable or greater than that required for key search 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. 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> Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference.</t>
<table anchor="tab-strengths"> <table anchor="tab-strengths">
<name>ML-KEM parameter sets, NIST Security Level, and sizes in bytes</na me> <name>ML-KEM parameter Sets, NIST Security Level, and Sizes in Bytes</na me>
<thead> <thead>
<tr> <tr>
<th align="left">Parameter Set</th> <th align="left">Parameter Set</th>
<th align="left">Level</th> <th align="left">Level</th>
<th align="left">Encap. Key Size</th> <th align="left">Encap. Key Size</th>
<th align="left">Decap. Key Size</th> <th align="left">Decap. Key Size</th>
<th align="left">Ciphertext Size</th> <th align="left">Ciphertext Size</th>
<th align="left">Shared Secret Size</th> <th align="left">Shared Secret Size</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 805 skipping to change at line 616
<t>KEMRecipientInfo key wrap using AES-128-KEYWRAP.</t> <t>KEMRecipientInfo key wrap using AES-128-KEYWRAP.</t>
</li> </li>
</ul> </ul>
<t>In real-world use, the originator would encrypt the content- <t>In real-world use, the originator would encrypt the content-
encryption key in a manner that would allow decryption with their own 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 private key as well as the recipient's private key. This is omitted
in an attempt to simplify the example.</t> in an attempt to simplify the example.</t>
<section anchor="originator-cms-processing"> <section anchor="originator-cms-processing">
<name>Originator CMS Processing</name> <name>Originator CMS Processing</name>
<t>Alice obtains Bob's ML-KEM-512 public key:</t> <t>Alice obtains Bob's ML-KEM-512 public key:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MIIDMjALBglghkgBZQMEBAEDggMhADmVgV5ZfRBDVc8pqlMzyTJRhp1bzb5IcST2 MIIDMjALBglghkgBZQMEBAEDggMhADmVgV5ZfRBDVc8pqlMzyTJRhp1bzb5IcST2
Ari2pmwWxHYWSK12XPXYAGtRXpBafwrAdrDGLvoygVPnylcBaZ8TBfHmvG+QsOSb Ari2pmwWxHYWSK12XPXYAGtRXpBafwrAdrDGLvoygVPnylcBaZ8TBfHmvG+QsOSb
aTUSts6ZKouAFt38GmYsfj+WGcvYad13GvMIlszVkYrGy3dGbF53mZbWf/mqvJdQ aTUSts6ZKouAFt38GmYsfj+WGcvYad13GvMIlszVkYrGy3dGbF53mZbWf/mqvJdQ
Pyx7fi0ADYZFD7GAfKTKvaRlgloxx4mht6SRqzhydl0yDQtxkg+iE8lAk0Frg7gS Pyx7fi0ADYZFD7GAfKTKvaRlgloxx4mht6SRqzhydl0yDQtxkg+iE8lAk0Frg7gS
Tmn2XmLLUADcw3qpoP/3OXDEdy81fSQYnKb1MFVowOI3ajdipoxgXlY8XSCVcuD8 Tmn2XmLLUADcw3qpoP/3OXDEdy81fSQYnKb1MFVowOI3ajdipoxgXlY8XSCVcuD8
dTLKKUcpU1VntfxBPF6HktJGRTbMgI+YrddGZPFBVm+QFqkKVBgpqYoEZM5BqLtE dTLKKUcpU1VntfxBPF6HktJGRTbMgI+YrddGZPFBVm+QFqkKVBgpqYoEZM5BqLtE
wtT6PCwglGByjvFKGnxMm5jRIgO0zDUpFgqasteDj3/2tTrgWqMafWRrevpsRZMl wtT6PCwglGByjvFKGnxMm5jRIgO0zDUpFgqasteDj3/2tTrgWqMafWRrevpsRZMl
JqPDdVYZvplMIRwqMcBbNEeDbLIVC+GCna5rBMVTXP9Ubjkrp5dBFyD5JPSQpaxU JqPDdVYZvplMIRwqMcBbNEeDbLIVC+GCna5rBMVTXP9Ubjkrp5dBFyD5JPSQpaxU
lfITVtVQt4KmTBaItrZVvMeEIZekNML2Vjtbfwmni8xIgjJ4NWHRb0y6tnVUAAUH lfITVtVQt4KmTBaItrZVvMeEIZekNML2Vjtbfwmni8xIgjJ4NWHRb0y6tnVUAAUH
gVcMZmBLgXrRJSKUc26LAYYaS1p0UZuLb+UUiaUHI5Llh2JscTd2V10zgGocjicy gVcMZmBLgXrRJSKUc26LAYYaS1p0UZuLb+UUiaUHI5Llh2JscTd2V10zgGocjicy
r5fCaA9RZmMxxOuLvAQxxPloMtrxs8RVKPuhU/bHixwZhwKUfM0zdyekb7U7oR3l r5fCaA9RZmMxxOuLvAQxxPloMtrxs8RVKPuhU/bHixwZhwKUfM0zdyekb7U7oR3l
y0GRNGhZUWy2rXJADzzyCbI2rvNaWArIfrPjD6/WaXPKin3SZ1r0H3oXthQzzRr4 y0GRNGhZUWy2rXJADzzyCbI2rvNaWArIfrPjD6/WaXPKin3SZ1r0H3oXthQzzRr4
D3cIhp9mVIhJeYCxrBCgzctjagDthoGzXkKRJMqANQcluF+DperDpKPMFgCQPmUp D3cIhp9mVIhJeYCxrBCgzctjagDthoGzXkKRJMqANQcluF+DperDpKPMFgCQPmUp
NWC5szblrw1SnawaBIEZMCy3qbzBELlIUb8CEX8ZncSFqFK3Rz8JuDGmgx1bVMC3 NWC5szblrw1SnawaBIEZMCy3qbzBELlIUb8CEX8ZncSFqFK3Rz8JuDGmgx1bVMC3
kNIlz2u5LZRiomzbM92lEjx6rw4moLg2Ve6ii/OoB0clAY/WuuS2Ac9huqtxp6PT kNIlz2u5LZRiomzbM92lEjx6rw4moLg2Ve6ii/OoB0clAY/WuuS2Ac9huqtxp6PT
UZejQ+dLSicsEl1UCJZCbYW3lY07OKa6mH7DciXHtEzbEt3kU5tKsII2NoPwS/eg UZejQ+dLSicsEl1UCJZCbYW3lY07OKa6mH7DciXHtEzbEt3kU5tKsII2NoPwS/eg
nMXEHf6DChsWLgsyQzQ2LwhKFEZ3IzRLrdAA+NjFN8SPmY8FMHzr0e3guBw7xZoG nMXEHf6DChsWLgsyQzQ2LwhKFEZ3IzRLrdAA+NjFN8SPmY8FMHzr0e3guBw7xZoG
WhttY7Js WhttY7Js
]]></artwork> -----END PUBLIC KEY-----]]></sourcecode>
<t>Bob's ML-KEM-512 public key has the following key identifier:</t> <t>Bob's ML-KEM-512 public key has the following key identifier:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
599788C37AED400EE405D1B2A3366AB17D824A51 599788C37AED400EE405D1B2A3366AB17D824A51]]></sourcecode>
]]></artwork>
<t>Alice generates a shared secret and ciphertext using Bob's ML-KEM-512 public key:</t> <t>Alice generates a shared secret and ciphertext using Bob's ML-KEM-512 public key:</t>
<t>Shared secret:</t> <t>Shared secret:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
7DF12D412AE299A24FDE6D7C3BB8E3194C80AD3C733DCF2775E09FE8BEDB86D8 7DF12D412AE299A24FDE6D7C3BB8E3194C80AD3C733DCF2775E09FE8BEDB86D8]]></sourcecode>
]]></artwork>
<t>Ciphertext:</t> <t>Ciphertext:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
3EA40FC6CA090E2C8AF76E2727AB38E0652D9515986FE186827FE84E596E421B 3EA40FC6CA090E2C8AF76E2727AB38E0652D9515986FE186827FE84E596E421B
85FD459CC78997372C9DE31D191B39C1D5A3EB6DDB56AADEDE765CC390FDBBC2 85FD459CC78997372C9DE31D191B39C1D5A3EB6DDB56AADEDE765CC390FDBBC2
F88CB175681D4201B81CCDFCB24FEF13AF2F5A1ABCF8D8AF384F02A010A6E919 F88CB175681D4201B81CCDFCB24FEF13AF2F5A1ABCF8D8AF384F02A010A6E919
F1987A5E9B1C0E2D3F07F58A9FA539CE86CC149910A1692C0CA4CE0ECE4EEED2 F1987A5E9B1C0E2D3F07F58A9FA539CE86CC149910A1692C0CA4CE0ECE4EEED2
E6699CB976332452DE4A2EB5CA61F7B081330C34798EF712A24E59C33CEA1F1F E6699CB976332452DE4A2EB5CA61F7B081330C34798EF712A24E59C33CEA1F1F
9E6D4FBF3743A38467430011336F62D870792B866BEFCD1D1B365BED1952673D 9E6D4FBF3743A38467430011336F62D870792B866BEFCD1D1B365BED1952673D
3A5B0C20B386B4EFD1CF63FD376BD47CCC46AC4DD8EC66B047C4C95ACFF1CFD0 3A5B0C20B386B4EFD1CF63FD376BD47CCC46AC4DD8EC66B047C4C95ACFF1CFD0
28A419B002FDA1B617CBA61D2E91CFE8FFFBCB8FFD4D5F6AD8B158C219E36DC5 28A419B002FDA1B617CBA61D2E91CFE8FFFBCB8FFD4D5F6AD8B158C219E36DC5
1405DC0C0B234979AC658E72BDDF1B6773B96B2AE3E4D07BE86048040C016743 1405DC0C0B234979AC658E72BDDF1B6773B96B2AE3E4D07BE86048040C016743
6FA839E7529B00CC9AB55A2F25DB63CC9F557594E691C11E553D4A3EBC760F5F 6FA839E7529B00CC9AB55A2F25DB63CC9F557594E691C11E553D4A3EBC760F5F
skipping to change at line 861 skipping to change at line 669
39B6F93A3A2E5997807F06361C83F4E67F8E3F9CF68316011514F5D85A181CEA 39B6F93A3A2E5997807F06361C83F4E67F8E3F9CF68316011514F5D85A181CEA
D714CD4940E4EBAC01D66528DA32F89CEA0428E8EBCADCF8AA188C9F62E85B19 D714CD4940E4EBAC01D66528DA32F89CEA0428E8EBCADCF8AA188C9F62E85B19
57655B7FE2B8D7973B7A7226B66D93BF7B232F3DCF653C84B4ECF1A9920DB194 57655B7FE2B8D7973B7A7226B66D93BF7B232F3DCF653C84B4ECF1A9920DB194
9AD750B546A5552A20E54909719B8C0C07056FCB7E574AD2A32EC95001DDE844 9AD750B546A5552A20E54909719B8C0C07056FCB7E574AD2A32EC95001DDE844
81BE77D039ED5BF74262ECF3981F1B00D3366A9C2E061C47E241A061C6249560 81BE77D039ED5BF74262ECF3981F1B00D3366A9C2E061C47E241A061C6249560
D2B8446A480C38C28BA989D9F68ADC4BBAF2A20B47E4923128C72342D597FDA2 D2B8446A480C38C28BA989D9F68ADC4BBAF2A20B47E4923128C72342D597FDA2
59DE0B83C2056D6B77E799B319324AA50B1D659C2A56029B7453C5F3BA5243D9 59DE0B83C2056D6B77E799B319324AA50B1D659C2A56029B7453C5F3BA5243D9
FA749D917C40D9D101E453BC8B10E42A7C089323C026F783E100B9FA6E701442 FA749D917C40D9D101E453BC8B10E42A7C089323C026F783E100B9FA6E701442
4DA6FA3792BC957EE8219D016B773F28FEDCC962A485ABAFFEC023281971E29A 4DA6FA3792BC957EE8219D016B773F28FEDCC962A485ABAFFEC023281971E29A
A689839ECFD2619E92287CD230DB26A2507CC500EB1C7A5293B5FE917AE29BF1 A689839ECFD2619E92287CD230DB26A2507CC500EB1C7A5293B5FE917AE29BF1
AD350124F8A311635214B411DB9F67D3B85BD715018537EA45B41F41B4C66051 AD350124F8A311635214B411DB9F67D3B85BD715018537EA45B41F41B4C66051]]></sourcecode>
]]></artwork>
<t>Alice encodes the CMSORIforKEMOtherInfo:</t> <t>Alice encodes the CMSORIforKEMOtherInfo:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
3010300B0609608648016503040105020110 3010300B0609608648016503040105020110]]></sourcecode>
]]></artwork>
<t>Alice derives the key-encryption key from the shared secret and CMSOR IforKEMOtherInfo using HKDF with SHA-256:</t> <t>Alice derives the key-encryption key from the shared secret and CMSOR IforKEMOtherInfo using HKDF with SHA-256:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
CF453A3E2BAE0A78701B8206C185A008 CF453A3E2BAE0A78701B8206C185A008]]></sourcecode>
]]></artwork>
<t>Alice randomly generates a 128-bit content-encryption key:</t> <t>Alice randomly generates a 128-bit content-encryption key:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
C5153005588269A0A59F3C01943FDD56 C5153005588269A0A59F3C01943FDD56]]></sourcecode>
]]></artwork>
<t>Alice uses AES-128-KEYWRAP to encrypt the content-encryption key with the key-encryption key:</t> <t>Alice uses AES-128-KEYWRAP to encrypt the content-encryption key with the key-encryption key:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
C050E4392F9C14DD0AC2220203F317D701F94F9DD92778F5 C050E4392F9C14DD0AC2220203F317D701F94F9DD92778F5]]></sourcecode>
]]></artwork>
<t>Alice encrypts the padded content using AES-128-GCM with the content- encryption key and encodes the AuthEnvelopedData (using KEMRecipientInfo) and Co ntentInfo, and then sends the result to Bob.</t> <t>Alice encrypts the padded content using AES-128-GCM with the content- encryption key and encodes the AuthEnvelopedData (using KEMRecipientInfo) and Co ntentInfo, and then sends the result to Bob.</t>
<t>The Base64-encoded result is:</t> <t>The Base64-encoded result is:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
-----BEGIN CMS----- -----BEGIN CMS-----
MIID4gYLKoZIhvcNAQkQARegggPRMIIDzQIBADGCA3ikggN0BgsqhkiG9w0BCRAN MIID4gYLKoZIhvcNAQkQARegggPRMIIDzQIBADGCA3ikggN0BgsqhkiG9w0BCRAN
AzCCA2MCAQCAFFmXiMN67UAO5AXRsqM2arF9gkpRMAsGCWCGSAFlAwQEAQSCAwA+ AzCCA2MCAQCAFFmXiMN67UAO5AXRsqM2arF9gkpRMAsGCWCGSAFlAwQEAQSCAwA+
pA/GygkOLIr3bicnqzjgZS2VFZhv4YaCf+hOWW5CG4X9RZzHiZc3LJ3jHRkbOcHV pA/GygkOLIr3bicnqzjgZS2VFZhv4YaCf+hOWW5CG4X9RZzHiZc3LJ3jHRkbOcHV
o+tt21aq3t52XMOQ/bvC+IyxdWgdQgG4HM38sk/vE68vWhq8+NivOE8CoBCm6Rnx o+tt21aq3t52XMOQ/bvC+IyxdWgdQgG4HM38sk/vE68vWhq8+NivOE8CoBCm6Rnx
mHpemxwOLT8H9YqfpTnOhswUmRChaSwMpM4Ozk7u0uZpnLl2MyRS3koutcph97CB mHpemxwOLT8H9YqfpTnOhswUmRChaSwMpM4Ozk7u0uZpnLl2MyRS3koutcph97CB
Mww0eY73EqJOWcM86h8fnm1PvzdDo4RnQwARM29i2HB5K4Zr780dGzZb7RlSZz06 Mww0eY73EqJOWcM86h8fnm1PvzdDo4RnQwARM29i2HB5K4Zr780dGzZb7RlSZz06
Wwwgs4a079HPY/03a9R8zEasTdjsZrBHxMlaz/HP0CikGbAC/aG2F8umHS6Rz+j/ Wwwgs4a079HPY/03a9R8zEasTdjsZrBHxMlaz/HP0CikGbAC/aG2F8umHS6Rz+j/
+8uP/U1fatixWMIZ423FFAXcDAsjSXmsZY5yvd8bZ3O5ayrj5NB76GBIBAwBZ0Nv +8uP/U1fatixWMIZ423FFAXcDAsjSXmsZY5yvd8bZ3O5ayrj5NB76GBIBAwBZ0Nv
qDnnUpsAzJq1Wi8l22PMn1V1lOaRwR5VPUo+vHYPXxnl/hRIOLTH0VkdqbXUZ0lP qDnnUpsAzJq1Wi8l22PMn1V1lOaRwR5VPUo+vHYPXxnl/hRIOLTH0VkdqbXUZ0lP
skipping to change at line 904 skipping to change at line 707
jj+c9oMWARUU9dhaGBzq1xTNSUDk66wB1mUo2jL4nOoEKOjrytz4qhiMn2LoWxlX jj+c9oMWARUU9dhaGBzq1xTNSUDk66wB1mUo2jL4nOoEKOjrytz4qhiMn2LoWxlX
ZVt/4rjXlzt6cia2bZO/eyMvPc9lPIS07PGpkg2xlJrXULVGpVUqIOVJCXGbjAwH ZVt/4rjXlzt6cia2bZO/eyMvPc9lPIS07PGpkg2xlJrXULVGpVUqIOVJCXGbjAwH
BW/LfldK0qMuyVAB3ehEgb530DntW/dCYuzzmB8bANM2apwuBhxH4kGgYcYklWDS BW/LfldK0qMuyVAB3ehEgb530DntW/dCYuzzmB8bANM2apwuBhxH4kGgYcYklWDS
uERqSAw4woupidn2itxLuvKiC0fkkjEoxyNC1Zf9olneC4PCBW1rd+eZsxkySqUL uERqSAw4woupidn2itxLuvKiC0fkkjEoxyNC1Zf9olneC4PCBW1rd+eZsxkySqUL
HWWcKlYCm3RTxfO6UkPZ+nSdkXxA2dEB5FO8ixDkKnwIkyPAJveD4QC5+m5wFEJN HWWcKlYCm3RTxfO6UkPZ+nSdkXxA2dEB5FO8ixDkKnwIkyPAJveD4QC5+m5wFEJN
pvo3kryVfughnQFrdz8o/tzJYqSFq6/+wCMoGXHimqaJg57P0mGekih80jDbJqJQ pvo3kryVfughnQFrdz8o/tzJYqSFq6/+wCMoGXHimqaJg57P0mGekih80jDbJqJQ
fMUA6xx6UpO1/pF64pvxrTUBJPijEWNSFLQR259n07hb1xUBhTfqRbQfQbTGYFEw fMUA6xx6UpO1/pF64pvxrTUBJPijEWNSFLQR259n07hb1xUBhTfqRbQfQbTGYFEw
DQYLKoZIhvcNAQkQAxwCARAwCwYJYIZIAWUDBAEFBBjAUOQ5L5wU3QrCIgID8xfX DQYLKoZIhvcNAQkQAxwCARAwCwYJYIZIAWUDBAEFBBjAUOQ5L5wU3QrCIgID8xfX
AflPndknePUwOgYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBBjARBAxcpXRouBvwO42n AflPndknePUwOgYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBBjARBAxcpXRouBvwO42n
GGwCARCADZTIaJqZ0sOOGS+muggEEFzxeGxXx0ArVPyTwwpKRTM= GGwCARCADZTIaJqZ0sOOGS+muggEEFzxeGxXx0ArVPyTwwpKRTM=
]]></artwork> -----END CMS-----]]></sourcecode>
<t>This result decodes to:</t> <t>This result decodes to:</t>
<artwork><![CDATA[ <!-- [rfced] The following line exceeds the line limit by 3 characters. Please
review and let us know how this line can be modified.
980 16: OCTET STRING 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33
-->
<sourcecode><![CDATA[
0 994: SEQUENCE { 0 994: SEQUENCE {
4 11: OBJECT IDENTIFIER 4 11: OBJECT IDENTIFIER
: authEnvelopedData (1 2 840 113549 1 9 16 1 23) : authEnvelopedData (1 2 840 113549 1 9 16 1 23)
17 977: [0] { 17 977: [0] {
21 973: SEQUENCE { 21 973: SEQUENCE {
25 1: INTEGER 0 25 1: INTEGER 0
28 888: SET { 28 888: SET {
32 884: [4] { 32 884: [4] {
36 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3' 36 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3'
49 867: SEQUENCE { 49 867: SEQUENCE {
skipping to change at line 1004 skipping to change at line 813
946 17: SEQUENCE { 946 17: SEQUENCE {
948 12: OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C 948 12: OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C
962 1: INTEGER 16 962 1: INTEGER 16
: } : }
: } : }
965 13: [0] 94 C8 68 9A 99 D2 C3 8E 19 2F A6 BA 08 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 980 16: OCTET STRING 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33
: } : }
: } : }
: } : }]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="recipient-cms-processing"> <section anchor="recipient-cms-processing">
<name>Recipient CMS Processing</name> <name>Recipient CMS Processing</name>
<t>Bob's ML-KEM-512 private key:</t> <t>Bob's ML-KEM-512 private key:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8= GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8=
]]></artwork> -----END PRIVATE KEY-----]]></sourcecode>
<t>Bob decapsulates the ciphertext in the KEMRecipientInfo to get the ML -KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives the key-encry ption 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 w ith the key-encryption key, and decrypts the encrypted contents with the content -encryption key, revealing the plaintext content:</t> <t>Bob decapsulates the ciphertext in the KEMRecipientInfo to get the ML -KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives the key-encry ption 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 w ith the key-encryption key, and decrypts the encrypted contents with the content -encryption key, revealing the plaintext content:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Hello, world! Hello, world!]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<!-- [rfced] The following was provided in response to the intake form:
Acknowledgements should maybe mention draft-ietf-lamps-kyber-certificates.
There is an Informative reference to I-D.kampanakis-ml-kem-ikev2 which is only r
eferenced from the Acknowledgements section. That s polite, but if this RFC will
be delayed waiting for the other one, then it can be removed.
Please provide text if you would like to update the Acknowledgements section.
Note that draft-ietf-lamps-kyber-certificates is now in AUTH48 as RFC-to-be 9935
.
-->
<section anchor="sec-acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>This document borrows heavily from <xref target="RFC9690"/>, <xref
target="FIPS203"/>, and <xref
target="I-D.ietf-ipsecme-ikev2-mlkem"/>. Thanks go to the authors of
those documents. "Copying always makes things easier and less error
prone." - <xref target="RFC8411"/>.</t>
<t>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>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA8192XLj2JnmPZ7idFbEWNkpStgJyG13Y5UoiVpI7Q5HD0hC
JMQFFACKotLV0e8wtzMR8yzzKP0k8/0HAAkuysqy52Iy7Ezp4Cz/vp0fqFqt
JrwdMUXoxd1JMA6PWC8JnrNaFGbPtVEwnqa17jitDRedMKlJipBF2QiTbtOQ
xc+seV4785osmrBsEDInWUyzuJ8E00HUZc0wTYN+yNqLSRa8sz2n2f4qBJ1O
EuK8jYXNttCNJ2k4SWfpEftDlszCPwjprDOO0jSKJ9liijMb3o0v9IIsPBJ+
Yf/yT7Ua478wWZSVmiSxWu3P2w/4qJBmwaT378EonmCYdme/sJtBlLJRmKVs
lrJezJ6DSXfBglkW1/rhJEyCDCcTkkn4HCbhpBumQjRN+Po0k0XRFGUhSMLg
iLXD7iyJsoUwj5NhP4ln0yN2bjWv2sIwXGCsdySwGjsLF8ybdINpOhvlmzfD
7iCYROmY7YEaX/kkr9kKu9E0CidZY/Ic01hOLP6U2CB0gV0/ThZHLM16wls4
mYEkjBUHfzmPxlEW9pjV60V0TDBaHZSy5zhhV2eNBwaKsHaz0fTYHufz1y/Y
I6f0l3vgEU367Ji2pPFxEI0wnk6DdPxvJBsHcdKnB0HSHeDBIMum6dHhIc2j
oegtPCinHdLAYSeJ52l4yHc4pJX9KBvMOlibS9m8f7gUtC8CxKEHAI7Am1qQ
dqNImEZHDH9+Yd1ggtEQJyfBgu1FzywYjdgiTL8yoDYI0gEbgF+ETNw9ogf4
MY2TDHxMj/gWvfA5mI3A+Swuny/G+WP6VYAQDOKEaMpYjf/NIKp4enrAriAY
xVCuL6ezEZhVHQfOR4UyXITv2Uo88scpIAmzIybp+8yOZ6PwLUjAiiCaZLXj
MAEJJ8XMLhYdsasgidJyJJ5NMuK8n0Bcw+VoD4DUNVHUipEwZ9gLh+1gCtj+
rcsBmgCgWloAdNCNx9tINg/Y5WySQm6zwRqmzWgYbj3iyHoTrhSsEL3iUans
xdMN9GWAy9rxCHKYsVYc9Nh//ef/YO0ZNmCSKK6R4DLLgnmwzy5hSpIo3iSG
E0yCXrBGjDP5jCnHG+QYA4GDuETg38Icrt1UcA/YHSTtOAzTdX67UKRwtPXw
/x+m9ziAB2/BpE/wfcp4QZjEODiDrpKo+42rtiwqQPCycSCJB7ooG4cXjfbN
AT05wCNMavmOoWkSzX/QDTFXEfCkT7iVRmA+nx9E2ewAuB0mYffwptbynNrD
ARbk83Mf8ucCbDJzHA5YxAyGahKP4v4C1s7qgGpBNytdyEWc5bMuJyHbs9oX
B9LXo2KT9hRW8znqLq12J0jhhCbFEj5r6RWkGkw3l9Cqohc8bNzc1m74SBom
UZhGAK88hT9jMNDxeBxOenzrI7bCDDPal4cNzzlihiGrNemITsvpppkSp5vT
vmztpls3TboHsNLZQT9+O5wm8UvYzdJDHDadZXC/JfdqcYc/qSVhH7PD5DAY
wR/Ano6LoWSFdEFsp9hkKZfsMt8E2OSbbBGkFPiLoPAijUmK3bAL0bdNLhUy
nHJHcrPkW1WHSHrWKa/WRKMmi0LpqD334vLGO2LPM9jwNGczeaiMnDPMdDSB
IyNzvqJS7jdIgg+7QSc+HCbBuBfPJ7XkuSvrspl7/KgUqly4CZLa1fXvovs0
TrPa6yyYZLNxrbuKbRZVul7RpOt8UjUAWsAh8H12kLWWC9rfQdeSjpJek2Si
I8SpeXf1+8SpGqXVxnEPxqj2FoyiXJxrmIiH4x1w/71QF6T6shEf8pNhR8uT
iWJ08pcNVAWhBkkJCmMgCPnC2nmQZVE3rNlBChlBcFX7NLjKA6ivDDIVsJKj
CVSb4sKMIUirhWtrx+uB2QGCRZhvNg0AXkhalFLcmAtqWAazSyVEaBKyNDdI
AK2z4LNu27+TdmyPpPYrBclkgUEL5QArwYYeIMDCaNJF+JlSoFaaBu5nJv1s
wPZos164nDENE64RcCBf9wmgdAsfAjvHpaZJ8n75c1039jloxe8S1PggD5+R
NMxgCLMltilHFbE8olLCNSfSjENQkGkOEv1kulAspMmbcTEhOutmM4BcmgnQ
6b/+83/e8iVbsbawEWszq+RW+vPpy3/95/9iezDlzISd+XogCLkNA2nAjaW3
4vaHRHYc9XqjUCBj14ADh9h2uXR9/wXsqkWVoV8F4YYEKVeJQrJ/nDBUZXrC
GhduzXEsOfcRv7GUr0sLqYs+ctJ9/14EAL/+WkosiR+7unZKU4Y5hR399deD
ZQqXs5xcBUJ6sJ2CahoBUyDpa8e8hQmlc1yYIqI7uTaA1wHSXCymSVhLl+pQ
TE/3Qd4MG3cR6GOXLzwL+gLyf//+T+AGMQNA52KQ/pa0lEo7yzPYNcVdqTS4
zUII8Siehr0abFFAQp2RqFOKtL+cRBaSRJ1ysp0TCdfdk3+w/4/VqxclxI3Z
rhz8B5jnyhQG3QEto8nZTquWxOOqNOxz3o4WrHn2k6aBNTKADmARfbGg14Ol
TSk3A3e7o1kvrNK/tJ0pgZHRSDBZsMGik0Q9lnYH4TgEo3/5BQHMyqbkdjIZ
R4WhrChULVuNF1oF884oCU/Zl+Zt++bLfv4vQ+RBP7e869tGy3Pp5/aJdX6+
/EEoZrRPLm/P3dVPq5XOZbPpXbj5YoyytSHhS9N6/JIT6Mvl1U3j8sI6/5Jz
qspdsrtQmk6IRwAfZKL0PUiFXph2k6iTK6jtXP2f/y2pLBd6WZJI6PNfDKmu
4pc5hCs/LZ6AX/mvoPVCCKbTMEhoF8qVYRaiLBhBr0D2dIDYiYdYoPM//4Uo
89cj9i+d7lRS/1wMEMJrgyXN1gY5zbZHthbnRNwxtOOYJTXXxjcovQ6v9bj2
e0n3yuC//OsIloLVJONfYanXjHhFesincsvJ7TkksBDVqrCNR7VhOIacrYxh
wEZFYNLhgQlJ32fBReEXC6sPDk3od24JvSSJk5QYFFGFagKXP1pwP55Qjg1D
uw8GR9BlfuZSy3vl8TCfSCEpvMkGASnWM6wp68dxrxoKcGlJwhEPlCEz6ZgE
hAY7wYgm5AjQAIwKpCSj3DaFNU+XHmBOUlQ184WH37YtR78nvKgszu1y1XIt
4x0k0uEoZXPIL+sO4jT3P1Al4DxC6JNxGc+dYkCU4rU9+PfOKO4OC6RoV0kG
GJIJuHCUrOmsA8LvgzZke3PqHMDhgEfxqAdlQ5j8FkFB2ThOSHFXOSw525wy
m1ASljntBMECnTecT7FlQbrn2YTLH6gGb34cTvYQt618eki/0oZuWBk6yE3e
czwaxXMeGM7GY8jBR+460q3NPw1i95d1T9qmGydEiXhCVbnK6vXA4UgQSlBZ
7c9sLxzus94QOfoRO85Lqrntn846I7BgXS1IzrDiK0cqIDl/o/m9cGsStoST
qQYsFf84j1nOihy1YMmMckNscYT9dbUWd7MQwhxCZPd6+x/FyRNA8T7Fj2Hv
629CsYwiITps77/nRx2URPjvX7e8KStqy4Ur/21K8Fm/BQWPAYMRVGUSlLYB
mhBUkYOdKM/uIThLSDXy/SeFSoU8KiuRJz1CPsmf4SjyFitk9U1k/527LkR8
/LBdiOf7pquzsH845DD0hgesDan8/r1d2FydVLJRcw8q9xD5HUQXNigv9IQp
dn3mccWSs0RJXjmmcCqFMuWVEFK4quoQcUlAu/ssTXP5zENXwJaU4dMf0pI9
JUP2SUURsoesE8PEBVWbuNf9WlieaZCmOXpr2xVynQ4CstIpZWZYheOLFCks
w27QuI/YOYuTqnzJ4orkOSoE0S5CFxH5ukyVKssPK7YRhKrt6EFZu5wsabpO
kSp9SeCWcrmO/oo6nMW78VwjCbS4gqC0QjCHi0Dq/gjFdX3YhSJrPG+hEJG7
ipM8quKSSAZjn/1QoNk4WBBzJ5jPgzOwMleiNAunxOyiTLdDmI3fI8xcbrEn
XUatyzCLtnHJfW+JDJdKjhFxaKnIhT0snM6mU1oF4SSDCNmUGtzffv4Td9T4
6czj/pHfGdFv5CBLApFjXAuiVt5vFT9Vn1cz340oq7xYrHiklYSsbguLIIzH
T2XuvFmEQSBIDAvH01G8yKkA10zqlbvspRSm1Y1/kJQVwbamazJlRT+ZAW6s
quSXP50NlluIhkKJd2OSh0JdxJf7u5O+tcQ4ohvOVVi2g1SQ3jxEQgSYJcEk
heMvCzkEBVXHqDhSeh2uj+umasvcQSaukhhx6FbtZwvaPFopPAPVEUileOy7
0iGZpGKJE+JDgDybTuMk+yR6CTiNKwDyRCaCNIQ86aJVa9HUyn7khpqWr4z3
jtVrgddydZ6triNYzV0rkltLqrMgx/elL97iEPnlqiAHK9ByEVg/sBIKFFYX
4fAGMtCNS6xM1lf+VMUtSKtFt6qwlfFnFI56aanIWzsNgrfcSazi1HEYUPID
zyP8eVknKsx8cS9Qjk5mY9jOPyIxWiIiHtAyKhnAXE6yVamk6swrxpZXI5a+
nS9GHre5eI0Fq/NIKYJokhsTWLNeDZOKVDA3mOtDPMHBgeujyzQHBm95bpIX
YZOw8KQFfXnCuZrDycwh7mYljSqueLl2eZFSVUqs6z1vYkoVcPgZ8itcAUqk
D+jOLczFh1MEyu+u5vmlxuyduf7X3MrQoaQ66xyf5qagNMq96JnnFjw5LQpX
rr8yU9FuNYDtKzWwcImcIaUhOKE9Cltp6GT6uL2BwyKPRk8ogpAM8U+ra038
VlPJMK8Ev+DTAHSq0QY1hDK0nnbPb94qDCsrMLrEzRIi8VXhf6kb+dNcUVcZ
MVeSpQgHnZToMc9NAJi2fVRexUmrFOKXoLmTWPrJxnLFDnqB/iW5YtJ+woqb
2nk4GhViNTzPrxBK9UP2WKpycVVSdQakCZRIpXz1bMiNVTwtbjqiCYKi0jls
iNnSZPJsv0jSt6qaJEzLamIvnIa8vlWtIQb81LdgNIM/TOON6tpy7XQU8ILH
AvrwOosSTpc03ytK8/WISNdjN2XN73Dp3kr4g048y/WD4FgymNNjngTTqrYF
myRc2fhZkTUUD3/ggLf5WvB05WrJEK1rBxcXr127B0Q1RHOFbCqKSbXDH0BV
1YswxcoaR+rTFZ/piIIYiMcvvwk7LCZbxvDcUv4AlUK1/w5UsPL/MSrb6vXZ
1lWd+/49fA9oJwBfOBee0BejJIFhmgVwV+mAMAg+i8vW7tk+uxDg9wvrAfnS
P5BUr93ebdZAb1eFSOoogAskFarGNN3lcBnQrGqjyxBmFXDnRrFS31yt33IH
P4hIigJyJ1zlT1lu/QM2jibReDaG7UijIiWtJEAHQhv/JMF2YsSjlE4IDJb8
55Dza7H2FTNEsabVqVMnYxIE41+5V2lfHeQPppmUaNxVIwfdjWAuIoULjNNw
03d8Fin+yqMEIs/+qn6ziqVIVPLLuNyAlwTYNnvhTnL/jARxs88voil5gPin
z4ulH6cAmmenUK4pl9ilRq3BUOT1pa2tr9laRIJ/W3WrtMt77b9VEkKG3+i8
aRJGY7qsTVez2osxrHCSR3hVRVnNEf5Gt7Qbf9bHds340fjaHMBP1rKDwLEy
WjXQbNeMfNbu8a39Tfmz/cmIsl0ziv2L8b1//vrDE8hIfnICN8y7ZuSzdo+v
7//9iP0Cca2BKTFJLnWK/OlLIX9bgrcU1k1d/QJbQ4g0CqEO8sAAPoKHrOQn
KCMsISqqQJDjiO6UF7nod5DPUURBngXUoRn8AjOlc8f8Sg3hBzdgPMlbK1ZQ
7Fnc+HwSJOeZEY9Rl5kmv7vhWKVR2bi23M17z/sJSJuKASrorKrvgOI//uM/
BHq2lyLl22eNs+Y+D0322flXgbE/VRfuVXddLfhaWUHb5UZ7ZQw2ubBf5Omj
rBLLUo1hUhqkgGcl0TI3+QiTuDbKlQ6MJoPw5Use9C0B5lieV698VlcOZfjI
awNEPx5UbpkPbbNEMMjDtHUwo0keQwIbMHRVEd8qvhZXY8tS5c7UA97mOUrG
OdLntP+m/yni3h9F0av8Zt0t73a2my7ZqaS1nxUaKPUlf0y9K5psiGWWhB/X
b094eTF+jkZhpXHn4UATzeo5vGLW4OW/MKO0ZFQ0XqZU0a0UGlIiVrdaRiel
4iVUYVWlXTVJVKgfd/I4iFO2ssGy9vRJag8Ibna0IHWDJFlUoqPVjulGuxZQ
+8tvFmv/mpd58v55J5gGnWgEDQZlrAwS3pn9gBnpOBqHNaod/Uqx37LCdaAd
lFUu6rHdaGnhR62dFCxPykh9JvGMX+jyRooI8QzCxbyhYhVzcmIi2mgfcsCj
NZHmnfVF9HrAuBUgYeYxVh52UiqWRv3JT9Q5c7M24hfQG8dQkBxNVp0gP8Qs
BzjHbZkqbNVy1yvGlbLZqmhSVKbWD0Nc4V3feheOx2suYcpj4P7uzfISYAF4
UfypTNzKFZZ15e7yuIabZ/0FeX9qkzLr/3SzjbpCYZmoR4Iuo3KkNizLUgSX
NK8taV77NP6v7gBbX4sm9G7QZgW/UYG96JWolK7yO4gqfmXaC8OcG7FKrbhS
mA/WO/3+Qm3Uf+WGo1pjYcCgWj6jvpbyWgVIRfQaz1HuNhmj3thKG+Clfeo5
N6zhehc3Db/htdjR0Z/Yd/YSU5N+lMa1bjfKsj3563pf/p6kU+1rz1BFegWl
H0yiDy7pe9JX1o/f9iQRP3TTONlTyqVrR++pX9mveDAMfwDFBrAqVmDJVvHx
0/V8c2nXKgoUf7hK3rWKB38/XKasLdsqp322FoQG4Qo6jUOq9dY6cW8Bui+p
nKRBL432JEnRVPMrmw67KRGb/q2Ze2a5mos5Zw8gAPGZbOQwIfn/CXZH2axG
7N7F6FVL9A/ZvcE24nSFB5VqymfQEKQal46NmsWPFqi0gsdyv6wyKGf9MjFX
zeUrBetXjcWd2mdrC43nBX5o389cba4UtaikUdSwyCO7aFk0LV7fWJVGfG7o
+zEZ5V6Udmf8fcDKpWWtXLlKCdZRKfpY6CSk6ARq+jyaDRIC8TlZivNnhOD5
+67IDyYmI1NdMd6Vi9n9T6ql+z+o6u1D2nnPca1yM7h8trxzL9Zu3h6u1wcv
n4t2n7JzY8Qt4+b1MRnVcEpNllQA4U1YRTl6Hk3pGvmZomZY6APmgvqjOJ1t
edvqflCUEQXN6QzZQbSqMCBmi4paLSAp0ExLGq7uJoMsB3/7sN9Lyjj5aWpt
Qb0OMW0TpGncjXieUKzFT8XevwfaHzH490McUMEHAVBv7cWnDXjX9lnCDDe8
ejt0o82AtwPmPpnOGgcTgMxL6UUPxDPMYVGh+rTmReZj/TXaipzwMyjQw5ME
UoeIPr/Uy1tSecX+By0sS+UvYv3iGgCJQy98ndEZ0zSc9eLa2t4lONRWuXfV
ujhOv+YtTqvGNOzDbwFSHgqvBAIhUjbi0eYkXtoZ6nNeLzcQtVY4UwxcAKDI
tc4iW7VYlSFPL8z7TeEjikIEvx0Jl0njXl7CnFAXdcktRWa0GdEwDZO3shkl
CV+KOIyj8PVgE7o1YhJwRVE2P7K3SqwqtcqtZIntLJN3FjtQKWfyzGGDEIUe
LDuCKnexrGzZKZZwbAjOeRgMR7DPvMmzqHsSZbIs6A7BXhJOhIc9KjyMZ90B
oxdfcsO/DAj5xsR76vOIknhSXOYHlVvTgva8Y311q7oP5vEXm4vsIBcO3mHJ
W2bTkOda0xgOapnH5Df14yDL11XIuLZ3eXUFuVnWg4se3Zx6PMfh+VT4viI7
tsqRZ0GfUuVsXSvWtQ96wfOddXXj/I+eYT6AzB9JPtny4utAyd37quuK0Enj
cViVxso92MGyDXpdb4sXkSojvJYWzzJexdlsiVvvNf6k7kLZDak970Eahz2y
daXu5q9H4IS8/3MBuifgS7jDk6/6zsHQt3Adn+Jeb9cRvKAw6hb4pLzdkvOO
qkgR5xoFLnzoC9lWRi3fE6pU7ufDc/Iu4HM8LSqahW3lpfuKafjsphFCxGMi
SsNBscPN1jpqXlwZXGokzAbxrD/IS5qUglXRqp5RAALqPs9GeWlhCeV+UdWb
8piqhBX+o0u0gx3iircGcZrPD7rcLuzDuoyoEQBOZbRIq5Ef2YwyB0xXLQfV
zebc7REGnwEIHuedxthtP+92X3vfsYSk7AvjHeG80bEQXVLOaRDxdyVyMQUL
ivdQ8pdyljsEb3FU9LMmUTrMQX6bjej4orpQdInk6zllK7FFNqj0sReOm8tG
HuwVfACxyH0HHFN6TZz3nlCrOCf/0hsJAl1ERYXvIoNAUcCMvzFe1GQ3hD/g
RiVJ8ig24dLBaT3arNis3g6FGSQOBzna/CbsJ9/qpDfo7q6+wqDQvzxGWKtI
7I6/t4oL1oW1O5OJIFHbWYxf6EXeJ1EAxyOXIJ1IVKjiO/IemVdodhH3gHJR
n7uX7RvgvcuGu+plHRdbVp7f2C4SwOLy0eWv8ExLM/wFWRyW8G+qFJkHvRVd
VMMvqaSzvnE64DJPlgHRXh7EFYH1l3azsUrRaF1R1ivQXBVivrDitXBEFNKB
fIAE9iDPnQ+kA/xfPxA332bcQc5NXljd4SSej8Jev7jOyxkRbAzzXLLakNGB
zFG73yAM3qLRoizj/yvPDU2RmLL2+lmeOvLUbYgEE4ANoyX1omH4JufV/mAy
pBdcytuC/N3logmNLldLANID9sWJp4v8YnIewAiMgyG3OdSBVsYNdCw3VSG9
ikMaNwm/sBovz6qSxGNcfiTOc4JkxO7BoaALP34Kz8id+EkwHoejom02xMDN
LJlQ50/BYxj5IKJXGuF8onDO51W34gNXA9iS6TRkTtjNIyZuuuPpyszAYPJQ
pNy3aBxIN3i6yZl1htKNZgdTOGur6vL9F64rBRupHAkr/V5WQtOKfhUy+/07
fRuiCBjKmIQvLrVlTFXcssVpeZFTfCQhF4BlpaD4peyh+v79J8oNxc3YvziX
rsds77hx0f6z4DTbtaJoQDonlKWm31dkEtiqzFQpMOWYpXtYt1vFC7MAMrqe
37ho0FtpbdZoXp03nMYNu7GO27yCw6EVBO/h6rJ102bW+fkfEbc0+W84m9ev
a4511eYVKL91WemQrnxJo0YfKGLgLPtLQda/FiWrJdqrrobaWhlL+QpV6e3p
X4sO7zBb1ePY0lDvaV9Xb7Kl9Nt0GL3v1Uv898TVmoIiwS44RXlPM77mNTFi
jXV+fNlq3Jw0V/hh+BMUZWWJIglLieI/iuPfhWSJJRj+KbR7kmgWuA57wVZN
dIUyv6qFO8AqacVG0oFtHH+v+BZ/fk6KOYiIczgge3rJqeE8qJYv98uBsjy5
wgRaZ4VpK8XDyyCcfi6XvxMhoYLGWu13JzrCOo9INwEQCZ9SovRzfbzbRfB9
bhHW1q1+5WtWv9L8FWkeNNGsWiROld++evz9Ql6R0ZW0/0NC/k6gr6ybtifJ
ZNz+SG4E/yuj6R99hmBVFac1AnYKqvcYa7Ygr20TFJV69xbD6PmV1bKaMJst
r+io5YO3NqwsIHpsg2przOKldXZ71uRLyrZVGltZWqxZHusy+3HHrcuvJENV
FOhS5feigDW/GwU65x9Hge+yiQK/4fm9OJQS/ruQ4Cf941jk2xAakMDbaY8n
kmVMVNmlHWZ5yMHbIWCCBKHdhM1wIKf0rDIVCAtc1TbE8+C/cStDK9jfcu3Y
4P5vzODt/zum7PAKu6atm9/PZ5T2uDJjP59wcHBAlPIu3CJMwk8Ikopbo6tl
ywwnSJlk8ECWv0yMoDB/ExrByQRpU8AjTH5BW5bIlo12vEW7+OxO9XKeXlDN
kqCsJQljKpEk1TbdMX0ygnJl5PxFBkWvZVcTxv08Cx3wzyXk18ObjZwdpPRR
d1hUIsuvORZZefEavcB3Cd+nPCBFSM9fmOffD6M0e/WuXPnZoG7+zQZ6426J
2qQndEeUO3apGsJrc1SMiykZLCuulbeueG9DdxCF1KhZfmxFWEI/pi/qFf2S
xduF5feDAEQ8S6gjgmBIwmC4/AKMULkHG1NTQCevXPcxK1t1mwbLrfNXNniL
Eq9wCqAzb4GjF/6KXrg8haFf6OaW5p/nBJH2mZI/1DbflS9myPypyqt13Xg0
itL8rT86Kk9ai9czincLa4qhUn1hyacD6gNdl8e/5cfjX+5cDrifIbnECH8r
a23EWRVai5F2XnBs5wXHfFD420ZDZ/n75vjfO8Lyfspq9yfvw8yfUDfx+lwm
6Yq8PsJbOtdG1mdsHlLMx7RySwnEXdtAVtfPxRzRMNZHfnwIt7o0TSs30PTN
DaTNkR1zdh1SaQ/lpiTd6BBd/7xEYQqW1ooLyf7qqwv8FVm6OqF20eX3PKi5
xFq7bPOWr2K6VF71ijb877+UbfpFKlz259MnVIoLq7JNnxc6+MdsSl3acVMp
LHv2jwThn1lFNP7If9/qf6X5lfdnckPJO0qrLzr9kRuiTzfg3QP50gI0csj3
LeuKCuR07RWMavM4GfVIZ/c3+/LyGuyud1SE7ReD6PKD23RucOaVW0v6Mlkx
t2yTjBIWzyfC2v103ghQ1hs/rW7n1QV672gcZfQB0qi8GwrHU/76UUolzajo
US8Yl/fwXa5wI1FYvbRKrUpU5y07Ee24g3Mr+ru6zylaimr0hyfwRagDDjzy
QaHZaLjNF+vc7o/6g2Hffrpuerbluf1+c2C547v+nfb03LLdu64xfR01PxY3
p63BVOp8dLRGt30jC1YSydPx/P795PG+fSbJD1cPj9Zx1nqY2sHzPLF6iXt8
/hYv+ndXk8WoawdPxo39fDJ+O/52nV62O0Jwc9vOUv3pLJ5ZfqYYx+PH9Pnl
2/1x9+0x6EnK8VuzMUo/7oaPyfFC6R13fE0ZP3Xunw/Hr2+nvWvhavFef45E
y3188t36sfV8dnP2FrRG/VH8/q6OB5nebr1+DBa9kbhwr7P3Yf9b5Bkjayj6
Sb/ebws344n8MD4/v7Xc7lx5ncZXh8rlg+v1Fob03L5+nJx1pKZ/F88vG0rw
0oum8Xv/YfRoPLSdu+7MNYTezfnZ2W13eivdTbLnd/vK10+G2elx66bT7De+
PSa93vHTlW/fjb9d+6/Dszu7P319jL2npma/nmeeMM9u9Ctn3h8d24uXN//s
ePLeHGsvrUb/Uvxwb6d+/zVAMOO+KIdydpP071+bwfN9KwnfpmnrqTkSTl+v
3N7d49PbdNRstOavza7dufBCt3PeuHO+HTuTQEvs5t3Nw5V523kZJlOtZ/sL
Vzu9al9Pg/dbYfTcuLnL7q4z9Wx8YweNLHm6e2uGXuMpHF40z+W7l6zzPB9P
IuO90X85VS/uT1odcaFnk7tby7o9Efp33ebT2D7vPySt0zaoIevn1uNj0Jam
4u3T7Lzz7fY2Cm5PGtr5aCCfpt2bnnwniR/947j7EnUXQqI9O4Fltp7Gzff3
y9n5m3X9/n41iptZ8p4arbuzq9ng9rBzEr3Pnwbzs9vnpvjRW4TDTv22HreU
kbAQj1sXx4On2/uFnDycWu7Hx8LpNOTk7SK4t5LGc3L14uqH98HD1Vk0UdpP
UiKeKPFDNrj++GglquAq3cZgao7vGoPT8NF5T2yn/9HNXoK+mw3i44+H4Vnr
tPlqXVx3RzP/mzsNE3d6dtX0+8711fh2KlzcO1r60Rklc6k9CeaB3QCLnYXy
2vmwvfNR47ZjON6D8TTptv1X/0xpfRinM/d43H+XOndNRxGGF43RhzzTzp9a
UTz+6DRNeeS9vOvJXB3H5335LtSj6PAytsXuyHo8vJ/N2rLVNQez1+x9ql/d
CLdP4cv1t955O+qm3ki6dU6fnM7jvTJ6FOuXZ4E+Pqm73ejhJPM+Ol6mDG+1
7CxtNOSL+GrePgz7wqT54J08664zSO/P++ni+uNaPp8PznzvSWl8tM6TnmV9
u3jxL4z21fjR8JsnH4kYKv2ZPa+/P8XHwv0gyx7rp2ludBC8b5kcHsr/wGhR
zLzx5hA328trg8KqaaZZNwxHqcNcIVrwPFXUXMmWLUXRdcuW6q4hq5Ym5Qfm
NnP1lZsfX+8WjujHprVd3aAAqu76kuyqkmx5smlasuq7nu7WHcW2DU+RTNUx
YKkUp64oruPL9brmiabvGbbn2oYOW8KBXYWGxbaKZ6mi7+iOJZqiJzuG5dd1
T67LdctWDE/UNdk1NUkzDd33JEM35Do2VT3N1D1VlmzB0HxX1UzHqRsgm1KX
HdMFPK5kSrZiOpKrWYpn665ra7pluZ7r1XXNcRRT9F3bdmTBB6lBU8RHkqvK
omQbkuO4vmMDRc+XFMuXfc2SLNvxDRfgIVz2RdkSJdHSPVMyBV8yjbqleaYt
OUDBVXyx7muGZfqWBgg8Q3ccSTVNLJB0U3ZEx1IdT/QcT/U8z5UFT9dN07HN
uq4osgqEPdWSPVtzLF3y67ZoSIoiOopaNw3Pr4MDMuHvKIrjWZIv+YIJTqi+
7St1VbEAn45/RVHCMt3XZdeoi3VTBhd02/MdF7SxFV0DYyRTk/W64gqKpdmi
I4sguW6rnu9Kjq8rvqvUddtV647jqLrlqK5reA52ETGkOqZmOb6Pma4oyIal
SqYtirLvWpKtS3XHBvSuDAo5YJjv+7Zj4x9XdTVft1zDljTDkSXTU6CTmiCR
jIM0oi0rqlk3LUfXDK8u2y7kztbrdcU2daiAp3iqK9ZtUFVUDVHFConQFXTf
MhTTq2sygeE4pmVrmiX7subauoLffU2ra6bq6YBIkjxNU1yVRMOp66Kv+QJA
0SBiqmoohq06dRdCJ7mWaWsuEdSEwJuO5Wiy42gaDtZFxTRd27XrsgzG2IIJ
tooS+CXWIawudjDdumVpdQuCZoAmYKHrSZ5sGEAEywypLrkOjlTAFN0UNMU3
DdWRoPaaBmh027JExwMhXAWnQt59VRXrONzBxhqI5Iqeb9r1uqRonmUJimnr
vgkRgPhwIwJBFHUFJxuKD8zrPlTVN8FbAxkCBESTVF9zDYg3hN6zBLcuYW/g
KkI2bQvouDo00HAtRfYNyLIlqrLhAVvHgpYbFhYaIK0ue4ZmQxc0KJdmQ0Uh
bm4d+mjXLdBHt3XdNRUb0ixjJ7IQuqY4hgphc3zJMk1ZdLFeBRFdIGhrkDdN
0yDqoqeppmjWIV0GyUdd1HQoZ93T6qrlwibKHiQR0u66sAuqYEi2V6+7YA6o
iANVGcA5vmIaUBXwxuVG1HRk2BbJUeuerEoW/ajLqqnpouACdBXHQ7ocBSJq
2JZpmC6QNICzatswCADLxlLVlBWE804dMiu7mlmH8Msw364n2oYCfdJ0Vwd7
vLpp2rCR0G7Ig2iDqtBf2cJxkNa6ClJovmJbmqwqLgyKBXFzTeiQKkKGJFHy
MMV2oDPgi2zVHdHAXoojyrpfNxRPEkUb1kb36iLkVxZU14I6KKT0oE3d8wwo
mgtFASyKLxu+5zp0fwMcNQv4+B62UiCPIDOsuyVYumGSNkG3ZR2KYcqyUXdc
WQGXZN2SNRE2AUT3YPIgiTJYC90BxOQcbF8S4Ak0UYIFNSxFQl6tyRJ4LUku
4NTrrmJDXCBsmGNoSh0+QMNTX5WgeLourrs2/oWx4toTCcNlq/EcJ/Bb/GMq
Df6x+NyVwCTD7NnQTFMXDR0MlHQNQyoeaCJMuyRW98378Fbf4/jsmzvb7nQn
FJ9lhwV0jg8ewt7ISEJEqw6bDE8ji7oDCliiaFQhy3vGKm/LkVcv30/d3YBb
ngJXCRpommHIummJlmb6kBNoFqy5q+nVU5BsppsZ6c99DmHtRbtPAAHFPVUx
ZZgbCY5DtBxZlsEExVcQwAB7HxbVdF0ToYLhaxsMpw2Lt+OCXm/VR7uRRx87
lc9bfwIr/zJXRYSo9LAsOPB6w16+6Wbynn92zcl3zV/EXH6/Lw3LL+sVTaug
G2Kqog+XvpCuq7X81FWjc7qdtdIV+TJdVfuP52fxU2Pw1r2wrofXVivs9/tX
LXr2cd2wLffYsZRo2O9fiHY/fR0Mo2NzLtpOy7oQrA8qRjYd69qBQo8fouaF
Xr+1LjXroZW+NuUg8c3+cNpqWumxc+8cty1/ZM2vPeu67Vhz65swtQ6PF/3h
5XkjUTpRd/L68dJ/ast3/tPgTX0MnOdvg8v7e805Vh+Qy3ycRE9d5fxUeTlp
DTuX3ZM7If6WZbIUvCqZJj80L68PO2/Ot8bivXff7133j9WTpmKkw8M3Tzfe
7gevxreL6O3SM5zYdsZ6a/IujE+m4fh9fnl+Y5yYj6/P05vJ5SCd345bziBo
z5vTpnr5MazPxNnTdHI+kpuLVlsZxrOsOx2YCDiE5nwuho91xXs9vbzvNg19
YDxPxtLV20fPjdXW5HputZqyGckntnamPiVwkL3jj6dOvTVqP32IunA/n/dT
NUC4dHL1eCgqgdkyPrwgvem9pE+JffLeHAUfhydXohMNjzuWcxgcwy/Oxidt
vfXx7eVQ+GbMrg5vpecgi97vm40nVVZ833roulb60n4Yp0+P2uKtZ3SelEst
WCQv2oVd149t8HZuP4kXb8KrO5ncTlPr4/RVuo+MkSxfNSfSnTS6DFrzlnZ3
dRt/ezt5vHp4n4wOB60GiHUi3g17r52H2ydxdCXI3cQ/b95dXx9b2qQjK43p
SzIezu1wbqsd892cPLyOwmymZoO5qAzUOFq8Kmd2t/cxuDbE+9GN8O3xxk6y
uyftfvbqXj49iouPy+u3ltW7vrkIR2EgXn7r9N4vwteXsfztJtbPR+OH/olx
fDFYuObl06Hw8vKta8bNe6t1e2v2BsGx/fEqvd9ctG/doa7PbWl8G8sv5+rk
MvbOLl+SRfahvg6i5kQ+j+/fRw/C0112qCYvD6OPTO9Ggdx5ujwMF823q645
umq0xfrV8XTYl99Hp8nD7fnd8fTu9rVxeXfqPBx3Xqz5iWDfH54/j3pn4mtz
trhDIhEOvH4HhtGdZPeHPedx9vExto2OdQG9mM5n9uD9RB0e9x+7j8PRvdsW
Zl7rtW3N1Xk8m0a9iRxl7+ezt7PIEZ+Hwxcvfl9cONLTsxmPJqGjXjn2vZT0
voVP6ftw0X69PRdO7u+7Z6NHZ6y0bt6fL/Xb4dXTt0m7N3x4t+QeYnv/0oje
3eHZZN4YLq6s07fQVa8d7dtYm/ve6YUwfYuVYbK4e571B5NrP+l9GPFh9nH6
+IoMWz/8Nnea8fHDSTR+DU77Wv1KHB+Hw2hgiC9u5/T19Fp4bt5a+vu7fju9
lA6nvq5O396Tm1v79Cp68e4v2v75dUvWzIlYH3Sk91t7cPP82upcP193bo4f
fW8uuNcb1uh97lgta+7MH08fG08N6/7WhS/zbfvFur281s61+a1ynTiNfsM1
3p8fBOt5dDXpDSfh1e38sv94utqsazdttWqFaI+Wbb13pw+teGa/zS9VeSIc
H9OJiDSfbhrB6euTmF5eHre/jWf9vuf5H+/h8fvDu2gld1eLm/l8eta6af5p
lZ0vTSv3LDf5Z7m4Ie6FhTeIl28misw01aPVy6l056oyJklHbPvFr/Jynv7b
VsG2N5GYzAxVZHnfBJOYSZ9vxSi9jCjVmVmvY+VfxL/SKTIe1xXaqXq2TKV9
if/3txoXN96x12KiQC/TGYbBR9veDc1TcJKh8hH2F5VvqOgF2PRn+521P3wC
ncKUPwgMA4ZeLxZXAdKUJUDrMGk4ThbLB0CqShzGNBPoAUbmKKxuMc9lOFr0
mKcyUWOuxGyZWQoBrVvMltYX111myEy1GOJBVjcqeK3BZtB9ilk+2YWzTChy
pBmCaaaAtSqT/rB+Gv35VWCmRLc+5dClcwNKt29ajYvj9emKxywg4TNHZ47F
RJPQkh1mWMyvMx0/1+l/ls0Ug3ni+mJdY7LLTI1JGjMNpvvMk0B5QreOnw2m
ekQ67KICdnt9saEx36VXDk2HOSAuJ7FSp8NNl3kKk1z6OLKEk03mbNDU1Yje
ns10l7k2sc+ymOvR/+o60xxilCnSAbbNHHl9sQ8BdMAmVteYbtA5AA8EtfEz
VrrMd4ihKlDwIVLriy2fyT7TLCaB0w7t5Ro0CPJggQg5AH9EZunMA/DmxskS
0QkSpHnMtOk0orbLFKysM18jsps+szSOs7dBMHDIYZIKHecnSEw3iVqiQyyE
EGEv/A2aeyDEBs6eTrNBatskCikKk1WmyUQwSKbsMVsj/usSsd3e4LMh0QKc
o6isDt3yaJIEVOWCw6C24jAPRAHB/PXFpkdMAm1sn9irKsQ5Q2U6/1kkFabd
ITw6wDE2dEekA2WbkNdt4gfYQ4Jhk7JpNqkihASIYDvF3ZBti2YAbFlktkJb
2CptAX11cJpC4gGIsK8LvJz1xSC1CqnC3y5x2HOYjvUiU+vMAbVNEgHs4vO9
3A2CwcSBJQAMCyASOAfcsnUym45NsgEUQHOTL/Y2cPaxq03zDJ9riMs0n+wK
oIDMajBCMm0NDQFdHW19sZRbJC4Vog1jTcYQJAQi0FZwri4zGxj5REK9vkFt
hcQD9JAt2h7WzQX9bdJkHZgbTFT5vlLOvA1jALk1SG69OvED4g3egoqmRbIF
akFt4BCgraC8s0FtCL2mkT6aKokqEQZGzqNBxSUJhZ2CtkFyYaq0DQkjYsCY
eIQ8gIQmgs8wKeAzZBOktkwCwc1lbkMlIZiuSaLvaKRM+FsTyboDYeACSwRq
2bBKMmmut2HDgJvK6VHn2Na5DQTxYfKxEnoOTcbfwBm2xdY3wOb6BAUEnuQT
OdnpKIPkBGA7HCMolkuqvuGRIL0mqRHoZHlkDzVOBTAPlhBMAhUhKq7Ckdqw
JDB3vkpIguBgqcNB1eqEDhgODQHz6nXyprBTlrWhVSZJMg6HeincdBTeUSSj
L+qkmEDNUOgMbwNnzIAMwtzBEvk6TYJLA/3gQIAqDCCEnGwrt8TexslunSYB
Wog0gId4wgFYnP6uzp0RELYomoBVNjckDMYJqGKGR2wkhrvcelv8NPgDkxsg
PIXN2LTboA22xwNyazIx061zd2UT5aBSsk5EgT6aUKEN8axzNYT0Q5LJ7mjE
UnCOjJFDBgTiacIBuaTeprolYTgKIgkBJnukkUpATmDSwG0QAh67LhHDDNL5
9cXwKTAGEEkYk7pHWECTXB6qgG1kw0ROPJf7anXL6NseiYHLNQGGFvjD7kN4
iE6AXCGVkLglETcMoFsGQ+AzjhK5SMB0gniqRC4SjgYRB3wQogd9czGnsKrS
ejI6Dqk0jB40BKRCoACFJeHhLFQ3VNJG4MI9E6wfHagSbRWJOA+TQPZQJm0B
88gqb3hJSDL0ESshmDiQiOeSSoEKsGrwu3AjsDYKD+esDdOLZVBanQc04BBi
EpGbwbpK2grDAoIBOthG+D13MzKwaB6MBgVuDok3kITegz0eXw/rB/wlLvby
hmJggWiQ6AE9RyRhBJ+AAqIxWCWYdOyOIAzOlCzkBs7wL3BImAFXCFLhHLAE
0gKRoKje5eaekwBqK2/6Ko94AEmCSMDjIaZDpIhoCOMEiMKNGZdQcN7cABvH
gpmAEyECOVGZpAI/AwosA1IYUUSynsBoi1UizQBVgaHHQ6k6py0pIHcGREiL
Hwux3QgfLTh+jRCDAJINUCgIgVvCeokrJn7FsWQSIP8bjs7mJoKMEd8COINy
MC8IZWmlTxJODkgnH4KY38DGsKU7Yn4DwlLJBn6couV/qMnzPsoG7fxjKJ9k
aUT3r9uLfxUMyj+2MyBJFwzo++7MxDAoa/pBZrJ9UPULJXs70hY45t3gwf2D
J7+dtkC4NK4KsEwy9ybgG+yYaJHewllD9USFNA6u1N0IcwAE3BccP4QbWob0
BlTxtS2Aft0c2Rz4VTBhh+FnjzZIZsryimTbmVxvd4INifoqmIiFIfVHm1ww
Fa3Chd/kQcEBqizvZoCOo1RKsnfkyaZKWaq8iw2UW1FQo1LmRAkTlEskP2jA
jNTJleqOYOryJ1L2EyQ2uVIU6kLlBciEY9Bx8IUwwTAKSDcQRUic9TAiMKqi
sc0aSqgl/WgXBnC6FKs55BLhFUAapBiaSokf7Ae2hxypXKOVDeVfB3jtt/LT
OZWv+G91hm03LFT+60LbzWCtxp1141W6wfxrx7reLF5d27Z3hmHLtvpNz75+
PHGs4Zkzn1+4fePaazVufPv23n/vPwnHg7R70lKfG44XNRbXo9OoG5+14+Tc
EWfnH9Z786UpXtw8KpfuUL/8mJtXL0alFrUFT9kqUnlPP9z6rvynn4Nd/XeC
KgRZu6ba/+1bs/1/4AKMRl2vtbzh+F0XYvuf3jwVPYp/583Tfvnhg9Xl0da3
Y9Lfui7aL75LUHbET0f0Bjhxo5hfCNtJOBqBhLxt85/4yP8FJSkn5tmBAAA=
<!-- [rfced] FYI - We updated artwork elements to sourcecode per the guidance
given in the document intake form:
"...the two-line code block in section 2.2.1, the identifiers in section 3 and
especially the sample data in Appendix C."
A) Please review and let us know if any other artwork elements need to be
marked as sourcecode.
B) Please review the current list of preferred
values for sourcecode "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
and let us know how/if type should be set. If the list does not contain an
applicable type, then feel free to let us know. Also, note that it is
acceptable to leave the "type" attribute not set.
--> -->
<!-- [rfced] We have added expansions for abbreviations throughout the
document and use abbreviated forms for expansions upon first use. Please
let us know any objections.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
In addition, please consider whether "tradition" should be updated for
clarity. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone. Possible
substitutions for "traditional" (used in past RFCs) include "commonly used",
"typical", "long-established", "conventional", and "time-honored". -->
</rfc> </rfc>
 End of changes. 88 change blocks. 
948 lines changed or deleted 439 lines changed or added

This html diff was produced by rfcdiff 1.48.