<?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.18 (Ruby 2.6.10) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-cms-cek-hkdf-sha256-05" number="9709" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.23.1 -->version="3" xml:lang="en"> <front> <title abbrev="Encryption Key Derivation in CMS">Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-cms-cek-hkdf-sha256-05"/>name="RFC" value="9709"/> <author initials="R." surname="Housley" fullname="Russ Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal><city>Herndon, VA</city> <country>US</country><city>Herndon</city> <region>VA</region> <country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <dateyear="2024" month="September" day="19"/> <area>Security</area> <keyword>Internet-Draft</keyword>year="2025" month="January"/> <area>SEC</area> <workgroup>lamps</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 83?><t>This document specifies the derivation of the content-encryption key or the content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256. The use of this mechanism provides protection againstwhere thean attacker that manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier.</t> </abstract> </front> <middle><?line 92?><section anchor="introduction"> <name>Introduction</name> <t>This document specifies the derivation of the content-encryption key for the Cryptographic Message Syntax (CMS) enveloped-data content type <xref target="RFC5652"/>, the content-encryption key for the CMS encrypted-data content type <xref target="RFC5652"/>, or the content-authenticated-encryption key for the authenticated-enveloped-data content type <xref target="RFC5083"/>.</t> <t>The use of this mechanism provides protection againstwhere thean attacker that manipulates the content-encryption algorithm identifier or the content-authenticated-encryption algorithm identifier. Johannes Roth and Falko Strenzke presented such an attack at IETF 118 <xref target="RS2023"/>, where:</t> <ol spacing="normal" type="1"><li> <t>The attacker intercepts aCMS Authenticated-Enveloped-DataCMS authenticated-enveloped-data content <xref target="RFC5083"/> that uses either AES-CCM or AES-GCM <xref target="RFC5084"/>.</t> </li> <li> <t>The attacker turns the intercepted content into a "garbage" CMSEnveloped-Dataenveloped-data content<xref(<xref section="6" sectionFormat="of"target="RFC5652"/>target="RFC5652"/>) that is composed of AES-CBC guess blocks.</t> </li> <li> <t>The attacker sends the "garbage" message to the victim, and the victim reveals the result of the decryption to the attacker.</t> </li> <li> <t>If any of the transformed plaintext blocks match the guess for that block, then the attacker learns the plaintext for that block.</t> </li> </ol> <t>With highly structured messages, one block can reveal the only sensitive part of the original message.</t> <t>This attack is thwarted if the encryption key depends upon the delivery of the unmodified algorithm identifier.</t> <t>The mitigation for this attack has three parts:</t><ul spacing="normal"> <li> <t>Potential<ol spacing="normal" type="1"> <li>Potential recipients include the id-alg-cek-hkdf-sha256 algorithm identifier (with no parameters) in S/MIME Capabilities to indicate support for thismitigation.</t> </li> <li> <t>Asmitigation.</li> <li>As a flag to the recipient that this mitigation is being used, carry the id-alg-cek-hkdf-sha256 algorithm identifier as the contentEncryptionAlgorithm in the EncryptedContentInfo structure. This structure is used in the enveloped-data content type, the encrypted-data content type, and the authenticated-enveloped-data content type. The parameters field of the id-alg-cek-hkdf-sha256 algorithm identifier identifies the content-encryption algorithm or the content-authenticated-encryption algorithm and any associatedparameters.</t>parameters. </li><li> <t>Perform<li><t>Perform encryption with a derived content-encryption key or content-authenticated-encryption key:</t></li> </ul><artwork><![CDATA[ CEK' = HKDF(CEK, AlgorithmIdentifier) ]]></artwork> </li> </ol> <section anchor="asn1"> <name>ASN.1</name> <t>CMS values are generated using ASN.1 <xref target="X680"/>, using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X690"/>.</t> </section> <section anchor="terminology"> <name>Terminology</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="cryptographic-algorithm-agility-considerations"> <name>Cryptographic Algorithm Agility Considerations</name> <t>There is no provision for key derivation functions other than HKDF, and there is no provision for hash functions other than SHA-256. If there is ever a need to support another key derivation function or another hash function, it will be very straightforward to assign a new object identifier. At this point, keeping the design very simple seems most important.</t> </section> </section> <section anchor="cmskdf"> <name>Use ofofHKDF with SHA-256 to Derive Encryption Keys</name> <!-- [rfced] Note that we changed "input key material" to "input keying material" here because OKM is introduced as "output keying material (OKM)" and IKM is defined as "input keying material" under Inputs. Please let us know if this is incorrect. Original: The mitigation uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) [RFC5869] to derive output keying material (OKM) from input key material (IKM). --> <t>The mitigation uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) <xref target="RFC5869"/> to derive output keying material (OKM) from inputkeykeying material (IKM). HKDF is used with the SHA-256 hash function <xref target="FIPS180"/>. The derivation includes the DER-encoded AlgorithmIdentifier as the optional info input value. The encoded value includes the ASN.1 tag for SEQUENCE (0x30), the length, and the value. ThisAlgoritmIdentifierAlgorithmIdentifier is carried as the parameter to the id-alg-cek-hkdf-sha256 algorithm identifier. If an attacker were to change the originator-providedAlgoritmIdentifier,AlgorithmIdentifier, then the recipient will derive a different content-encryption key or content-authenticated-encryption key.</t> <t>The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF-Expand functions to derive the OKM from the IKM:</t> <!-- [rfced] Section 2: We converted this <artwork> into a <dl> that is followed by <artwork>. Please review and let us know if this is incorrect. Original XML: <artwork><![CDATA[ Inputs: IKM input keying material info DER-encoded AlgoritmIdentifier Output: OKM output keying material (same size as IKM) The output OKM is calculated as follows: OKM_SIZE = len(IKM) /* length in octets */ IF OKM_SIZE > 8160 THEN raise error salt = "The Cryptographic Message Syntax" PRK = HKDF-Extract(salt, IKM) OKM = HKDF-Expand(PRK, info, OKM_SIZE) ]]></artwork> --> <dl spacing="normal" newline="true"> <dt>Inputs:</dt> <dd><dl newline="false" spacing="compact" indent="6"> <dt>IKM</dt><dd>input keying material</dd> <dt>info</dt><dd>DER-encoded AlgorithmIdentifier</dd> </dl> </dd> <dt>Output:</dt> <dd><dl newline="false" spacing="compact" indent="6"> <dt>OKM</dt><dd>output keying material (same size as IKM)</dd> </dl> </dd> </dl> <t>The output OKM is calculated as follows:</t> <artwork><![CDATA[ OKM_SIZE = len(IKM) /* length in octets */ IF OKM_SIZE > 8160 THEN raise error salt = "The Cryptographic Message Syntax" PRK = HKDF-Extract(salt, IKM) OKM = HKDF-Expand(PRK, info, OKM_SIZE) ]]></artwork> </section> <section anchor="alg-def"> <name>The id-alg-cek-hkdf-sha256 Algorithm Identifier</name> <t>The id-alg-cek-hkdf-sha256algoritmalgorithm identifier indicates that the CMS_CEK_HKDF_SHA256 function defined in <xref target="cmskdf"/> is used to derive the content-encryption key or the content-authenticated-encryption key.</t> <t>The following object identifier identifies the id-alg-cek-hkdf-sha256 algorithm:</t> <sourcecode type="asn.1"><![CDATA[ id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 31 } ]]></sourcecode> <t>The id-alg-cek-hkdf-sha256 parameters field has an ASN.1 type of AlgorithmIdentifier.</t> <t>Using the conventions from <xref target="RFC5911"/>, the id-alg-cek-hkdf-sha256 algorithm identifier is defined as:</t> <sourcecode type="asn.1"><![CDATA[ ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier{CONTENT-ENCRYPTION, { ... } } cea-CEKHKDFSHA256 CONTENT-ENCRYPTION ::= { IDENTIFIER id-alg-cek-hkdf-sha256 PARAMS TYPE ContentEncryptionAlgorithmIdentifier ARE required SMIME-CAPS { IDENTIFIED BY id-alg-cek-hkdf-sha256 } } ]]></sourcecode> </section> <section anchor="smimecapabilities-attribute-conventions"> <name>SMIMECapabilities Attribute Conventions</name> <t>The SMIMECapabilitiesAttributeattribute is defined in <xref section="2.5.2" sectionFormat="of" target="RFC8551"/>. An S/MIME client announces the set of cryptographic functions it supports using the SMIMECapabilities attribute.</t> <t>If an S/MIME client supports the mechanism in this document, the id-alg-cek-hkdf-sha256 object identifier <bcp14>SHOULD</bcp14> be included in the set of cryptographic functions. The parameter with this encoding <bcp14>MUST</bcp14> be absent.</t> <t>The encoding for id-alg-cek-hkdf-sha256, in hexadecimal, is:</t> <artwork><![CDATA[ 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 1f ]]></artwork> </section> <section anchor="use-of-hkdf-with-sha-256-with-cms"> <name>Use of HKDF with SHA-256 with CMS</name> <t>This section describes the originator and recipient processing to implement this mitigation for each of the CMS encrypting content types.</t> <section anchor="enveloped-data-content-type"> <name>Enveloped-Data Content Type</name> <!-- [rfced] Note that we lowercased the following throughout. Please let us know if corrections are needed. Enveloped-data -> enveloped-data (matches RFC 5652) Authenticated-Enveloped-Data -> authenticated-enveloped-data (matches RFC 5083) --> <t>The fourth step of constructing anEnveloped-dataenveloped-data content type is repeated below from <xref section="6" sectionFormat="of" target="RFC5652"/>:</t><artwork><![CDATA[<!-- [rfced] Because the text is quoted from RFC 5652, we marked it as a blockquote and updated it to match RFC 5652 exactly. Note that the HTML and PDF are linked to Section 6.3 of RFC 5652. However, the TXT only says "see Section 6.3". Please let us know if this causes any concern. Original (first sentence included for context): The fourth step of constructing an Enveloped-data is repeated below from Section 6 of [RFC5652]: 4. The content is encrypted with the content-encryption key. Content encryption may require that the content be padded to a multiple of some block size; see Section 6.3 of [RFC5652].]]></artwork>Current: | 4. The content is encrypted with the content-encryption key. | Content encryption may require that the content be padded to a | multiple of some block size; see Section 6.3. --> <blockquote> <ol start="4"><li>The content is encrypted with the content-encryption key. Content encryption may require that the content be padded to a multiple of some block size; see Section <xref target="RFC5652" sectionFormat="bare" section="6.3"/>.</li> </ol> </blockquote> <t>To implement this mitigation, the originator expands this step as follows:</t> <ul spacing="normal"><li> <t>Include<li>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure, and set the contentEncryptionAlgorithm.parameters field to the AlgorithmIdentifier for the content-encryption algorithm that will be used to encrypt the content, including both the algorithm and optionalparameters.</t> </li> <li> <t>Deriveparameters.</li> <li><t>Derive the new content-encryption key (CEK') from the original content-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier, which is carried in the contentEncryptionAlgorithm.parameters field:</t></li> </ul><artwork><![CDATA[ CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier) ]]></artwork><ul spacing="normal"> <li> <t>The</li> <li>The content is encrypted with the new content-encryption key (CEK'). Content encryption may require that the content be padded to a multiple of some block size; see <xref section="6.3" sectionFormat="of"target="RFC5652"/>.</t> </li>target="RFC5652"/>.</li> </ul> <t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure tells the recipient to derive the new content-encryption key (CEK') as shown above, and then use it for decryption of the EncryptedContent. If the id-alg-cek-hkdf-sha256 algorithm identifier is not present in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure, then the recipient uses the original content-encryption key (CEK) for decryption of the EncryptedContent.</t> </section> <section anchor="encrypted-data-content-type"> <name>Encrypted-Data Content Type</name> <t>As specified in <xref section="8" sectionFormat="of" target="RFC5652"/>, the content-encryption key is managed by other means.</t> <t>To implement this mitigation, the originator performs the following:</t> <ul spacing="normal"><li> <t>Include<li>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure, and set the contentEncryptionAlgorithm.parameters field to the AlgorithmIdentifier for the content-encryption algorithm that will be used to encrypt the content, including both the algorithm and optionalparameters.</t> </li> <li> <t>Deriveparameters.</li> <li><t>Derive the new content-encryption key (CEK') from the original content-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier, which is carried in the contentEncryptionAlgorithm.parameters field:</t></li> </ul><artwork><![CDATA[ CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier) ]]></artwork><ul spacing="normal"> <li> <t>The</li> <li>The content is encrypted with the new content-encryption key (CEK'). Content encryption may require that the content be padded to a multiple of some block size; see <xref section="6.3" sectionFormat="of"target="RFC5652"/>.</t> </li>target="RFC5652"/>.</li> </ul> <t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure tells the recipient to derive the new content-encryption key (CEK') as shown above, and then use it for decryption of the EncryptedContent. If the id-alg-cek-hkdf-sha256 algorithm identifier is not present in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure, then the recipient uses the original content-encryption key (CEK) for decryption of the EncryptedContent.</t> </section> <section anchor="authenticated-enveloped-data-content-type"> <name>Authenticated-Enveloped-Data Content Type</name> <t>The fifth step of constructing anAuthenticated-Enveloped-Dataauthenticated-enveloped-data content type is repeated below from <xref section="2" sectionFormat="of" target="RFC5083"/>:</t><artwork><![CDATA[<!-- [rfced] Similar to above, we have changed the following to a blockquote and updated "Section 6.3 of [RFC5652]" to "Section 6.3 of [CMS]". "6.3" currently links to Section 6.3 of RFC 3852 to accurately reflect the intent of RFC 5083. In order to link to RFC 3852, we had to add an informative reference to RFC 3852. Please review and let us know if you have concerns or have an alternate suggestion. In addition, would you like to include a note to highlight that RFC 3852 has been obsoleted? See the suggested text below Original (the first sentence is included for context): The fifth step of constructing an Authenticated-Enveloped-Data is repeated below from Section 2 of [RFC5083]: 5. The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the content- authenticated-encryption key. If the authenticated encryption algorithm requires either the additional authenticated data (AAD) or the content to be padded to a multiple of some block size, then the padding is added as described in Section 6.3 of [RFC5652].]]></artwork>Perhaps: | 5. The attributes collected in step 4 are authenticated and the | CMS content is authenticated and encrypted with the content- | authenticated-encryption key. If the authenticated encryption | algorithm requires either the additional authenticated data | (AAD) or the content to be padded to a multiple of some block | size, then the padding is added as described in Section 6.3 of | [CMS]. Note that [CMS] refers to RFC 3852, which has been obsoleted by RFC 5652, but the text in Section 6.3 was unchanged in RFC 5652. --> <blockquote> <ol start="5"><li> The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the content- authenticated-encryption key. If the authenticated encryption algorithm requires either the additional authenticated data (AAD) or the content to be padded to a multiple of some block size, then the padding is added as described in Section <xref target="RFC3852" sectionFormat="bare" section="6.3"/> of [CMS].</li></ol></blockquote> <aside><t>Note that [CMS] refers to <xref target="RFC3852"/>, which has been obsoleted by <xref target="RFC5652"/>, but the text in Section 6.3 was unchanged in RFC 5652.</t></aside> <t>To implement this mitigation, the originator expands this step as follows:</t> <ul spacing="normal"><li> <t>Include<li>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure, and set the contentEncryptionAlgorithm.parameters field to the AlgorithmIdentifier for the content-authenticated-encryption algorithm that will be used for authenticated encryption of the content, including both the algorithm and optionalparameters.</t> </li> <li> <t>Deriveparameters.</li> <li><t>Derive the new content-authenticated-encryption key (CEK') from the original content-authenticated-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier:</t></li> </ul><artwork><![CDATA[ CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier) ]]></artwork><ul spacing="normal"> <li> <t>The</li> <li>The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the new content-authenticated-encryption key (CEK'). If the authenticated encryption algorithm requires either the additional authenticated data (AAD) or the content to be padded to a multiple of some block size, then the padding is added as described in <xref section="6.3" sectionFormat="of"target="RFC5652"/>.</t> </li>target="RFC5652"/>.</li> </ul> <t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure tells the recipient to derive the new content-authenticated-encryption key (CEK') as shown above, and then use it for authenticated decryption of the EncryptedContent and the authentication of the AAD. If the id-alg-cek-hkdf-sha256 algorithm identifier is not present in the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure, then the recipient uses the original content-authenticated-encryption (CEK) for decryption and authentication of the EncryptedContent and the authentication of the AAD.</t> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This mitigation always uses HKDF with SHA-256. One KDF algorithm was selected to avoid the need for negotiation. In the future, if a weakness is found in the KDF algorithm, a new attribute will need to be assigned for use with an alternative KDF algorithm.</t> <t>If the attacker removes the id-alg-cek-hkdf-sha256 object identifier from the contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo structure prior to delivery to the recipient, then the recipient will not attempt to derive CEK', which will deny the recipient access to thecontent,content but will not assist the attacker in recovering the plaintext content.</t> <t>If the attacker changes contentEncryptionAlgorithm.parameters field of the EncryptedContentInfo structure prior to delivery to the recipient, then the recipient will derive a different CEK', which will not assist the attacker in recovering the plaintext content. Providing the object identifier as an input to the key derivation function is sufficient to mitigate the attack described in <xref target="RS2023"/>, but this mitigation includes both the object identifier and the parameters to protect against some yet-to-be-discovered attack that only manipulates the parameters.</t> <t>Implementations <bcp14>MUST</bcp14> protect the content-encryption keys and content-authenticated-encryption keys,this includesincluding the CEK and CEK'. Compromise of a content-encryption key may result in disclosure of the associated encrypted content. Compromise of a content-authenticated-encryption key may result in disclosure of the associated encrypted content or allow modification of the authenticated content and theadditional authenticated data (AAD).</t>AAD.</t> <t>Implementations <bcp14>MUST</bcp14> randomly generate content-encryption keys and content-authenticated-encryption keys. Using an inadequatepseudo-randompseudorandom number generator (PRNG) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced thekeys,keys and thensearchingsearch the resulting small set of possibilities, rather thanbrute forcebrute-force searching the whole key space. The generation of quality random numbers is difficult. <xref target="RFC4086"/> offers important guidance on this topic.</t> </section> <section anchor="privacy-considerations"> <name>Privacy Considerations</name> <t>If the message-digest attribute is included in the AuthAttributes, then the attribute value will contain the unencrypted one-way hash value of the plaintext of the content. Disclosure of this hash value enables content tracking, and it can be used to determine if the content matches one or more candidates. For these reasons, the AuthAttributes <bcp14>SHOULD NOT</bcp14> contain the message-digest attribute.</t> </section> <section anchor="operations-considerations"> <name>Operations Considerations</name> <!-- [rfced] "message content plaintext" reads awkwardly to us. Would "plaintext message content" also work? It appears twice in the following text. Original: Mitigation strategies for unwanted message traffic involve analysis of message content plaintext. When recipients accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many mitigation strategies will be unable to access the message content plaintext. --> <t>CMS is often used to provide encryption in messaging environments, where various forms of unsolicited messages (such as spam and phishing) represent a significant volume of unwanted traffic. Mitigation strategies for unwanted message traffic involve analysis of message content plaintext. When recipients accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many mitigation strategies will be unable to access the message content plaintext. Therefore, software that receives messages that have been encrypted using CMS ought to provide alternate mechanisms to handle the unwanted message traffic. One approach that does not require disclosure of keying material to a server is to reject or discard encrypted messages unless they purport to come from a member of a previously approved originator list.</t> </section> <section anchor="iana"> <name>IANA Considerations</name> <t>For the ASN.1Modulemodule inthe<xref target="appendix-asn1"/> of this document, IANAis requested to assign anhas assigned the following object identifier (OID)for the module identifier (TBD0) with a Description of "id-mod-CMS-CEK-HKDF-SHA256-2023". The OID for the module should be allocatedin the "SMI Security for S/MIME ModuleIdentifier" registry (1.2.840.113549.1.9.16.0).</t>Identifier (1.2.840.113549.1.9.16.0)" registry: </t> <table anchor="tab1"> <name></name> <thead> <tr> <th>Decimal</th> <th>Description</th> <th>References</th> </tr> </thead> <tbody> <tr> <td>80</td> <td>id-mod-CMS-CEK-HKDF-SHA256-2023</td> <td>RFC 9709</td> </tr> </tbody> </table> <t>IANA has allocated the id-alg-cek-hkdf-sha256 algorithm identifier as specified in <xref target="alg-def"/>of this document. The object identifier (OID) value of 1.2.840.113549.1.9.16.3.31 was allocated with a description of "id-alg-cek-hkdf-sha256"in the "SMI Security for S/MIMEAlgorithms"Algorithms (1.2.840.113549.1.9.16.3)" registry(1.2.840.113549.1.9.16.3).</t> </section> <section anchor="acknowledgements"> <name>Acknowledgements</name> <t>Thanks to Mike Ounsworth, Carl Wallace, and Joe Mandel their careful review and constructive comments.</t>as follows: </t> <table anchor="tab2"> <name></name> <thead> <tr> <th>Decimal</th> <th>Description</th> <th>References</th> </tr> </thead> <tbody> <tr> <td>31</td> <td>id-alg-cek-hkdf-sha256</td> <td>RFC 9709</td> </tr> </tbody> </table> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><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="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="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> </front> <seriesInfo name="RFC" value="5869"/> <seriesInfo name="DOI" value="10.17487/RFC5869"/> </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"/> <date month="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> </front> <seriesInfo name="RFC" value="8551"/> <seriesInfo name="DOI" value="10.17487/RFC8551"/> </reference><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.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <!-- [FIPS180] --> <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf"> <front> <title>Secure Hash Standard (SHS)</title> <author> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <date year="2015" month="August"/> </front> <seriesInfo name="FIPS PUB" value="180-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> </reference> <!-- [X680] --> <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> <!-- [X690] --> <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690"> <front> <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ISO/IEC" value="8825-1-2021"/> </reference><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC4086"> <front> <title>Randomness Requirements for Security</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="J. Schiller" initials="J." surname="Schiller"/> <author fullname="S. Crocker" initials="S." surname="Crocker"/> <date month="June" year="2005"/> <abstract> <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t> <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="106"/> <seriesInfo name="RFC" value="4086"/> <seriesInfo name="DOI" value="10.17487/RFC4086"/> </reference> <reference anchor="RFC5084"> <front> <title>Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="November" year="2007"/> <abstract> <t>This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5084"/> <seriesInfo name="DOI" value="10.17487/RFC5084"/> </reference> <reference anchor="RFC5911"> <front> <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="June" year="2010"/> <abstract> <t>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5911"/> <seriesInfo name="DOI" value="10.17487/RFC5911"/> </reference> <reference anchor="RFC5912"> <front> <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</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 Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5912"/> <seriesInfo name="DOI" value="10.17487/RFC5912"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3852.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5084.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/> <!-- [RS2023] --> <reference anchor="RS2023" target="https://datatracker.ietf.org/meeting/118/materials/slides-118-lamps-attack-against-aead-in-cms"> <front> <title>AEAD-to-CBC Downgrade Attacks on CMS</title> <author initials="J." surname="Roth" fullname="Johannes Roth"> <organization>MTG AG</organization> </author> <author initials="F." surname="Strenzke" fullname="Falko Strenzke"> <organization>MTG AG</organization> </author> <date year="2023" month="November" day="08"/> </front> <refcontent>IETF 118 Proceedings</refcontent> </reference> </references> </references> <?line 485?> <section anchor="appendix-asn1"> <name>ASN.1 Module</name> <!-- [rfced] We replaced TBD0 with value 80 in the ASN.1, but we note a disrepancy in the year: Original: id-mod-CMS-CEK-HKDF-SHA256-2024(TBD0) The description in the IANA Considerations section uses 2023: id-mod-CMS-CEK-HKDF-SHA256-2023 Please review and let us know if 2023 or 2024 is correct. In addition, are these slight variations in the ASN.1 correct? pkcs9(9) vs pkcs-9(9) id-smime(16) vs smime(16) Section 3: id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 31 } Appendix A: CMS-CEK-HKDF-SHA256-Module-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-CMS-CEK-HKDF-SHA256-2024(TBD0) } ... id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 31 } --> <!-- [rfced] The ANS.1 refers to RFC 5911, but it does not mention RFC 5912. Should RFC 5912 be mentioned? Original: This ASN.1 module builds upon the conventions established in [RFC5911] and [RFC5912]. ... FROM AlgorithmInformation-2009 - in [RFC5911] (note: double hyphen reduced to a single above so this can be included in a comment.) --> <t>This ASN.1Modulemodule builds upon the conventions established in <xref target="RFC5911"/> and <xref target="RFC5912"/>.</t> <sourcecodetype="asn.1"><![CDATA[ <CODE STARTS>type="asn.1" markers="true"><![CDATA[ CMS-CEK-HKDF-SHA256-Module-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0)id-mod-CMS-CEK-HKDF-SHA256-2024(TBD0)id-mod-CMS-CEK-HKDF-SHA256-2024(80) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS AlgorithmIdentifier{}, CONTENT-ENCRYPTION, SMIME-CAPS FROM AlgorithmInformation-2009 -- in[RFC5911]RFC 5911 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; -- -- CEK-HKDF-SHA256 Algorithm -- id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 31 } ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier{CONTENT-ENCRYPTION, { ... } } cea-CEKHKDFSHA256 CONTENT-ENCRYPTION ::= { IDENTIFIER id-alg-cek-hkdf-sha256 PARAMS TYPE ContentEncryptionAlgorithmIdentifier ARE required SMIME-CAPS { IDENTIFIED BY id-alg-cek-hkdf-sha256 } } -- -- S/MIIME Capability for CEK-HKDF-SHA256 Algorithm -- SMimeCaps SMIME-CAPS ::= { cap-CMSCEKHKDFSHA256, ... } cap-CMSCEKHKDFSHA256 SMIME-CAPS ::= { -- No value -- IDENTIFIED BY id-alg-cek-hkdf-sha256 } END<CODE ENDS>]]></sourcecode> </section> <section anchor="cmscekhkdfsha256-function-examples"> <name>CMS_CEK_HKDF_SHA256 Function Examples</name> <t>This appendix provides two testvectoresvectors for the CMS_CEK_HKDF_SHA256 function.</t> <section anchor="cmscekhkdfsha256-with-aes-128-gcm"> <name>CMS_CEK_HKDF_SHA256 with AES-128-GCM</name> <t>This test vectorusesincludes an AlgorithmIdentifierfor<br/>for AES-128-GCM.</t><artwork><![CDATA[<!-- [rfced] In B.1 and B.2, we have changed <artwork> to <sourcecode type="test-vectors"> because "test-vectors" are a defined sourcecode type (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types). Please review. --> <sourcecode type="test-vectors"><![CDATA[ IKM = c702e7d0a9e064b09ba55245fb733cf3 The AES-128-GCM AlgorithmIdentifier: algorithm=2.16.840.1.101.3.4.1.6 parameters=GCMParameters: aes-nonce=0x5c79058ba2f43447639d29e2 aes-ICVlen is ommited; it indicates the DEFAULT of 12 DER-encoded AlgorithmIdentifier: 301b0609608648016503040106300e040c5c79058ba2f43447639d29e2 OKM = 2124ffb29fac4e0fbbc7d5d87492bff3]]></artwork>]]></sourcecode> </section> <section anchor="cmscekhkdfsha256-with-aes-128-cbc"> <name>CMS_CEK_HKDF_SHA256 with AES-128-CBC</name> <t>This test vector uses includes an AlgorithmIdentifierfor<br/>for AES-128-CBC.</t><artwork><![CDATA[<sourcecode type="test-vectors"><![CDATA[ IKM = c702e7d0a9e064b09ba55245fb733cf3 The AES-128-CBC AlgorithmIdentifier: algorithm=2.16.840.1.101.3.4.1.2 parameters=AES-IV=0x651f722ffd512c52fe072e507d72b377 DER-encoded AlgorithmIdentifier: 301d06096086480165030401020410651f722ffd512c52fe072e507d72b377 OKM = 9cd102c52f1e19ece8729b35bfeceb50]]></artwork>]]></sourcecode> </section> </section> <section anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>Thanks to <contact fullname="Mike Ounsworth"/>, <contact fullname="Carl Wallace"/>, and <contact fullname="Joe Mandel"/> their careful review and constructive comments.</t> </section> </back> <!--##markdown-source: H4sIADZY7GYAA+08aXPjtpLf8Suwng8jp0RZp205mbzVyJoZZcbHWpocm3qV gkhI4poi9QjKGsU1+S3vt7xftt0NgIdE+ZgkVXsklcQkiKPRdzcachyHqUSE 3i8iiEJ5xpN4JZm/jOlJJc16vVtvMi9yQ7GAz14sponjy2TqBGKxVI67gP/k rTO/9aaOmotm59ipd5grkjOuEo+5UahkqFbqjL/EuV+ypX/GOE8iF1o2Ur2E FxXFSSynKteyWeQbEj8JYPWXg9CNN8vEj0L+Xm74uYz9O0GvfsiTueR9/BzN YrGc+y6/kEqJmeSjTZiIT7zSvxgd8pXywxl/9/78DV/7yZyP3vUcgPolE5NJ LO8eWwXmeMnUarLwlYKm8WYJgA0H4zdMxFKc8ZF0V7GfbNjtGtrDRMahTJxz xBvzRAKdm/Vm26l3nUaXMbFK5lF8xhyu8XuzUoq/i1YqkBtAQxTPzvj3/swP 0nmr/MOHPnyy0Ba/wgcX/pzxd7CuF4VV/n0P26JVmMTQ/HEEb3Ih/OCMz/Uy /36HMyjp1txowZgfTqN4Adu9k0inmzf9dv302Dx26qdt+9htNLLHJj2OYGst fAL6aor1Br1zJ4mc/us+P4/WIVDGk7yXJMK9VTwidOr+Ip5J4Jl5kizV2dER oEokMfSScQ3ZrQaoOFpImQDxjhqN0yMAEegiAnWkAt+TyoFGw5OCpnfETPih Shwhhef4IbIqLWVxzukfx/zlQFzgt+9q/CZK5mmjJst30VyEoVTFb0Sdi/Fb 3ntbPtmbGh8BY4e/3sqtCd+I4Dba/bg9Y8owLdieUz9lLNwiDlCkZR+PO037 eHrcNY+nnQ7R6c3wetQ4rZ+VYju8C5ariaqFvkpqs+juCB+w5QiHHV0OR+Ma PtVgBqddW3rTPJGJ+SR/JxRIEyoTEXu8Mno3OtzBt6O3eEniJAIQEAWTrBLJ o2k6VnH4y8fSnYdREM02vIIAHBYw0uggOrBFARtIhWxrSXqAoPLrj68PzvgB QXwAX3483rf79XpdAyBqfpgcxdI9Gjs3g77zYw0G5Lf5rZl+aCUE2DfJgHQs 8XsThZybWLVzGSW681UoeaU3uqw1Di2oo6V0/anv6g6Ag4lQoLhCM2Qf/obj j864yCHAHs09+KDe/EaCfC8kYBhnPuPZ/qDH6OpoOOif8dNT0E2NM5yPUNZ9 Lsq6X4YyRAqXoRt5qJzjVSBBfHaQ85qQM7DdbrAbr7we3BxWzUR9EUYhjAh2 evWhF/HVObA2tK98NZfeTrdz6PYnY71bhvWO03AI68xxHFDumoUYG899xcH8 rmCOhCuNEQAUjZ2XGSZADraAtU2gnyMzC3YLFiyK8SuzX3Fr8BcRK73tvk82 pMwY0ote3wGuRVx+IqAdwLIz+LREZG/Zzzer0KWHCtrfw4IBrsFeJVhnqTcD 214ApwjQRAu+jKM7VPL4APxDUxj1ztdzCcoHYdZ6X8Z8AaOWqwC2pwobz21V BLMIDOZ8wWFewAUgNTZ44o/hiZUNrmnKLXzPCyRjL9D2x5G3ImD/IDpODSGf 4OXI8E4G0RLgRktqJ+QJuCv8/t5Yi8+fq/vwk1sObTQ3nx6f7zm8ZhfY7pQH nZUsBTbv8+ca+1/OMLzoVpByKvoFAL0E7xkm42rlYg8DMhMJ+ZwcnB7ECTle iH3a2xljjRof5zfooyPqymUCthXp+a9/9gqwDlKcn+fJm0M36qxkDusCwhWX sBmYtjcYOf3+BeIBH9/Cox3SJgo1t+BIVnGomT6FCDZnl4O2COA7mIl4Ahx9 QJxXBA3ByKAbGdIeIwukTKjhBH4A1buMUDPBVwIVvNDZCsSFT4IIHFAAsLUF IKDb0wBmUCyMgAFw+OHOh0UXVaJX9s7BG5fgjmo8SXhVqyCxAu3JlJHMLHZF gKFd48MpTLexvUGNhgotJoC+DASi6lNiYAZeTYAVsJveihYiYb6TQIcWiHRb gRQW8dmExZEAyA+ojuf+bB5sIHiLQXeBX+fZ/SsQbvBgqDN3gRf1jmnSKMQh EOj56JvypYhx64w+xRBfoK9npqkZZahhQzIl8zX0h4V8vf0tLeHJJRFltYxC g8wAFok3doVVuAAbDjLllUqpURQLAG2mtazeeAbDXCAQsdSAK5Cfr/h1hDwG AQZs0/WXPrwoYFA3WHlaefieA6ttB7+lEAA5KmTqwghXgAgAeF8doq0dHV0M LwbgtyzFxA8ARNRAEXzxSDJB7pdLiI4RZIyaSculG6khoD0U6WkgZpazUng1 cbfGIMInEi03CLJXBULGgElUevw5W+JC5VVfFjL3bGecT9NrYG1HX3dGbzDj L9CDxA9pA0KIsJnhGLDuN2bVPMeUdzByyviDdqYwiGCSOVpx2HPgGfl8JqbS xwLG8uaB5wY+0aTkRuD+UHkIpSLXx34wYQY6Mcm1jFGf5EWLGFJo5yPTwbuu I+OPAwM9QWh+++0364YP3r/kryjJAo73+ypPuWKY4uWQ+rMXL7T3zxgq+zsR gFLjArhgJkMZ40ImY6NjhPt7jOPQ1OlWxBWFBawsLEh19ENOPyOnn2bu1slq AUxjGS98HaZo9YHIWEcYnB5cfByND6r6L7+8ouebwX98HN4MzvEZHNoPH9IH ZnqM3l19/HCePWUj+1cXF4PLcz0YWnmhiR1c9H460Gx8cHU9Hl5d9j4caOHI +5SIM9AAE2NawXVA3AnFwA1yY3+iBep1//pf/2y0Ybf/Bvay2Wh0wV7ql9PG CRhtdCFCvRopdf0KONwwsVyCGcFZRBCA4lj6CRi8KqoCNY/WIUfnA9ntZ8TM 38/4NxN32Wh/axpww4VGi7NCI+Fst2VnsEZiSVPJMik2C+1bmC7C2/up8G7x nmv85m+BD+bQaZz+7VtGPFN0y1OW570ZavYNB/WnQBnEpIcVsZXWdmgW0GFV 1jhps5dGBVMTNikekdsFej0k4SI6oQ3cM88cUzKlo23QxdH1sBMwMOig2Xko gVmAl6zxgaCaRu4BC3WW7YIrMvuhyn1wt31gFuBKstgY1oJ/kQBwa8wSob+n lD8LadU1jyb/BS4dK3jJPWPDlhEwdhWAkEsr+cDaOFZP7S+WARhMKRdg7yIF sywQehEmKNL8ow4U4N+d3C+CQVFqaqtM7lfx+xfuQoGG/7zjRJAfjEA8JwJm 2xGwdpdPj1EMAQqtjXm0SparBPGNO7WpTl65en9xyKdxtGB+aDrkvg7hK+CL tmdtKG0TobRbLbAEu783eUHQe9rmeflsN3k7epegIx1K0MCkJdocFQ15e0uT 2cNUCNdQklI309spqK24glbwiZgxZN0RKIfBZX/AK/VPrfqhtvOBDGfJPOd6 pzPDfg1UeaCApdG/Ic/QeL/WLlpv6RmWnISFpUEYzLGWWuli2DnTbqFxd5Mo dkwQ6pVApt10ciYyd40kxXAAGGZ/OoXpoX2/aX6KYTbuL1jXX8AU/4Lc8Qsw A24yFeCMl+GrY7iYsGwaiJVTRcIyTsVBwJXElPQCTGhcATZE6ivKh0GrzYuX MDajD8Av+E8Jo+UQx9gVyQbNemVn3ScvCmgNiuFXieRH8dC4MN1xOEaJInAp 9icmmUZBEK0xBtAL/DIa/ucAfBlgPRIwzo++MnyIljByEwmBwVdHtMs32Yhv +WnjuM7H7waXHHQeKB8Zx0Ay7KcERIav+MH4kUQbpq359c1740pZwlRwfNXs x6DhVZ5SFRhTJYxWU4Aoq2lcLpLEPYyfma2cHN2/wK6etGrwYaEper8mklE2 GillxdRkAF9NwaySr3J/b3Tv51SdFRnv96c7jXBooiPvaAP0gPtevvUsw6OZ HzgprDWIr8tRdfX6u0F/zIfng8vx8M1wcMPPzl7xe9hoVGkcGjd6IRcTGTuT yNtUmnhyWTlt1w95rISn/Eqj0eq0u4d8eesqGEN/nW6la0erhb+QlcbxIdKl 0jrkrQb/rDngARruxDwYHIPOM9oZk3CYTdm1AIDKj6lLDri/ww/odZBq0Hau 22iYnOOzwmd0cw1bCLWF4P7eADTHv4BbQkrJt/v+1eUYiOCAsbn5idy8KtCh Vqvxz4AujH6kcIBdkVuN3twdoqlHa+RIuodXsNd176YH8c74p+vB07bQuxlA ZP+PlR9TfMf5CBMHTr93PQJw00XP+euf9uH2syX/Cz24kHToJQkECXgS189o pznloc450pDE2oxcs9apNU1WDo8gyb/ohczkO9yALJ4IwwgE34iWkpQvcwsa MfNewZc0DqnKgj+2C5ywwAFHUl6NFxdNJ8E1s5TxdkClU+N7ULmrJkzwMUmd Gpu/MNtie7a1nWqwHhtAkp6HUfQEM4sJZoONzkq/ordUDibaAAjKPgkPfIyF COBdZXF6q87rHq8f8/qENwU/PebtU/z/9ITaG7ze5Q3o0+KNqeUb40TvetD0 gof5OrmnpNXmOvZUW74R+RaZ5wOeEjCBpil4jejIIwnYdu4KtyqFO7eJ0tzJ BI7Np3CUjuO3EttG1DiWbVjVv4oBdJXIJTEfkIQSUTgfsM6gmCQCcGIJUTA6 CxP4sGZGu5Vnoq0n1DZUThPdKktZZS56uTmrkbRbwHPfFmJjNUJmW+0KE2Qp z9Mmk7LmfLEKEh9DJIBQRQubyUX36GsMm3i6h1oL+/xstvH3mtnFOEea7bRi dZvAkjwRpfsRdgvO1Vd8+GW51CwruD/1WMsG5vN2pYlILDaymUcdWKC8Ppza rO0YSR1MsFILkx5zPXiqRBS0sTL6OlQkZemdH181GgY5dBIZ3immA9MobCsN eJ75Thht7/GfMGX38jBz6W0GP5cJLBmRJdueYs/wwH4NinCuPXAdoxmF+QzE GwEz+cYSx1KnH58CkclHfvUEQX0UdzX2B0jso/Ka0zpaYlO9Y0yEPj50peX/ LxCzP0jIsuR+IoNAbZ9TFLz6cuyyHGemCUcxie6yDD/FsegmoMDlTtxM1n4b sDT39VxfNIwSezL7BJbdRRN7/FAkyw/k0JRG6alAPiiOpVjYWdeaSXuAUmIm eyotWNjy8k4LXFd9wIoh3hYihNgWDOfGZCIXUoSomJ5lWJb6KENjIg3c/jIp f5mUv0zKXyblL5PyP8WkPFhgVBKH+dMHwrAHJ/MVKwZlfCsos4kIXckEAq7l smOisjRhgBVDQQCDtOIgYNp0sFrIIWZayRSv50R7t+MDgV5aaLo3PZnyU3He Qu1AvnrAqIK0QIuGep5vdHdxFopoK73euc4YFk2KOUvO6Y+HtIeuv00ZDEch 5RAhNF4oXjiGLmoZGvxXuPkn+QZPKCFBy4HWM+cr0DT7uG6rTrXMfSgUtex1 IDjf70I8WDq65VDQXRlTZ/bk8Ye50qCnmPM/yzP4nfrnudoHcPzEmh7repRr ISrMKmGmL9dBv1cDPV3//D/wc/YWIz/T69mi16M+UMqduYE5lQGkfsxLKi2X 5l/uJbFHkfzFXtJe6Sn1l6hSbxsrpa7bE5BIxzjm2l9JaVExcS6CtdgovZGd 5D3QA68mYXOG+bVQTEmjjFD47iLfM0xmrEMoZ1Hi60pUvOOjI/KVRqM/BXld S3EbSqXQxZ1GqzCNxwprVU3xT6oHjSWyZUh48kFFQnpdhsypqxdxY3jDkm7E FSfVhz/JPFcEHcsFcPlDx7gl5zqphfnDxXkZ+1GsBdjUM28X8JYyo0ZNlDDY l1ws8yoAhbpqYmBTTBJutoYLF09a7FLWgDNAezozYVslReT5WO/tAv5ie8ab FZK7qd+/jXJdGKOe5dzs0StFOX0W9p5QY7ODuv14YI/igfNrKv2xPXa5Sp+p 62KYJCIVsK+4Dv3Z1XTqu1bfG7HOX2HJjBsj45ZdCEG67lSA26qrNNVTAqDx jHLUSSJ7mya9SkM2eCMTvOI7kY7nK8IMGlwNF6UksI6UbV2xKaaRhtbP1/pL H3jaxfbkuW6xPA/LH5/iyaiqxkKh4AxoTvtE2tdYP1rAigtfn3CKfdkYnXCh ux2AatxxEClkSMO2WRV2zvfKGGPfKg9a60fW5A+tScWZGAYxfUmiaEiKxt3d Nj57vDaWeW10OllOvximiRbBJq3k/v1UBATqGhMSHuGBp4nzLpVceZGjF2Th Cqtm7Kqw/cr1zeXbQ+TfDJLCYTwBoW+0WCQHfpKgnxmzMMLTbDKzVMKQvzW2 AZWFRi0BzxQUhxTK15WFsVzS5T8tpLg+k+GdH0ehiWYFHXpjD41qzaOp/6Wk iN251R8aLHxTCyy9hpCRAQGXEegnW/ZQBXwnaXnvJEYzCsbSlVtzredRoJWN WgrXlGUygxjDGYBVKljWCOUaoYpqPXzURAAMjKOSHvxxgM+fYdCUetiKWzZb +Z4g/9mUVSTR0nfJablGHefu+izGdphrQqBMwHAkOacgE9/UjcC0UFqLoqos NZfZKF1oSiodWUyYkaswk5QolA64R7p2Wfc34pGp9mLAC7s/35JCgI5Ka2k8 EFtMgszucfopAyCBJjHwC3KbjbTJiCV04UCaO1DprUe67SUV3bwCVl5EsB6M 9Xy8gozy8EYHTQq5RChAJGFhCzM8K40vYGEfrolOV0tLmx1SYd0FbDiaJjpW 8IxxwHLXfFAIy+glkPtyAgBA6luYdwLM+IousS1wPqCLigKwdUnu3hmv6NuP eAwldDIBxFYhSx9i5s9EBIKjj0gqDt7uomC1kHrKtaA7lEAE5F5A2kVmDLEi PZEzLBwi39J2Ti/96UGwFZgRnQbQhhtFm0/7WGKl7AJL/IDX8HJXx9DvAmct v7+MA7MbdkCVDTCGi4ZV3gF2keLsbhWgfAJLIaK3NwT7Rklb4CWgRenOTGIH dmfnsG5gxgSluxgjlQAv4NAroPZamGMG3Jn00ZlOiUQ6bS4ARRMJcGeb07Va yDLRajZP8qxivXfJ0jos8jPg0QukEdRygpigRSxhLkEXIgEqL5I6SrRHIkVb uV0fTDkFJeM7HV6S3qb7Bxi2wUi8obBLJAApMLjb8OUqpisSWASONKNwQZjK TUYmHvjzDpkcLCFBi7etcpnLAH9zg6zoCz7sXfa2hI3fv/CB5z4zZiTdVGJe gPEIpFWE9/d4OQfUwidHqLBBGplvlbPh5IwKmP6xAmmXhdsXYYkPWLkanh+m 6cQFLcjy38evz+uH9iLZObmgaWrgACIsGOIA3bF60qHyZJ0mwx86aB0YywNr bC2BKYlV4FHYB46Ldk3MPg9GF8Ms6qV7Arq2z6Ajy7AdAIvOALUQGFQatWbt tF2v6YrZWqMG/x3X6ofoeSLGqcQ1Xeq56R6ROx7X7rctlt6lgjlx2Idra3xY OcStWquBgXkO2PQWXx757KAc/oNH0ZiGZepx/LUOyUz03NswWgfSm5EHSMkH Ed6iOLEL/1byK9B5a5CReZX1RRzwHwB68Dz03aXvIskv4EEGaLb8GA9u5XSF t27vfMwJhF7uMOgOtdSCljG/tzDB2/DsRVEo7l8UpcHkQwp9Jis/yF8qzlcs g3SAntR3BXU8ZWuXCR77rrOFWTHyN/2r8wEfjXs349G3ZCR3OF8vjgLQBpG3 5d5fUOid1nkDpbNCby1zlbp92id9bSO6gJnzwZvh5RBrmEd8eHH9Ydgfjvm4 93ZEJc2vB2+Hl4wNfry+gk3x3ocPX4PMXNBb+fHDPQSdZSXVWbky/hjRzdVF bnD26zAO/uAYB7oC2n82WP877TPFVSo0nhPFM7AZv9JILHD3YO+IhVD/6lZW SG8d+ErnMKv4Vfi2vPU/VU5ymDMjDP5EGYz1ZqVzCsjjgAtgQviXb+E42xt+ 31dE/PAdgC2mILieegNgT+0/+7OL5f9Plcob0qJmLFzR1wrzYYqPLgD/MELl 19bUdcUSxbKApqpGISCw5OPWFEYaALLLyBgMeH7arjRzs8HlOTPaCh5BV5nq 7rI7YumFxcEngVG+TS5bDZv91EqyjniCYcQd2LYoliq16w/dPdPFAmU9yLTh z3Y0mqf40yJm4dwSOp+d5nSwTmDPeShnuYnsAfOQ7k25J/WmPPHqoivrx+1J vTsRnU6z3ZlOTlotd9rS50G54WWLnLHMN3jVROtI9rLWqDfAarfhCXg5S3m9 gmmu0ze8yyakcsII3PhX9U8d96Rb75xORHPabrXbJ8etrtfsyqbpNux/H0jK C4IpxEDiawwo8/es8Lbmm97HD2P0PxpNVPIPXt5EAFr1xqR+XO8eQ0DfPq03 jjv1Vr1db9SPW/W6hCd3L1hMX0BrNprt6XTS7E6F25b16WTinngd7/Sk3W1O pohIe+H/UWr3X/f/GGrDRL+H2viDMV9E7WaB2jjd8Hug7HGnMT1pNqdTr9No up3mVNZPmrJTP/FOmpPWyclTKeWVUqpZbwO5Hl1CU6vrejACOzRkowvR3OlJ sztpdSZTeJ506hpr/w0IVwbcIFQAAA==[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. --> </rfc>