]> CryptoNext Security

16, Boulevard Saint-Germain Paris 75007 France daniel.vangeest@cryptonext-security.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Bundesdruckerei GmbH

Kommandantenstr. 18 Berlin 10969 Germany jan.klaussner@bdr.de

Security LAMPS X.509 CMS Post-Quantum KEM Composite ML-KEM Composite ML-KEM defines combinations of Module-Lattice-based Key Encapsulation Mechanism (ML-KEM) with RSA-OAEP, ECDH, X25519, and X448. This document specifies the conventions for using Composite ML-KEM algorithms with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in “Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)” (RFC 9629). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines a collection of Key Encapsulation Mechanism (KEM) algorithms, referred to as Composite ML-KEM, which combine Module-Lattice-based Key Encapsulation Mechanism (ML-KEM) with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. defines the KEMRecipientInfo structure for the use of KEM algorithms for the Cryptographic Message Syntax (CMS) enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document acts as a companion to by providing conventions for using Composite ML-KEM algorithms with the KEMRecipientInfo structure within the CMS.

ASN.1 CMS values are generated using ASN.1 , using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings.

Composite ML-KEM ML-KEM is a lattice-based KEM using Module Learning with Errors as its underlying primitive. It was standardized in with three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Composite ML-KEM pairs ML-KEM-768 or ML-KEM-1024 with RSA-OAEP, ECDH, X25519, or X448 at similar security levels such that the shared secret key from each component algorithm is combined into a single shared secret key. Composite ML-KEM does not provide pairings based on ML-KEM-512. All KEM algorithms provide three functions: KeyGen(), Encapsulate(), and Decapsulate(). The names KeyGen(), Encapsulate(), and Decapsulate() are taken from , the specification of the KEMRecipientInfo structure. defines the same three operations for Composite ML-KEM under the names KeyGen(), Encaps(), and Decaps(). The two naming conventions refer to the same operations: Encapsulate() in this document and in is Encaps() in ; Decapsulate() is Decaps(). This document uses the names throughout, since it defines the CMS-specific KEMRecipientInfo processing. The parameter names also differ between the two documents, though they denote the same values. This document, following , uses pk for the public encapsulation key, sk for the private decapsulation key, and ct for the ciphertext; uses pk, sk, and ct for the same three values. Both documents use ss for the shared secret. The parameter order matches between the two documents for KeyGen() and for Decapsulate()/Decaps(), but not for Encapsulate()/Encaps(): this document's Encapsulate(pk) -> (ct, ss) returns the ciphertext before the shared secret, while 's Encaps(pk) -> (ss, ct) returns the shared secret before the ciphertext. Implementers referencing both documents should not assume positional correspondence between the two encapsulation functions' return values. The following summarizes these three functions for Composite ML-KEM:

KeyGen() -> (pk, sk):

Generate the public encapsulation key (pk) and a private decapsulation key (sk). specifies the KeyGen() algorithm for Composite ML-KEM.

Encapsulate(pk) -> (ct, ss):

Given the recipient's public key (pk), produce both a ciphertext (ct) to be passed to the recipient and a shared secret (ss) for use by the originator. specifies the Encaps() algorithm for Composite ML-KEM.

Decapsulate(sk, ct) -> ss:

Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss) for the recipient. specifies the Decaps() algorithm for Composite ML-KEM.

Use of Composite ML-KEM in the CMS Composite ML-KEM algorithms MAY be employed for one or more recipients in the CMS enveloped-data content type , the CMS authenticated-data content type , or the CMS authenticated-enveloped-data content type . In each case, the KEMRecipientInfo type is used with the Composite ML-KEM algorithm to securely transfer the content-encryption key or the content-authenticated-encryption key from the originator to the recipient. Processing a Composite ML-KEM algorithm with KEMRecipientInfo follows the same steps as . To support the Composite ML-KEM algorithm, a CMS originator MUST implement the Encapsulate() function and a CMS recipient MUST implement the Decapsulate() function.

RecipientInfo Conventions When a Composite ML-KEM algorithm is employed for a recipient, the RecipientInfo alternative for that recipient MUST be OtherRecipientInfo using the KEMRecipientInfo structure as defined in . The fields of the KEMRecipientInfo have the following meanings:

version

The syntax version number; it MUST be 0.

rid

Identifies the recipient's certificate or public key.

kem

Identifies the KEM algorithm; it MUST contain one of the Composite ML-KEM OIDs in .

kemct

The ciphertext produced for this recipient.

kdf

Identifies the key derivation algorithm. Note that the Key Derivation Function (KDF) used for CMS RecipientInfo process MAY be different than the KDF used within the Composite ML-KEM algorithm. Implementations MUST support the HMAC-based Key Derivation Function (HKDF) with SHA-256 , using the id-alg-hkdf-with-sha256 KDF object identifier (OID) . As specified in , the parameter field MUST be absent when this OID appears within the ASN.1 type AlgorithmIdentifier. Implementations MAY support other KDFs as well.

kekLength

The size of the key-encryption key in octets.

ukm

Optional input to the KDF. The secure use of Composite ML-KEM in CMS does not depend on the use of a ukm value, so this document does not place any requirements on this value. See for more information about the ukm parameter.

wrap

Identifies a key-encryption algorithm used to encrypt the content-encryption key or the content-authenticated-encryption key. Implementations MUST support the AES-Wrap-256 key-encryption algorithm using the id-aes256-wrap key-encryption algorithm OID . Implementations MAY support other key-encryption algorithms as well.

encryptedKey

The result of encrypting the content-encryption key or the content-authenticated-encryption key with the key-encryption key.

contains an example of establishing a content-encryption key using Composite ML-KEM in the KEMRecipientInfo type.

Underlying Components When Composite ML-KEM is employed in the CMS, the underlying components used within the KEMRecipientInfo structure SHOULD provide a security strength (as defined in ) of at least the security level of the ML-KEM variant used, as summarized in the table below. If underlying components other than those specified in are used, then the following table gives the minimum requirements on the components used with Composite ML-KEM in the KEMRecipientInfo type in order to satisfy the KDF and key wrapping algorithm requirements from . The components are chosen based on the ML-KEM variant used within the Composite ML-KEM algorithm. Composite ML-KEM KEMRecipientInfo Component Security Levels

Security Strength	ML-KEM Variant	KDF Preimage Strength	Symmetric Key-Encryption Strength
192-bit	ML-KEM-768	192-bit	192-bit (*)
256-bit	ML-KEM-1024	256-bit	256-bit

(*) In the case of AES Key Wrap, a 256-bit key is typically used because AES-192 is not as commonly deployed.

Use of the HKDF-Based Key Derivation Function The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions. When used with KEMRecipientInfo, the salt parameter is unused; that is, it is the zero-length string "". The IKM, info, and L parameters correspond to the same KDF inputs from . The info parameter is independently generated by the originator and recipient. Implementations MUST confirm that L is consistent with the key size of the key-encryption algorithm.

Certificate Conventions specifies the profile for using X.509 certificates in Internet applications. A recipient static public key is needed for Composite ML-KEM and the originator obtains that public key from the recipient's certificate. The conventions for carrying Composite ML-KEM public keys are specified in .

SMIME Capabilities Attribute Conventions defines the SMIMECapabilities attribute to announce a partial list of algorithms that an S/MIME implementation can support. When constructing a CMS signed-data content type , a compliant implementation MAY include the SMIMECapabilities attribute that announces support for one or more of the Composite ML-KEM algorithm identifiers. The SMIMECapability SEQUENCE representing the Composite ML-KEM algorithm MUST include one of the Composite ML-KEM OIDs in the capabilityID field. When one of the Composite ML-KEM OIDs appears in the capabilityID field, the parameters MUST NOT be present.

Identifiers All identifiers used to indicate Composite ML-KEM within the CMS are defined in , , and ; they are reproduced here for convenience:

Security Considerations The Security Considerations sections of and apply to this specification as well. Implementations MUST protect the Composite ML-KEM private key, the key-encryption key, the content-encryption key, message-authentication key, and the content-authenticated-encryption key. Of these keys, all but the private key are ephemeral and MUST be wiped after use. Disclosure of the Composite ML-KEM private key could result in the compromise of all messages protected with that key. Disclosure of the key-encryption key, the content-encryption key, or the content-authenticated-encryption key could result in the compromise of the associated encrypted content. Disclosure of the key-encryption key, the message-authentication key, or the content-authenticated-encryption key could allow modification of the associated authenticated content. Additional considerations related to key management may be found in . The generation of private keys relies on random numbers, as does the encapsulation function of Composite ML-KEM. The use of inadequate pseudorandom number generators (PRNGs) to generate these values can result in little or no security. If the random value is weakly chosen, then an attacker may find it much easier to reproduce the PRNG environment that produced the keys or ciphertext, searching the resulting small set of possibilities for a matching public key or ciphertext value, rather than performing a more complex algorithmic attack against the components of Composite ML-KEM. During encapsulation, the ML-KEM component draws the encapsulation randomness from a random bit generator. While Composite ML-KEM passes this randomness through a KDF before using it, the peer holding the decapsulation key has still received this randomness in the ML-KEM component of the ciphertext. Any information that this randomness provides about other outputs of the generator is available to that peer, therefore it is important to follow the RNG guidance in . Composite ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations MUST NOT use intermediate values directly for any purpose. Implementations SHOULD NOT reveal information about intermediate values or calculations, whether by timing or other "side channels"; otherwise an opponent may be able to determine information about the keying data and/or the recipient's private key. Although not all intermediate information may be useful to an opponent, it is preferable to conceal as much information as is practical, unless analysis specifically indicates that the information would not be useful to an opponent. Generally, good cryptographic practice employs a given Composite ML-KEM key pair in only one scheme. This practice avoids the risk that vulnerability in one scheme may compromise the security of the other and may be essential to maintain provable security.

IANA Considerations IANA is requested to allocate a value from the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry for the ASN.1 module in .

• Decimal: IANA Assigned - Replace TBDMOD
• Description: Composite-MLKEM-CMS-2026 - id-mod-composite-mlkem-cms-2026
• References: This Document

References Normative References National Institute of Standards and Technology (U.S.) ITU-T ITU-T The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST ML-KEM in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions. The purpose of this document is to make the AES Key Wrap algorithm conveniently available to the Internet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES Key Wrap posted by NIST. This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Informative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (NIST) The RSA Key Encapsulation Mechanism (RSA-KEM) algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. This document obsoletes RFC 5990. Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US National Institute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629).

ASN.1 Module This appendix includes the ASN.1 module for Composite ML-KEM. This module imports objects from , , , . Composite-MLKEM-CMS-2026 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-composite-mlkem-cms-2026(TBDMOD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS SMIME-CAPS FROM AlgorithmInformation-2009 -- [RFC5911] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } KEM-ALGORITHM FROM KEMAlgorithmInformation-2023 -- [RFC9629] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-kemAlgorithmInformation-2023(109) } kda-hkdf-with-sha256 FROM HKDF-OID-2019 -- [RFC8619] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) } kwa-aes256-wrap FROM CMSAesRsaesOaep-2009 -- [RFC5911] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes-02(38) } kema-MLKEM768-RSA2048-SHA3-256, kema-MLKEM768-RSA3072-SHA3-256, kema-MLKEM768-RSA4096-SHA3-256, kema-MLKEM768-X25519-SHA3-256, kema-MLKEM768-ECDH-P256-SHA3-256, kema-MLKEM768-ECDH-P384-SHA3-256, kema-MLKEM768-ECDH-brainpoolP256r1-SHA3-256, kema-MLKEM1024-RSA3072-SHA3-256, kema-MLKEM1024-ECDH-P384-SHA3-256, kema-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256, kema-MLKEM1024-X448, kema-MLKEM1024-ECDH-P521-SHA3-256 FROM Composite-MLKEM-2025 -- [I-D.ietf-lamps-pq-composite-kem] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-composite-mlkem-2025(TBDCompositeMOD) } ; -- Updates for the SMIME-CAPS Set from RFC 5911 SMimeCapsSet SMIME-CAPS ::= { kema-MLKEM768-RSA2048-SHA3-256.&smimeCaps | kema-MLKEM768-RSA3072-SHA3-256.&smimeCaps | kema-MLKEM768-RSA4096-SHA3-256.&smimeCaps | kema-MLKEM768-X25519-SHA3-256.&smimeCaps | kema-MLKEM768-ECDH-P256-SHA3-256.&smimeCaps | kema-MLKEM768-ECDH-P384-SHA3-256.&smimeCaps | kema-MLKEM768-ECDH-brainpoolP256r1-SHA3-256.&smimeCaps | kema-MLKEM1024-RSA3072-SHA3-256.&smimeCaps | kema-MLKEM1024-ECDH-P384-SHA3-256.&smimeCaps | kema-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256.&smimeCaps | kema-MLKEM1024-X448.&smimeCaps | kema-MLKEM1024-ECDH-P521-SHA3-256.&smimeCaps | kda-hkdf-with-sha256.&smimeCaps | kwa-aes256-wrap.&smimeCaps, ... } END ]]>

Composite ML-KEM CMS Authenticated-Enveloped-Data Example This example shows the establishment of an AES-256 content-encryption key using:

• id-MLKEM768-ECDH-P256-SHA3-256;
• KEMRecipientInfo key derivation using HKDF with SHA-256; and
• KEMRecipientInfo key wrap using AES-256-KEYWRAP.

In real-world use, the originator would encrypt the content- encryption key in a manner that would allow decryption with their own private key as well as the recipient's private key. This is omitted in an attempt to simplify the example.

Originator CMS Processing Alice obtains Bob's id-MLKEM768-ECDH-P256-SHA3-256 public key: Bob's id-MLKEM768-ECDH-P256-SHA3-256 public key has the following key identifier: Alice generates a shared secret and ciphertext using Bob's id-MLKEM768-ECDH-P256-SHA3-256 public key: Shared secret: Ciphertext: Alice encodes the CMSORIforKEMOtherInfo: Alice derives the key-encryption key from the shared secret and CMSORIforKEMOtherInfo using HKDF with SHA-256: Alice randomly generates a 256-bit content-encryption key: Alice uses AES-256-KEYWRAP to encrypt the content-encryption key with the key-encryption key: Alice encrypts the padded content using AES-256-GCM with the content-encryption key and encodes the AuthEnvelopedData (using KEMRecipientInfo) and ContentInfo, and then sends the result to Bob. The Base64-encoded result is: This result decodes to:

Recipient CMS Processing Bob's id-MLKEM768-ECDH-P256-SHA3-256 private key: Bob decapsulates the ciphertext in the KEMRecipientInfo to get the MLKEM768-ECDH-P256-SHA3-256 shared secret, encodes the CMSORIforKEMOtherInfo, derives the key-encryption key from the shared secret and the DER-encoded CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-256-KEYWRAP to decrypt the content-encryption key with the key-encryption key, and decrypts the encrypted contents with the content-encryption key, revealing the plaintext content:

Acknowledgments This document borrows heavily from and . Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - RFC8411.