]> CryptoNext Security

16, Boulevard Saint-Germain Paris 75005 France julien.prat@cryptonext-security.com

Entrust Limited

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

CryptoNext Security

16, Boulevard Saint-Germain Paris 75005 France daniel.vangeest.ietf@gmail.com

Security LAMPS Key Encapsulation Mechanism (KEM) KEMRecipientInfo ML-KEM Kyber The Module-Lattice-based Key-Encapsulation Mechanism (ML-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 ML-KEM public key. Three parameters sets for the ML-KEM algorithm are specified by NIST in [EDNOTE: Change to when it is published]. 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 KEMRecipientInfo as specified in . About This Document Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction ML-KEM is an IND-CCA2-secure key-encapsulation mechanism (KEM) standardized in by the US NIST PQC Project . Native support for Key Encapsulation Mechanisms (KEMs) was added to CMS in , which defines the KEMRecipientInfo structure for the use of KEM algorithms for the CMS enveloped-data content type, the CMS authenticated-data content type, and the CMS authenticated-enveloped-data content type. This document specifies the direct use of ML-KEM in the KEMRecipientInfo structure in CMS using each of the three parameter sets from , namely MK-KEM-512, ML-KEM-768, and ML-KEM-1024. It does not address or preclude the use of ML-KEM as part of any hybrid scheme.

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 BCP14 when, and only when, they appear in all capitals, as shown here.

ML-KEM ML-KEM is a lattice-based key encapsulation mechanism using Module Learning with Errors as its underlying primitive, which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. These were mapped by NIST to the three security levels defined in the NIST PQC Project, Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256 respectively. Like all KEM algorithms, ML-KEM provides three functions: KeyGen(), Encapsulate(), and Decapsulate().

KeyGen() -> (pk, sk):

Generate the public key (pk) and a private key (sk).

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

Given the recipient's public key (pk), produce a ciphertext (ct) to be passed to the recipient and a shared secret (ss) for use by the originator.

Decapsulate(sk, ct) -> ss:

Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss) for the recipient.

The KEM functions defined above correspond to the following functions in :

KeyGen():

ML-KEM.KeyGen() from section 6.1.

Encapsulate():

ML-KEM.Encaps() from section 6.2.

Decapsulate():

ML-KEM.Decaps() from section 6.3.

All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE256, and SHAKE512 internally.

Use of the ML-KEM Algorithm in CMS The ML-KEM algorithm 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 is used with the ML-KEM algorithm to securely transfer the content-encryption key from the originator to the recipient. Processing ML-KEM with KEMRecipientInfo follows the same steps as Section 2 of . To support the ML-KEM algorithm, a CMS originator MUST implement the Encapsulate() function and a CMS responder MUST implement the Decapsulate() function.

RecipientInfo Conventions When the 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 MUST have the following values:

• version is 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 id-ML-KEM-512, id-ML-KEM-768, or id-ML-KEM-1024. These identifiers are reproduced in .

• kemct is 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 ML-KEM algorithm.

• kekLength is the size of the key-encryption key in octets.

• ukm is an optional random input to the key-derivation function. ML-KEM doesn't place any requirements on the ukm contents.

• wrap identifies a key wrapping algorithm used to encrypt the content-encryption key.

Underlying Components When ML-KEM is employed in CMS, the security levels of the different underlying components used within the KEMRecipientInfo structure SHOULD be consistent.

Use of the HKDF-based Key Derivation Function The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is defined in . The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions. HKDF(salt, IKM, info, L) takes the following parameters:

salt:

optional salt value (a non-secret random value). In this document this parameter is unused, that is it is the zero-length string "".

IKM:

input keying material. In this document this is the shared secret outputted from the Encapsulate() or Decapsulate() functions. This corresponds to the IKM KDF input from Section 5 of .

info:

optional context and application specific information. In this document this corresponds to the info KDF input from Section 5 of . This is the ASN.1 DER encoding of CMSORIforKEMOtherInfo.

L:

length of output keying material in octets. This corresponds to the L KDF input from Section 5 of , which is identified in the kekLength value from KEMRecipientInfo.

HKDF may be used with different hash functions, including SHA2-256 or SHA2-512 . The object identifiers id-alg-hkdf-with-sha256 and id-alg-hkdf-with-sha512 are defined in (see ), and specify the use of HKDF with SHA2-256 and SHA2-512 respectively. The parameter field MUST be absent when one of these algorithm identifiers is used to specify the KDF for ML-KEM in KemRecipientInfo.

Use of the KMAC-based Key Derivation Function KMAC128-KDF and KMAC256-KDF are KMAC-based KDFs specified for use in CMS in . Here, KMAC# indicates the use of either KMAC128-KDF or KMAC256-KDF. KMAC#(K, X, L, S) takes the following parameters:

K:

the input key-derivation key. In this document this is the shared secret outputted from the Encapsulate() or Decapsulate() functions. This corresponds to the IKM KDF input from Section 5 of .

X:

the context, corresponding to the info KDF input from Section 5 of . This is the ASN.1 DER encoding of CMSORIforKEMOtherInfo.

L:

the output length, in bits. This corresponds to the L KDF input from Section 5 of , which is identified in the kekLength value from KEMRecipientInfo. The L KDF input and kekLength values are specified in octets while this L parameter is specified in bits.

S:

the optional customization label. In this document this parameter is unused, that is it is the zero-length string "".

The object identifier for KMAC128-KDF is id-kmac128 (see ). The object identifier for KMAC256-KDF is id-kmac256 (see ). Since the customization label to KMAC# is not used, the parameter field MUST be absent when id-kmac128 or id-kmac256 is used as part of an algorithm identifier specifying the KDF to use for ML-KEM in KemRecipientInfo.

Components for ML-KEM in CMS An implementation MUST support at least one of KMAC# or HMAC as the KDF for ML-KEM in KemRecipientInfo. It is RECOMMENDED that a CMS recipient supports both. KMAC# is given as an option because ML-KEM uses SHA3 and SHAKE as internal functions, so an implementation may want to use these to reduce code size. HMAC is given as an option because SHA2 is widely supported and the CMS-level code may not have access to underlying KECCAK-based implementations. Note that the KDF used to process the KEMRecipientInfo structure MAY be different from the KDF used in the ML-KEM algorithm. For ML-KEM-512, the following underlying components MUST be supported:

• KDF: KMAC128-KDF using id-kmac128 or HMAC with SHA2-256 using id-alg-hkdf-with-sha256

• Key wrapping: 128-bit AES key wrapping using id-aes128-wrap

For ML-KEM-768, the following underlying components MUST be supported:

• KDF: KMAC256-KDF using id-kmac256 or HMAC with SHA2-512 using id-alg-hkdf-with-sha512

• Key wrapping: 256-bit AES key wrapping using id-aes256-wrap

For ML-KEM-1024, the following underlying components MUST be supported:

• KDF: KMAC256-KDF using id-kmac256 or HMAC with SHA2-512 using id-alg-hkdf-with-sha512

• Key wrapping: 256-bit AES key wrapping using id-aes256-wrap

The above object identifiers are reproduced for convenience in . An implementation MAY also support other key-derivation functions and other key-encryption algorithms. If underlying components other than those specified above are used, then the following KDF requirements are in effect in addition to those asserted in :

• ML-KEM-512 SHOULD be used with a KDF capable of outputting a key with at least 128 bits of security and with a key wrapping algorithm with a key length of at least 128 bits.

• ML-KEM-768 SHOULD be used with a KDF capable of outputting a key with at least 192 bits of security and with a key wrapping algorithm with a key length of at least 192 bits.

• ML-KEM-1024 SHOULD be used with a KDF capable of outputting a key with at least 256 bits of security and with a key wrapping algorithm with a key length of at least 256 bits.

Certificate Conventions The conventions specified in this section augment . A recipient who employs the ML-KEM algorithm with a certificate MUST identify the public key in the certificate using the id-ML-KEM-512, id-ML-KEM-768, or id-ML-KEM-1024 object identifiers following the conventions specified in and reproduced in . In particular, the key usage certificate extension MUST only contain keyEncipherment (Section 4.2.1.3 of ).

SMIME Capabilities Attribute Conventions Section 2.5.2 of 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 ML-KEM algorithm identifiers. The SMIMECapability SEQUENCE representing the ML-KEM algorithm MUST include one of the ML-KEM object identifiers in the capabilityID field. When the one of the ML-KEM object identifiers appears in the capabilityID field, the parameters MUST NOT be present.

Identifiers All identifiers used by ML-KEM in CMS are defined elsewhere but reproduced here for convenience:

Security Considerations [EDNOTE: many of the security considerations below apply to ML-KEM in general and are not specific to ML-KEM within CMS. As this document and draft-ietf-lamps-kyber-certificates approach WGLC, the two Security Consideration sections should be harmonized and duplicate text removed.] The Security Considerations sections of and apply to this specification as well. The ML-KEM variant and the underlying components need to be selected consistent with the desired security level. Several security levels have been identified in the NIST SP 800-57 Part 1 . To achieve 128-bit security, ML-KEM-512 SHOULD be used, the key-derivation function SHOULD provide at least 128 bits of security, and the symmetric key-encryption algorithm SHOULD be AES Key Wrap with a 128-bit key. To achieve 192-bit security, ML-KEM-768 SHOULD be used, the key-derivation function SHOULD provide at least 192 bits of security, and the symmetric key-encryption algorithm SHOULD be AES Key Wrap with a 192-bit key or larger. In this case AES Key Wrap with a 256-bit key is typically used because AES-192 is not as commonly deployed. To achieve 256-bit security, ML-KEM-1024 SHOULD be used, the key-derivation function SHOULD provide at least 256 bits of security, and the symmetric key-encryption algorithm SHOULD be AES Key Wrap with a 256-bit key. Provided all inputs are well-formed, the key establishment procedure of ML-KEM will never explicitly fail. Specifically, the ML-KEM.Encaps and ML-KEM.Decaps algorithms from will always output a value with the same data type as a shared secret key, and will never output an error or failure symbol. However, it is possible (though extremely unlikely) that the process will fail in the sense that ML-KEM.Encaps and ML-KEM.Decaps will produce different outputs, even though both of them are behaving honestly and no adversarial interference is present. In this case, the sender and recipient clearly did not succeed in producing a shared secret key. This event is called a decapsulation failure. Estimates for the decapsulation failure probability (or rate) for each of the ML-KEM parameter sets are provided in Table 1 [EDNOTE: make sure this doesn't change] of and reproduced here in . ML-KEM decapsulation failures rates

Parameter set	Decapsulation failure rate
ML-KEM-512	2^(-139)
ML-KEM-768	2^(-164)
ML-KEM-1024	2^(-174)

Implementations MUST protect the ML-KEM private key, the key-encryption key, the content-encryption key, message-authentication key, and the content-authenticated-encryption key. Disclosure of the ML-KEM private key could result in the compromise of all messages protected with that key. Disclosure of the key-encryption key, the content- encryption key, or the content-authenticated-encryption key could result in 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 security of the ML-KEM algorithm depends on a quality random number generator. For further discussion on random number generation, see . ML-KEM encapsulation and decapsulation only outputs a shared secret and ciphertext. Implementations SHOULD 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 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. Parties MAY gain assurance that implementations are correct through formal implementation validation, such as the NIST Cryptographic Module Validation Program (CMVP) .

IANA Considerations None. Within the CMS, algorithms are identified by object identifiers (OIDs). All of the OIDs used in this document were assigned in other IETF documents, in ISO/IEC standards documents, by the National Institute of Standards and Technology (NIST).

Acknowledgements This document borrows heavily from , , and . Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - RFC8411. Thanks to Carl Wallace and Jonathan Hammel for the detailed review and Carl Wallace for interoperability testing.

References Normative References n.d. National Institute of Standards and Technology (NIST) Vigil Security, LLC Entrust DigiCert, Inc. 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. 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 the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] 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. Vigil Security, LLC This document describes the conventions for using the one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). The SHA3 family can be used as a message digest algorithm, as part of a signature algorithm, as part of a message authentication code, or part of a key derivation function. 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] sn3rd AWS AWS Cloudflare Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also known as Kyber, is a key-encapsulation mechanism (KEM). This document specifies algorithm identifiers and ASN.1 encoding format for ML-KEM in public key certificates. The encoding for public and private keys are also provided. [EDNOTE: This document is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] 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. Informative References National Institute of Standards and Technology National Institute of Standards and Technology Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Vigil Security, LLC sn3rd 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 XXXX. This document obsoletes RFC 5990. RFC EDITOR: Please replace XXXX with the RFC number assigned to draft-ietf-lamps-cms-kemri. Amazon Web Services Amazon Web Services [EDNOTE: The intention of this draft is to get IANA KE codepoints for ML-KEM. It could be a standards track draft given that ML-KEM will see a lot of adoption, an AD sponsored draft, or even an individual stable draft which gets codepoints from Expert Review. The approach is to be decided by the IPSECME WG. ] NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM.

ASN.1 Module RFC EDITOR: Please replace TBD2 with the value assigned by IANA during the publication of .

Examples

Revision History [EDNOTE: remove before publishing]

• draft-ietf-lamps-cms-kyber-04:
  • Add HMAC with SHA2 KDF.
  • Address Jonathan Hammell's review:
    • Remove section introducing KEMs, move relevant bits to ML-KEM section
    • Remove kemri processing summary, move relevant bits elsewhere
    • Minor editorial changes
  • ASN.1 module
• draft-ietf-lamps-cms-kyber-03:
  • Switch MTI KDF from HKDF to KMAC.
• draft-ietf-lamps-cms-kyber-02:
  • Rearrange and rewrite to align with rfc5990bis and I-D.ietf-lamps-cms-kemri
  • Move Revision History to end to avoid renumbering later
  • Add Security Considerations
• draft-ietf-lamps-cms-kyber-01:
  • Details of the KEMRecipientInfo content when using Kyber;
  • Editorial changes.
• draft-ietf-lamps-cms-kyber-00:
  • Use of KEMRecipientInfo to communicate algorithm info;
  • Editorial changes.