rfc9709.original.xml   rfc9709.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 2.6. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
10) --> -ietf-lamps-cms-cek-hkdf-sha256-05" number="9709" updates="" obsoletes="" catego
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ry="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true
-ietf-lamps-cms-cek-hkdf-sha256-05" category="std" consensus="true" submissionTy " symRefs="true" version="3" xml:lang="en">
pe="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.23.1 -->
<front> <front>
<title abbrev="Encryption Key Derivation in CMS">Encryption Key Derivation i n the Cryptographic Message Syntax (CMS) using HKDF with SHA-256</title> <title abbrev="Encryption Key Derivation in CMS">Encryption Key Derivation i n the Cryptographic Message Syntax (CMS) using HKDF with SHA-256</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-cek-hkdf-sha25 6-05"/> <seriesInfo name="RFC" value="9709"/>
<author initials="R." surname="Housley" fullname="Russ Housley"> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<city>Herndon, VA</city> <city>Herndon</city>
<country>US</country> <region>VA</region>
<country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2024" month="September" day="19"/> <date year="2025" month="January"/>
<area>Security</area> <area>SEC</area>
<keyword>Internet-Draft</keyword> <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> <abstract>
<?line 83?>
<t>This document specifies the derivation of the content-encryption key or the <t>This document specifies the derivation of the content-encryption key or the
content-authenticated-encryption key in the Cryptographic Message Syntax (CMS) content-authenticated-encryption key in the Cryptographic Message Syntax (CMS)
using HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-256. using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) with SHA-
The use of this mechanism provides protection against where the attacker manipul 256.
ates the The use of this mechanism provides protection against an attacker that manipulat
es the
content-encryption algorithm identifier or the content-authenticated-encryption content-encryption algorithm identifier or the content-authenticated-encryption
algorithm identifier.</t> algorithm identifier.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 92?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies the derivation of the content-encryption key fo r the <t>This document specifies the derivation of the content-encryption key fo r the
Cryptographic Message Syntax (CMS) enveloped-data content type <xref target="RFC 5652"/>, the Cryptographic Message Syntax (CMS) enveloped-data content type <xref target="RFC 5652"/>, the
content-encryption key for the CMS encrypted-data content type <xref target="RFC 5652"/>, or the content-encryption key for the CMS encrypted-data content type <xref target="RFC 5652"/>, or the
content-authenticated-encryption key for the authenticated-enveloped-data content-authenticated-encryption key for the authenticated-enveloped-data
content type <xref target="RFC5083"/>.</t> content type <xref target="RFC5083"/>.</t>
<t>The use of this mechanism provides protection against where the attacke r manipulates the <t>The use of this mechanism provides protection against an attacker that manipulates the
content-encryption algorithm identifier or the content-authenticated-encryption content-encryption algorithm identifier or the content-authenticated-encryption
algorithm identifier. Johannes Roth and Falko Strenzke presented such an attack algorithm identifier. Johannes Roth and Falko Strenzke presented such an attack
at IETF 118 <xref target="RS2023"/>, where:</t> at IETF 118 <xref target="RS2023"/>, where:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The attacker intercepts a CMS Authenticated-Enveloped-Data content <xref target="RFC5083"/> <t>The attacker intercepts a CMS authenticated-enveloped-data content <xref target="RFC5083"/>
that uses either AES-CCM or AES-GCM <xref target="RFC5084"/>.</t> that uses either AES-CCM or AES-GCM <xref target="RFC5084"/>.</t>
</li> </li>
<li> <li>
<t>The attacker turns the intercepted content into a "garbage" CMS Env <t>The attacker turns the intercepted content into a "garbage" CMS env
eloped-Data eloped-data
content <xref section="6" sectionFormat="of" target="RFC5652"/> that is composed content (<xref section="6" sectionFormat="of" target="RFC5652"/>) that is compos
of AES-CBC guess blocks.</t> ed of AES-CBC guess blocks.</t>
</li> </li>
<li> <li>
<t>The attacker sends the "garbage" message to the victim, and the vic tim reveals <t>The attacker sends the "garbage" message to the victim, and the vict im reveals
the result of the decryption to the attacker.</t> the result of the decryption to the attacker.</t>
</li> </li>
<li> <li>
<t>If any of the transformed plaintext blocks match the guess for that block, then <t>If any of the transformed plaintext blocks match the guess for that block, then
the attacker learns the plaintext for that block.</t> the attacker learns the plaintext for that block.</t>
</li> </li>
</ol> </ol>
<t>With highly structured messages, one block can reveal the only sensitiv e part of <t>With highly structured messages, one block can reveal the only sensitiv e part of
the original message.</t> the original message.</t>
<t>This attack is thwarted if the encryption key depends upon the delivery of <t>This attack is thwarted if the encryption key depends upon the delivery of
the unmodified algorithm identifier.</t> the unmodified algorithm identifier.</t>
<t>The mitigation for this attack has three parts:</t> <t>The mitigation for this attack has three parts:</t>
<ul spacing="normal"> <ol spacing="normal" type="1">
<li> <li>Potential recipients include the id-alg-cek-hkdf-sha256 algorithm
<t>Potential recipients include the id-alg-cek-hkdf-sha256 algorithm i identifier (with no parameters) in S/MIME Capabilities to indicate
dentifier support for this mitigation.</li>
(with no parameters) in S/MIME Capabilities to indicate support for <li>As a flag to the recipient that this mitigation is being used,
this mitigation.</t> carry the id-alg-cek-hkdf-sha256 algorithm identifier as the
</li> contentEncryptionAlgorithm in the EncryptedContentInfo structure.
<li> This structure is used in the enveloped-data content type, the
<t>As a flag to the recipient that this mitigation is being used, carr encrypted-data content type, and the authenticated-enveloped-data
y the content type. The parameters field of the id-alg-cek-hkdf-sha256
id-alg-cek-hkdf-sha256 algorithm identifier as the contentEncryptionAlgorithm algorithm identifier identifies the content-encryption algorithm or
in the EncryptedContentInfo structure. This structure is used in the the content-authenticated-encryption algorithm and any associated
enveloped-data content type, the encrypted-data content type, and the parameters.
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 associated
parameters.</t>
</li>
<li>
<t>Perform encryption with a derived content-encryption key or
content-authenticated-encryption key:</t>
</li> </li>
</ul> <li><t>Perform encryption with a derived content-encryption key or
content-authenticated-encryption key:</t>
<artwork><![CDATA[ <artwork><![CDATA[
CEK' = HKDF(CEK, AlgorithmIdentifier) CEK' = HKDF(CEK, AlgorithmIdentifier)
]]></artwork> ]]></artwork>
</li>
</ol>
<section anchor="asn1"> <section anchor="asn1">
<name>ASN.1</name> <name>ASN.1</name>
<t>CMS values are generated using ASN.1 <xref target="X680"/>, using the Basic <t>CMS values are generated using ASN.1 <xref target="X680"/>, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules Encoding Rules (BER) and the Distinguished Encoding Rules
(DER) <xref target="X690"/>.</t> (DER) <xref target="X690"/>.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</section> </t>
</section>
<section anchor="cryptographic-algorithm-agility-considerations"> <section anchor="cryptographic-algorithm-agility-considerations">
<name>Cryptographic Algorithm Agility Considerations</name> <name>Cryptographic Algorithm Agility Considerations</name>
<t>There is no provision for key derivation functions other than HKDF, a nd <t>There is no provision for key derivation functions other than HKDF, a nd
there is no provision for hash functions other than SHA-256. If there is 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 ever a need to support another key derivation function or another hash
function, it will be very straightforward to assign a new object function, it will be very straightforward to assign a new object
identifier. At this point, keeping the design very simple seems most identifier. At this point, keeping the design very simple seems most
important.</t> important.</t>
</section> </section>
</section> </section>
<section anchor="cmskdf"> <section anchor="cmskdf">
<name>Use of of HKDF with SHA-256 to Derive Encryption Keys</name> <name>Use of HKDF 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 de
fined as "input keying material" under Inputs. Please let us know if this is in
correct.
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 <t>The mitigation uses the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) <xref target="RFC5869"/> to derive output keying material (OKM) from Function (HKDF) <xref target="RFC5869"/> to derive output keying material (OKM) from
input key material (IKM). HKDF is used with the SHA-256 hash function input keying material (IKM). HKDF is used with the SHA-256 hash function
<xref target="FIPS180"/>. The derivation includes the DER-encoded AlgorithmIden tifier as <xref target="FIPS180"/>. The derivation includes the DER-encoded AlgorithmIden tifier as
the optional info input value. The encoded value includes the ASN.1 tag the optional info input value. The encoded value includes the ASN.1 tag
for SEQUENCE (0x30), the length, and the value. This AlgoritmIdentifier is for SEQUENCE (0x30), the length, and the value. This AlgorithmIdentifier is
carried as the parameter to the id-alg-cek-hkdf-sha256 algorithm identifier. If carried as the parameter to the id-alg-cek-hkdf-sha256 algorithm identifier. If
an attacker were to change the originator-provided AlgoritmIdentifier, then the an attacker were to change the originator-provided AlgorithmIdentifier, then the
recipient will derive a different content-encryption key or recipient will derive a different content-encryption key or
content-authenticated-encryption key.</t> content-authenticated-encryption key.</t>
<t>The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF-Expand functions <t>The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF-Expand functions
to derive the OKM from the IKM:</t> 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[ <artwork><![CDATA[
Inputs: Inputs:
IKM input keying material IKM input keying material
info DER-encoded AlgoritmIdentifier info DER-encoded AlgoritmIdentifier
Output: Output:
OKM output keying material (same size as IKM) OKM output keying material (same size as IKM)
The output OKM is calculated as follows: The output OKM is calculated as follows:
OKM_SIZE = len(IKM) /* length in octets */ OKM_SIZE = len(IKM) /* length in octets */
IF OKM_SIZE > 8160 THEN raise error IF OKM_SIZE > 8160 THEN raise error
salt = "The Cryptographic Message Syntax" salt = "The Cryptographic Message Syntax"
PRK = HKDF-Extract(salt, IKM) PRK = HKDF-Extract(salt, IKM)
OKM = HKDF-Expand(PRK, info, OKM_SIZE) OKM = HKDF-Expand(PRK, info, OKM_SIZE)
]]></artwork> ]]></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>
<section anchor="alg-def"> <section anchor="alg-def">
<name>The id-alg-cek-hkdf-sha256 Algorithm Identifier</name> <name>The id-alg-cek-hkdf-sha256 Algorithm Identifier</name>
<t>The id-alg-cek-hkdf-sha256 algoritm identifier indicates that the CMS_C EK_HKDF_SHA256 <t>The id-alg-cek-hkdf-sha256 algorithm identifier indicates that the CMS_ CEK_HKDF_SHA256
function defined in <xref target="cmskdf"/> is used to derive the content-encryp tion key or the function defined in <xref target="cmskdf"/> is used to derive the content-encryp tion key or the
content-authenticated-encryption key.</t> content-authenticated-encryption key.</t>
<t>The following object identifier identifies the id-alg-cek-hkdf-sha256 <t>The following object identifier identifies the id-alg-cek-hkdf-sha256
algorithm:</t> algorithm:</t>
<sourcecode type="asn.1"><![CDATA[ <sourcecode type="asn.1"><![CDATA[
id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 31 } smime(16) alg(3) 31 }
]]></sourcecode> ]]></sourcecode>
<t>The id-alg-cek-hkdf-sha256 parameters field has an ASN.1 type of Algori thmIdentifier.</t> <t>The id-alg-cek-hkdf-sha256 parameters field has an ASN.1 type of Algori thmIdentifier.</t>
skipping to change at line 186 skipping to change at line 232
AlgorithmIdentifier{CONTENT-ENCRYPTION, { ... } } AlgorithmIdentifier{CONTENT-ENCRYPTION, { ... } }
cea-CEKHKDFSHA256 CONTENT-ENCRYPTION ::= { cea-CEKHKDFSHA256 CONTENT-ENCRYPTION ::= {
IDENTIFIER id-alg-cek-hkdf-sha256 IDENTIFIER id-alg-cek-hkdf-sha256
PARAMS TYPE ContentEncryptionAlgorithmIdentifier ARE required PARAMS TYPE ContentEncryptionAlgorithmIdentifier ARE required
SMIME-CAPS { IDENTIFIED BY id-alg-cek-hkdf-sha256 } } SMIME-CAPS { IDENTIFIED BY id-alg-cek-hkdf-sha256 } }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="smimecapabilities-attribute-conventions"> <section anchor="smimecapabilities-attribute-conventions">
<name>SMIMECapabilities Attribute Conventions</name> <name>SMIMECapabilities Attribute Conventions</name>
<t>The SMIMECapabilities Attribute is defined in <xref section="2.5.2" sec tionFormat="of" target="RFC8551"/>. An <t>The SMIMECapabilities attribute is defined in <xref section="2.5.2" sec tionFormat="of" target="RFC8551"/>. An
S/MIME client announces the set of cryptographic functions it supports using the S/MIME client announces the set of cryptographic functions it supports using the
SMIMECapabilities attribute.</t> SMIMECapabilities attribute.</t>
<t>If an S/MIME client supports the mechanism in this document, the <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 th e set of id-alg-cek-hkdf-sha256 object identifier <bcp14>SHOULD</bcp14> be included in th e set of
cryptographic functions. The parameter with this encoding <bcp14>MUST</bcp14> b e absent.</t> cryptographic functions. The parameter with this encoding <bcp14>MUST</bcp14> b e absent.</t>
<t>The encoding for id-alg-cek-hkdf-sha256, in hexadecimal, is:</t> <t>The encoding for id-alg-cek-hkdf-sha256, in hexadecimal, is:</t>
<artwork><![CDATA[ <artwork><![CDATA[
30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 1f 30 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 03 1f
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="use-of-hkdf-with-sha-256-with-cms"> <section anchor="use-of-hkdf-with-sha-256-with-cms">
<name>Use of HKDF with SHA-256 with CMS</name> <name>Use of HKDF with SHA-256 with CMS</name>
<t>This section describes the originator and recipient processing to imple ment <t>This section describes the originator and recipient processing to imple ment
this mitigation for each of the CMS encrypting content types.</t> this mitigation for each of the CMS encrypting content types.</t>
<section anchor="enveloped-data-content-type"> <section anchor="enveloped-data-content-type">
<name>Enveloped-Data Content Type</name> <name>Enveloped-Data Content Type</name>
<t>The fourth step of constructing an Enveloped-data is repeated below <!-- [rfced] Note that we lowercased the following throughout. Please let us kno
w 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 an enveloped-data content type is rep
eated below
from <xref section="6" sectionFormat="of" target="RFC5652"/>:</t> from <xref section="6" sectionFormat="of" target="RFC5652"/>:</t>
<artwork><![CDATA[
4. The content is encrypted with the content-encryption key. <!-- [rfced] Because the text is quoted from RFC 5652, we marked it as a blockqu
ote and updated it to match RFC 5652 exactly. Note that the HTML and PDF are lin
ked 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].
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 Content encryption may require that the content be padded to a
multiple of some block size; see Section 6.3 of [RFC5652]. multiple of some block size; see Section <xref target="RFC5652" sectionForma
t="bare" section="6.3"/>.</li>
</ol>
</blockquote>
]]></artwork>
<t>To implement this mitigation, the originator expands this step as fol lows:</t> <t>To implement this mitigation, the originator expands this step as fol lows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the
<t>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo EncryptedContentInfo structure, and set the
structure, and set the contentEncryptionAlgorithm.parameters field to the contentEncryptionAlgorithm.parameters field to the
AlgorithmIdentifier for the content-encryption algorithm that will be used AlgorithmIdentifier for the content-encryption algorithm that will
to encrypt the content, including both the algorithm and optional parameters.</t be used to encrypt the content, including both the algorithm and
> optional parameters.</li>
</li> <li><t>Derive the new content-encryption key (CEK') from the original
<li> content-encryption key (CEK) and the
<t>Derive the new content-encryption key (CEK') from the original ContentEncryptionAlgorithmIdentifier, which is carried in the
content-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm.parameters field:</t>
which is carried in the contentEncryptionAlgorithm.parameters field:</t>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier) CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier)
]]></artwork> ]]></artwork>
<ul spacing="normal"> </li>
<li> <li>The content is encrypted with the new content-encryption key
<t>The content is encrypted with the new content-encryption key (CEK (CEK'). Content encryption may require that the content be padded
'). to a multiple of some block size; see <xref section="6.3"
Content encryption may require that the content be padded to a sectionFormat="of" target="RFC5652"/>.</li>
multiple of some block size; see <xref section="6.3" sectionFormat="of" target="
RFC5652"/>.</t>
</li>
</ul> </ul>
<t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in th e <t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in th e
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo
structure tells the recipient to derive the new content-encryption structure tells the recipient to derive the new content-encryption
key (CEK') as shown above, and then use it for decryption of the key (CEK') as shown above, and then use it for decryption of the
EncryptedContent. If the id-alg-cek-hkdf-sha256 algorithm identifier EncryptedContent. If the id-alg-cek-hkdf-sha256 algorithm identifier
is not present in the contentEncryptionAlgorithm.algorithm field of is not present in the contentEncryptionAlgorithm.algorithm field of
the EncryptedContentInfo structure, then the recipient uses the original the EncryptedContentInfo structure, then the recipient uses the original
content-encryption key (CEK) for decryption of the EncryptedContent.</t> content-encryption key (CEK) for decryption of the EncryptedContent.</t>
</section> </section>
<section anchor="encrypted-data-content-type"> <section anchor="encrypted-data-content-type">
<name>Encrypted-Data Content Type</name> <name>Encrypted-Data Content Type</name>
<t>As specified in <xref section="8" sectionFormat="of" target="RFC5652" />, the content-encryption key <t>As specified in <xref section="8" sectionFormat="of" target="RFC5652" />, the content-encryption key
is managed by other means.</t> is managed by other means.</t>
<t>To implement this mitigation, the originator performs the following:< /t> <t>To implement this mitigation, the originator performs the following:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Include the id-alg-cek-hkdf-sha256 algorithm identifier in
<t>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the the contentEncryptionAlgorithm.algorithm field of the
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo EncryptedContentInfo structure, and set the
structure, and set the contentEncryptionAlgorithm.parameters field to the contentEncryptionAlgorithm.parameters field to the
AlgorithmIdentifier for the content-encryption algorithm that will be used AlgorithmIdentifier for the content-encryption algorithm that will
to encrypt the content, including both the algorithm and optional parameters.</t be used to encrypt the content, including both the algorithm and
> optional parameters.</li>
</li> <li><t>Derive the new content-encryption key (CEK') from the
<li> original content-encryption key (CEK) and the
<t>Derive the new content-encryption key (CEK') from the original ContentEncryptionAlgorithmIdentifier, which is carried in the
content-encryption key (CEK) and the ContentEncryptionAlgorithmIdentifier, contentEncryptionAlgorithm.parameters field:</t>
which is carried in the contentEncryptionAlgorithm.parameters field:</t>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier) CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier)
]]></artwork> ]]></artwork>
<ul spacing="normal"> </li>
<li> <li>The content is encrypted with the new content-encryption key
<t>The content is encrypted with the new content-encryption key (CEK (CEK'). Content encryption may require that the content be padded
'). to a multiple of some block size; see <xref section="6.3"
Content encryption may require that the content be padded to a sectionFormat="of" target="RFC5652"/>.</li>
multiple of some block size; see <xref section="6.3" sectionFormat="of" target="
RFC5652"/>.</t>
</li>
</ul> </ul>
<t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in th e <t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in th e
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo
structure tells the recipient to derive the new content-encryption structure tells the recipient to derive the new content-encryption
key (CEK') as shown above, and then use it for decryption of the key (CEK') as shown above, and then use it for decryption of the
EncryptedContent. If the id-alg-cek-hkdf-sha256 algorithm identifier EncryptedContent. If the id-alg-cek-hkdf-sha256 algorithm identifier
is not present in the contentEncryptionAlgorithm.algorithm field of is not present in the contentEncryptionAlgorithm.algorithm field of
the EncryptedContentInfo structure, then the recipient uses the original the EncryptedContentInfo structure, then the recipient uses the original
content-encryption key (CEK) for decryption of the EncryptedContent.</t> content-encryption key (CEK) for decryption of the EncryptedContent.</t>
</section> </section>
<section anchor="authenticated-enveloped-data-content-type"> <section anchor="authenticated-enveloped-data-content-type">
<name>Authenticated-Enveloped-Data Content Type</name> <name>Authenticated-Enveloped-Data Content Type</name>
<t>The fifth step of constructing an Authenticated-Enveloped-Data is <t>The fifth step of constructing an authenticated-enveloped-data conten t type is
repeated below from <xref section="2" sectionFormat="of" target="RFC5083"/>:</t> repeated below from <xref section="2" sectionFormat="of" target="RFC5083"/>:</t>
<artwork><![CDATA[
5. The attributes collected in step 4 are authenticated and the CMS <!-- [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" current
ly 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 3
852. Please review and let us know if you have concerns or have an alternate su
ggestion.
In addition, would you like to include a note to highlight that RFC 3852 has bee
n 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].
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- content is authenticated and encrypted with the content-
authenticated-encryption key. If the authenticated encryption authenticated-encryption key. If the authenticated encryption
algorithm requires either the additional authenticated data (AAD) algorithm requires either the additional authenticated data (AAD)
or the content to be padded to a multiple of some block size, 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 then the padding is added as described in Section <xref target="RFC3852" sec
[RFC5652]. tionFormat="bare" section="6.3"/> of [CMS].</li></ol></blockquote>
<aside><t>Note that [CMS] refers to <xref target="RFC3852"/>, which has been obs
oleted by <xref target="RFC5652"/>, but the text in Section 6.3 was unchanged in
RFC 5652.</t></aside>
]]></artwork>
<t>To implement this mitigation, the originator expands this step as fol lows:</t> <t>To implement this mitigation, the originator expands this step as fol lows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the
<t>Include the id-alg-cek-hkdf-sha256 algorithm identifier in the contentEncryptionAlgorithm.algorithm field of the
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo EncryptedContentInfo structure, and set the
structure, and set the contentEncryptionAlgorithm.parameters field to the contentEncryptionAlgorithm.parameters field to the
AlgorithmIdentifier for the content-authenticated-encryption algorithm that AlgorithmIdentifier for the content-authenticated-encryption
will be used for authenticated encryption of the content, including both the algorithm that will be used for authenticated encryption of the
algorithm and optional parameters.</t> content, including both the algorithm and optional parameters.</li>
</li> <li><t>Derive the new content-authenticated-encryption key (CEK')
<li> from the original content-authenticated-encryption key (CEK) and the
<t>Derive the new content-authenticated-encryption key (CEK') from t ContentEncryptionAlgorithmIdentifier:</t>
he
original content-authenticated-encryption key (CEK) and the
ContentEncryptionAlgorithmIdentifier:</t>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier) CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier)
]]></artwork> ]]></artwork>
<ul spacing="normal"> </li>
<li> <li>The attributes collected in step 4 are authenticated and the CMS
<t>The attributes collected in step 4 are authenticated and the CMS content is authenticated and encrypted with the new
content is authenticated and encrypted with the new content-authenticated-encryption key (CEK'). If the authenticated
content-authenticated-encryption key (CEK'). If the authenticated encryption algorithm requires either the additional authenticated
encryption algorithm requires either the additional authenticated data (AAD) data (AAD) or the content to be padded to a multiple of some block
or the content to be padded to a multiple of some block size, size, then the padding is added as described in <xref section="6.3"
then the padding is added as described in <xref section="6.3" sectionFormat="of" sectionFormat="of" target="RFC5652"/>.</li>
target="RFC5652"/>.</t>
</li>
</ul> </ul>
<t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in th e <t>The presence of the id-alg-cek-hkdf-sha256 algorithm identifier in th e
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo
structure tells the recipient to derive the new content-authenticated-encryption 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 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-sha2 56 EncryptedContent and the authentication of the AAD. If the id-alg-cek-hkdf-sha2 56
algorithm identifier is not present in the contentEncryptionAlgorithm.algorithm algorithm identifier is not present in the contentEncryptionAlgorithm.algorithm
field of the EncryptedContentInfo structure, then the recipient uses the origina l field of the EncryptedContentInfo structure, then the recipient uses the origina l
content-authenticated-encryption (CEK) for decryption and authentication of content-authenticated-encryption (CEK) for decryption and authentication of
the EncryptedContent and the authentication of the AAD.</t> the EncryptedContent and the authentication of the AAD.</t>
skipping to change at line 346 skipping to change at line 435
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This mitigation always uses HKDF with SHA-256. One KDF algorithm was <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 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 is found in the KDF algorithm, a new attribute will need to be assigned for
use with an alternative KDF algorithm.</t> use with an alternative KDF algorithm.</t>
<t>If the attacker removes the id-alg-cek-hkdf-sha256 object identifier fr om the <t>If the attacker removes the id-alg-cek-hkdf-sha256 object identifier fr om the
contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo contentEncryptionAlgorithm.algorithm field of the EncryptedContentInfo
structure prior to delivery to the recipient, then the recipient will not structure prior to delivery to the recipient, then the recipient will not
attempt to derive CEK', which will deny the recipient access to the content, attempt to derive CEK', which will deny the recipient access to the content
but will not assist the attacker in recovering the plaintext content.</t> but will not assist the attacker in recovering the plaintext content.</t>
<t>If the attacker changes contentEncryptionAlgorithm.parameters field of the <t>If the attacker changes contentEncryptionAlgorithm.parameters field of the
EncryptedContentInfo structure prior to delivery to the recipient, then the EncryptedContentInfo structure prior to delivery to the recipient, then the
recipient will derive a different CEK', which will not assist the attacker in recipient will derive a different CEK', which will not assist the attacker in
recovering the plaintext content. Providing the object identifier as an input t o recovering the plaintext content. Providing the object identifier as an input t o
the key derivation function is sufficient to mitigate the attack described the key derivation function is sufficient to mitigate the attack described
in <xref target="RS2023"/>, but this mitigation includes both the object identif ier and the in <xref target="RS2023"/>, but this mitigation includes both the object identif ier and the
parameters to protect against some yet-to-be-discovered attack that only parameters to protect against some yet-to-be-discovered attack that only
manipulates the parameters.</t> manipulates the parameters.</t>
<t>Implementations <bcp14>MUST</bcp14> protect the content-encryption keys and <t>Implementations <bcp14>MUST</bcp14> protect the content-encryption keys and
content-authenticated-encryption keys, this includes the CEK and CEK'. content-authenticated-encryption keys, including the CEK and CEK'.
Compromise of a content-encryption key may result in disclosure of the Compromise of a content-encryption key may result in disclosure of the
associated encrypted content. Compromise of a content-authenticated-encryption associated encrypted content. Compromise of a content-authenticated-encryption
key may result in disclosure of the associated encrypted content or allow key may result in disclosure of the associated encrypted content or allow
modification of the authenticated content and the additional authenticated modification of the authenticated content and the AAD.</t>
data (AAD).</t>
<t>Implementations <bcp14>MUST</bcp14> randomly generate content-encryptio n keys and <t>Implementations <bcp14>MUST</bcp14> randomly generate content-encryptio n keys and
content-authenticated-encryption keys. Using an inadequate pseudo-random content-authenticated-encryption keys. Using an inadequate pseudorandom
number generator (PRNG) to generate cryptographic keys can result in little or 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 no security. An attacker may find it much easier to reproduce the PRNG
environment that produced the keys, and then searching the resulting small set environment that produced the keys and then search the resulting small set
of possibilities, rather than brute force searching the whole key space. The of possibilities, rather than brute-force searching the whole key space. The
generation of quality random numbers is difficult. <xref target="RFC4086"/> off ers important generation of quality random numbers is difficult. <xref target="RFC4086"/> off ers important
guidance on this topic.</t> guidance on this topic.</t>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>If the message-digest attribute is included in the AuthAttributes, <t>If the message-digest attribute is included in the AuthAttributes,
then the attribute value will contain the unencrypted one-way hash then the attribute value will contain the unencrypted one-way hash
value of the plaintext of the content. Disclosure of this hash value value of the plaintext of the content. Disclosure of this hash value
enables content tracking, and it can be used to determine if the enables content tracking, and it can be used to determine if the
content matches one or more candidates. For these reasons, content matches one or more candidates. For these reasons,
the AuthAttributes <bcp14>SHOULD NOT</bcp14> contain the message-digest attribut e.</t> the AuthAttributes <bcp14>SHOULD NOT</bcp14> contain the message-digest attribut e.</t>
</section> </section>
<section anchor="operations-considerations"> <section anchor="operations-considerations">
<name>Operations Considerations</name> <name>Operations Considerations</name>
<!-- [rfced] "message content plaintext" reads awkwardly to us. Would "plaintex
t 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, <t>CMS is often used to provide encryption in messaging environments,
where various forms of unsolicited messages (such as spam and phishing) where various forms of unsolicited messages (such as spam and phishing)
represent a significant volume of unwanted traffic. Mitigation strategies for represent a significant volume of unwanted traffic. Mitigation strategies for
unwanted message traffic involve analysis of message content plaintext. When unwanted message traffic involve analysis of message content plaintext. When
recipients accept unsolicited encrypted messages, they become even more recipients accept unsolicited encrypted messages, they become even more
vulnerable to unwanted traffic since many mitigation strategies will be vulnerable to unwanted traffic since many mitigation strategies will be
unable to access the message content plaintext. Therefore, software that unable to access the message content plaintext. Therefore, software that
receives messages that have been encrypted using CMS ought to provide alternate receives messages that have been encrypted using CMS ought to provide alternate
mechanisms to handle the unwanted message traffic. One approach that mechanisms to handle the unwanted message traffic. One approach that
does not require disclosure of keying material to a server is to reject 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 or discard encrypted messages unless they purport to come from a member
of a previously approved originator list.</t> of a previously approved originator list.</t>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>For the ASN.1 Module in the <xref target="appendix-asn1"/> of this docu <t>For the ASN.1 module in <xref target="appendix-asn1"/> of this document
ment, IANA , IANA has assigned the following object identifier (OID) in the "SMI Security f
is requested to assign an object identifier (OID) for the module or S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry: </t>
identifier (TBD0) with a Description of "id-mod-CMS-CEK-HKDF-SHA256-2023". The
OID for the module should be allocated in the "SMI Security for S/MIME Module Id <table anchor="tab1">
entifier" <name></name>
registry (1.2.840.113549.1.9.16.0).</t> <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 s pecified <t>IANA has allocated the id-alg-cek-hkdf-sha256 algorithm identifier as s pecified
in <xref target="alg-def"/> of this document. The object identifier (OID) value in <xref target="alg-def"/> in the "SMI Security for S/MIME Algorithms (1.2.840.
of 113549.1.9.16.3)" registry as follows: </t>
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/MIME Algorithms" <table anchor="tab2">
registry (1.2.840.113549.1.9.16.3).</t> <name></name>
</section> <thead>
<section anchor="acknowledgements"> <tr>
<name>Acknowledgements</name> <th>Decimal</th>
<t>Thanks to <th>Description</th>
Mike Ounsworth, <th>References</th>
Carl Wallace, and </tr>
Joe Mandel </thead>
their careful review and constructive comments.</t> <tbody>
<tr>
<td>31</td>
<td>id-alg-cek-hkdf-sha256</td>
<td>RFC 9709</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC5083">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
<title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Da 83.xml"/>
ta Content Type</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
<author fullname="R. Housley" initials="R." surname="Housley"/> 52.xml"/>
<date month="November" year="2007"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<abstract> 69.xml"/>
<t>This document describes an additional content type for the Cryp <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
tographic Message Syntax (CMS). The authenticated-enveloped-data content type is 51.xml"/>
intended for use with authenticated encryption modes. All of the various key ma
nagement techniques that are supported in the CMS enveloped-data content type ar <!-- [FIPS180] -->
e also supported by the CMS authenticated-enveloped-data content type. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5083"/>
<seriesInfo name="DOI" value="10.17487/RFC5083"/>
</reference>
<reference anchor="RFC5652">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS).
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
ry message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="RFC5869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
/title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2010"/>
<abstract>
<t>This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
g block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is co
nservative in its use of cryptographic hash functions. This document is not an I
nternet Standards Track specification; it is published for informational purpose
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="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 Extensi
ons (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive s
ecure MIME data. Digital signatures provide authentication, message integrity, a
nd non-repudiation with proof of origin. Encryption provides data confidentialit
y. Compression can be used to reduce data size. This document obsoletes RFC 5751
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8551"/>
<seriesInfo name="DOI" value="10.17487/RFC8551"/>
</reference>
<reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.180-4.pdf"> <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.180-4.pdf">
<front> <front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization>National Institute of Standards and Technology (NIST )</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="180-4"/> <seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<!-- [X680] -->
<reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680"> <reference anchor="X680" target="https://www.itu.int/rec/T-REC-X.680">
<front> <front>
<title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title> <title>Information technology -- Abstract Syntax Notation One (ASN.1 ): Specification of basic notation</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ITU-T Recommendation" value="X.680"/>
<seriesInfo name="ISO/IEC" value="8824-1:2021"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
</reference> </reference>
<!-- [X690] -->
<reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690"> <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690">
<front> <front>
<title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1-2021"/> <seriesInfo name="ISO/IEC" value="8825-1-2021"/>
</reference> </reference>
<reference anchor="RFC2119">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 19.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 74.xml"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4086"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.38
<front> 52.xml"/>
<title>Randomness Requirements for Security</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 86.xml"/>
rd"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
<author fullname="J. Schiller" initials="J." surname="Schiller"/> 84.xml"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<date month="June" year="2005"/> 11.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<t>Security systems are built on strong cryptographic algorithms t 12.xml"/>
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s <!-- [RS2023] -->
imilar quantities. The use of pseudo-random processes to generate secret quantit <reference anchor="RS2023" target="https://datatracker.ietf.org/meeting/1
ies can result in pseudo-security. A sophisticated attacker may find it easier t 18/materials/slides-118-lamps-attack-against-aead-in-cms">
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e 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 u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re 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 Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s 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 Cry
ptographic 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 a
nd the AES-GCM authenticated encryption algorithms with the Cryptographic Messag
e 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 associa
ted 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 f
ormats; this is simply a change to the syntax. This document is not an Internet
Standards Track specification; it is published for informational purposes.</t>
</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.5
09 (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 fo
rmat, 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 c
hanges to any of the formats; this is simply a change to the syntax. This docume
nt is not an Internet Standards Track specification; it is published for informa
tional purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5912"/>
<seriesInfo name="DOI" value="10.17487/RFC5912"/>
</reference>
<reference anchor="RS2023" target="https://datatracker.ietf.org/meeting/
118/materials/slides-118-lamps-attack-against-aead-in-cms">
<front> <front>
<title>AEAD-to-CBC Downgrade Attacks on CMS</title> <title>AEAD-to-CBC Downgrade Attacks on CMS</title>
<author initials="J." surname="Roth" fullname="Johannes Roth"> <author initials="J." surname="Roth" fullname="Johannes Roth">
<organization>MTG AG</organization> <organization>MTG AG</organization>
</author> </author>
<author initials="F." surname="Strenzke" fullname="Falko Strenzke"> <author initials="F." surname="Strenzke" fullname="Falko Strenzke">
<organization>MTG AG</organization> <organization>MTG AG</organization>
</author> </author>
<date year="2023" month="November" day="08"/> <date year="2023" month="November" day="08"/>
</front> </front>
<refcontent>IETF 118 Proceedings</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<?line 485?> <?line 485?>
<section anchor="appendix-asn1"> <section anchor="appendix-asn1">
<name>ASN.1 Module</name> <name>ASN.1 Module</name>
<t>This ASN.1 Module builds upon the conventions established in <xref targ <!-- [rfced] We replaced TBD0 with value 80 in the ASN.1, but we note a disrepan
et="RFC5911"/> and <xref target="RFC5912"/>.</t> cy in the year:
<sourcecode type="asn.1"><![CDATA[
<CODE STARTS> 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. Sh
ould 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 comm
ent.)
-->
<t>This ASN.1 module builds upon the conventions established in <xref targ
et="RFC5911"/> and <xref target="RFC5912"/>.</t>
<sourcecode type="asn.1" markers="true"><![CDATA[
CMS-CEK-HKDF-SHA256-Module-2024 CMS-CEK-HKDF-SHA256-Module-2024
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { 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-smime(16) id-mod(0) id-mod-CMS-CEK-HKDF-SHA256-2024(80) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
AlgorithmIdentifier{}, CONTENT-ENCRYPTION, SMIME-CAPS AlgorithmIdentifier{}, CONTENT-ENCRYPTION, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [RFC5911] FROM AlgorithmInformation-2009 -- in RFC 5911
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } ; id-mod-algorithmInformation-02(58) } ;
-- --
-- CEK-HKDF-SHA256 Algorithm -- CEK-HKDF-SHA256 Algorithm
-- --
id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 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 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 31 }
skipping to change at line 652 skipping to change at line 708
-- --
-- S/MIIME Capability for CEK-HKDF-SHA256 Algorithm -- S/MIIME Capability for CEK-HKDF-SHA256 Algorithm
-- --
SMimeCaps SMIME-CAPS ::= { cap-CMSCEKHKDFSHA256, ... } SMimeCaps SMIME-CAPS ::= { cap-CMSCEKHKDFSHA256, ... }
cap-CMSCEKHKDFSHA256 SMIME-CAPS ::= cap-CMSCEKHKDFSHA256 SMIME-CAPS ::=
{ -- No value -- IDENTIFIED BY id-alg-cek-hkdf-sha256 } { -- No value -- IDENTIFIED BY id-alg-cek-hkdf-sha256 }
END END
<CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
<section anchor="cmscekhkdfsha256-function-examples"> <section anchor="cmscekhkdfsha256-function-examples">
<name>CMS_CEK_HKDF_SHA256 Function Examples</name> <name>CMS_CEK_HKDF_SHA256 Function Examples</name>
<t>This appendix provides two test vectores for the CMS_CEK_HKDF_SHA256 fu nction.</t> <t>This appendix provides two test vectors for the CMS_CEK_HKDF_SHA256 fun ction.</t>
<section anchor="cmscekhkdfsha256-with-aes-128-gcm"> <section anchor="cmscekhkdfsha256-with-aes-128-gcm">
<name>CMS_CEK_HKDF_SHA256 with AES-128-GCM</name> <name>CMS_CEK_HKDF_SHA256 with AES-128-GCM</name>
<t>This test vector uses includes an AlgorithmIdentifier for<br/> <t>This test vector includes an AlgorithmIdentifier for AES-128-GCM.</t>
AES-128-GCM.</t> <!-- [rfced] In B.1 and B.2, we have changed <artwork> to <sourcecode type="test
<artwork><![CDATA[ -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 IKM = c702e7d0a9e064b09ba55245fb733cf3
The AES-128-GCM AlgorithmIdentifier: The AES-128-GCM AlgorithmIdentifier:
algorithm=2.16.840.1.101.3.4.1.6 algorithm=2.16.840.1.101.3.4.1.6
parameters=GCMParameters: parameters=GCMParameters:
aes-nonce=0x5c79058ba2f43447639d29e2 aes-nonce=0x5c79058ba2f43447639d29e2
aes-ICVlen is ommited; it indicates the DEFAULT of 12 aes-ICVlen is ommited; it indicates the DEFAULT of 12
DER-encoded AlgorithmIdentifier: DER-encoded AlgorithmIdentifier:
301b0609608648016503040106300e040c5c79058ba2f43447639d29e2 301b0609608648016503040106300e040c5c79058ba2f43447639d29e2
OKM = 2124ffb29fac4e0fbbc7d5d87492bff3 OKM = 2124ffb29fac4e0fbbc7d5d87492bff3
]]></sourcecode>
]]></artwork>
</section> </section>
<section anchor="cmscekhkdfsha256-with-aes-128-cbc"> <section anchor="cmscekhkdfsha256-with-aes-128-cbc">
<name>CMS_CEK_HKDF_SHA256 with AES-128-CBC</name> <name>CMS_CEK_HKDF_SHA256 with AES-128-CBC</name>
<t>This test vector uses includes an AlgorithmIdentifier for<br/> <t>This test vector uses includes an AlgorithmIdentifier for AES-128-CBC
AES-128-CBC.</t> .</t>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
IKM = c702e7d0a9e064b09ba55245fb733cf3 IKM = c702e7d0a9e064b09ba55245fb733cf3
The AES-128-CBC AlgorithmIdentifier: The AES-128-CBC AlgorithmIdentifier:
algorithm=2.16.840.1.101.3.4.1.2 algorithm=2.16.840.1.101.3.4.1.2
parameters=AES-IV=0x651f722ffd512c52fe072e507d72b377 parameters=AES-IV=0x651f722ffd512c52fe072e507d72b377
DER-encoded AlgorithmIdentifier: DER-encoded AlgorithmIdentifier:
301d06096086480165030401020410651f722ffd512c52fe072e507d72b377 301d06096086480165030401020410651f722ffd512c52fe072e507d72b377
OKM = 9cd102c52f1e19ece8729b35bfeceb50 OKM = 9cd102c52f1e19ece8729b35bfeceb50
]]></sourcecode>
]]></artwork>
</section> </section>
</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> </back>
<!-- ##markdown-source: <!-- [rfced] Please review the "Inclusive Language" portion of the online
H4sIADZY7GYAA+08aXPjtpLf8Suwng8jp0RZp205mbzVyJoZZcbHWpocm3qV Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
gkhI4poi9QjKGsU1+S3vt7xftt0NgIdE+ZgkVXsklcQkiKPRdzcachyHqUSE and let us know if any changes are needed. Updates of this nature typically
3i8iiEJ5xpN4JZm/jOlJJc16vVtvMi9yQ7GAz14sponjy2TqBGKxVI67gP/k result in more precise language, which is helpful for readers.
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==
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 67 change blocks. 
530 lines changed or deleted 418 lines changed or added

This html diff was produced by rfcdiff 1.48.