<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-cms-kyber-13" number="9936" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.30.2 --><front> <title abbrev="ML-KEM in the CMS">Use of ML-KEM in the Cryptographic Message Syntax (CMS)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-cms-kyber-13"/>name="RFC" value="9936"/> <author initials="J." surname="Prat" fullname="Julien Prat"> <organization>CryptoNext Security</organization> <address> <postal> <street>16, Boulevard Saint-Germain</street> <city>Paris</city> <code>75005</code> <country>France</country> </postal> <email>julien.prat@cryptonext-security.com</email> </address> </author> <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth"> <organization abbrev="Entrust">Entrust Limited</organization> <address> <postal> <street>2500 Solandt Road -- Suite 100</street><city>Ottawa, Ontario</city><city>Ottawa</city><region>Ontario</region> <code>K2K 3G5</code> <country>Canada</country> </postal> <email>mike.ounsworth@entrust.com</email> </address> </author> <author initials="D." surname="Van Geest" fullname="Daniel Van Geest"> <organization>CryptoNext Security</organization> <address> <postal> <street>16, Boulevard Saint-Germain</street> <city>Paris</city> <code>75005</code> <country>France</country> </postal> <email>daniel.vangeest@cryptonext-security.com</email> </address> </author> <dateyear="2025" month="September" day="23"/> <area>Security</area> <workgroup>LAMPS</workgroup>year="2026" month="February"/> <area>SEC</area> <workgroup>lamps</workgroup> <keyword>Key Encapsulation Mechanism (KEM)</keyword> <keyword>KEMRecipientInfo</keyword> <keyword>ML-KEM</keyword> <keyword>Kyber</keyword> <abstract><?line 105?><t>Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistantkey-encapsulation mechanismKey Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US National Institute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629).</t><!-- End of 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 mailing list (<eref target="mailto:spasm@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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> <middle><?line 112?><section anchor="sec-introduction"> <name>Introduction</name><t>The<!-- [rfced] FYI: We have updated "Module Lattice Key Encapsulation Mechanism" to "Module-Lattice-Based Key-Encapsulation Mechanism" to match its use in NIST FIPS 203 and draft-ietf-lamps-kyber-certificates (and for consistency with the Abstract). Please let us know any objections. 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]. 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 of KEM algorithms for the CMS enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document specifies the direct use of ML-KEM in the KEMRecipientInfo structure using each of the three parameter sets from <xref target="FIPS203"/>, namelyMK-KEM-512,ML-KEM-512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude the use of ML-KEM as part of any hybrid scheme.</t> <section anchor="sec-intro-terminology"> <name>Conventions and Terminology</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?> <!-- End of terminology section -->here. </t> </section> <section anchor="sec-intro-ml-kem"> <name>ML-KEM</name> <t>ML-KEM is a lattice-basedkey encapsulation mechanismKEM using Module Learning with Errors as its underlying primitive, which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The parameters for each of the security levels were chosen to be at least as secure as a generic block cipher of 128, 192, or 256 bits, respectively. <xref target="arnold"/> provides more information on ML-KEM security levels and sizes.</t> <t>All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate().</t> <t>The following summarizes these three functions for the ML-KEM algorithm, referencing corresponding functions in <xref target="FIPS203"/>:</t> <dl> <dt>KeyGen() -> (ek, dk):</dt> <dd> <t>Generate the public encapsulation key (ek) and a private decapsulation key (dk). <xref target="FIPS203"/> specifies two formats for an ML-KEM private key: a 64-octet seed (d,z) and an (expanded) private decapsulation key (dk). Algorithm 19 (<tt>ML-KEM.KeyGen()</tt>) from <xref target="FIPS203"/> generates the public encapsulation key (ek) and the private decapsulation key (dk). As an alternative, when a seed (d,z) is generated first and then the seed is expanded to get the keys, algorithm 16 (<tt>ML-KEM.KeyGen_internal(d,z)</tt>) from <xref target="FIPS203"/> expands the seed to ek and dk. See <xref section="6" sectionFormat="of"target="I-D.ietf-lamps-kyber-certificates"/>target="RFC9935"/> for private key encoding considerations.</t> </dd> <dt>Encapsulate(ek) -> (c, ss):</dt> <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 originator. Algorithm 20 (<tt>ML-KEM.Encaps(ek)</tt>) from <xref target="FIPS203"/> is the encapsulation function for ML-KEM.</t> </dd> <dt>Decapsulate(dk, c) -> ss:</dt> <dd> <t>Given the private key (dk) and the ciphertext (c), produce the shared secret (ss) for the recipient. Algorithm 21 (<tt>ML-KEM.Decaps(dk,c)</tt>) from <xref target="FIPS203"/> is the decapsulation function for ML-KEM. If the private key is stored in seed form, <tt>ML-KEM.KeyGen_internal(d,z)</tt> may be needed as a first step to compute dk. See <xref section="8" sectionFormat="of"target="I-D.ietf-lamps-kyber-certificates"/>target="RFC9935"/> for consistency considerations if the private key was stored in both seed and expanded formats.</t> </dd> </dl> <t>All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE128, and SHAKE256 internally.</t><!-- End of ML-KEM section --> <!-- End of introduction section --></section> </section> <section anchor="sec-using"> <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 recipients in the CMS enveloped-data content type <xref target="RFC5652"/>, the CMS authenticated-data content type <xref target="RFC5652"/>, or the CMS authenticated-enveloped-data content type <xref target="RFC5083"/>. In each case, the KEMRecipientInfo <xref target="RFC9629"/> is used with the ML-KEM algorithm to securely 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 algorithm, a CMS originator <bcp14>MUST</bcp14> implement the Encapsulate() function and a CMS recipient <bcp14>MUST</bcp14> implement the Decapsulate() function.</t> <section anchor="sec-using-recipientInfo"> <name>RecipientInfo Conventions</name> <t>When the ML-KEM algorithm is employed for a recipient, the RecipientInfo alternative for that recipient <bcp14>MUST</bcp14> be OtherRecipientInfo using the KEMRecipientInfo structure as defined in <xref target="RFC9629"/>.</t> <t>The fields of the KEMRecipientInfo have the following meanings:</t><ul empty="true"> <li> <t>version is the<dl spacing="normal" newline="true"> <dt>version</dt><dd>The syntax version number; it <bcp14>MUST</bcp14> be0.</t> </li> </ul> <ul empty="true"> <li> <t>rid identifies0.</dd> <dt>rid</dt><dd>Identifies the recipient's certificate or publickey.</t> </li> </ul> <ul empty="true"> <li> <t>kem identifieskey.</dd> <dt>kem</dt><dd>Identifies the KEM algorithm; it <bcp14>MUST</bcp14> contain one of id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These identifiers are reproduced in <xreftarget="sec-identifiers"/>.</t> </li> </ul> <ul empty="true"> <li> <t>kemct is thetarget="sec-identifiers"/>.</dd> <dt>kemct</dt><dd>The ciphertext produced for thisrecipient.</t> </li> </ul> <ul empty="true"> <li> <t>kdf identifiesrecipient.</dd> <!-- [rfced] We have updated the following sentence since we fully expanded HKDF. Please let us know any objections. Original: Implementations MUST support HKDF [RFC5869] with SHA-256 [FIPS180], using the id-alg-hkdf-with-sha256 KDF object identifier [RFC8619]. Current: Implementations MUST support the HMAC-based Key Derivation Function (HKDF) [RFC5869] with SHA-256 [FIPS180] using the id- alg-hkdf-with-sha256 KDF object identifier [RFC8619]. --> <dt>kdf</dt><dd>Identifies thekey-derivationkey derivation algorithm. Note that the Key Derivation Function (KDF) used for CMS RecipientInfo process <bcp14>MAY</bcp14> be different than the KDF used within the ML-KEM algorithm. Implementations <bcp14>MUST</bcp14> supportHKDFthe HMAC-based Key Derivation Function (HKDF) <xref target="RFC5869"/> with SHA-256 <xreftarget="FIPS180"/>,target="FIPS180"/> using the id-alg-hkdf-with-sha256 KDF object identifier (OID) <xref target="RFC8619"/>. As specified in <xref target="RFC8619"/>, the parameter field <bcp14>MUST</bcp14> be absent when thisobject identifierOID appears within the ASN.1 type AlgorithmIdentifier. Implementations <bcp14>MAY</bcp14> support other KDFs aswell.</t> </li> </ul> <ul empty="true"> <li> <t>kekLength is thewell.</dd> <dt>kekLength</dt><dd>The size of the key-encryption key inoctets.</t> </li> </ul> <ul empty="true"> <li> <t>ukm is optionaloctets.</dd> <dt>ukm</dt><dd>Optional input to thekey-derivation function.KDF. The secure use of ML-KEM in CMS does not depend on the use of a ukm value, so this document does not place any requirements on this value. See <xref section="3" sectionFormat="of" target="RFC9629"/> for more information about the ukmparameter.</t> </li> </ul> <ul empty="true"> <li> <t>wrap identifiesparameter.</dd> <dt>wrap</dt><dd>Identifies a key-encryption algorithm used to encrypt the content-encryption key. Implementations supporting ML-KEM-512 <bcp14>MUST</bcp14> support the AES-Wrap-128 <xref target="RFC3394"/> key-encryption algorithm using the id-aes128-wrap key-encryption algorithmobject identifierOID <xref target="RFC3565"/>. Implementations supporting ML-KEM-768 or ML-KEM-1024 <bcp14>MUST</bcp14> support the AES-Wrap-256 <xref target="RFC3394"/> key-encryption algorithm using the id-aes256-wrap key-encryption algorithmobject identifierOID <xref target="RFC3565"/>. Implementations <bcp14>MAY</bcp14> support other key-encryption algorithms aswell.</t> </li> </ul>well.</dd> </dl> <t><xref target="example"/> contains an example of establishing a content-encryption key using ML-KEM in the KEMRecipientInfo type.</t><!-- End of recipientinfo conventions section --></section> <section anchor="sec-using-components"> <name>Underlying Components</name> <t>When ML-KEM is employed in the CMS, the underlying components used within the KEMRecipientInfo structure <bcp14>SHOULD</bcp14> be consistent with a minimum desired security level. Several security levels have been identified inNIST SP 800-57 Part 1<xref target="NIST.SP.800-57pt1r5"/>.</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 section="7" sectionFormat="of" target="RFC9629"/>:</t> <table anchor="tab-strong"> <name>ML-KEM KEMRecipientInfocomponent security levels</name>Component Security Levels</name> <thead> <tr> <th align="left">Security Strength</th> <th align="left">Algorithm</th> <th align="left">KDFpreimage strength</th>Preimage Strength</th> <th align="left">Symmetrickey-encryption strength</th>Key-Encryption Strength</th> </tr> </thead> <tbody> <tr> <td align="left">128-bit</td> <td align="left">ML-KEM-512</td> <td align="left">128-bit</td> <td align="left">128-bit</td> </tr> <tr> <td align="left">192-bit</td> <td align="left">ML-KEM-768</td> <td align="left">192-bit</td> <td align="left">192-bit (*)</td> </tr> <tr> <td align="left">256-bit</td> <td align="left">ML-KEM-1024</td> <td align="left">256-bit</td> <td align="left">256-bit</td> </tr> </tbody> </table> <t>(*) In the case of AES Key Wrap, a 256-bit key is typically used because AES-192 is not as commonly deployed.</t> <section anchor="use-of-the-hkdf-based-key-derivation-function"> <name>Use of theHKDF-basedHKDF-Based Key Derivation Function</name> <t>The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions.</t><artwork><![CDATA[<sourcecode><![CDATA[ HKDF(salt, IKM, info, L) = HKDF-Expand(HKDF-Extract(salt, IKM), info,L) ]]></artwork>L)]]></sourcecode> <t>When used with KEMRecipientInfo, the salt parameter isunused,unused; thatisis, it is the zero-length string "". The IKM,infoinfo, and L parameters correspond to the same KDF inputs from <xref section="5" sectionFormat="of" target="RFC9629"/>. The info parameter is independently generated by the originator and recipient. Implementations <bcp14>MUST</bcp14> confirm that L is consistent with the key size of the key-encryption algorithm.</t><!-- End of Underlying Components section --></section> </section> <section anchor="sec-using-certs"> <name>Certificate Conventions</name><t>RFC 5280 <xref<t><xref target="RFC5280"/> specifies the profile for using X.509Certificatescertificates in Internet applications. A recipient static public key is needed forML-KEM,ML-KEM and the originator obtains that public key from the recipient's certificate. The conventions for carrying ML-KEM public keys are specified in <xreftarget="I-D.ietf-lamps-kyber-certificates"/>.</t>target="RFC9935"/>.</t> </section> <section anchor="sec-using-smime-caps"> <name>SMIME Capabilities Attribute Conventions</name> <t><xref section="2.5.2" sectionFormat="of" target="RFC8551"/> defines the SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content type <xref target="RFC5652"/>, a compliant implementation <bcp14>MAY</bcp14> include the SMIMECapabilities attribute that announces support for one or more of the ML-KEM algorithm identifiers.</t> <t>The SMIMECapability SEQUENCE representing the ML-KEM algorithm <bcp14>MUST</bcp14> include one of the ML-KEMobject identifiersOIDs in the capabilityID field. When one of the ML-KEMobject identifiersOIDs appears in the capabilityID field, the parameters <bcp14>MUST NOT</bcp14> be present.</t><!-- End of smime-capabilities-attribute-conventions section --> <!-- End of use-in-cms section --></section> </section> <section anchor="sec-identifiers"> <name>Identifiers</name> <t>All identifiers used to indicate ML-KEM within the CMS are defined in <xref target="CSOR"/> and <xreftarget="RFC8619"/> buttarget="RFC8619"/>; they are reproduced here for convenience:</t><artwork><![CDATA[<sourcecode><![CDATA[ nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) } kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 } id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 } id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 } id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { kems 3 } id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 28 } aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 } id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45} ]]></artwork>}]]></sourcecode> </section> <section anchor="sec-security-considerations"> <name>Security Considerations</name> <t>The Security Considerations sections of <xreftarget="I-D.ietf-lamps-kyber-certificates"/>target="RFC9935"/> and <xref target="RFC9629"/> apply to this specification as well.</t> <t>For ongoing discussions of ML-KEM-specific security considerations, refer 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 key are ephemeral and <bcp14>MUST</bcp14> be wiped after use. Disclosure of the ML-KEM private key could result in the compromise of all messages protected with that key. Disclosure of the key-encryption key, the content-encryption key, or the content-authenticated-encryption key could result in the compromise of the associated encrypted content. Disclosure of the key-encryption key, the message-authentication key, or the content-authenticated-encryption key could allow modification of the associated authenticated content.</t> <t>Additional considerations related to key management may be found in <xref target="NIST.SP.800-57pt1r5"/>.</t> <t>The generation of private keys relies on random numbers, as does the encapsulation function of ML-KEM. The use of inadequatepseudo-randompseudorandom number generators (PRNGs) to generate these values can result in little or no security. In the case of key generation, a random 32-byte seed is used to deterministically derive the key (with an additional 32 bytes reserved as a rejection value). In the case of encapsulation, a KEM is derived from the underlying ML-KEM public key encryption algorithm by deterministically encrypting a random 32-byte message for the public key. If the random value isweakly-chosen,weakly chosen, then an attacker may find it much easier to reproduce the PRNG environment that produced the keys or ciphertext, searching the resulting small set of possibilities for a matching public key or ciphertext value, rather than performing a more complex algorithmic attack against ML-KEM. The generation of quality random numbers is difficult; see Section 3.3 of <xref target="FIPS203"/> 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 directly for any purpose.</t> <t>Implementations <bcp14>SHOULD NOT</bcp14> reveal information about intermediate values or calculations, whether by timing or other "sidechannels", otherwisechannels"; otherwise, an opponent may be able to determine information about the keying data and/or the recipient's private key. Although not all intermediate information may be useful to an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically indicates that the information would not be useful to an opponent.</t> <t>Generally, good cryptographic practice employs a given ML-KEM key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of theother,other and may be essential to maintain provable security.</t> <t>Parties can gain assurance that implementations are correct through formal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) <xref target="CMVP"/>.</t><!-- End of security-considerations section --></section> <section anchor="sec-iana-considerations"> <name>IANA Considerations</name> <t>For the ASN.1 Module in <xref target="asn1"/>, IANAis requested to assignhas assigned anobject identifier (OID)OID for the module identifier(TBD1)(84) with aDescriptiondescription of"id-mod-cms-ml-kem-2024". The OID for the module should be allocated"id-mod-cms-ml-kem-2024" in the "SMI Security for S/MIME ModuleIdentifier" registry (1.2.840.113549.1.9.16.0).</t> <!-- End of iana-considerations section --> </section> <section anchor="sec-acknowledgements"> <name>Acknowledgements</name> <t>This document borrows heavily from <xref target="RFC9690"/>, <xref target="FIPS203"/>, and <xref target="I-D.kampanakis-ml-kem-ikev2"/>. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - RFC8411.</t> <t>Thanks to Carl Wallace, Jonathan Hammel, and Sean Turner for the detailed review and Carl Wallace and Philippe Cece for interoperability testing for the examples.</t> <!-- End of acknowledgements section -->Identifier (1.2.840.113549.1.9.16.0)" registry.</t> </section> </middle> <back> <displayreference target="I-D.sfluhrer-cfrg-ml-kem-security-considerations" to="MLKEM-SEC-CONS"/> <displayreference target="I-D.ietf-ipsecme-ikev2-mlkem" to="IKEv2-MLKEM"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <reference anchor="FIPS203"> <front><title>Module-lattice-based key-encapsulation mechanism standard</title><title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title> <author><organization/> </author> <date month="August" year="2024"/> </front> <seriesInfo name="DOI" value="10.6028/nist.fips.203"/> <refcontent>National<organization abbrev="NIST">National Institute of Standards andTechnology (U.S.)</refcontent> </reference> <reference anchor="RFC8551"> <front> <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <author fullname="B. Ramsdell" initials="B." surname="Ramsdell"/> <author fullname="S. Turner" initials="S." surname="Turner"/>Technology</organization> </author> <datemonth="April" year="2019"/> <abstract> <t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.</t> </abstract>month="August" year="2024"/> </front> <seriesInfoname="RFC" value="8551"/>name="NIST FIPS" value="203"/> <seriesInfo name="DOI"value="10.17487/RFC8551"/>value="10.6028/NIST.FIPS.203"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680"> <front> <title>Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/> </reference><reference anchor="RFC5911"> <front> <title>New ASN.1 Modules<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/> <!-- [rfced] References a) FYI: We updated the date forCryptographic Message Syntax (CMS) and S/MIME</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="June" year="2010"/> <abstract> <t>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform[CSOR] from "20 August 2024" to "13 June 2025" to match the1988 version of ASN.1. This document updates those ASN.1 modulesmost current date provided at the URL. Original: [CSOR] NIST, "Computer Security Objects Register", 20 August 2024, <https://csrc.nist.gov/projects/computer-security- objects-register/algorithm-registration>. Current: [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June 2025, <https://csrc.nist.gov/projects/computer-security- objects-register/algorithm-registration>. b) FYI: We've updated the date for [NIST-PQ] from "20 December 2016" toconform"30 September 2025" to match the2002 version of ASN.1. There are no bits-on-the-wire changes to anymost 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 theformats; this is simply a changedate for [CMVP] from "2016" to "3 September 2025" to match thesyntax. This document is not an Internetmost current date provided at the URL. Original: [CMVP] National Institute of StandardsTrack specification; itand 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. Please let us know if this ispublished for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5911"/> <seriesInfo name="DOI" value="10.17487/RFC5911"/> </reference>incorrect. --> <reference anchor="CSOR" target="https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration"> <front> <title>Computer Security ObjectsRegister</title>Register (CSOR)</title> <author initials="" surname="NIST" fullname="National Institute of Standards and Technology"> <organization/> </author> <dateyear="2024" month="August" day="20"/> </front> </reference> <reference anchor="RFC9629"> <front> <title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="J. Gray" initials="J." surname="Gray"/> <author fullname="T. Okubo" initials="T." surname="Okubo"/> <date month="August" year="2024"/> <abstract> <t>The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652.</t> </abstract> </front> <seriesInfo name="RFC" value="9629"/> <seriesInfo name="DOI" value="10.17487/RFC9629"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC5652"> <front> <title>Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="September" year="2009"/> <abstract> <t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="70"/> <seriesInfo name="RFC" value="5652"/> <seriesInfo name="DOI" value="10.17487/RFC5652"/> </reference> <reference anchor="RFC5083"> <front> <title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="November" year="2007"/> <abstract> <t>This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5083"/> <seriesInfo name="DOI" value="10.17487/RFC5083"/> </reference> <reference anchor="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 building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract>year="2025" month="June" day="13"/> </front><seriesInfo name="RFC" value="5869"/> <seriesInfo name="DOI" value="10.17487/RFC5869"/></reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/> <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FIPS/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 Technology</organization><address> <postal> <country>US</country> <city>Gaithersburg</city> </postal> </address></author> <datemonth="July"month="August" year="2015"/> </front> <seriesInfo name="NISTFederal Information Processing Standards Publications"FIPS" value="180-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8619.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8411.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3565.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <!-- RFC 9935 draft-ietf-lamps-kyber-certificates-11 --> <referenceanchor="RFC8619"> <front> <title>Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="June" year="2019"/> <abstract> <t>RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.</t> </abstract> </front> <seriesInfo name="RFC" value="8619"/> <seriesInfo name="DOI" value="10.17487/RFC8619"/> </reference> <reference anchor="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 Algorithm 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 Message 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 Certificate Revocation List (CRL) Profile</title> <author fullname="D. Cooper" initials="D." surname="Cooper"/> <author fullname="S. Santesson" initials="S." surname="Santesson"/> <author fullname="S. Farrell" initials="S." surname="Farrell"/> <author fullname="S. Boeyen" initials="S." surname="Boeyen"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="W. Polk" initials="W." surname="Polk"/> <date month="May" year="2008"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5280"/> <seriesInfo name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="I-D.ietf-lamps-kyber-certificates">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> <authorfullname="Sean Turner"initials="S."surname="Turner">surname="Turner" fullname="Sean Turner"> <organization>sn3rd</organization> </author> <authorfullname="Panos Kampanakis"initials="P."surname="Kampanakis">surname="Kampanakis" fullname="Panos Kampanakis"> <organization>AWS</organization> </author> <authorfullname="Jake Massimo"initials="J."surname="Massimo">surname="Massimo" fullname="Jake Massimo"> <organization>AWS</organization> </author> <author initials="B. E." surname="Westerbaan" fullname="BasWesterbaan" initials="B." surname="Westerbaan">Westerbaan"> <organization>Cloudflare</organization> </author> <dateday="22" month="July" year="2025"/> <abstract> <t> The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. </t> </abstract>month="February" year="2026"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-kyber-certificates-11"/>name="RFC" value="9935"/> <seriesInfo name="DOI" value="10.17487/RFC9935"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="NIST-PQ" target="https://csrc.nist.gov/projects/post-quantum-cryptography"> <front> <title>Post-Quantum CryptographyProject</title>(PQC)</title> <author><organization>National Institute of Standards and Technology</organization><organization>NIST</organization> </author> <dateyear="2016" month="December" day="20"/>year="2025" month="September" day="30"/> </front> </reference> <reference anchor="CMVP" target="https://csrc.nist.gov/projects/cryptographic-module-validation-program"> <front> <title>Cryptographic Module ValidationProgram</title>Program (CMVP)</title> <author><organization>National Institute of Standards and Technology</organization><organization>NIST</organization> </author> <dateyear="2016"/>day="3" month="9" year="2025"/> </front> </reference> <reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf"> <front> <title>Recommendation forkey management:partKey Management: Part 1 -general</title>General</title> <author fullname="Elaine Barker" surname="Barker"> <organization>Information Technology Laboratory</organization> </author><author> <organization abbrev="NIST">National Institute of Standards and Technology</organization> <address> <postal> <country>US</country> <city>Gaithersburg</city> </postal> </address> </author><date month="May" year="2020"/> </front> <seriesInfo name="NISTSpecial Publications (General)"SP" value="800-57pt1r5"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/> </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</organization> </author> <author fullname="John Preuss Mattsson" initials="J. P." surname="Mattsson"> <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<!-- I-D.sfluhrer-cfrg-ml-kem-security-considerations draft-sfluhrer-cfrg-ml-kem-security-considerations-03 IESG State: I-D Exists asFIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-sfluhrer-cfrg-ml-kem-security-considerations-03"/> </reference> <reference anchor="RFC9690"> <front> <title>Useofthe RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <author fullname="S. Turner" initials="S." surname="Turner"/> <date month="February" year="2025"/> <abstract> <t>The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. This document obsoletes RFC 5990.</t> </abstract> </front> <seriesInfo name="RFC" value="9690"/> <seriesInfo name="DOI" value="10.17487/RFC9690"/> </reference> <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="Kampanakis"> <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 mechanism, 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> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-kampanakis-ml-kem-ikev2-09"/> </reference>10/24/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.sfluhrer-cfrg-ml-kem-security-considerations.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9690.xml"/> <!-- I-D.kampanakis-ml-kem-ikev2 draft-kampanakis-ml-kem-ikev2-09 IESG State: Replaced by draft-ietf-ipsecme-ikev2-mlkem --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-ikev2-mlkem.xml"/> </references> </references><?line 308?><section anchor="asn1"> <name>ASN.1 Module</name> <t>This appendix includes the ASN.1 module <xref target="X680"/> for ML-KEM. This module imports objects from <xref target="RFC5911"/>, <xref target="RFC9629"/>, <xref target="RFC8619"/>, and <xreftarget="I-D.ietf-lamps-kyber-certificates"/>.</t>target="RFC9935"/>.</t> <sourcecodemarkers="true"><![CDATA[markers="true" type="asn.1"><![CDATA[ CMS-ML-KEM-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)id-mod-cms-ml-kem-2024(TBD1)id-mod-cms-ml-kem-2024(84) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS SMIME-CAPS FROM AlgorithmInformation-2009 -- [RFC5911] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } KEM-ALGORITHM FROM KEMAlgorithmInformation-2023 -- [RFC9629] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-kemAlgorithmInformation-2023(109) } kda-hkdf-with-sha256 FROM HKDF-OID-2019 -- [RFC8619] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) } kwa-aes128-wrap, kwa-aes256-wrap FROM CMSAesRsaesOaep-2009 -- [RFC5911] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes-02(38) } id-alg-ml-kem-512, id-alg-ml-kem-768, id-alg-ml-kem-1024, pk-ml-kem-512, pk-ml-kem-768, pk-ml-kem-1024 FROM X509-ML-KEM-2024 --[I-D.ietf-lamps-kyber-certificates][RFC9935] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-x509-ml-kem-2025(121) }; -- -- ML-KEM Key Encapsulation Mechanism Algorithms -- kema-ml-kem-512 KEM-ALGORITHM ::= { IDENTIFIER id-alg-ml-kem-512 PARAMS ARE absent PUBLIC-KEYS { pk-ml-kem-512 } UKM ARE optional SMIME-CAPS { IDENTIFIED BY id-alg-ml-kem-512 } } kema-ml-kem-768 KEM-ALGORITHM ::= { IDENTIFIER id-alg-ml-kem-768 PARAMS ARE absent PUBLIC-KEYS { pk-ml-kem-768 } UKM ARE optional SMIME-CAPS { IDENTIFIED BY id-alg-ml-kem-768 } } kema-ml-kem-1024 KEM-ALGORITHM ::= { IDENTIFIER id-alg-ml-kem-1024 PARAMS ARE absent PUBLIC-KEYS { pk-ml-kem-1024 } UKM ARE optional SMIME-CAPS { IDENTIFIED BY id-alg-ml-kem-1024 } } -- Updates for the SMIME-CAPS Set from RFC 5911 SMimeCapsSet SMIME-CAPS ::= { kema-ml-kem-512.&smimeCaps | kema-ml-kem-768.&smimeCaps | kema-ml-kem-1024.&smimeCaps | kda-hkdf-with-sha256.&smimeCaps | kwa-aes128-wrap.&smimeCaps | kwa-aes256-wrap.&smimeCaps, ... }END ]]></sourcecode>END]]></sourcecode> </section> <section anchor="arnold"> <name>Parameter Set Security and Sizes</name> <t>Instead of defining the strength of a quantum algorithm in a traditional manner using the imprecise notion of bits of security, NIST has defined security levels by picking a reference scheme, whichNIST expectsis expected to offer notable levels of resistance to both quantum and classicalattack.attacks. To wit, a KEM algorithm that achieves NISTPQCPost-Quantum Cryptography (PQC) security must require computational resources to break IND-CCA2 security comparable or greater than that required for key search on AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference.</t> <table anchor="tab-strengths"> <name>ML-KEM parametersets,Sets, NIST Security Level, andsizesSizes inbytes</name>Bytes</name> <thead> <tr> <th align="left">Parameter Set</th> <th align="left">Level</th> <th align="left">Encap. Key Size</th> <th align="left">Decap. Key Size</th> <th align="left">Ciphertext Size</th> <th align="left">Shared Secret Size</th> </tr> </thead> <tbody> <tr> <td align="left">ML-KEM-512</td> <td align="left">1</td> <td align="left">800</td> <td align="left">1632</td> <td align="left">768</td> <td align="left">32</td> </tr> <tr> <td align="left">ML-KEM-768</td> <td align="left">3</td> <td align="left">1184</td> <td align="left">2400</td> <td align="left">1088</td> <td align="left">32</td> </tr> <tr> <td align="left">ML-KEM-1024</td> <td align="left">5</td> <td align="left">1568</td> <td align="left">3168</td> <td align="left">1568</td> <td align="left">32</td> </tr> </tbody> </table> </section> <section anchor="example"> <name>ML-KEM CMS Authenticated-Enveloped-Data Example</name> <t>This example shows the establishment of an AES-128 content-encryption key using:</t> <ul spacing="normal"> <li> <t>ML-KEM-512;</t> </li> <li> <t>KEMRecipientInfo key derivation using HKDF with SHA-256; and</t> </li> <li> <t>KEMRecipientInfo key wrap using AES-128-KEYWRAP.</t> </li> </ul> <t>In real-world use, the originator would encrypt the content- encryption key in a manner that would allow decryption with their own private key as well as the recipient's private key. This is omitted in an attempt to simplify the example.</t> <section anchor="originator-cms-processing"> <name>Originator CMS Processing</name> <t>Alice obtains Bob's ML-KEM-512 public key:</t><artwork><![CDATA[<sourcecode><![CDATA[ -----BEGIN PUBLIC KEY----- MIIDMjALBglghkgBZQMEBAEDggMhADmVgV5ZfRBDVc8pqlMzyTJRhp1bzb5IcST2 Ari2pmwWxHYWSK12XPXYAGtRXpBafwrAdrDGLvoygVPnylcBaZ8TBfHmvG+QsOSb aTUSts6ZKouAFt38GmYsfj+WGcvYad13GvMIlszVkYrGy3dGbF53mZbWf/mqvJdQ Pyx7fi0ADYZFD7GAfKTKvaRlgloxx4mht6SRqzhydl0yDQtxkg+iE8lAk0Frg7gS Tmn2XmLLUADcw3qpoP/3OXDEdy81fSQYnKb1MFVowOI3ajdipoxgXlY8XSCVcuD8 dTLKKUcpU1VntfxBPF6HktJGRTbMgI+YrddGZPFBVm+QFqkKVBgpqYoEZM5BqLtE wtT6PCwglGByjvFKGnxMm5jRIgO0zDUpFgqasteDj3/2tTrgWqMafWRrevpsRZMl JqPDdVYZvplMIRwqMcBbNEeDbLIVC+GCna5rBMVTXP9Ubjkrp5dBFyD5JPSQpaxU lfITVtVQt4KmTBaItrZVvMeEIZekNML2Vjtbfwmni8xIgjJ4NWHRb0y6tnVUAAUH gVcMZmBLgXrRJSKUc26LAYYaS1p0UZuLb+UUiaUHI5Llh2JscTd2V10zgGocjicy r5fCaA9RZmMxxOuLvAQxxPloMtrxs8RVKPuhU/bHixwZhwKUfM0zdyekb7U7oR3l y0GRNGhZUWy2rXJADzzyCbI2rvNaWArIfrPjD6/WaXPKin3SZ1r0H3oXthQzzRr4 D3cIhp9mVIhJeYCxrBCgzctjagDthoGzXkKRJMqANQcluF+DperDpKPMFgCQPmUp NWC5szblrw1SnawaBIEZMCy3qbzBELlIUb8CEX8ZncSFqFK3Rz8JuDGmgx1bVMC3 kNIlz2u5LZRiomzbM92lEjx6rw4moLg2Ve6ii/OoB0clAY/WuuS2Ac9huqtxp6PT UZejQ+dLSicsEl1UCJZCbYW3lY07OKa6mH7DciXHtEzbEt3kU5tKsII2NoPwS/eg nMXEHf6DChsWLgsyQzQ2LwhKFEZ3IzRLrdAA+NjFN8SPmY8FMHzr0e3guBw7xZoG WhttY7Js -----END PUBLICKEY----- ]]></artwork>KEY-----]]></sourcecode> <t>Bob's ML-KEM-512 public key has the following key identifier:</t><artwork><![CDATA[ 599788C37AED400EE405D1B2A3366AB17D824A51 ]]></artwork><sourcecode><![CDATA[ 599788C37AED400EE405D1B2A3366AB17D824A51]]></sourcecode> <t>Alice generates a shared secret and ciphertext using Bob's ML-KEM-512 public key:</t> <t>Shared secret:</t><artwork><![CDATA[ 7DF12D412AE299A24FDE6D7C3BB8E3194C80AD3C733DCF2775E09FE8BEDB86D8 ]]></artwork><sourcecode><![CDATA[ 7DF12D412AE299A24FDE6D7C3BB8E3194C80AD3C733DCF2775E09FE8BEDB86D8]]></sourcecode> <t>Ciphertext:</t><artwork><![CDATA[<sourcecode><![CDATA[ 3EA40FC6CA090E2C8AF76E2727AB38E0652D9515986FE186827FE84E596E421B 85FD459CC78997372C9DE31D191B39C1D5A3EB6DDB56AADEDE765CC390FDBBC2 F88CB175681D4201B81CCDFCB24FEF13AF2F5A1ABCF8D8AF384F02A010A6E919 F1987A5E9B1C0E2D3F07F58A9FA539CE86CC149910A1692C0CA4CE0ECE4EEED2 E6699CB976332452DE4A2EB5CA61F7B081330C34798EF712A24E59C33CEA1F1F 9E6D4FBF3743A38467430011336F62D870792B866BEFCD1D1B365BED1952673D 3A5B0C20B386B4EFD1CF63FD376BD47CCC46AC4DD8EC66B047C4C95ACFF1CFD0 28A419B002FDA1B617CBA61D2E91CFE8FFFBCB8FFD4D5F6AD8B158C219E36DC5 1405DC0C0B234979AC658E72BDDF1B6773B96B2AE3E4D07BE86048040C016743 6FA839E7529B00CC9AB55A2F25DB63CC9F557594E691C11E553D4A3EBC760F5F 19E5FE144838B4C7D1591DA9B5D467494FD9CAC52CC5504060399DBDB72298EB 9A4C017B00786FDC7D9D7AA57ADBB8B61C34DE1E288B2AB728171DCE143CD169 53F984C1AED559E56BAA0CE658D32CCE42F4407504CD7A579AD0EF9B77135EAA 39B6F93A3A2E5997807F06361C83F4E67F8E3F9CF68316011514F5D85A181CEA D714CD4940E4EBAC01D66528DA32F89CEA0428E8EBCADCF8AA188C9F62E85B19 57655B7FE2B8D7973B7A7226B66D93BF7B232F3DCF653C84B4ECF1A9920DB194 9AD750B546A5552A20E54909719B8C0C07056FCB7E574AD2A32EC95001DDE844 81BE77D039ED5BF74262ECF3981F1B00D3366A9C2E061C47E241A061C6249560 D2B8446A480C38C28BA989D9F68ADC4BBAF2A20B47E4923128C72342D597FDA2 59DE0B83C2056D6B77E799B319324AA50B1D659C2A56029B7453C5F3BA5243D9 FA749D917C40D9D101E453BC8B10E42A7C089323C026F783E100B9FA6E701442 4DA6FA3792BC957EE8219D016B773F28FEDCC962A485ABAFFEC023281971E29A A689839ECFD2619E92287CD230DB26A2507CC500EB1C7A5293B5FE917AE29BF1AD350124F8A311635214B411DB9F67D3B85BD715018537EA45B41F41B4C66051 ]]></artwork>AD350124F8A311635214B411DB9F67D3B85BD715018537EA45B41F41B4C66051]]></sourcecode> <t>Alice encodes the CMSORIforKEMOtherInfo:</t><artwork><![CDATA[ 3010300B0609608648016503040105020110 ]]></artwork><sourcecode><![CDATA[ 3010300B0609608648016503040105020110]]></sourcecode> <t>Alice derives the key-encryption key from the shared secret and CMSORIforKEMOtherInfo using HKDF with SHA-256:</t><artwork><![CDATA[ CF453A3E2BAE0A78701B8206C185A008 ]]></artwork><sourcecode><![CDATA[ CF453A3E2BAE0A78701B8206C185A008]]></sourcecode> <t>Alice randomly generates a 128-bit content-encryption key:</t><artwork><![CDATA[ C5153005588269A0A59F3C01943FDD56 ]]></artwork><sourcecode><![CDATA[ C5153005588269A0A59F3C01943FDD56]]></sourcecode> <t>Alice uses AES-128-KEYWRAP to encrypt the content-encryption key with the key-encryption key:</t><artwork><![CDATA[ C050E4392F9C14DD0AC2220203F317D701F94F9DD92778F5 ]]></artwork><sourcecode><![CDATA[ C050E4392F9C14DD0AC2220203F317D701F94F9DD92778F5]]></sourcecode> <t>Alice encrypts the padded content using AES-128-GCM with the content-encryption key and encodes the AuthEnvelopedData (using KEMRecipientInfo) and ContentInfo, and then sends the result to Bob.</t> <t>The Base64-encoded result is:</t><artwork><![CDATA[<sourcecode><![CDATA[ -----BEGIN CMS----- MIID4gYLKoZIhvcNAQkQARegggPRMIIDzQIBADGCA3ikggN0BgsqhkiG9w0BCRAN AzCCA2MCAQCAFFmXiMN67UAO5AXRsqM2arF9gkpRMAsGCWCGSAFlAwQEAQSCAwA+ pA/GygkOLIr3bicnqzjgZS2VFZhv4YaCf+hOWW5CG4X9RZzHiZc3LJ3jHRkbOcHV o+tt21aq3t52XMOQ/bvC+IyxdWgdQgG4HM38sk/vE68vWhq8+NivOE8CoBCm6Rnx mHpemxwOLT8H9YqfpTnOhswUmRChaSwMpM4Ozk7u0uZpnLl2MyRS3koutcph97CB Mww0eY73EqJOWcM86h8fnm1PvzdDo4RnQwARM29i2HB5K4Zr780dGzZb7RlSZz06 Wwwgs4a079HPY/03a9R8zEasTdjsZrBHxMlaz/HP0CikGbAC/aG2F8umHS6Rz+j/ +8uP/U1fatixWMIZ423FFAXcDAsjSXmsZY5yvd8bZ3O5ayrj5NB76GBIBAwBZ0Nv qDnnUpsAzJq1Wi8l22PMn1V1lOaRwR5VPUo+vHYPXxnl/hRIOLTH0VkdqbXUZ0lP 2crFLMVQQGA5nb23IpjrmkwBewB4b9x9nXqletu4thw03h4oiyq3KBcdzhQ80WlT +YTBrtVZ5WuqDOZY0yzOQvRAdQTNelea0O+bdxNeqjm2+To6LlmXgH8GNhyD9OZ/ jj+c9oMWARUU9dhaGBzq1xTNSUDk66wB1mUo2jL4nOoEKOjrytz4qhiMn2LoWxlX ZVt/4rjXlzt6cia2bZO/eyMvPc9lPIS07PGpkg2xlJrXULVGpVUqIOVJCXGbjAwH BW/LfldK0qMuyVAB3ehEgb530DntW/dCYuzzmB8bANM2apwuBhxH4kGgYcYklWDS uERqSAw4woupidn2itxLuvKiC0fkkjEoxyNC1Zf9olneC4PCBW1rd+eZsxkySqUL HWWcKlYCm3RTxfO6UkPZ+nSdkXxA2dEB5FO8ixDkKnwIkyPAJveD4QC5+m5wFEJN pvo3kryVfughnQFrdz8o/tzJYqSFq6/+wCMoGXHimqaJg57P0mGekih80jDbJqJQ fMUA6xx6UpO1/pF64pvxrTUBJPijEWNSFLQR259n07hb1xUBhTfqRbQfQbTGYFEw DQYLKoZIhvcNAQkQAxwCARAwCwYJYIZIAWUDBAEFBBjAUOQ5L5wU3QrCIgID8xfX AflPndknePUwOgYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBBjARBAxcpXRouBvwO42n GGwCARCADZTIaJqZ0sOOGS+muggEEFzxeGxXx0ArVPyTwwpKRTM= -----ENDCMS----- ]]></artwork>CMS-----]]></sourcecode> <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 { 4 11: OBJECT IDENTIFIER : authEnvelopedData (1 2 840 113549 1 9 16 1 23) 17 977: [0] { 21 973: SEQUENCE { 25 1: INTEGER 0 28 888: SET { 32 884: [4] { 36 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3' 49 867: SEQUENCE { 53 1: INTEGER 0 56 20: [0] : 59 97 88 C3 7A ED 40 0E E4 05 D1 B2 A3 36 6A B1 : 7D 82 4A 51 78 11: SEQUENCE { 80 9: OBJECT IDENTIFIER '2 16 840 1 101 3 4 4 1' : } 91 768: OCTET STRING : 3E A4 0F C6 CA 09 0E 2C 8A F7 6E 27 27 AB 38 E0 : 65 2D 95 15 98 6F E1 86 82 7F E8 4E 59 6E 42 1B : 85 FD 45 9C C7 89 97 37 2C 9D E3 1D 19 1B 39 C1 : D5 A3 EB 6D DB 56 AA DE DE 76 5C C3 90 FD BB C2 : F8 8C B1 75 68 1D 42 01 B8 1C CD FC B2 4F EF 13 : AF 2F 5A 1A BC F8 D8 AF 38 4F 02 A0 10 A6 E9 19 : F1 98 7A 5E 9B 1C 0E 2D 3F 07 F5 8A 9F A5 39 CE : 86 CC 14 99 10 A1 69 2C 0C A4 CE 0E CE 4E EE D2 : E6 69 9C B9 76 33 24 52 DE 4A 2E B5 CA 61 F7 B0 : 81 33 0C 34 79 8E F7 12 A2 4E 59 C3 3C EA 1F 1F : 9E 6D 4F BF 37 43 A3 84 67 43 00 11 33 6F 62 D8 : 70 79 2B 86 6B EF CD 1D 1B 36 5B ED 19 52 67 3D : 3A 5B 0C 20 B3 86 B4 EF D1 CF 63 FD 37 6B D4 7C : CC 46 AC 4D D8 EC 66 B0 47 C4 C9 5A CF F1 CF D0 : 28 A4 19 B0 02 FD A1 B6 17 CB A6 1D 2E 91 CF E8 : FF FB CB 8F FD 4D 5F 6A D8 B1 58 C2 19 E3 6D C5 : 14 05 DC 0C 0B 23 49 79 AC 65 8E 72 BD DF 1B 67 : 73 B9 6B 2A E3 E4 D0 7B E8 60 48 04 0C 01 67 43 : 6F A8 39 E7 52 9B 00 CC 9A B5 5A 2F 25 DB 63 CC : 9F 55 75 94 E6 91 C1 1E 55 3D 4A 3E BC 76 0F 5F : 19 E5 FE 14 48 38 B4 C7 D1 59 1D A9 B5 D4 67 49 : 4F D9 CA C5 2C C5 50 40 60 39 9D BD B7 22 98 EB : 9A 4C 01 7B 00 78 6F DC 7D 9D 7A A5 7A DB B8 B6 : 1C 34 DE 1E 28 8B 2A B7 28 17 1D CE 14 3C D1 69 : 53 F9 84 C1 AE D5 59 E5 6B AA 0C E6 58 D3 2C CE : 42 F4 40 75 04 CD 7A 57 9A D0 EF 9B 77 13 5E AA : 39 B6 F9 3A 3A 2E 59 97 80 7F 06 36 1C 83 F4 E6 : 7F 8E 3F 9C F6 83 16 01 15 14 F5 D8 5A 18 1C EA : D7 14 CD 49 40 E4 EB AC 01 D6 65 28 DA 32 F8 9C : EA 04 28 E8 EB CA DC F8 AA 18 8C 9F 62 E8 5B 19 : 57 65 5B 7F E2 B8 D7 97 3B 7A 72 26 B6 6D 93 BF : 7B 23 2F 3D CF 65 3C 84 B4 EC F1 A9 92 0D B1 94 : 9A D7 50 B5 46 A5 55 2A 20 E5 49 09 71 9B 8C 0C : 07 05 6F CB 7E 57 4A D2 A3 2E C9 50 01 DD E8 44 : 81 BE 77 D0 39 ED 5B F7 42 62 EC F3 98 1F 1B 00 : D3 36 6A 9C 2E 06 1C 47 E2 41 A0 61 C6 24 95 60 : D2 B8 44 6A 48 0C 38 C2 8B A9 89 D9 F6 8A DC 4B : BA F2 A2 0B 47 E4 92 31 28 C7 23 42 D5 97 FD A2 : 59 DE 0B 83 C2 05 6D 6B 77 E7 99 B3 19 32 4A A5 : 0B 1D 65 9C 2A 56 02 9B 74 53 C5 F3 BA 52 43 D9 : FA 74 9D 91 7C 40 D9 D1 01 E4 53 BC 8B 10 E4 2A : 7C 08 93 23 C0 26 F7 83 E1 00 B9 FA 6E 70 14 42 : 4D A6 FA 37 92 BC 95 7E E8 21 9D 01 6B 77 3F 28 : FE DC C9 62 A4 85 AB AF FE C0 23 28 19 71 E2 9A : A6 89 83 9E CF D2 61 9E 92 28 7C D2 30 DB 26 A2 : 50 7C C5 00 EB 1C 7A 52 93 B5 FE 91 7A E2 9B F1 : AD 35 01 24 F8 A3 11 63 52 14 B4 11 DB 9F 67 D3 : B8 5B D7 15 01 85 37 EA 45 B4 1F 41 B4 C6 60 51 863 13: SEQUENCE { 865 11: OBJECT IDENTIFIER : hkdfWithSha256 (1 2 840 113549 1 9 16 3 28) : } 878 1: INTEGER 16 881 11: SEQUENCE { 883 9: OBJECT IDENTIFIER : aes128-wrap (2 16 840 1 101 3 4 1 5) : } 894 24: OCTET STRING : C0 50 E4 39 2F 9C 14 DD 0A C2 22 02 03 F3 17 D7 : 01 F9 4F 9D D9 27 78 F5 : } : } : } 920 58: SEQUENCE { 922 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 933 30: SEQUENCE { 935 9: OBJECT IDENTIFIER : aes128-GCM (2 16 840 1 101 3 4 1 6) 946 17: SEQUENCE { 948 12: OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C 962 1: INTEGER 16 : } : } 965 13: [0] 94 C8 68 9A 99 D2 C3 8E 19 2F A6 BA 08 : } 980 16: OCTET STRING 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33 : } : } :} ]]></artwork>}]]></sourcecode> </section> <section anchor="recipient-cms-processing"> <name>Recipient CMS Processing</name> <t>Bob's ML-KEM-512 private key:</t><artwork><![CDATA[<sourcecode><![CDATA[ -----BEGIN PRIVATE KEY----- MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8= -----END PRIVATEKEY----- ]]></artwork>KEY-----]]></sourcecode> <t>Bob decapsulates the ciphertext in the KEMRecipientInfo to get the ML-KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives the key-encryption key from the shared secret and the DER-encoded CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-128-KEYWRAP to decrypt the content-encryption key with the key-encryption key, and decrypts the encrypted contents with the content-encryption key, revealing the plaintext content:</t><artwork><![CDATA[<sourcecode><![CDATA[ Hello,world! ]]></artwork>world!]]></sourcecode> </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 referenced 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> <!--##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-library/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>