Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
Extracted elements (19)
FIPS 203 Algorithm 19 does not make seed values available to callers for serialization. This document proposes Algorithm 19b as an extension that returns (ek, dk, d, z), and promotes Algorithm 16 (ML-KEM.KeyGen_internal) to a 'main algorithm' for external use in expanding keys from seeds.
The CHOICE of three private key formats (seed, expandedKey, both) provides interoperability: some implementations want to retain only the compact 64-byte seed while others only support the expanded format. The 'both' format bridges these without forcing a single representation.
Unlike other private key compression methods, expanding a private key from a seed is a one-way function: once the full key is expanded and the seed discarded, the seed cannot be recreated. For this reason, implementations are RECOMMENDED to retain and export the seed even when also exporting the expanded private key.
ML-KEM and Kyber (the pre-standardization version) are not compatible. Implementations MUST NOT treat Kyber keys or ciphertexts as interchangeable with ML-KEM.
ML-KEM certificates can only be used as end-entity identity certificates in TLS and would require significant protocol updates (e.g., KEM-TLS). They are not directly usable as TLS server certificates under current TLS 1.3.
If the keyUsage extension is present in certificates carrying an ML-KEM public key, then keyEncipherment MUST be the only key usage bit set. No other key usage bits are permitted for id-alg-ml-kem-* certificates.
Implementations MUST use ASN.1 tag values to parse the private key CHOICE: context-specific [0] (raw value 0x80) for seed, OCTET STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both. Heuristics such as length of the enclosing OCTET STRING MUST NOT be used.
The AlgorithmIdentifier for an ML-KEM public key MUST use one of the id-alg-ml-kem OIDs (id-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024) assigned by NIST based on the security level. The parameters field of the AlgorithmIdentifier MUST be absent.
The seed-only private key 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) with the first 32 octets as d and the remaining 32 octets as z.
When receiving a private key containing an expandedKey, a 'hash check' as stipulated in FIPS 203 Section 7.3 MUST be performed before use. Type and length checks are satisfied by conformance to this standard.
When receiving a private key containing both the seed and the expandedKey, the recipient SHOULD perform a seed consistency check by regenerating the expanded form via ML-KEM.KeyGen_internal(d,z) and comparing it bytewise. If inconsistent, the recipient MUST reject the private key as malformed.
ML-KEM private keys are encoded as a DER CHOICE with three alternatives: seed (context-specific [0] implicit tag, 64 octets for all levels), expandedKey (OCTET STRING, size varies by level), and both (SEQUENCE containing seed and expandedKey). All three are wrapped in the privateKey field of OneAsymmetricKey (RFC 5958).
Three ML-KEM OIDs are defined under the NIST kems arc (2.16.840.1.101.3.4.4): id-alg-ml-kem-512 ({ kems 1 }), id-alg-ml-kem-768 ({ kems 2 }), and id-alg-ml-kem-1024 ({ kems 3 }). These identify the three NIST PQC security levels.
Three NIST PQC security levels are supported. ML-KEM-512 targets Level 1 (AES-128 equivalent), ML-KEM-768 targets Level 3 (AES-192 equivalent), and ML-KEM-1024 targets Level 5 (AES-256 equivalent). All parameter sets produce a 32-byte shared secret; ciphertext sizes are 768, 1088, and 1568 bytes respectively.
IANA has assigned OID 121 with description 'id-mod-x509-ml-kem-2025' in the 'SMI Security for PKIX Module Identifier' registry (1.3.6.1.5.5.7.0) for the ASN.1 module defined in this document.
Per [KEMMY24], ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT-secure when using the expanded private key format, but is neither MAL-BIND-K-CT nor MAL-BIND-K-PK secure. Using the 64-byte seed format provides a step up and additionally provides MAL-BIND-K-CT security, though MAL-BIND-K-PK security is still not achieved.
Protection of the private key (seed) is vital. Disclosure enables masquerades. The generation of private keys relies on a CSPRNG; inadequate PRNGs can result in little or no security, as an attacker may find it much easier to reproduce the PRNG environment than brute-force the full key space.
ML-KEM public keys are encoded as raw byte streams with no ASN.1 wrapping in subjectPublicKey. Sizes are fixed per parameter set: ML-KEM-512 is 800 octets, ML-KEM-768 is 1184 octets, and ML-KEM-1024 is 1568 octets.
The seed format is a fixed 64-byte OCTET STRING (66 bytes total with 0x8040 tag and length) for all security levels. The expandedKey sizes are: ML-KEM-512 = 1632 octets, ML-KEM-768 = 2400 octets, ML-KEM-1024 = 3168 octets.