rfc9882v1.txt		rfc9882.txt
	skipping to change at line 20 ¶		skipping to change at line 20 ¶
	Syntax (CMS)		Syntax (CMS)
	Abstract		Abstract
	The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as		The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as
	defined by NIST in FIPS 204, is a post-quantum digital signature		defined by NIST in FIPS 204, is a post-quantum digital signature
	scheme that aims to be secure against an adversary in possession of a		scheme that aims to be secure against an adversary in possession of a
	Cryptographically Relevant Quantum Computer (CRQC). This document		Cryptographically Relevant Quantum Computer (CRQC). This document
	specifies the conventions for using the ML-DSA signature algorithm		specifies the conventions for using the ML-DSA signature algorithm
	with the Cryptographic Message Syntax (CMS). In addition, the		with the Cryptographic Message Syntax (CMS). In addition, the
	algorithm identifier and public key syntax are provided.		algorithm identifier syntax is provided.
	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
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 74 ¶		skipping to change at line 74 ¶
	7.1. Normative References		7.1. Normative References
	7.2. Informative References		7.2. Informative References
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	Appendix B. Examples		Appendix B. Examples
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a		The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a
	digital signature algorithm standardised by the US National Institute		post-quantum digital signature algorithm standardised by the US
	of Standards and Technology (NIST) as part of their post-quantum		National Institute of Standards and Technology (NIST) as part of
	cryptography standardisation process. It is intended to be secure		their post-quantum cryptography standardisation process. It offers
	against both "traditional" cryptographic attacks, as well as attacks		smaller signatures and significantly faster runtimes than SLH-DSA
	utilising a quantum computer. It offers smaller signatures and		[FIPS205], an alternative post-quantum signature algorithm also
	significantly faster runtimes than SLH-DSA [FIPS205], an alternative		standardised by NIST. This document specifies the use of the ML-DSA
	post-quantum signature algorithm also standardised by NIST. This		in the CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-
	document specifies the use of the ML-DSA in the CMS at three security		DSA-87. See Appendix B of [RFC9881] for more information on the
	levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See Appendix B of		security levels and key sizes of ML-DSA.
	[RFC9881] for more information on the security levels and key sizes
	of ML-DSA.
	Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and		Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and
	Dilithium are not compatible.		Dilithium are not compatible.
	For each of the ML-DSA parameter sets, an algorithm identifier OID		For each of the ML-DSA parameter sets, an algorithm identifier OID
	has been specified.		has been specified.
	[FIPS204] also specifies a pre-hashed variant of ML-DSA, called		[FIPS204] also specifies a pre-hashed variant of ML-DSA, called
	HashML-DSA. Use of HashML-DSA in the CMS is not specified in this		HashML-DSA. Use of HashML-DSA in the CMS is not specified in this
	document. See Section 3.1 for more details.		document. See Section 3.1 for more details.
	skipping to change at line 239 ¶		skipping to change at line 237 ¶
	and any associated parameters. Each ML-DSA parameter set has a		and any associated parameters. Each ML-DSA parameter set has a
	collision strength parameter, represented by the "λ" (GREEK SMALL		collision strength parameter, represented by the "λ" (GREEK SMALL
	LETTER LAMDA, U+03BB) symbol in [FIPS204]. When signers utilise		LETTER LAMDA, U+03BB) symbol in [FIPS204]. When signers utilise
	signed attributes, their choice of digest algorithm may impact the		signed attributes, their choice of digest algorithm may impact the
	overall security level of their signature. Selecting a digest		overall security level of their signature. Selecting a digest
	algorithm that offers λ bits of security strength against second		algorithm that offers λ bits of security strength against second
	preimage attacks and collision attacks is sufficient to meet the		preimage attacks and collision attacks is sufficient to meet the
	security level offered by a given parameter set, so long as the		security level offered by a given parameter set, so long as the
	digest algorithm produces at least 2 * λ bits of output. The		digest algorithm produces at least 2 * λ bits of output. The
	overall security strength offered by an ML-DSA signature		overall security strength offered by an ML-DSA signature
	calculated over signed attributes is the floor of the digest		calculated over signed attributes is constrained by either the
	algorithm's strength and is the strength of the ML-DSA parameter		digest algorithm's strength or the strength of the ML-DSA
	set. Verifiers MAY reject a signature if the signer's choice of		parameter set, whichever is lower. Verifiers MAY reject a
	digest algorithm does not meet the security requirements of their		signature if the signer's choice of digest algorithm does not meet
	choice of ML-DSA parameter set. Table 1 shows appropriate SHA-2		the security requirements of their choice of ML-DSA parameter set.
	and SHA-3 digest algorithms for each parameter set.		Table 1 shows appropriate SHA-2 and SHA-3 digest algorithms for
			each parameter set.
	SHA-512 [FIPS180] MUST be supported for use with the variants of		SHA-512 [FIPS180] MUST be supported for use with the variants of
	ML-DSA in this document. SHA-512 is suitable for all ML-DSA		ML-DSA in this document. SHA-512 is suitable for all ML-DSA
	parameter sets and provides an interoperable option for legacy CMS		parameter sets and provides an interoperable option for legacy CMS
	implementations that wish to migrate to use post-quantum		implementations that wish to migrate to use post-quantum
	cryptography, but that may not support use of SHA-3 derivatives at		cryptography, but that may not support use of SHA-3 derivatives at
	the CMS layer. However, other hash functions MAY also be		the CMS layer. However, other hash functions MAY also be
	supported; in particular, SHAKE256 SHOULD be supported, as this is		supported; in particular, SHAKE256 SHOULD be supported, as this is
	the digest algorithm used internally in ML-DSA. When SHA-512 is		the digest algorithm used internally in ML-DSA. When SHA-512 is
	used, the id-sha512 [RFC5754] digest algorithm identifier is used		used, the id-sha512 [RFC5754] digest algorithm identifier is used
	skipping to change at line 357 ¶		skipping to change at line 356 ¶
	DSA's internal functions. Implementers SHOULD consider implementing		DSA's internal functions. Implementers SHOULD consider implementing
	such protection measures if it would be beneficial for their		such protection measures if it would be beneficial for their
	particular use cases.		particular use cases.
	To avoid algorithm substitution attacks, the CMSAlgorithmProtection		To avoid algorithm substitution attacks, the CMSAlgorithmProtection
	attribute defined in [RFC6211] SHOULD be included in signed		attribute defined in [RFC6211] SHOULD be included in signed
	attributes.		attributes.
	5. Operational Considerations		5. Operational Considerations
	If ML-DSA signing is implemented in a hardware device such as the		If ML-DSA signing is implemented in a hardware device such as a
	hardware security module (HSM) or portable cryptographic token,		hardware security module (HSM) or a portable cryptographic token,
	implementers might want to avoid sending the full content to the		implementers might want to avoid sending the full content to the
	device for performance reasons. By including signed attributes,		device for performance reasons. By including signed attributes,
	which necessarily includes the message-digest attribute and the		which necessarily includes the message-digest attribute and the
	content-type attribute as described in Section 5.3 of [RFC5652], the		content-type attribute as described in Section 5.3 of [RFC5652], the
	much smaller set of signed attributes are sent to the device for		much smaller set of signed attributes are sent to the device for
	signing.		signing.
	Additionally, the pure variant of ML-DSA does support a form of pre-		Additionally, the pure variant of ML-DSA does support a form of pre-
	hash via external calculation of the "μ" (GREEK SMALL LETTER MU,		hash via external calculation of the "μ" (GREEK SMALL LETTER MU,
	U+03BC) "message representative" value described in Section 6.2 of		U+03BC) "message representative" value described in Section 6.2 of
	skipping to change at line 381 ¶		skipping to change at line 380 ¶
	than requiring the entire message to be transmitted. Appendix D of		than requiring the entire message to be transmitted. Appendix D of
	[RFC9881] describes use of external μ calculations in further detail.		[RFC9881] describes use of external μ calculations in further detail.
	6. IANA Considerations		6. IANA Considerations
	For the ASN.1 module in Appendix A, IANA has assigned the following		For the ASN.1 module in Appendix A, IANA has assigned the following
	object identifier in the "SMI Security for S/MIME Module Identifier		object identifier in the "SMI Security for S/MIME Module Identifier
	(1.2.840.113549.1.9.16.0)" registry:		(1.2.840.113549.1.9.16.0)" registry:
	+=========+====================+===========+		+=========+====================+===========+
	| Decimal | Description | Refernece |		| Decimal | Description | Reference |
	+=========+====================+===========+		+=========+====================+===========+
	| 83 | id-mod-ml-dsa-2024 | RFC 9882 |		| 83 | id-mod-ml-dsa-2024 | RFC 9882 |
	+---------+--------------------+-----------+		+---------+--------------------+-----------+
	Table 3		Table 3: Object Identifier Assignments
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June		[CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June
	2025, <https://csrc.nist.gov/projects/computer-security-		2025, <https://csrc.nist.gov/projects/computer-security-
	objects-register/algorithm-registration>.		objects-register/algorithm-registration>.
	[FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard",		[FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard",
End of changes. 6 change blocks.
	22 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.48.