]> 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.

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.

The PUBLIC-KEY ASN.1 type for ML-KEM are defined here: When an ML-KEM public key appears outside of a SubjectPublicKeyInfo type in an environment that uses ASN.1 encoding, it can be encoded as an OCTET STRING by using the ML-KEM-512-PublicKey, ML-KEM-768-PublicKey, ML-KEM-1024-PublicKey types corresponding to the correct key size. describes the Asymmetric Key Package's OneAsymmetricKey type for encoding asymmetric keypairs. When an ML-KEM private key or keypair is encoded as a OneAsymmetricKey, it follows the description in . When the ML-KEM private key appears outside of an Asymmetric Key Package in an environment that uses ASN.1 encoding, it can be encoded using one of the the ML-KEM-PrivateKey CHOICE formats defined in . The seed format is RECOMMENDED as it efficiently stores both the private and public key. contains examples for ML-KEM public keys encoded using the textual encoding defined in .

Key Usage Bits The intended application for the key is indicated in the keyUsage certificate extension; see . If the keyUsage extension is present in a certificate that indicates id-alg-ml-kem-* in the SubjectPublicKeyInfo, then keyEncipherment MUST be the only key usage set.

Private Key Format 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. If the expanded private key is generated without exporting the seed, ML-KEM.KeyGen() (algorithm 19), which combines seed generation with ML-KEM.KeyGen_internal(d,z), is used. 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. For ML-KEM private keys, the privateKey field in OneAsymmetricKey contains one of the following DER-encoded CHOICE structures. The seed format is a fixed 64 byte OCTET STRING (66 bytes total with the 0x8040 tag and length) for all security levels, while the expandedKey and both formats vary in size by security level: The CHOICE allows three representations of the private key:

• The seed format (tag [0]) contains just the 64-byte seed value from which both the expanded private key and public key can be derived using ML-KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as d and the remaining 32 octets as z.
• The expandedKey format contains the expanded private key that was derived from the seed. If the seed is not exported, both the expanded private key and public key can be derived using ML-KEM.KeyGen() (algorithm 16).
• The both format contains both the seed and expanded private key, allowing for interoperability; some may want to use and retain the seed and others may only support expanded private keys.

When encoding an ML-KEM private key in a OneAsymmetricKey object, any of these three formats may be used, though the seed format is RECOMMENDED for storage efficiency. The privateKeyAlgorithm field uses the AlgorithmIdentifier structure with the appropriate OID as defined in . If present, the publicKey field will hold the encoded public key as defined in . NOTE: While the private key can be stored in multiple formats, the seed-only format is RECOMMENDED as it is the most compact representation. Both the expanded private key and the public key can be deterministically derived 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. Alternatively, the public key can be extracted from the extended private key. While the publicKey field and expandedKey format are technically redundant when using the seed-only format, they MAY be included to enable keypair consistency checks during import operations. When parsing the private key, the ASN.1 tag explicitly indicates which variant of CHOICE is present. Implementations should use tag UNIVERSAL IMPLICIT [0] (raw value 0x80) for seed, OCTET STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both to parse the private key, rather than any other heuristic like length of the enclosing OCTET STRING. 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 private key.

Private Key Consistency Tesing When receiving a private key that contains both the seed and the expandedKey, the recipient SHOULD perform a seed consistency check to ensure that the sender properly generated the private key. Recipients that do not perform this seed consistency check avoid keygen and compare operations, but are unable to ensure that the seed and expandedKey match. If the check is done and the seed and the expandedKey are not consistent, the recipient MUST reject the private key as malformed. When receiving a private key that contains an expandedKey, stipulates in section 7.3 that before use, a "hash check" MUST be performed. That section stipulates two other checks on the type and length of the expandedKey which are ensured by this standard. The seed consistency check consists of regenerating the expanded form from the seed via ML-KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as d and the remaining 32 octets as z and ensuring it is bytewise equal to the value presented in the private key. includes some examples of inconsistent seeds and expanded private keys.

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-2025". 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, certificates, and inconsistent seed and expanded private keys.

Example Private Keys The following examples show ML-KEM private keys in different formats, all derived from the same seed 000102...1e1f. For each security level, we show the seed-only format (using a context-specific [0] primitive tag with an implicit encoding of OCTET STRING), the expanded format, and both formats together. NOTE: All examples use the same seed value, showing how the same seed produces different expanded private keys for each security level.

ML-KEM-512 Private Key Examples Each of the examples includes the textual encoding followed by the so-called "pretty print"; the private keys are the same.

Seed Format

Expanded Format

Both Format

ML-KEM-768 Private Key Examples Each of the examples includes the textual encoding followed by the so-called "pretty print"; the private keys are the same.

Seed Format

Expanded Format

Both Format

ML-KEM-1024 Private Key Examples Each of the examples includes the textual encoding followed by the so-called "pretty print"; the private keys are the same.

Seed Format

Expanded Format

Both Format

Example Public Keys The following is the ML-KEM-512 public key corresponding to the private key in the previous section. The textual encoding is followed by the so-called "pretty print"; the public keys are the same. The following is the ML-KEM-768 public key corresponding to the private key in the previous section. The textual encoding is followed by the so-called "pretty print"; the public keys are the same. The following is the ML-KEM-1024 public key corresponding to the private key in the previous section. The textual encoding is followed by the so-called "pretty print"; the public keys are the same.

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 textual encoding is followed by the so-called "pretty print"; the certificates are the same. 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 textual encoding is followed by the so-called "pretty print"; the certificates are the same. 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 . The textual encoding is followed by the so-called "pretty print"; the certificates are the same.

Examples of Bad Private Keys The following examples demonstrate inconsistent seed and expanded private keys.

ML-KEM Inconsistent Seed and Expanded Private Keys Four ML-KEM-512-PrivateKey examples of inconsistent seed and expanded private keys follow:

1. The first ML-KEM-512-PrivateKey example includes the both CHOICE , i.e., both seed and expandedKey are included. The seed and expanded values can be checked for inconsistencies.
2. The second ML-KEM-512-PrivateKey example includes only expandedKey. The expanded private key has a mutated s_0 and a valid public key hash, but a pairwise consistency check would find that the public key fails to match private.
3. The third ML-KEM-512-PrivateKey example includes only expandedKey. The expanded private key has a mutated H(ek); both a public key digest check and a pairwise consistency check should fail.
4. The fourth ML-KEM-512-PrivateKey example includes the both CHOICE , i.e., both seed and expandedKey are included. There is mismatch of the seed and expanded private key in only the z implicit rejection secret; here the private and public vectors match and the pairwise consistency check passes, but z is different.

The following is the first example: The following is the second example: The following is the third example: The following is the fourth example:

Acknowledgments The authors wish to thank the following people for their contributions to this document: Deirdre Connolly, Viktor Dukhovni, Alicja Kario, Russ Housley, Mike Ounsworth, Daniel Van Geest, Thom Wiggers, and Carl Wallace. In addition, we would like to thank those who contributed to the private key format discussion: Tony Arcieri, Bob Beck, Dmitry Belyavskiy, David Benjamin, Daniel Bernstein, Uri Blumenthal, Theo Buehler, Stephen Farrell, Jean-Pierre Fiset, Scott Fluhrer, Alex Gaynor, John Gray, Peter Gutmann, David Hook, Tim Hudson, Paul Kehrer, John Kemp, Watson Ladd, Adam Langley, John Mattsson, Damien Miller, Robert Relyea, Michael Richardson, Markku-Juhani O. Saarinen, Rich Salz, Roland Shoemaker, Sophie Schmieg, Simo Sorce, Michael St. Johns, Falko Strenzke, Filippo Valsorda, and Wei-Jun Wang.