rfc9709.original   rfc9709.txt 
Network Working Group R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9709 Vigil Security
Intended status: Standards Track 19 September 2024 Category: Standards Track January 2025
Expires: 23 March 2025 ISSN: 2070-1721
Encryption Key Derivation in the Cryptographic Message Syntax (CMS) Encryption Key Derivation in the Cryptographic Message Syntax (CMS)
using HKDF with SHA-256 using HKDF with SHA-256
draft-ietf-lamps-cms-cek-hkdf-sha256-05
Abstract Abstract
This document specifies the derivation of the content-encryption key This document specifies the derivation of the content-encryption key
or the content-authenticated-encryption key in the Cryptographic or the content-authenticated-encryption key in the Cryptographic
Message Syntax (CMS) using HMAC-based Extract-and-Expand Key Message Syntax (CMS) using the HMAC-based Extract-and-Expand Key
Derivation Function (HKDF) with SHA-256. The use of this mechanism Derivation Function (HKDF) with SHA-256. The use of this mechanism
provides protection against where the attacker manipulates the provides protection against an attacker that manipulates the content-
content-encryption algorithm identifier or the content-authenticated- encryption algorithm identifier or the content-authenticated-
encryption algorithm identifier. encryption algorithm identifier.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 March 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9709.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. ASN.1
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology
1.3. Cryptographic Algorithm Agility Considerations . . . . . 4 1.3. Cryptographic Algorithm Agility Considerations
2. Use of of HKDF with SHA-256 to Derive Encryption Keys . . . . 4 2. Use of HKDF with SHA-256 to Derive Encryption Keys
3. The id-alg-cek-hkdf-sha256 Algorithm Identifier . . . . . . . 5 3. The id-alg-cek-hkdf-sha256 Algorithm Identifier
4. SMIMECapabilities Attribute Conventions . . . . . . . . . . . 6 4. SMIMECapabilities Attribute Conventions
5. Use of HKDF with SHA-256 with CMS . . . . . . . . . . . . . . 6 5. Use of HKDF with SHA-256 with CMS
5.1. Enveloped-Data Content Type . . . . . . . . . . . . . . . 6 5.1. Enveloped-Data Content Type
5.2. Encrypted-Data Content Type . . . . . . . . . . . . . . . 7 5.2. Encrypted-Data Content Type
5.3. Authenticated-Enveloped-Data Content Type . . . . . . . . 8 5.3. Authenticated-Enveloped-Data Content Type
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 7. Privacy Considerations
8. Operations Considerations . . . . . . . . . . . . . . . . . . 10 8. Operations Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix B. CMS_CEK_HKDF_SHA256 Function Examples
Appendix B. CMS_CEK_HKDF_SHA256 Function Examples . . . . . . . 14 B.1. CMS_CEK_HKDF_SHA256 with AES-128-GCM
B.1. CMS_CEK_HKDF_SHA256 with AES-128-GCM . . . . . . . . . . 14 B.2. CMS_CEK_HKDF_SHA256 with AES-128-CBC
B.2. CMS_CEK_HKDF_SHA256 with AES-128-CBC . . . . . . . . . . 14 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address
1. Introduction 1. Introduction
This document specifies the derivation of the content-encryption key This document specifies the derivation of the content-encryption key
for the Cryptographic Message Syntax (CMS) enveloped-data content for the Cryptographic Message Syntax (CMS) enveloped-data content
type [RFC5652], the content-encryption key for the CMS encrypted-data type [RFC5652], the content-encryption key for the CMS encrypted-data
content type [RFC5652], or the content-authenticated-encryption key content type [RFC5652], or the content-authenticated-encryption key
for the authenticated-enveloped-data content type [RFC5083]. for the authenticated-enveloped-data content type [RFC5083].
The use of this mechanism provides protection against where the The use of this mechanism provides protection against an attacker
attacker manipulates the content-encryption algorithm identifier or that manipulates the content-encryption algorithm identifier or the
the content-authenticated-encryption algorithm identifier. Johannes content-authenticated-encryption algorithm identifier. Johannes Roth
Roth and Falko Strenzke presented such an attack at IETF 118 and Falko Strenzke presented such an attack at IETF 118 [RS2023],
[RS2023], where: where:
1. The attacker intercepts a CMS Authenticated-Enveloped-Data 1. The attacker intercepts a CMS authenticated-enveloped-data
content [RFC5083] that uses either AES-CCM or AES-GCM [RFC5084]. content [RFC5083] that uses either AES-CCM or AES-GCM [RFC5084].
2. The attacker turns the intercepted content into a "garbage" CMS 2. The attacker turns the intercepted content into a "garbage" CMS
Enveloped-Data content Section 6 of [RFC5652] that is composed of enveloped-data content (Section 6 of [RFC5652]) that is composed
AES-CBC guess blocks. of AES-CBC guess blocks.
3. The attacker sends the "garbage" message to the victim, and the 3. The attacker sends the "garbage" message to the victim, and the
victim reveals the result of the decryption to the attacker. victim reveals the result of the decryption to the attacker.
4. If any of the transformed plaintext blocks match the guess for 4. If any of the transformed plaintext blocks match the guess for
that block, then the attacker learns the plaintext for that that block, then the attacker learns the plaintext for that
block. block.
With highly structured messages, one block can reveal the only With highly structured messages, one block can reveal the only
sensitive part of the original message. sensitive part of the original message.
This attack is thwarted if the encryption key depends upon the This attack is thwarted if the encryption key depends upon the
delivery of the unmodified algorithm identifier. delivery of the unmodified algorithm identifier.
The mitigation for this attack has three parts: The mitigation for this attack has three parts:
* Potential recipients include the id-alg-cek-hkdf-sha256 algorithm 1. Potential recipients include the id-alg-cek-hkdf-sha256 algorithm
identifier (with no parameters) in S/MIME Capabilities to indicate identifier (with no parameters) in S/MIME Capabilities to
support for this mitigation. indicate support for this mitigation.
* As a flag to the recipient that this mitigation is being used, 2. As a flag to the recipient that this mitigation is being used,
carry the id-alg-cek-hkdf-sha256 algorithm identifier as the carry the id-alg-cek-hkdf-sha256 algorithm identifier as the
contentEncryptionAlgorithm in the EncryptedContentInfo structure. contentEncryptionAlgorithm in the EncryptedContentInfo structure.
This structure is used in the enveloped-data content type, the This structure is used in the enveloped-data content type, the
encrypted-data content type, and the authenticated-enveloped-data encrypted-data content type, and the authenticated-enveloped-data
content type. The parameters field of the id-alg-cek-hkdf-sha256 content type. The parameters field of the id-alg-cek-hkdf-sha256
algorithm identifier identifies the content-encryption algorithm algorithm identifier identifies the content-encryption algorithm
or the content-authenticated-encryption algorithm and any or the content-authenticated-encryption algorithm and any
associated parameters. associated parameters.
* Perform encryption with a derived content-encryption key or 3. Perform encryption with a derived content-encryption key or
content-authenticated-encryption key: content-authenticated-encryption key:
CEK' = HKDF(CEK, AlgorithmIdentifier) CEK' = HKDF(CEK, AlgorithmIdentifier)
1.1. ASN.1 1.1. ASN.1
CMS values are generated using ASN.1 [X680], using the Basic Encoding CMS values are generated using ASN.1 [X680], using the Basic Encoding
Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 4, line 27 skipping to change at line 153
1.3. Cryptographic Algorithm Agility Considerations 1.3. Cryptographic Algorithm Agility Considerations
There is no provision for key derivation functions other than HKDF, There is no provision for key derivation functions other than HKDF,
and there is no provision for hash functions other than SHA-256. If 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 there is ever a need to support another key derivation function or
another hash function, it will be very straightforward to assign a another hash function, it will be very straightforward to assign a
new object identifier. At this point, keeping the design very simple new object identifier. At this point, keeping the design very simple
seems most important. seems most important.
2. Use of of HKDF with SHA-256 to Derive Encryption Keys 2. Use of HKDF with SHA-256 to Derive Encryption Keys
The mitigation uses the HMAC-based Extract-and-Expand Key Derivation The mitigation uses the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) [RFC5869] to derive output keying material (OKM) from Function (HKDF) [RFC5869] to derive output keying material (OKM) from
input key material (IKM). HKDF is used with the SHA-256 hash input keying material (IKM). HKDF is used with the SHA-256 hash
function [FIPS180]. The derivation includes the DER-encoded function [FIPS180]. The derivation includes the DER-encoded
AlgorithmIdentifier as the optional info input value. The encoded AlgorithmIdentifier as the optional info input value. The encoded
value includes the ASN.1 tag for SEQUENCE (0x30), the length, and the value includes the ASN.1 tag for SEQUENCE (0x30), the length, and the
value. This AlgoritmIdentifier is carried as the parameter to the value. This AlgorithmIdentifier is carried as the parameter to the
id-alg-cek-hkdf-sha256 algorithm identifier. If an attacker were to id-alg-cek-hkdf-sha256 algorithm identifier. If an attacker were to
change the originator-provided AlgoritmIdentifier, then the recipient change the originator-provided AlgorithmIdentifier, then the
will derive a different content-encryption key or content- recipient will derive a different content-encryption key or content-
authenticated-encryption key. authenticated-encryption key.
The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF- The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF-
Expand functions to derive the OKM from the IKM: Expand functions to derive the OKM from the IKM:
Inputs: Inputs:
IKM input keying material IKM input keying material
info DER-encoded AlgoritmIdentifier info DER-encoded AlgorithmIdentifier
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)
3. The id-alg-cek-hkdf-sha256 Algorithm Identifier 3. The id-alg-cek-hkdf-sha256 Algorithm Identifier
The id-alg-cek-hkdf-sha256 algoritm identifier indicates that the The id-alg-cek-hkdf-sha256 algorithm identifier indicates that the
CMS_CEK_HKDF_SHA256 function defined in Section 2 is used to derive CMS_CEK_HKDF_SHA256 function defined in Section 2 is used to derive
the content-encryption key or the content-authenticated-encryption the content-encryption key or the content-authenticated-encryption
key. key.
The following object identifier identifies the id-alg-cek-hkdf-sha256 The following object identifier identifies the id-alg-cek-hkdf-sha256
algorithm: algorithm:
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 }
skipping to change at page 6, line 7 skipping to change at line 217
ContentEncryptionAlgorithmIdentifier ::= ContentEncryptionAlgorithmIdentifier ::=
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 } }
4. SMIMECapabilities Attribute Conventions 4. SMIMECapabilities Attribute Conventions
The SMIMECapabilities Attribute is defined in Section 2.5.2 of The SMIMECapabilities attribute is defined in Section 2.5.2 of
[RFC8551]. An S/MIME client announces the set of cryptographic [RFC8551]. An S/MIME client announces the set of cryptographic
functions it supports using the SMIMECapabilities attribute. functions it supports using the SMIMECapabilities attribute.
If an S/MIME client supports the mechanism in this document, the id- If an S/MIME client supports the mechanism in this document, the id-
alg-cek-hkdf-sha256 object identifier SHOULD be included in the set alg-cek-hkdf-sha256 object identifier SHOULD be included in the set
of cryptographic functions. The parameter with this encoding MUST be of cryptographic functions. The parameter with this encoding MUST be
absent. absent.
The encoding for id-alg-cek-hkdf-sha256, in hexadecimal, is: The encoding for id-alg-cek-hkdf-sha256, in hexadecimal, is:
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
5. Use of HKDF with SHA-256 with CMS 5. Use of HKDF with SHA-256 with CMS
This section describes the originator and recipient processing to This section describes the originator and recipient processing to
implement this mitigation for each of the CMS encrypting content implement this mitigation for each of the CMS encrypting content
types. types.
5.1. Enveloped-Data Content Type 5.1. Enveloped-Data Content Type
The fourth step of constructing an Enveloped-data is repeated below The fourth step of constructing an enveloped-data content type is
from Section 6 of [RFC5652]: repeated below from Section 6 of [RFC5652]:
4. The content is encrypted with the content-encryption key. | 4. 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 6.3.
To implement this mitigation, the originator expands this step as To implement this mitigation, the originator expands this step as
follows: follows:
* Include the id-alg-cek-hkdf-sha256 algorithm identifier in the * Include the id-alg-cek-hkdf-sha256 algorithm identifier in the
contentEncryptionAlgorithm.algorithm field of the contentEncryptionAlgorithm.algorithm field of the
EncryptedContentInfo structure, and set the EncryptedContentInfo structure, and set the
contentEncryptionAlgorithm.parameters field to the contentEncryptionAlgorithm.parameters field to the
AlgorithmIdentifier for the content-encryption algorithm that will AlgorithmIdentifier for the content-encryption algorithm that will
be used to encrypt the content, including both the algorithm and be used to encrypt the content, including both the algorithm and
skipping to change at page 8, line 17 skipping to change at line 315
EncryptedContentInfo structure tells the recipient to derive the new EncryptedContentInfo structure tells the recipient to derive the new
content-encryption key (CEK') as shown above, and then use it for content-encryption key (CEK') as shown above, and then use it for
decryption of the EncryptedContent. If the id-alg-cek-hkdf-sha256 decryption of the EncryptedContent. If the id-alg-cek-hkdf-sha256
algorithm identifier is not present in the algorithm identifier is not present in the
contentEncryptionAlgorithm.algorithm field of the contentEncryptionAlgorithm.algorithm field of the
EncryptedContentInfo structure, then the recipient uses the original EncryptedContentInfo structure, then the recipient uses the original
content-encryption key (CEK) for decryption of the EncryptedContent. content-encryption key (CEK) for decryption of the EncryptedContent.
5.3. Authenticated-Enveloped-Data Content Type 5.3. Authenticated-Enveloped-Data Content Type
The fifth step of constructing an Authenticated-Enveloped-Data is The fifth step of constructing an authenticated-enveloped-data
repeated below from Section 2 of [RFC5083]: content type is repeated below from Section 2 of [RFC5083]:
5. The attributes collected in step 4 are authenticated and the CMS | 5. The attributes collected in step 4 are authenticated and the
content is authenticated and encrypted with the content- | CMS 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
or the content to be padded to a multiple of some block size, | (AAD) or the content to be padded to a multiple of some block
then the padding is added as described in Section 6.3 of | size, then the padding is added as described in Section 6.3 of
[RFC5652]. | [CMS].
| Note that [CMS] refers to [RFC3852], which has been obsoleted
| by [RFC5652], but the text in Section 6.3 was unchanged in RFC
| 5652.
To implement this mitigation, the originator expands this step as To implement this mitigation, the originator expands this step as
follows: follows:
* Include the id-alg-cek-hkdf-sha256 algorithm identifier in the * Include the id-alg-cek-hkdf-sha256 algorithm identifier in the
contentEncryptionAlgorithm.algorithm field of the contentEncryptionAlgorithm.algorithm field of the
EncryptedContentInfo structure, and set the EncryptedContentInfo structure, and set the
contentEncryptionAlgorithm.parameters field to the contentEncryptionAlgorithm.parameters field to the
AlgorithmIdentifier for the content-authenticated-encryption AlgorithmIdentifier for the content-authenticated-encryption
algorithm that will be used for authenticated encryption of the algorithm that will be used for authenticated encryption of the
skipping to change at page 9, line 28 skipping to change at line 378
This mitigation always uses HKDF with SHA-256. One KDF algorithm was This mitigation always uses HKDF with SHA-256. One KDF algorithm was
selected to avoid the need for negotiation. In the future, if a 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 weakness is found in the KDF algorithm, a new attribute will need to
be assigned for use with an alternative KDF algorithm. be assigned for use with an alternative KDF algorithm.
If the attacker removes the id-alg-cek-hkdf-sha256 object identifier If the attacker removes the id-alg-cek-hkdf-sha256 object identifier
from the contentEncryptionAlgorithm.algorithm field of the from the contentEncryptionAlgorithm.algorithm field of the
EncryptedContentInfo structure prior to delivery to the recipient, EncryptedContentInfo structure prior to delivery to the recipient,
then the recipient will not attempt to derive CEK', which will deny then the recipient will not attempt to derive CEK', which will deny
the recipient access to the content, but will not assist the attacker the recipient access to the content but will not assist the attacker
in recovering the plaintext content. in recovering the plaintext content.
If the attacker changes contentEncryptionAlgorithm.parameters field If the attacker changes contentEncryptionAlgorithm.parameters field
of the EncryptedContentInfo structure prior to delivery to the of the EncryptedContentInfo structure prior to delivery to the
recipient, then the recipient will derive a different CEK', which recipient, then the recipient will derive a different CEK', which
will not assist the attacker in recovering the plaintext content. will not assist the attacker in recovering the plaintext content.
Providing the object identifier as an input to the key derivation Providing the object identifier as an input to the key derivation
function is sufficient to mitigate the attack described in [RS2023], function is sufficient to mitigate the attack described in [RS2023],
but this mitigation includes both the object identifier and the but this mitigation includes both the object identifier and the
parameters to protect against some yet-to-be-discovered attack that parameters to protect against some yet-to-be-discovered attack that
only manipulates the parameters. only manipulates the parameters.
Implementations MUST protect the content-encryption keys and content- Implementations MUST protect the content-encryption keys and content-
authenticated-encryption keys, this includes the CEK and CEK'. authenticated-encryption keys, including the CEK and CEK'.
Compromise of a content-encryption key may result in disclosure of Compromise of a content-encryption key may result in disclosure of
the associated encrypted content. Compromise of a content- the associated encrypted content. Compromise of a content-
authenticated-encryption key may result in disclosure of the authenticated-encryption key may result in disclosure of the
associated encrypted content or allow modification of the associated encrypted content or allow modification of the
authenticated content and the additional authenticated data (AAD). authenticated content and the AAD.
Implementations MUST randomly generate content-encryption keys and Implementations MUST randomly generate content-encryption keys and
content-authenticated-encryption keys. Using an inadequate pseudo- content-authenticated-encryption keys. Using an inadequate
random number generator (PRNG) to generate cryptographic keys can pseudorandom number generator (PRNG) to generate cryptographic keys
result in little or no security. An attacker may find it much easier can result in little or no security. An attacker may find it much
to reproduce the PRNG environment that produced the keys, and then easier to reproduce the PRNG environment that produced the keys and
searching the resulting small set of possibilities, rather than brute then search the resulting small set of possibilities, rather than
force searching the whole key space. The generation of quality brute-force searching the whole key space. The generation of quality
random numbers is difficult. [RFC4086] offers important guidance on random numbers is difficult. [RFC4086] offers important guidance on
this topic. this topic.
7. Privacy Considerations 7. Privacy Considerations
If the message-digest attribute is included in the AuthAttributes, 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, the content matches one or more candidates. For these reasons, the
skipping to change at page 10, line 37 skipping to change at line 436
traffic since many mitigation strategies will be unable to access the traffic since many mitigation strategies will be unable to access the
message content plaintext. Therefore, software that receives message content plaintext. Therefore, software that receives
messages that have been encrypted using CMS ought to provide messages that have been encrypted using CMS ought to provide
alternate mechanisms to handle the unwanted message traffic. One alternate mechanisms to handle the unwanted message traffic. One
approach that does not require disclosure of keying material to a approach that does not require disclosure of keying material to a
server is to reject or discard encrypted messages unless they purport server is to reject or discard encrypted messages unless they purport
to come from a member of a previously approved originator list. to come from a member of a previously approved originator list.
9. IANA Considerations 9. IANA Considerations
For the ASN.1 Module in the Appendix A of this document, IANA is For the ASN.1 module in Appendix A of this document, IANA has
requested to assign an object identifier (OID) for the module assigned the following object identifier (OID) in the "SMI Security
identifier (TBD0) with a Description of "id-mod-CMS-CEK-HKDF- for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
SHA256-2023". The OID for the module should be allocated in the "SMI
Security for S/MIME Module Identifier" registry +=========+=================================+============+
(1.2.840.113549.1.9.16.0). | Decimal | Description | References |
+=========+=================================+============+
| 80 | id-mod-CMS-CEK-HKDF-SHA256-2023 | RFC 9709 |
+---------+---------------------------------+------------+
Table 1
IANA has allocated the id-alg-cek-hkdf-sha256 algorithm identifier as IANA has allocated the id-alg-cek-hkdf-sha256 algorithm identifier as
specified in Section 3 of this document. The object identifier (OID) specified in Section 3 in the "SMI Security for S/MIME Algorithms
value of 1.2.840.113549.1.9.16.3.31 was allocated with a description (1.2.840.113549.1.9.16.3)" registry as follows:
of "id-alg-cek-hkdf-sha256" in the "SMI Security for S/MIME
Algorithms" registry (1.2.840.113549.1.9.16.3).
10. Acknowledgements +=========+========================+============+
| Decimal | Description | References |
+=========+========================+============+
| 31 | id-alg-cek-hkdf-sha256 | RFC 9709 |
+---------+------------------------+------------+
Thanks to Mike Ounsworth, Carl Wallace, and Joe Mandel their careful Table 2
review and constructive comments.
11. References 10. References
11.1. Normative References 10.1. Normative References
[FIPS180] National Institute of Standards and Technology (NIST), [FIPS180] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, "Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
DOI 10.17487/RFC5083, November 2007, DOI 10.17487/RFC5083, November 2007,
<https://www.rfc-editor.org/rfc/rfc5083>. <https://www.rfc-editor.org/info/rfc5083>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551, Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/rfc/rfc8551>. April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation [X680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: [X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021, (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>. February 2021, <https://www.itu.int/rec/T-REC-X.690>.
11.2. Informative References 10.2. Informative References
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, DOI 10.17487/RFC3852, July 2004,
<https://www.rfc-editor.org/info/rfc3852>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
RFC 5084, DOI 10.17487/RFC5084, November 2007, RFC 5084, DOI 10.17487/RFC5084, November 2007,
<https://www.rfc-editor.org/rfc/rfc5084>. <https://www.rfc-editor.org/info/rfc5084>.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010, DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/rfc/rfc5911>. <https://www.rfc-editor.org/info/rfc5911>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/rfc/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RS2023] Roth, J. and F. Strenzke, "AEAD-to-CBC Downgrade Attacks [RS2023] Roth, J. and F. Strenzke, "AEAD-to-CBC Downgrade Attacks
on CMS", 8 November 2023, on CMS", IETF 118 Proceedings, 8 November 2023,
<https://datatracker.ietf.org/meeting/118/materials/ <https://datatracker.ietf.org/meeting/118/materials/
slides-118-lamps-attack-against-aead-in-cms>. slides-118-lamps-attack-against-aead-in-cms>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This ASN.1 Module builds upon the conventions established in This ASN.1 module builds upon the conventions established in
[RFC5911] and [RFC5912]. [RFC5911] and [RFC5912].
<CODE STARTS> <CODE BEGINS>
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 page 13, line 47 skipping to change at line 586
-- --
-- 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> <CODE ENDS>
Appendix B. CMS_CEK_HKDF_SHA256 Function Examples Appendix B. CMS_CEK_HKDF_SHA256 Function Examples
This appendix provides two test vectores for the CMS_CEK_HKDF_SHA256 This appendix provides two test vectors for the CMS_CEK_HKDF_SHA256
function. function.
B.1. CMS_CEK_HKDF_SHA256 with AES-128-GCM B.1. CMS_CEK_HKDF_SHA256 with AES-128-GCM
This test vector uses includes an AlgorithmIdentifier for This test vector includes an AlgorithmIdentifier for AES-128-GCM.
AES-128-GCM.
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
B.2. CMS_CEK_HKDF_SHA256 with AES-128-CBC B.2. CMS_CEK_HKDF_SHA256 with AES-128-CBC
This test vector uses includes an AlgorithmIdentifier for This test vector uses includes an AlgorithmIdentifier for AES-
AES-128-CBC. 128-CBC.
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
Acknowledgements
Thanks to Mike Ounsworth, Carl Wallace, and Joe Mandel their careful
review and constructive comments.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
Herndon, VA, Herndon, VA
United States of America United States of America
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 62 change blocks. 
148 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48.