]> sn3rd

sean@sn3rd.com

AWS

kpanos@amazon.com

AWS

jakemas@amazon.com

Cloudflare

bas@westerbaan.name

SEC LAMPS ML-KEM Kyber KEM Certificate X.509 PKIX The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document describes the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also described. 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 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 The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) standardized in is a quantum-resistant key-encapsulation mechanism (KEM) standardized by the US National Institute of Standards and Technology (NIST) PQC Project . Prior to standardization, the earlier versions of the mechanism were known as Kyber. ML-KEM and Kyber are not compatible. This document specifies the use of ML-KEM in Public Key Infrastructure X.509 (PKIX) certificates at three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, using object identifiers assigned by NIST. The private key format is also specified.

Applicability Statement ML-KEM certificates are used in protocols where the public key is used to generate and encapsulate a shared secret used to derive a symmetric key used to encrypt a payload; see . To be used in TLS, ML-KEM certificates could only be used as end-entity identity certificates and would require significant updates to the protocol; see .

Conventions and Definitions 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.

Algorithm Identifiers The AlgorithmIdentifier type is defined in as follows: The fields in AlgorithmIdentifier have the following meanings:

• algorithm identifies the cryptographic algorithm with an object identifier.
• parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field.

The AlgorithmIdentifier for an ML-KEM public key MUST use one of the id-alg-ml-kem object identifiers listed below, based on the security level. The parameters field of the AlgorithmIdentifier for the ML-KEM public key MUST be absent. When any of the ML-KEM AlgorithmIdentifiers appear in the SubjectPublicKeyInfo field of an X.509 certificate, the key usage certificate extension MUST only contain keyEncipherment . No additional encoding of the ML-KEM public key value is applied in the SubjectPublicKeyInfo field of an X.509 certificate . However, whenever it appears outside of a certificate, it MAY be encoded as an OCTET STRING by using the ML-KEM-PublicKey type. No additional encoding of the ML-KEM private key value is applied in the PrivateKeyInfo field of the OneAsymmetricKey type of an Asymmetric Key Package . However, whenever it appears outside of a Asymmetric Key Package, it MAY be encoded as an OCTET STRING by using the ML-KEM-PrivateKey type.

Subject Public Key Fields In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: The fields in SubjectPublicKeyInfo have the following meaning:

• algorithm is the algorithm identifier and parameters for the public key (see above).
• subjectPublicKey contains the byte stream of the public key.

contains examples for ML-KEM public keys encoded using the textual encoding defined in .

Private Key Format In short, an ML-KEM private key is encoded by storing its 64-octet seed in the privateKey field as follows. specifies two formats for an ML-KEM private key: a 64-octet seed and an (expanded) private key, which is referred to as the decapsulation key. The expanded private key (and public key) is computed from the seed using ML-KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as d and the remaining 32 octets as z. A keypair is generated by sampling 64 octets uniformly at random for the seed (private key) from a cryptographically secure pseudorandom number generator (CSPRNGs). The public key can then be computed using ML-KEM.KeyGen_internal(d,z) as described earlier. "Asymmetric Key Packages" describes how to encode a private key in a structure that both identifies which algorithm the private key is for and allows for the public key and additional attributes about the key to be included as well. For illustration, the ASN.1 structure OneAsymmetricKey is replicated below. When used in a OneAsymmetricKey type, the privateKey OCTET STRING contains the raw octet string encoding of the 64-octet seed. The publicKey field SHOULD be omitted because the public key can be computed as noted earlier in this section. contains examples for ML-KEM private keys encoded using the textual encoding defined in .

Implementation Considerations Though section 7.1 of mentions the potential to save seed values for future expansion, Algorithm 19 does not make the seed values available to a caller for serialization. Similarly, the algorithm that expands seed values is not listed as one of the "main algorithms" and features "internal" in the name even though it is clear that it is allowed to be exposed externally for the purposes of expanding a key from a seed. Below are possible ways to extend the APIs defined in to support serialization of seed values as private keys. To support serialization of seed values as private keys, let Algorithm 19b denote the same procedure as Algorithm 19 in except it returns (ek, dk, d, z) on line 7. Additionally, Algorithm 16 should be promoted to be a "main algorithm" for external use in expanding seed values. Note also that unlike other private key compression methods in other algorithms, expanding a private key from a seed is a one-way function, meaning that once a full key is expanded from seed and the seed discarded, the seed cannot be re-created even if the full expanded private key is available. For this reason it is RECOMMENDED that implementations retain and export the seed, even when also exporting the expanded key.

Security Considerations The Security Considerations section of applies to this specification as well. Protection of the private-key information, i.e., the seed, is vital to public-key cryptography. Disclosure of the private-key material to another entity can lead to masquerades. For ML-KEM specific security considerations refer to . The generation of private keys relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate these values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult, and offers important guidance in this area. ML-KEM key generation as standardized in has specific requirements around randomness generation, described in section 3.3, 'Randomness generation'. Many protocols only rely on the IND-CCA security of a KEM. Some (implicitly) require further binding properties, formalized in . The private key format influences these binding properties. Per , ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT-secure when using the expanded private key format, but not MAL-BIND-K-CT nor MAL-BIND-K-PK. Using the 64-byte seed format provides a step up in binding security, additionally providing MAL-BIND-K-CT security, but still not MAL-BIND-K-PK. For more guidance, see .

IANA Considerations For the ASN.1 Module in , IANA is requested to assign an object identifier (OID) for the module identifier (TBD) with a Description of "id-mod-x509-ml-kem-2024". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

References Normative References ITU-T ITU-T National Institute of Standards and Technology (U.S.) 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] 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. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] 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. Informative References CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security National Institute of Standards and Technology (NIST) CryptoNext Security Entrust Limited CryptoNext Security Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameters sets for the ML-KEM algorithm are specified by 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. PQShield Brave Software Radboud University and MPI-SP University of Waterloo This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Cisco Systems National Institute of Standards and Technology Ericsson Quantinuum Arqit Quantum Inc NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM - that is, what problem it solves, and how to use it securely. 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. AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described.

ASN.1 Module This appendix includes the ASN.1 module for the ML-KEM. Note that as per , certificates use the Distinguished Encoding Rules; see . This module imports objects from and .

Parameter Set Security and Sizes Instead of defining the strength of a quantum algorithm in a traditional manner using the imprecise notion of bits of security, NIST has defined security levels by picking a reference scheme, which NIST expects to offer notable levels of resistance to both quantum and classical attack. To wit, a KEM algorithm that achieves NIST PQC security must require computational resources to break IND-CCA security comparable or greater than that required for key search on AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference. Mapping between NIST Security Level, ML-KEM parameter set, and sizes in bytes

Level	Parameter Set	Encap. Key	Decap. Key	Ciphertext	Secret
1	ML-KEM-512	800	1632	768	32
3	ML-KEM-768	1184	2400	1952	32
5	ML-KEM-1024	1568	3168	2592	32

Examples This appendix contains examples of ML-KEM public keys, private keys and certificates.

Example Private Key The following is an example of a ML-KEM-512 private key with hex seed 0001…3f: The following is an example of a ML-KEM-768 private key from the same seed. The following is an example of a ML-KEM-1024 private key from the same seed.

Example Public Key The following is the ML-KEM-512 public key corresponding to the private key in the previous section. The following is the ML-KEM-768 public key corresponding to the private key in the previous section. The following is the ML-KEM-1024 public key corresponding to the private key in the previous section.

Example Certificates The following is the ML-KEM-512 certificate that corresponding to the public key in the previous section signed with the ML-DSA-44 private key from . The following is the ML-KEM-768 certificate that corresponding to the public key in the previous section signed with the ML-DSA-65 private key from . The following is the ML-KEM-1024 certificate that corresponding to the public key in the previous section signed with the ML-DSA-87 private key from .

Acknowledgments TODO acknowledge.