rfc9935v1.txt		rfc9935.txt
	skipping to change at line 17 ¶		skipping to change at line 17 ¶
	B. E. Westerbaan		B. E. Westerbaan
	Cloudflare		Cloudflare
	February 2026		February 2026
	Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the		Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the
	Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)		Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
	Abstract		Abstract
	The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a		The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a
	quantum-resistant Key Encapsulation Mechanism (KEM). This document		quantum-resistant Key Encapsulation Mechanism. This document
	specifies the conventions for using the ML-KEM in X.509 Public Key		specifies the conventions for using the ML-KEM in X.509 Public Key
	Infrastructure. The conventions for the subject public keys and		Infrastructure. The conventions for the subject public keys and
	private keys are also specified.		private keys are also specified.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	skipping to change at line 327 ¶		skipping to change at line 327 ¶
	allowing for interoperability; some may want to use and retain the		allowing for interoperability; some may want to use and retain the
	seed and others may only support expanded private keys.		seed and others may only support expanded private keys.
	The privateKeyAlgorithm field uses the AlgorithmIdentifier structure		The privateKeyAlgorithm field uses the AlgorithmIdentifier structure
	with the appropriate OID as defined in Section 3.		with the appropriate OID as defined in Section 3.
	The publicKey field contains the byte stream of the public key. If		The publicKey field contains the byte stream of the public key. If
	present, the publicKey field will hold the encoded public key as		present, the publicKey field will hold the encoded public key as
	defined in Section 4.		defined in Section 4.
	NOTE: While the private key can be stored in multiple formats, the		Note that while the private key can be stored in multiple formats,
	seed-only format is RECOMMENDED, as it is the most compact		the seed-only format is RECOMMENDED, as it is the most compact
	representation. Both the expanded private key and the public key can		representation. Both the expanded private key and the public key can
	be deterministically derived from the seed using ML-		be deterministically derived from the seed using ML-
	KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as		KEM.KeyGen_internal(d,z) (algorithm 16) using the first 32 octets as
	_d_ and the remaining 32 octets as _z_. Alternatively, the public		_d_ and the remaining 32 octets as _z_. Alternatively, the public
	key can be extracted from the expanded private key. While the		key can be extracted from the expanded private key. While the
	publicKey field and expandedKey format are technically redundant when		publicKey field and expandedKey format are technically redundant when
	using the seed-only format, they MAY be included to enable key pair		using the seed-only format, they MAY be included to enable key pair
	consistency checks during import operations.		consistency checks during import operations.
	When parsing the private key, the ASN.1 tag explicitly indicates		When parsing the private key, the ASN.1 tag explicitly indicates
	skipping to change at line 667 ¶		skipping to change at line 667 ¶
	ML-KEM-768-PublicKey ::= OCTET STRING (SIZE (1184))		ML-KEM-768-PublicKey ::= OCTET STRING (SIZE (1184))
	ML-KEM-1024-PublicKey ::= OCTET STRING (SIZE (1568))		ML-KEM-1024-PublicKey ::= OCTET STRING (SIZE (1568))
	END		END
	<CODE ENDS>		<CODE ENDS>
	Appendix B. Parameter Set Security and Sizes		Appendix B. Parameter Set Security and Sizes
	Instead of defining the strength of a quantum algorithm in a		Instead of defining the strength of a quantum algorithm in a typical
	traditional manner using the imprecise notion of bits of security,		manner using the imprecise notion of bits of security, NIST has
	NIST has defined security levels by picking a reference scheme, which		defined security levels by picking a reference scheme, which is
	is expected to offer notable levels of resistance to both quantum and		expected to offer notable levels of resistance to both quantum and
	classical attacks. To wit, a KEM algorithm that achieves NIST PQC		classical attacks. To wit, a KEM algorithm that achieves NIST PQC
	security must require computational resources to break IND-CCA		security must require computational resources to break IND-CCA
	security comparable or greater than that required for key search on		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.		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		Levels 2 and 4 use collision search for SHA-256 and SHA-384 as
	reference.		reference.
	+=======+===============+========+========+============+========+		+=======+===============+========+========+============+========+
	| Level | Parameter Set | Encap. | Decap. | Ciphertext | Secret |		| Level | Parameter Set | Encap. | Decap. | Ciphertext | Secret |
	| | | Key | Key | | |		| | | Key | Key | | |
	skipping to change at line 705 ¶		skipping to change at line 705 ¶
	certificates, and inconsistent seed and expanded private keys.		certificates, and inconsistent seed and expanded private keys.
	C.1. Example Private Keys		C.1. Example Private Keys
	The following examples show ML-KEM private keys in different formats,		The following examples show ML-KEM private keys in different formats,
	all derived from the same seed 000102...1e1f. For each security		all derived from the same seed 000102...1e1f. For each security
	level, we show the seed-only format (using a context-specific [0]		level, we show the seed-only format (using a context-specific [0]
	primitive tag with an implicit encoding of OCTET STRING), the		primitive tag with an implicit encoding of OCTET STRING), the
	expanded format, and both formats together.		expanded format, and both formats together.
	NOTE: All examples use the same seed value, showing how the same seed		| NOTE: All examples use the same seed value, showing how the
	produces different expanded private keys for each security level.		| same seed produces different expanded private keys for each
			| security level.
	C.1.1. ML-KEM-512 Private Key Examples		C.1.1. ML-KEM-512 Private Key Examples
	Each of the examples includes the textual encoding [RFC7468] followed		Each of the examples includes the textual encoding [RFC7468] followed
	by the so-called "pretty print"; the private keys are the same.		by the so-called "pretty print"; the private keys are the same.
	C.1.1.1. Seed Format		C.1.1.1. Seed Format
	-----BEGIN PRIVATE KEY-----		-----BEGIN PRIVATE KEY-----
	MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ		MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
End of changes. 4 change blocks.
	9 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48.