Diff: rfc9936.original

	rfc9936.original	rfc9936.txt


	LAMPS J. Prat	Internet Engineering Task Force (IETF) J. Prat
	Internet-Draft CryptoNext Security	Request for Comments: 9936 CryptoNext Security
	Intended status: Standards Track M. Ounsworth	Category: Standards Track M. Ounsworth
	Expires: 27 March 2026 Entrust	ISSN: 2070-1721 Entrust
	D. Van Geest	D. Van Geest
	CryptoNext Security	CryptoNext Security

	23 September 2025	February 2026

	Use of ML-KEM in the Cryptographic Message Syntax (CMS)	Use of ML-KEM in the Cryptographic Message Syntax (CMS)

	draft-ietf-lamps-cms-kyber-13

	Abstract	Abstract

	Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a	Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a

	quantum-resistant key-encapsulation mechanism (KEM). Three parameter	quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter
	sets for the ML-KEM algorithm are specified by the US National	sets for the ML-KEM algorithm are specified by the US National
	Institute of Standards and Technology (NIST) in FIPS 203. In order	Institute of Standards and Technology (NIST) in FIPS 203. In order
	of increasing security strength (and decreasing performance), these	of increasing security strength (and decreasing performance), these
	parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This	parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This
	document specifies the conventions for using ML-KEM with the	document specifies the conventions for using ML-KEM with the
	Cryptographic Message Syntax (CMS) using the KEMRecipientInfo	Cryptographic Message Syntax (CMS) using the KEMRecipientInfo
	structure defined in "Using Key Encapsulation Mechanism (KEM)	structure defined in "Using Key Encapsulation Mechanism (KEM)
	Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629).	Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629).


	About This Document

	This note is to be removed before publishing as an RFC.

	Status information for this document may be found at
	https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber/.

	Discussion of this document takes place on the Limited Additional
	Mechanisms for PKIX and SMIME (lamps) Working Group mailing list
	(mailto:spasm@ietf.org), which is archived at
	https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at
	https://www.ietf.org/mailman/listinfo/spasm/.

	Source for this draft and an issue tracker can be found at
	https://github.com/lamps-wg/cms-kyber.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	This Internet-Draft will expire on 27 March 2026.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9936.

	Copyright Notice	Copyright Notice


	Copyright (c) 2025 IETF Trust and the persons identified as the	Copyright (c) 2026 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal

	Provisions Relating to IETF Documents (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction
	1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3	1.1. Conventions and Terminology
	1.2. ML-KEM . . . . . . . . . . . . . . . . . . . . . . . . . 3	1.2. ML-KEM
	2. Use of the ML-KEM Algorithm in the CMS . . . . . . . . . . . 4	2. Use of the ML-KEM Algorithm in the CMS
	2.1. RecipientInfo Conventions . . . . . . . . . . . . . . . . 5	2.1. RecipientInfo Conventions
	2.2. Underlying Components . . . . . . . . . . . . . . . . . . 6	2.2. Underlying Components
	2.2.1. Use of the HKDF-based Key Derivation Function . . . . 6	2.2.1. Use of the HKDF-Based Key Derivation Function
	2.3. Certificate Conventions . . . . . . . . . . . . . . . . . 7	2.3. Certificate Conventions
	2.4. SMIME Capabilities Attribute Conventions . . . . . . . . 7	2.4. SMIME Capabilities Attribute Conventions
	3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 7	3. Identifiers
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8	4. Security Considerations
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9	5. IANA Considerations
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9	6. References
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9	6.1. Normative References
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9	6.2. Informative References
	7.2. Informative References . . . . . . . . . . . . . . . . . 11	Appendix A. ASN.1 Module
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12	Appendix B. Parameter Set Security and Sizes
	Appendix B. Parameter Set Security and Sizes . . . . . . . . . . 14	Appendix C. ML-KEM CMS Authenticated-Enveloped-Data Example
	Appendix C. ML-KEM CMS Authenticated-Enveloped-Data Example . . 15	C.1. Originator CMS Processing
	C.1. Originator CMS Processing . . . . . . . . . . . . . . . . 15	C.2. Recipient CMS Processing
	C.2. Recipient CMS Processing . . . . . . . . . . . . . . . . 19	Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20	Authors' Addresses

	1. Introduction	1. Introduction


	The Module Lattice Key Encapsulation Mechanism (ML-KEM) is an IND-	The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is an
	CCA2-secure Key Encapsulation Mechanism (KEM) standardized in	IND-CCA2-secure Key Encapsulation Mechanism (KEM) standardized in
	[FIPS203] by the NIST PQC Project [NIST-PQ]. ML-KEM is the name	[FIPS203] by the NIST PQC Project [NIST-PQ]. ML-KEM is the name
	given to the final standardized version and is incompatible with pre-	given to the final standardized version and is incompatible with pre-
	standards versions, often called "Kyber".	standards versions, often called "Kyber".

	[RFC9629] defines the KEMRecipientInfo structure for the use of KEM	[RFC9629] defines the KEMRecipientInfo structure for the use of KEM
	algorithms for the CMS enveloped-data content type, the CMS	algorithms for the CMS enveloped-data content type, the CMS
	authenticated-data content type, and the CMS authenticated-enveloped-	authenticated-data content type, and the CMS authenticated-enveloped-
	data content type. This document specifies the direct use of ML-KEM	data content type. This document specifies the direct use of ML-KEM
	in the KEMRecipientInfo structure using each of the three parameter	in the KEMRecipientInfo structure using each of the three parameter

	sets from [FIPS203], namely MK-KEM-512, ML-KEM-768, and ML-KEM-1024.	sets from [FIPS203], namely ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
	It does not address or preclude the use of ML-KEM as part of any	It does not address or preclude the use of ML-KEM as part of any
	hybrid scheme.	hybrid scheme.

	1.1. Conventions and Terminology	1.1. Conventions and Terminology

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in

	BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	1.2. ML-KEM	1.2. ML-KEM


	ML-KEM is a lattice-based key encapsulation mechanism using Module	ML-KEM is a lattice-based KEM using Module Learning with Errors as
	Learning with Errors as its underlying primitive, which is a	its underlying primitive, which is a structured lattices variant that
	structured lattices variant that offers good performance and	offers good performance and relatively small and balanced key and
	relatively small and balanced key and ciphertext sizes. ML-KEM was	ciphertext sizes. ML-KEM was standardized with three parameter sets:
	standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and	ML-KEM-512, ML-KEM-768, and ML-KEM-1024. The parameters for each of
	ML-KEM-1024. The parameters for each of the security levels were	the security levels were chosen to be at least as secure as a generic
	chosen to be at least as secure as a generic block cipher of 128,	block cipher of 128, 192, or 256 bits, respectively. Appendix B
	192, or 256 bits, respectively. Appendix B provides more information	provides more information on ML-KEM security levels and sizes.
	on ML-KEM security levels and sizes.

	All KEM algorithms provide three functions: KeyGen(), Encapsulate(),	All KEM algorithms provide three functions: KeyGen(), Encapsulate(),
	and Decapsulate().	and Decapsulate().

	The following summarizes these three functions for the ML-KEM	The following summarizes these three functions for the ML-KEM
	algorithm, referencing corresponding functions in [FIPS203]:	algorithm, referencing corresponding functions in [FIPS203]:

	KeyGen() -> (ek, dk): Generate the public encapsulation key (ek) and	KeyGen() -> (ek, dk): Generate the public encapsulation key (ek) and
	a private decapsulation key (dk). [FIPS203] specifies two formats	a private decapsulation key (dk). [FIPS203] specifies two formats
	for an ML-KEM private key: a 64-octet seed (d,z) and an (expanded)	for an ML-KEM private key: a 64-octet seed (d,z) and an (expanded)
	private decapsulation key (dk). Algorithm 19 (ML-KEM.KeyGen())	private decapsulation key (dk). Algorithm 19 (ML-KEM.KeyGen())
	from [FIPS203] generates the public encapsulation key (ek) and the	from [FIPS203] generates the public encapsulation key (ek) and the
	private decapsulation key (dk). As an alternative, when a seed	private decapsulation key (dk). As an alternative, when a seed
	(d,z) is generated first and then the seed is expanded to get the	(d,z) is generated first and then the seed is expanded to get the
	keys, algorithm 16 (ML-KEM.KeyGen_internal(d,z)) from [FIPS203]	keys, algorithm 16 (ML-KEM.KeyGen_internal(d,z)) from [FIPS203]

	expands the seed to ek and dk. See Section 6 of	expands the seed to ek and dk. See Section 6 of [RFC9935] for
	[I-D.ietf-lamps-kyber-certificates] for private key encoding	private key encoding considerations.
	considerations.

	Encapsulate(ek) -> (c, ss): Given the recipient's public key (ek),	Encapsulate(ek) -> (c, ss): Given the recipient's public key (ek),
	produce both a ciphertext (c) to be passed to the recipient and a	produce both a ciphertext (c) to be passed to the recipient and a
	shared secret (ss) for use by the originator. Algorithm 20 (ML-	shared secret (ss) for use by the originator. Algorithm 20 (ML-
	KEM.Encaps(ek)) from [FIPS203] is the encapsulation function for	KEM.Encaps(ek)) from [FIPS203] is the encapsulation function for
	ML-KEM.	ML-KEM.

	Decapsulate(dk, c) -> ss: Given the private key (dk) and the	Decapsulate(dk, c) -> ss: Given the private key (dk) and the
	ciphertext (c), produce the shared secret (ss) for the recipient.	ciphertext (c), produce the shared secret (ss) for the recipient.
	Algorithm 21 (ML-KEM.Decaps(dk,c)) from [FIPS203] is the	Algorithm 21 (ML-KEM.Decaps(dk,c)) from [FIPS203] is the
	decapsulation function for ML-KEM. If the private key is stored	decapsulation function for ML-KEM. If the private key is stored
	in seed form, ML-KEM.KeyGen_internal(d,z) may be needed as a first	in seed form, ML-KEM.KeyGen_internal(d,z) may be needed as a first

	step to compute dk. See Section 8 of	step to compute dk. See Section 8 of [RFC9935] for consistency
	[I-D.ietf-lamps-kyber-certificates] for consistency considerations	considerations if the private key was stored in both seed and
	if the private key was stored in both seed and expanded formats.	expanded formats.

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

	2. Use of the ML-KEM Algorithm in the CMS	2. Use of the ML-KEM Algorithm in the CMS

	The ML-KEM algorithm MAY be employed for one or more recipients in	The ML-KEM algorithm MAY be employed for one or more recipients in
	the CMS enveloped-data content type [RFC5652], the CMS authenticated-	the CMS enveloped-data content type [RFC5652], the CMS authenticated-
	data content type [RFC5652], or the CMS authenticated-enveloped-data	data content type [RFC5652], or the CMS authenticated-enveloped-data
	content type [RFC5083]. In each case, the KEMRecipientInfo [RFC9629]	content type [RFC5083]. In each case, the KEMRecipientInfo [RFC9629]

	skipping to change at page 5, line 14 ¶	skipping to change at line 173 ¶

	2.1. RecipientInfo Conventions	2.1. RecipientInfo Conventions

	When the ML-KEM algorithm is employed for a recipient, the	When the ML-KEM algorithm is employed for a recipient, the
	RecipientInfo alternative for that recipient MUST be	RecipientInfo alternative for that recipient MUST be
	OtherRecipientInfo using the KEMRecipientInfo structure as defined in	OtherRecipientInfo using the KEMRecipientInfo structure as defined in
	[RFC9629].	[RFC9629].

	The fields of the KEMRecipientInfo have the following meanings:	The fields of the KEMRecipientInfo have the following meanings:


	version is the syntax version number; it MUST be 0.	version
		The syntax version number; it MUST be 0.


	rid identifies the recipient's certificate or public key.	rid
		Identifies the recipient's certificate or public key.


	kem identifies the KEM algorithm; it MUST contain one of id-alg-	kem
	ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These	Identifies the KEM algorithm; it MUST contain one of id-alg-ml-
		kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These
	identifiers are reproduced in Section 3.	identifiers are reproduced in Section 3.


	kemct is the ciphertext produced for this recipient.	kemct
		The ciphertext produced for this recipient.


	kdf identifies the key-derivation algorithm. Note that the Key	kdf
		Identifies the key derivation algorithm. Note that the Key
	Derivation Function (KDF) used for CMS RecipientInfo process MAY	Derivation Function (KDF) used for CMS RecipientInfo process MAY
	be different than the KDF used within the ML-KEM algorithm.	be different than the KDF used within the ML-KEM algorithm.

	Implementations MUST support HKDF [RFC5869] with SHA-256	Implementations MUST support the HMAC-based Key Derivation
	[FIPS180], using the id-alg-hkdf-with-sha256 KDF object identifier	Function (HKDF) [RFC5869] with SHA-256 [FIPS180] using the id-alg-
	[RFC8619]. As specified in [RFC8619], the parameter field MUST be	hkdf-with-sha256 KDF object identifier (OID) [RFC8619]. As
	absent when this object identifier appears within the ASN.1 type	specified in [RFC8619], the parameter field MUST be absent when
	AlgorithmIdentifier. Implementations MAY support other KDFs as	this OID appears within the ASN.1 type AlgorithmIdentifier.
	well.	Implementations MAY support other KDFs as well.


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


	ukm is optional input to the key-derivation function. The secure	ukm
	use of ML-KEM in CMS does not depend on the use of a ukm value, so	Optional input to the KDF. The secure use of ML-KEM in CMS does
	this document does not place any requirements on this value. See	not depend on the use of a ukm value, so this document does not
	Section 3 of [RFC9629] for more information about the ukm	place any requirements on this value. See Section 3 of [RFC9629]
	parameter.	for more information about the ukm parameter.


	wrap identifies a key-encryption algorithm used to encrypt the	wrap
	content-encryption key. Implementations supporting ML-KEM-512	Identifies a key-encryption algorithm used to encrypt the content-
	MUST support the AES-Wrap-128 [RFC3394] key-encryption algorithm	encryption key. Implementations supporting ML-KEM-512 MUST
	using the id-aes128-wrap key-encryption algorithm object	support the AES-Wrap-128 [RFC3394] key-encryption algorithm using
	identifier [RFC3565]. Implementations supporting ML-KEM-768 or	the id-aes128-wrap key-encryption algorithm OID [RFC3565].
	ML-KEM-1024 MUST support the AES-Wrap-256 [RFC3394] key-encryption	Implementations supporting ML-KEM-768 or ML-KEM-1024 MUST support
	algorithm using the id-aes256-wrap key-encryption algorithm object	the AES-Wrap-256 [RFC3394] key-encryption algorithm using the id-
	identifier [RFC3565]. Implementations MAY support other key-	aes256-wrap key-encryption algorithm OID [RFC3565].
	encryption algorithms as well.	Implementations MAY support other key-encryption algorithms as
		well.

	Appendix C contains an example of establishing a content-encryption	Appendix C contains an example of establishing a content-encryption
	key using ML-KEM in the KEMRecipientInfo type.	key using ML-KEM in the KEMRecipientInfo type.

	2.2. Underlying Components	2.2. Underlying Components

	When ML-KEM is employed in the CMS, the underlying components used	When ML-KEM is employed in the CMS, the underlying components used
	within the KEMRecipientInfo structure SHOULD be consistent with a	within the KEMRecipientInfo structure SHOULD be consistent with a
	minimum desired security level. Several security levels have been	minimum desired security level. Several security levels have been

	identified in NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5].	identified in [NIST.SP.800-57pt1r5].

	If underlying components other than those specified in Section 2.1	If underlying components other than those specified in Section 2.1
	are used, then the following table gives the minimum requirements on	are used, then the following table gives the minimum requirements on
	the components used with ML-KEM in the KEMRecipientInfo type in order	the components used with ML-KEM in the KEMRecipientInfo type in order
	to satisfy the KDF and key wrapping algorithm requirements from	to satisfy the KDF and key wrapping algorithm requirements from
	Section 7 of [RFC9629]:	Section 7 of [RFC9629]:

	+==========+=============+==============+=====================+	+==========+=============+==============+=====================+

	\| Security \| Algorithm \| KDF preimage \| Symmetric key- \|	\| Security \| Algorithm \| KDF Preimage \| Symmetric Key- \|
	\| Strength \| \| strength \| encryption strength \|	\| Strength \| \| Strength \| Encryption Strength \|
	+==========+=============+==============+=====================+	+==========+=============+==============+=====================+
	\| 128-bit \| ML-KEM-512 \| 128-bit \| 128-bit \|	\| 128-bit \| ML-KEM-512 \| 128-bit \| 128-bit \|
	+----------+-------------+--------------+---------------------+	+----------+-------------+--------------+---------------------+
	\| 192-bit \| ML-KEM-768 \| 192-bit \| 192-bit (*) \|	\| 192-bit \| ML-KEM-768 \| 192-bit \| 192-bit (*) \|
	+----------+-------------+--------------+---------------------+	+----------+-------------+--------------+---------------------+
	\| 256-bit \| ML-KEM-1024 \| 256-bit \| 256-bit \|	\| 256-bit \| ML-KEM-1024 \| 256-bit \| 256-bit \|
	+----------+-------------+--------------+---------------------+	+----------+-------------+--------------+---------------------+


	Table 1: ML-KEM KEMRecipientInfo component security levels	Table 1: ML-KEM KEMRecipientInfo Component Security Levels

	(*) In the case of AES Key Wrap, a 256-bit key is typically used	(*) In the case of AES Key Wrap, a 256-bit key is typically used
	because AES-192 is not as commonly deployed.	because AES-192 is not as commonly deployed.


	2.2.1. Use of the HKDF-based Key Derivation Function	2.2.1. Use of the HKDF-Based Key Derivation Function

	The HKDF function is a composition of the HKDF-Extract and HKDF-	The HKDF function is a composition of the HKDF-Extract and HKDF-
	Expand functions.	Expand functions.

	HKDF(salt, IKM, info, L)	HKDF(salt, IKM, info, L)
	= HKDF-Expand(HKDF-Extract(salt, IKM), info, L)	= HKDF-Expand(HKDF-Extract(salt, IKM), info, L)


	When used with KEMRecipientInfo, the salt parameter is unused, that	When used with KEMRecipientInfo, the salt parameter is unused; that
	is it is the zero-length string "". The IKM, info and L parameters	is, it is the zero-length string "". The IKM, info, and L parameters
	correspond to the same KDF inputs from Section 5 of [RFC9629]. The	correspond to the same KDF inputs from Section 5 of [RFC9629]. The
	info parameter is independently generated by the originator and	info parameter is independently generated by the originator and
	recipient. Implementations MUST confirm that L is consistent with	recipient. Implementations MUST confirm that L is consistent with
	the key size of the key-encryption algorithm.	the key size of the key-encryption algorithm.

	2.3. Certificate Conventions	2.3. Certificate Conventions


	RFC 5280 [RFC5280] specifies the profile for using X.509 Certificates	[RFC5280] specifies the profile for using X.509 certificates in
	in Internet applications. A recipient static public key is needed	Internet applications. A recipient static public key is needed for
	for ML-KEM, and the originator obtains that public key from the	ML-KEM and the originator obtains that public key from the
	recipient's certificate. The conventions for carrying ML-KEM public	recipient's certificate. The conventions for carrying ML-KEM public

	keys are specified in [I-D.ietf-lamps-kyber-certificates].	keys are specified in [RFC9935].

	2.4. SMIME Capabilities Attribute Conventions	2.4. SMIME Capabilities Attribute Conventions

	Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to	Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to
	announce a partial list of algorithms that an S/MIME implementation	announce a partial list of algorithms that an S/MIME implementation
	can support. When constructing a CMS signed-data content type	can support. When constructing a CMS signed-data content type
	[RFC5652], a compliant implementation MAY include the	[RFC5652], a compliant implementation MAY include the
	SMIMECapabilities attribute that announces support for one or more of	SMIMECapabilities attribute that announces support for one or more of
	the ML-KEM algorithm identifiers.	the ML-KEM algorithm identifiers.

	The SMIMECapability SEQUENCE representing the ML-KEM algorithm MUST	The SMIMECapability SEQUENCE representing the ML-KEM algorithm MUST

	include one of the ML-KEM object identifiers in the capabilityID	include one of the ML-KEM OIDs in the capabilityID field. When one
	field. When one of the ML-KEM object identifiers appears in the	of the ML-KEM OIDs appears in the capabilityID field, the parameters
	capabilityID field, the parameters MUST NOT be present.	MUST NOT be present.

	3. Identifiers	3. Identifiers

	All identifiers used to indicate ML-KEM within the CMS are defined in	All identifiers used to indicate ML-KEM within the CMS are defined in

	[CSOR] and [RFC8619] but reproduced here for convenience:	[CSOR] and [RFC8619]; they are reproduced here for convenience:

	nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)	nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
	country(16) us(840) organization(1) gov(101) csor(3)	country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) }	nistAlgorithm(4) }
	kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 }	kems OBJECT IDENTIFIER ::= { nistAlgorithms 4 }

	id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }	id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }

	id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }	id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }


	skipping to change at page 8, line 7 ¶	skipping to change at line 315 ¶
	smime(16) alg(3) 28 }	smime(16) alg(3) 28 }

	aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)	aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
	organization(1) gov(101) csor(3) nistAlgorithms(4) 1 }	organization(1) gov(101) csor(3) nistAlgorithms(4) 1 }

	id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }	id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
	id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }	id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }

	4. Security Considerations	4. Security Considerations


	The Security Considerations sections of	The Security Considerations sections of [RFC9935] and [RFC9629] apply
	[I-D.ietf-lamps-kyber-certificates] and [RFC9629] apply to this	to this specification as well.
	specification as well.

	For ongoing discussions of ML-KEM-specific security considerations,	For ongoing discussions of ML-KEM-specific security considerations,

	refer to [I-D.sfluhrer-cfrg-ml-kem-security-considerations].	refer to [MLKEM-SEC-CONS].

	Implementations MUST protect the ML-KEM private key, the key-	Implementations MUST protect the ML-KEM private key, the key-
	encryption key, the content-encryption key, message-authentication	encryption key, the content-encryption key, message-authentication
	key, and the content-authenticated-encryption key. Of these keys,	key, and the content-authenticated-encryption key. Of these keys,
	all but the private key are ephemeral and MUST be wiped after use.	all but the private key are ephemeral and MUST be wiped after use.
	Disclosure of the ML-KEM private key could result in the compromise	Disclosure of the ML-KEM private key could result in the compromise
	of all messages protected with that key. Disclosure of the key-	of all messages protected with that key. Disclosure of the key-
	encryption key, the content-encryption key, or the content-	encryption key, the content-encryption key, or the content-

	authenticated-encryption key could result in compromise of the	authenticated-encryption key could result in the compromise of the
	associated encrypted content. Disclosure of the key-encryption key,	associated encrypted content. Disclosure of the key-encryption key,
	the message-authentication key, or the content-authenticated-	the message-authentication key, or the content-authenticated-
	encryption key could allow modification of the associated	encryption key could allow modification of the associated
	authenticated content.	authenticated content.

	Additional considerations related to key management may be found in	Additional considerations related to key management may be found in
	[NIST.SP.800-57pt1r5].	[NIST.SP.800-57pt1r5].

	The generation of private keys relies on random numbers, as does the	The generation of private keys relies on random numbers, as does the

	encapsulation function of ML-KEM. The use of inadequate pseudo-	encapsulation function of ML-KEM. The use of inadequate pseudorandom
	random number generators (PRNGs) to generate these values can result	number generators (PRNGs) to generate these values can result in
	in little or no security. In the case of key generation, a random	little or no security. In the case of key generation, a random
	32-byte seed is used to deterministically derive the key (with an	32-byte seed is used to deterministically derive the key (with an
	additional 32 bytes reserved as a rejection value). In the case of	additional 32 bytes reserved as a rejection value). In the case of
	encapsulation, a KEM is derived from the underlying ML-KEM public key	encapsulation, a KEM is derived from the underlying ML-KEM public key
	encryption algorithm by deterministically encrypting a random 32-byte	encryption algorithm by deterministically encrypting a random 32-byte

	message for the public key. If the random value is weakly-chosen,	message for the public key. If the random value is weakly chosen,
	then an attacker may find it much easier to reproduce the PRNG	then an attacker may find it much easier to reproduce the PRNG
	environment that produced the keys or ciphertext, searching the	environment that produced the keys or ciphertext, searching the
	resulting small set of possibilities for a matching public key or	resulting small set of possibilities for a matching public key or
	ciphertext value, rather than performing a more complex algorithmic	ciphertext value, rather than performing a more complex algorithmic
	attack against ML-KEM. The generation of quality random numbers is	attack against ML-KEM. The generation of quality random numbers is
	difficult; see Section 3.3 of [FIPS203] for some additional	difficult; see Section 3.3 of [FIPS203] for some additional
	information.	information.

	ML-KEM encapsulation and decapsulation only outputs a shared secret	ML-KEM encapsulation and decapsulation only outputs a shared secret
	and ciphertext. Implementations MUST NOT use intermediate values	and ciphertext. Implementations MUST NOT use intermediate values
	directly for any purpose.	directly for any purpose.

	Implementations SHOULD NOT reveal information about intermediate	Implementations SHOULD NOT reveal information about intermediate

	values or calculations, whether by timing or other "side channels",	values or calculations, whether by timing or other "side channels";
	otherwise an opponent may be able to determine information about the	otherwise, an opponent may be able to determine information about the
	keying data and/or the recipient's private key. Although not all	keying data and/or the recipient's private key. Although not all
	intermediate information may be useful to an opponent, it is	intermediate information may be useful to an opponent, it is
	preferable to conceal as much information as is practical, unless	preferable to conceal as much information as is practical, unless
	analysis specifically indicates that the information would not be	analysis specifically indicates that the information would not be
	useful to an opponent.	useful to an opponent.

	Generally, good cryptographic practice employs a given ML-KEM key	Generally, good cryptographic practice employs a given ML-KEM key
	pair in only one scheme. This practice avoids the risk that	pair in only one scheme. This practice avoids the risk that

	vulnerability in one scheme may compromise the security of the other,	vulnerability in one scheme may compromise the security of the other
	and may be essential to maintain provable security.	and may be essential to maintain provable security.

	Parties can gain assurance that implementations are correct through	Parties can gain assurance that implementations are correct through
	formal implementation validation, such as the NIST Cryptographic	formal implementation validation, such as the NIST Cryptographic
	Module Validation Program (CMVP) [CMVP].	Module Validation Program (CMVP) [CMVP].

	5. IANA Considerations	5. IANA Considerations


	For the ASN.1 Module in Appendix A, IANA is requested to assign an	For the ASN.1 Module in Appendix A, IANA has assigned an OID for the
	object identifier (OID) for the module identifier (TBD1) with a	module identifier (84) with a description of "id-mod-cms-ml-kem-2024"
	Description of "id-mod-cms-ml-kem-2024". The OID for the module	in the "SMI Security for S/MIME Module Identifier
	should be allocated in the "SMI Security for S/MIME Module	(1.2.840.113549.1.9.16.0)" registry.
	Identifier" registry (1.2.840.113549.1.9.16.0).

	6. Acknowledgements

	This document borrows heavily from [RFC9690], [FIPS203], and
	[I-D.kampanakis-ml-kem-ikev2]. Thanks go to the authors of those
	documents. "Copying always makes things easier and less error prone"
	- RFC8411.

	Thanks to Carl Wallace, Jonathan Hammel, and Sean Turner for the
	detailed review and Carl Wallace and Philippe Cece for
	interoperability testing for the examples.


	7. References	6. References


	7.1. Normative References	6.1. Normative References


	[CSOR] NIST, "Computer Security Objects Register", 20 August	[CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June
	2024, <https://csrc.nist.gov/projects/computer-security-	2025, <https://csrc.nist.gov/projects/computer-security-
	objects-register/algorithm-registration>.	objects-register/algorithm-registration>.


	[FIPS180] Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal	[FIPS180] NIST, "Secure Hash Standard", NIST FIPS 180-4,
	Information Processing Standards Publications 180-4,	DOI 10.6028/NIST.FIPS.180-4, August 2015,
	DOI 10.6028/NIST.FIPS.180-4, July 2015,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/	<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.180-4.pdf>.	NIST.FIPS.180-4.pdf>.


	[FIPS203] "Module-lattice-based key-encapsulation mechanism	[FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
	standard", National Institute of Standards and Technology	Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203,
	(U.S.), DOI 10.6028/nist.fips.203, August 2024,	August 2024, <https://doi.org/10.6028/NIST.FIPS.203>.
	<https://doi.org/10.6028/nist.fips.203>.

	[I-D.ietf-lamps-kyber-certificates]
	Turner, S., Kampanakis, P., Massimo, J., and B.
	Westerbaan, "Internet X.509 Public Key Infrastructure -
	Algorithm Identifiers for the Module-Lattice-Based Key-
	Encapsulation Mechanism (ML-KEM)", Work in Progress,
	Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
	July 2025, <https://datatracker.ietf.org/doc/html/draft-
	ietf-lamps-kyber-certificates-11>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,

	<https://www.rfc-editor.org/rfc/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,	(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,

	September 2002, <https://www.rfc-editor.org/rfc/rfc3394>.	September 2002, <https://www.rfc-editor.org/info/rfc3394>.

	[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)	[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
	Encryption Algorithm in Cryptographic Message Syntax	Encryption Algorithm in Cryptographic Message Syntax
	(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,	(CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,

	<https://www.rfc-editor.org/rfc/rfc3565>.	<https://www.rfc-editor.org/info/rfc3565>.

	[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)	[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
	Authenticated-Enveloped-Data Content Type", RFC 5083,	Authenticated-Enveloped-Data Content Type", RFC 5083,
	DOI 10.17487/RFC5083, November 2007,	DOI 10.17487/RFC5083, November 2007,

	<https://www.rfc-editor.org/rfc/rfc5083>.	<https://www.rfc-editor.org/info/rfc5083>.

	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key	Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List	Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,

	<https://www.rfc-editor.org/rfc/rfc5280>.	<https://www.rfc-editor.org/info/rfc5280>.

	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,	RFC 5652, DOI 10.17487/RFC5652, September 2009,

	<https://www.rfc-editor.org/rfc/rfc5652>.	<https://www.rfc-editor.org/info/rfc5652>.

	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,	Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,	DOI 10.17487/RFC5869, May 2010,

	<https://www.rfc-editor.org/rfc/rfc5869>.	<https://www.rfc-editor.org/info/rfc5869>.

	[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for	[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
	DOI 10.17487/RFC5911, June 2010,	DOI 10.17487/RFC5911, June 2010,

	<https://www.rfc-editor.org/rfc/rfc5911>.	<https://www.rfc-editor.org/info/rfc5911>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

		[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
		Cryptographic Algorithm Object Identifier Range",
		RFC 8411, DOI 10.17487/RFC8411, August 2018,
		<https://www.rfc-editor.org/info/rfc8411>.

	[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/	[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", RFC 8551, DOI 10.17487/RFC8551,	Message Specification", RFC 8551, DOI 10.17487/RFC8551,

	April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.	April 2019, <https://www.rfc-editor.org/info/rfc8551>.

	[RFC8619] Housley, R., "Algorithm Identifiers for the HMAC-based	[RFC8619] Housley, R., "Algorithm Identifiers for the HMAC-based
	Extract-and-Expand Key Derivation Function (HKDF)",	Extract-and-Expand Key Derivation Function (HKDF)",
	RFC 8619, DOI 10.17487/RFC8619, June 2019,	RFC 8619, DOI 10.17487/RFC8619, June 2019,

	<https://www.rfc-editor.org/rfc/rfc8619>.	<https://www.rfc-editor.org/info/rfc8619>.

	[RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key	[RFC9629] Housley, R., Gray, J., and T. Okubo, "Using Key
	Encapsulation Mechanism (KEM) Algorithms in the	Encapsulation Mechanism (KEM) Algorithms in the
	Cryptographic Message Syntax (CMS)", RFC 9629,	Cryptographic Message Syntax (CMS)", RFC 9629,
	DOI 10.17487/RFC9629, August 2024,	DOI 10.17487/RFC9629, August 2024,

	<https://www.rfc-editor.org/rfc/rfc9629>.	<https://www.rfc-editor.org/info/rfc9629>.

		[RFC9935] Turner, S., Kampanakis, P., Massimo, J., and B. E.
		Westerbaan, "Internet X.509 Public Key Infrastructure -
		Algorithm Identifiers for the Module-Lattice-Based Key-
		Encapsulation Mechanism (ML-KEM)", RFC 9935,
		DOI 10.17487/RFC9935, February 2026,
		<https://www.rfc-editor.org/info/rfc9935>.

	[X680] ITU-T, "Information technology - Abstract Syntax Notation	[X680] ITU-T, "Information technology - Abstract Syntax Notation
	One (ASN.1): Specification of basic notation", ITU-T	One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,	Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
	<https://www.itu.int/rec/T-REC-X.680>.	<https://www.itu.int/rec/T-REC-X.680>.


	7.2. Informative References	6.2. Informative References


	[CMVP] National Institute of Standards and Technology,	[CMVP] NIST, "Cryptographic Module Validation Program (CMVP)", 3
	"Cryptographic Module Validation Program", 2016,	September 2025, <https://csrc.nist.gov/projects/
	<https://csrc.nist.gov/projects/cryptographic-module-	cryptographic-module-validation-program>.
	validation-program>.


	[I-D.kampanakis-ml-kem-ikev2]	[IKEv2-MLKEM]
	Kampanakis, P. and G. Ravago, "Post-quantum Hybrid Key	Kampanakis, P., "Post-quantum Hybrid Key Exchange with ML-
	Exchange with ML-KEM in the Internet Key Exchange Protocol	KEM in the Internet Key Exchange Protocol Version 2
	Version 2 (IKEv2)", Work in Progress, Internet-Draft,	(IKEv2)", Work in Progress, Internet-Draft, draft-ietf-
	draft-kampanakis-ml-kem-ikev2-09, 4 November 2024,	ipsecme-ikev2-mlkem-03, 29 September 2025,
	<https://datatracker.ietf.org/doc/html/draft-kampanakis-	<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
	ml-kem-ikev2-09>.	ikev2-mlkem-03>.


	[I-D.sfluhrer-cfrg-ml-kem-security-considerations]	[MLKEM-SEC-CONS]
	Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D.	Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D.
	Shiu, "ML-KEM Security Considerations", Work in Progress,	Shiu, "ML-KEM Security Considerations", Work in Progress,
	Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-	Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-

	considerations-03, 15 May 2025,	considerations-04, 17 November 2025,
	<https://datatracker.ietf.org/doc/html/draft-sfluhrer-	<https://datatracker.ietf.org/doc/html/draft-sfluhrer-

	cfrg-ml-kem-security-considerations-03>.	cfrg-ml-kem-security-considerations-04>.


	[NIST-PQ] National Institute of Standards and Technology, "Post-	[NIST-PQ] NIST, "Post-Quantum Cryptography (PQC)", 30 September
	Quantum Cryptography Project", 20 December 2016,	2025, <https://csrc.nist.gov/projects/post-quantum-
	<https://csrc.nist.gov/projects/post-quantum-
	cryptography>.	cryptography>.

	[NIST.SP.800-57pt1r5]	[NIST.SP.800-57pt1r5]

	Barker, E. and NIST, "Recommendation for key	Barker, E., "Recommendation for Key Management: Part 1 -
	management:part 1 - general", NIST Special Publications	General", NIST SP 800-57pt1r5,
	(General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5,	DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
	May 2020,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-57pt1r5.pdf>.	NIST.SP.800-57pt1r5.pdf>.

	[RFC9690] Housley, R. and S. Turner, "Use of the RSA-KEM Algorithm	[RFC9690] Housley, R. and S. Turner, "Use of the RSA-KEM Algorithm
	in the Cryptographic Message Syntax (CMS)", RFC 9690,	in the Cryptographic Message Syntax (CMS)", RFC 9690,
	DOI 10.17487/RFC9690, February 2025,	DOI 10.17487/RFC9690, February 2025,

	<https://www.rfc-editor.org/rfc/rfc9690>.	<https://www.rfc-editor.org/info/rfc9690>.

	Appendix A. ASN.1 Module	Appendix A. ASN.1 Module

	This appendix includes the ASN.1 module [X680] for ML-KEM. This	This appendix includes the ASN.1 module [X680] for ML-KEM. This

	module imports objects from [RFC5911], [RFC9629], [RFC8619],	module imports objects from [RFC5911], [RFC9629], [RFC8619], and
	[I-D.ietf-lamps-kyber-certificates].	[RFC9935].

	<CODE BEGINS>	<CODE BEGINS>
	CMS-ML-KEM-2024	CMS-ML-KEM-2024
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)

	pkcs-9(9) smime(16) modules(0) id-mod-cms-ml-kem-2024(TBD1) }	pkcs-9(9) smime(16) modules(0) id-mod-cms-ml-kem-2024(84) }

	DEFINITIONS IMPLICIT TAGS ::= BEGIN	DEFINITIONS IMPLICIT TAGS ::= BEGIN

	EXPORTS ALL;	EXPORTS ALL;


	IMPORTS	IMPORTS
	SMIME-CAPS	SMIME-CAPS
	FROM AlgorithmInformation-2009 -- [RFC5911]	FROM AlgorithmInformation-2009 -- [RFC5911]
	{ iso(1) identified-organization(3) dod(6) internet(1)	{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)	security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-algorithmInformation-02(58) }	id-mod-algorithmInformation-02(58) }

	KEM-ALGORITHM	KEM-ALGORITHM
	FROM KEMAlgorithmInformation-2023 -- [RFC9629]	FROM KEMAlgorithmInformation-2023 -- [RFC9629]
	{ iso(1) identified-organization(3) dod(6) internet(1)	{ iso(1) identified-organization(3) dod(6) internet(1)

	skipping to change at page 13, line 30 ¶	skipping to change at line 555 ¶
	pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) }	pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) }

	kwa-aes128-wrap, kwa-aes256-wrap	kwa-aes128-wrap, kwa-aes256-wrap
	FROM CMSAesRsaesOaep-2009 -- [RFC5911]	FROM CMSAesRsaesOaep-2009 -- [RFC5911]
	{ iso(1) member-body(2) us(840) rsadsi(113549)	{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0)	pkcs(1) pkcs-9(9) smime(16) modules(0)
	id-mod-cms-aes-02(38) }	id-mod-cms-aes-02(38) }

	id-alg-ml-kem-512, id-alg-ml-kem-768, id-alg-ml-kem-1024,	id-alg-ml-kem-512, id-alg-ml-kem-768, id-alg-ml-kem-1024,
	pk-ml-kem-512, pk-ml-kem-768, pk-ml-kem-1024	pk-ml-kem-512, pk-ml-kem-768, pk-ml-kem-1024

	FROM X509-ML-KEM-2024 -- [I-D.ietf-lamps-kyber-certificates]	FROM X509-ML-KEM-2024 -- [RFC9935]
	{ iso(1) identified-organization(3) dod(6)	{ iso(1) identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-x509-ml-kem-2025(121) };	id-mod-x509-ml-kem-2025(121) };

	--	--
	-- ML-KEM Key Encapsulation Mechanism Algorithms	-- ML-KEM Key Encapsulation Mechanism Algorithms
	--	--

	kema-ml-kem-512 KEM-ALGORITHM ::= {	kema-ml-kem-512 KEM-ALGORITHM ::= {
	IDENTIFIER id-alg-ml-kem-512	IDENTIFIER id-alg-ml-kem-512

	skipping to change at page 14, line 31 ¶	skipping to change at line 604 ¶
	... }	... }

	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
	traditional manner using the imprecise notion of bits of security,	traditional manner using the imprecise notion of bits of security,
	NIST has defined security levels by picking a reference scheme, which	NIST has defined security levels by picking a reference scheme, which

	NIST expects to offer notable levels of resistance to both quantum	is expected to offer notable levels of resistance to both quantum and
	and classical attack. To wit, a KEM algorithm that achieves NIST PQC	classical attacks. To wit, a KEM algorithm that achieves NIST Post-
	security must require computational resources to break IND-CCA2	Quantum Cryptography (PQC) security must require computational
	security comparable or greater than that required for key search on	resources to break IND-CCA2 security comparable or greater than that
	AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively.	required for key search on AES-128, AES-192, and AES-256 for Levels
	Levels 2 and 4 use collision search for SHA-256 and SHA-384 as	1, 3, and 5, respectively. Levels 2 and 4 use collision search for
	reference.	SHA-256 and SHA-384 as reference.

	+=============+=======+==========+==========+============+========+	+=============+=======+==========+==========+============+========+
	\| Parameter \| Level \| Encap. \| Decap. \| Ciphertext \| Shared \|	\| Parameter \| Level \| Encap. \| Decap. \| Ciphertext \| Shared \|
	\| Set \| \| Key Size \| Key Size \| Size \| Secret \|	\| Set \| \| Key Size \| Key Size \| Size \| Secret \|
	\| \| \| \| \| \| Size \|	\| \| \| \| \| \| Size \|
	+=============+=======+==========+==========+============+========+	+=============+=======+==========+==========+============+========+
	\| ML-KEM-512 \| 1 \| 800 \| 1632 \| 768 \| 32 \|	\| ML-KEM-512 \| 1 \| 800 \| 1632 \| 768 \| 32 \|
	+-------------+-------+----------+----------+------------+--------+	+-------------+-------+----------+----------+------------+--------+
	\| ML-KEM-768 \| 3 \| 1184 \| 2400 \| 1088 \| 32 \|	\| ML-KEM-768 \| 3 \| 1184 \| 2400 \| 1088 \| 32 \|
	+-------------+-------+----------+----------+------------+--------+	+-------------+-------+----------+----------+------------+--------+
	\| ML-KEM-1024 \| 5 \| 1568 \| 3168 \| 1568 \| 32 \|	\| ML-KEM-1024 \| 5 \| 1568 \| 3168 \| 1568 \| 32 \|
	+-------------+-------+----------+----------+------------+--------+	+-------------+-------+----------+----------+------------+--------+


	Table 2: ML-KEM parameter sets, NIST Security Level, and sizes	Table 2: ML-KEM parameter Sets, NIST Security Level, and Sizes
	in bytes	in Bytes

	Appendix C. ML-KEM CMS Authenticated-Enveloped-Data Example	Appendix C. ML-KEM CMS Authenticated-Enveloped-Data Example

	This example shows the establishment of an AES-128 content-encryption	This example shows the establishment of an AES-128 content-encryption
	key using:	key using:

	* ML-KEM-512;	* ML-KEM-512;

	* KEMRecipientInfo key derivation using HKDF with SHA-256; and	* KEMRecipientInfo key derivation using HKDF with SHA-256; and


	skipping to change at page 17, line 36 ¶	skipping to change at line 756 ¶
	HWWcKlYCm3RTxfO6UkPZ+nSdkXxA2dEB5FO8ixDkKnwIkyPAJveD4QC5+m5wFEJN	HWWcKlYCm3RTxfO6UkPZ+nSdkXxA2dEB5FO8ixDkKnwIkyPAJveD4QC5+m5wFEJN
	pvo3kryVfughnQFrdz8o/tzJYqSFq6/+wCMoGXHimqaJg57P0mGekih80jDbJqJQ	pvo3kryVfughnQFrdz8o/tzJYqSFq6/+wCMoGXHimqaJg57P0mGekih80jDbJqJQ
	fMUA6xx6UpO1/pF64pvxrTUBJPijEWNSFLQR259n07hb1xUBhTfqRbQfQbTGYFEw	fMUA6xx6UpO1/pF64pvxrTUBJPijEWNSFLQR259n07hb1xUBhTfqRbQfQbTGYFEw
	DQYLKoZIhvcNAQkQAxwCARAwCwYJYIZIAWUDBAEFBBjAUOQ5L5wU3QrCIgID8xfX	DQYLKoZIhvcNAQkQAxwCARAwCwYJYIZIAWUDBAEFBBjAUOQ5L5wU3QrCIgID8xfX
	AflPndknePUwOgYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBBjARBAxcpXRouBvwO42n	AflPndknePUwOgYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBBjARBAxcpXRouBvwO42n
	GGwCARCADZTIaJqZ0sOOGS+muggEEFzxeGxXx0ArVPyTwwpKRTM=	GGwCARCADZTIaJqZ0sOOGS+muggEEFzxeGxXx0ArVPyTwwpKRTM=
	-----END CMS-----	-----END CMS-----

	This result decodes to:	This result decodes to:


	0 994: SEQUENCE {	0 994: SEQUENCE {
	4 11: OBJECT IDENTIFIER	4 11: OBJECT IDENTIFIER
	: authEnvelopedData (1 2 840 113549 1 9 16 1 23)	: authEnvelopedData (1 2 840 113549 1 9 16 1 23)
	17 977: [0] {	17 977: [0] {
	21 973: SEQUENCE {	21 973: SEQUENCE {
	25 1: INTEGER 0	25 1: INTEGER 0
	28 888: SET {	28 888: SET {
	32 884: [4] {	32 884: [4] {
	36 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3'	36 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3'
	49 867: SEQUENCE {	49 867: SEQUENCE {
	53 1: INTEGER 0	53 1: INTEGER 0
	56 20: [0]	56 20: [0]
	: 59 97 88 C3 7A ED 40 0E E4 05 D1 B2 A3 36 6A B1	: 59 97 88 C3 7A ED 40 0E E4 05 D1 B2 A3 36 6A B1
	: 7D 82 4A 51	: 7D 82 4A 51
	78 11: SEQUENCE {	78 11: SEQUENCE {
	80 9: OBJECT IDENTIFIER '2 16 840 1 101 3 4 4 1'	80 9: OBJECT IDENTIFIER '2 16 840 1 101 3 4 4 1'
	: }	: }
	91 768: OCTET STRING	91 768: OCTET STRING
	: 3E A4 0F C6 CA 09 0E 2C 8A F7 6E 27 27 AB 38 E0	: 3E A4 0F C6 CA 09 0E 2C 8A F7 6E 27 27 AB 38 E0
	: 65 2D 95 15 98 6F E1 86 82 7F E8 4E 59 6E 42 1B	: 65 2D 95 15 98 6F E1 86 82 7F E8 4E 59 6E 42 1B
	: 85 FD 45 9C C7 89 97 37 2C 9D E3 1D 19 1B 39 C1	: 85 FD 45 9C C7 89 97 37 2C 9D E3 1D 19 1B 39 C1
	: D5 A3 EB 6D DB 56 AA DE DE 76 5C C3 90 FD BB C2	: D5 A3 EB 6D DB 56 AA DE DE 76 5C C3 90 FD BB C2
	: F8 8C B1 75 68 1D 42 01 B8 1C CD FC B2 4F EF 13	: F8 8C B1 75 68 1D 42 01 B8 1C CD FC B2 4F EF 13
	: AF 2F 5A 1A BC F8 D8 AF 38 4F 02 A0 10 A6 E9 19	: AF 2F 5A 1A BC F8 D8 AF 38 4F 02 A0 10 A6 E9 19
	: F1 98 7A 5E 9B 1C 0E 2D 3F 07 F5 8A 9F A5 39 CE	: F1 98 7A 5E 9B 1C 0E 2D 3F 07 F5 8A 9F A5 39 CE
	: 86 CC 14 99 10 A1 69 2C 0C A4 CE 0E CE 4E EE D2	: 86 CC 14 99 10 A1 69 2C 0C A4 CE 0E CE 4E EE D2
	: E6 69 9C B9 76 33 24 52 DE 4A 2E B5 CA 61 F7 B0	: E6 69 9C B9 76 33 24 52 DE 4A 2E B5 CA 61 F7 B0
	: 81 33 0C 34 79 8E F7 12 A2 4E 59 C3 3C EA 1F 1F	: 81 33 0C 34 79 8E F7 12 A2 4E 59 C3 3C EA 1F 1F
	: 9E 6D 4F BF 37 43 A3 84 67 43 00 11 33 6F 62 D8	: 9E 6D 4F BF 37 43 A3 84 67 43 00 11 33 6F 62 D8
	: 70 79 2B 86 6B EF CD 1D 1B 36 5B ED 19 52 67 3D	: 70 79 2B 86 6B EF CD 1D 1B 36 5B ED 19 52 67 3D
	: 3A 5B 0C 20 B3 86 B4 EF D1 CF 63 FD 37 6B D4 7C	: 3A 5B 0C 20 B3 86 B4 EF D1 CF 63 FD 37 6B D4 7C
	: CC 46 AC 4D D8 EC 66 B0 47 C4 C9 5A CF F1 CF D0	: CC 46 AC 4D D8 EC 66 B0 47 C4 C9 5A CF F1 CF D0
	: 28 A4 19 B0 02 FD A1 B6 17 CB A6 1D 2E 91 CF E8	: 28 A4 19 B0 02 FD A1 B6 17 CB A6 1D 2E 91 CF E8
	: FF FB CB 8F FD 4D 5F 6A D8 B1 58 C2 19 E3 6D C5	: FF FB CB 8F FD 4D 5F 6A D8 B1 58 C2 19 E3 6D C5
	: 14 05 DC 0C 0B 23 49 79 AC 65 8E 72 BD DF 1B 67	: 14 05 DC 0C 0B 23 49 79 AC 65 8E 72 BD DF 1B 67
	: 73 B9 6B 2A E3 E4 D0 7B E8 60 48 04 0C 01 67 43	: 73 B9 6B 2A E3 E4 D0 7B E8 60 48 04 0C 01 67 43
	: 6F A8 39 E7 52 9B 00 CC 9A B5 5A 2F 25 DB 63 CC	: 6F A8 39 E7 52 9B 00 CC 9A B5 5A 2F 25 DB 63 CC
	: 9F 55 75 94 E6 91 C1 1E 55 3D 4A 3E BC 76 0F 5F	: 9F 55 75 94 E6 91 C1 1E 55 3D 4A 3E BC 76 0F 5F
	: 19 E5 FE 14 48 38 B4 C7 D1 59 1D A9 B5 D4 67 49	: 19 E5 FE 14 48 38 B4 C7 D1 59 1D A9 B5 D4 67 49
	: 4F D9 CA C5 2C C5 50 40 60 39 9D BD B7 22 98 EB	: 4F D9 CA C5 2C C5 50 40 60 39 9D BD B7 22 98 EB
	: 9A 4C 01 7B 00 78 6F DC 7D 9D 7A A5 7A DB B8 B6	: 9A 4C 01 7B 00 78 6F DC 7D 9D 7A A5 7A DB B8 B6
	: 1C 34 DE 1E 28 8B 2A B7 28 17 1D CE 14 3C D1 69	: 1C 34 DE 1E 28 8B 2A B7 28 17 1D CE 14 3C D1 69
	: 53 F9 84 C1 AE D5 59 E5 6B AA 0C E6 58 D3 2C CE	: 53 F9 84 C1 AE D5 59 E5 6B AA 0C E6 58 D3 2C CE
	: 42 F4 40 75 04 CD 7A 57 9A D0 EF 9B 77 13 5E AA	: 42 F4 40 75 04 CD 7A 57 9A D0 EF 9B 77 13 5E AA
	: 39 B6 F9 3A 3A 2E 59 97 80 7F 06 36 1C 83 F4 E6	: 39 B6 F9 3A 3A 2E 59 97 80 7F 06 36 1C 83 F4 E6
	: 7F 8E 3F 9C F6 83 16 01 15 14 F5 D8 5A 18 1C EA	: 7F 8E 3F 9C F6 83 16 01 15 14 F5 D8 5A 18 1C EA
	: D7 14 CD 49 40 E4 EB AC 01 D6 65 28 DA 32 F8 9C	: D7 14 CD 49 40 E4 EB AC 01 D6 65 28 DA 32 F8 9C
	: EA 04 28 E8 EB CA DC F8 AA 18 8C 9F 62 E8 5B 19	: EA 04 28 E8 EB CA DC F8 AA 18 8C 9F 62 E8 5B 19
	: 57 65 5B 7F E2 B8 D7 97 3B 7A 72 26 B6 6D 93 BF	: 57 65 5B 7F E2 B8 D7 97 3B 7A 72 26 B6 6D 93 BF
	: 7B 23 2F 3D CF 65 3C 84 B4 EC F1 A9 92 0D B1 94	: 7B 23 2F 3D CF 65 3C 84 B4 EC F1 A9 92 0D B1 94
	: 9A D7 50 B5 46 A5 55 2A 20 E5 49 09 71 9B 8C 0C	: 9A D7 50 B5 46 A5 55 2A 20 E5 49 09 71 9B 8C 0C
	: 07 05 6F CB 7E 57 4A D2 A3 2E C9 50 01 DD E8 44	: 07 05 6F CB 7E 57 4A D2 A3 2E C9 50 01 DD E8 44
	: 81 BE 77 D0 39 ED 5B F7 42 62 EC F3 98 1F 1B 00	: 81 BE 77 D0 39 ED 5B F7 42 62 EC F3 98 1F 1B 00
	: D3 36 6A 9C 2E 06 1C 47 E2 41 A0 61 C6 24 95 60	: D3 36 6A 9C 2E 06 1C 47 E2 41 A0 61 C6 24 95 60
	: D2 B8 44 6A 48 0C 38 C2 8B A9 89 D9 F6 8A DC 4B	: D2 B8 44 6A 48 0C 38 C2 8B A9 89 D9 F6 8A DC 4B
	: BA F2 A2 0B 47 E4 92 31 28 C7 23 42 D5 97 FD A2	: BA F2 A2 0B 47 E4 92 31 28 C7 23 42 D5 97 FD A2
	: 59 DE 0B 83 C2 05 6D 6B 77 E7 99 B3 19 32 4A A5	: 59 DE 0B 83 C2 05 6D 6B 77 E7 99 B3 19 32 4A A5
	: 0B 1D 65 9C 2A 56 02 9B 74 53 C5 F3 BA 52 43 D9	: 0B 1D 65 9C 2A 56 02 9B 74 53 C5 F3 BA 52 43 D9
	: FA 74 9D 91 7C 40 D9 D1 01 E4 53 BC 8B 10 E4 2A	: FA 74 9D 91 7C 40 D9 D1 01 E4 53 BC 8B 10 E4 2A
	: 7C 08 93 23 C0 26 F7 83 E1 00 B9 FA 6E 70 14 42	: 7C 08 93 23 C0 26 F7 83 E1 00 B9 FA 6E 70 14 42
	: 4D A6 FA 37 92 BC 95 7E E8 21 9D 01 6B 77 3F 28	: 4D A6 FA 37 92 BC 95 7E E8 21 9D 01 6B 77 3F 28
	: FE DC C9 62 A4 85 AB AF FE C0 23 28 19 71 E2 9A	: FE DC C9 62 A4 85 AB AF FE C0 23 28 19 71 E2 9A
	: A6 89 83 9E CF D2 61 9E 92 28 7C D2 30 DB 26 A2	: A6 89 83 9E CF D2 61 9E 92 28 7C D2 30 DB 26 A2
	: 50 7C C5 00 EB 1C 7A 52 93 B5 FE 91 7A E2 9B F1	: 50 7C C5 00 EB 1C 7A 52 93 B5 FE 91 7A E2 9B F1
	: AD 35 01 24 F8 A3 11 63 52 14 B4 11 DB 9F 67 D3	: AD 35 01 24 F8 A3 11 63 52 14 B4 11 DB 9F 67 D3
	: B8 5B D7 15 01 85 37 EA 45 B4 1F 41 B4 C6 60 51	: B8 5B D7 15 01 85 37 EA 45 B4 1F 41 B4 C6 60 51
	863 13: SEQUENCE {	863 13: SEQUENCE {
	865 11: OBJECT IDENTIFIER	865 11: OBJECT IDENTIFIER
	: hkdfWithSha256 (1 2 840 113549 1 9 16 3 28)	: hkdfWithSha256 (1 2 840 113549 1 9 16 3 28)
	: }	: }
	878 1: INTEGER 16	878 1: INTEGER 16
	881 11: SEQUENCE {	881 11: SEQUENCE {
	883 9: OBJECT IDENTIFIER	883 9: OBJECT IDENTIFIER
	: aes128-wrap (2 16 840 1 101 3 4 1 5)	: aes128-wrap (2 16 840 1 101 3 4 1 5)
	: }	: }
	894 24: OCTET STRING	894 24: OCTET STRING
	: C0 50 E4 39 2F 9C 14 DD 0A C2 22 02 03 F3 17 D7	: C0 50 E4 39 2F 9C 14 DD 0A C2 22 02 03 F3 17 D7
	: 01 F9 4F 9D D9 27 78 F5	: 01 F9 4F 9D D9 27 78 F5
	: }	: }
	: }	: }
	: }	: }
	920 58: SEQUENCE {	920 58: SEQUENCE {
	922 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)	922 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
	933 30: SEQUENCE {	933 30: SEQUENCE {
	935 9: OBJECT IDENTIFIER	935 9: OBJECT IDENTIFIER
	: aes128-GCM (2 16 840 1 101 3 4 1 6)	: aes128-GCM (2 16 840 1 101 3 4 1 6)
	946 17: SEQUENCE {	946 17: SEQUENCE {
	948 12: OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C	948 12: OCTET STRING 5C A5 74 68 B8 1B F0 3B 8D A7 18 6C
	962 1: INTEGER 16	962 1: INTEGER 16
	: }	: }
	: }	: }
	965 13: [0] 94 C8 68 9A 99 D2 C3 8E 19 2F A6 BA 08	965 13: [0] 94 C8 68 9A 99 D2 C3 8E 19 2F A6 BA 08
	: }	: }
	980 16: OCTET STRING 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33	980 16: OCTET STRING 5C F1 78 6C 57 C7 40 2B 54 FC 93 C3 0A 4A 45 33
	: }	: }
	: }	: }
	: }	: }

	C.2. Recipient CMS Processing	C.2. Recipient CMS Processing

	Bob's ML-KEM-512 private key:	Bob's ML-KEM-512 private key:

	-----BEGIN PRIVATE KEY-----	-----BEGIN PRIVATE KEY-----
	MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ	MFQCAQAwCwYJYIZIAWUDBAQBBEKAQAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZ
	GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8=	GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8=
	-----END PRIVATE KEY-----	-----END PRIVATE KEY-----


	Bob decapsulates the ciphertext in the KEMRecipientInfo to get the	Bob decapsulates the ciphertext in the KEMRecipientInfo to get the
	ML-KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives	ML-KEM-512 shared secret, encodes the CMSORIforKEMOtherInfo, derives
	the key-encryption key from the shared secret and the DER-encoded	the key-encryption key from the shared secret and the DER-encoded
	CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-128-KEYWRAP	CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-128-KEYWRAP
	to decrypt the content-encryption key with the key-encryption key,	to decrypt the content-encryption key with the key-encryption key,
	and decrypts the encrypted contents with the content-encryption key,	and decrypts the encrypted contents with the content-encryption key,
	revealing the plaintext content:	revealing the plaintext content:

	Hello, world!	Hello, world!


		Acknowledgements

		This document borrows heavily from [RFC9690], [FIPS203], and
		[IKEv2-MLKEM]. Thanks go to the authors of those documents.
		"Copying always makes things easier and less error prone." -
		[RFC8411].

		Thanks to Carl Wallace, Jonathan Hammel, and Sean Turner for the
		detailed review and Carl Wallace and Philippe Cece for
		interoperability testing for the examples.

	Authors' Addresses	Authors' Addresses

	Julien Prat	Julien Prat
	CryptoNext Security	CryptoNext Security
	16, Boulevard Saint-Germain	16, Boulevard Saint-Germain
	75005 Paris	75005 Paris
	France	France
	Email: julien.prat@cryptonext-security.com	Email: julien.prat@cryptonext-security.com

	Mike Ounsworth	Mike Ounsworth
	Entrust Limited	Entrust Limited
	2500 Solandt Road -- Suite 100	2500 Solandt Road -- Suite 100

	Ottawa, Ontario K2K 3G5	Ottawa Ontario K2K 3G5
	Canada	Canada
	Email: mike.ounsworth@entrust.com	Email: mike.ounsworth@entrust.com

	Daniel Van Geest	Daniel Van Geest
	CryptoNext Security	CryptoNext Security
	16, Boulevard Saint-Germain	16, Boulevard Saint-Germain
	75005 Paris	75005 Paris
	France	France
	Email: daniel.vangeest@cryptonext-security.com	Email: daniel.vangeest@cryptonext-security.com

End of changes. 79 change blocks.
	320 lines changed or deleted	304 lines changed or added
This html diff was produced by rfcdiff 1.48.