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 ML-DSA in
	post-quantum signature algorithm also standardised by NIST. This		the CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-
	document specifies the use of the ML-DSA in the CMS at three security		87. See Appendix B of [RFC9881] for more information on the security
	levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See Appendix B of		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 164 ¶		skipping to change at line 162 ¶
	3.1. Pure Mode Versus Pre-Hash Mode		3.1. Pure Mode Versus Pre-Hash Mode
	[RFC5652] specifies that digital signatures for CMS are produced		[RFC5652] specifies that digital signatures for CMS are produced
	using a digest of the message to be signed and the signer's private		using a digest of the message to be signed and the signer's private
	key. At the time RFC 5652 was published, all signature algorithms		key. At the time RFC 5652 was published, all signature algorithms
	supported in the CMS required a message digest to be calculated		supported in the CMS required a message digest to be calculated
	externally to that algorithm, which would then be supplied to the		externally to that algorithm, which would then be supplied to the
	algorithm implementation when calculating and verifying signatures.		algorithm implementation when calculating and verifying signatures.
	Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also		Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also
	been standardised, and these algorithms support both a "pure" and		been standardised, and these algorithms support both a "pure" and a
	"pre-hash" mode. In the pre-hash mode, a message digest (the "pre-		"pre-hash" mode. In the pre-hash mode, a message digest (the "pre-
	hash") is calculated separately and supplied to the signature		hash") is calculated separately and supplied to the signature
	algorithm as described above. In the pure mode, the message to be		algorithm as described above. In the pure mode, the message to be
	signed or verified is instead supplied directly to the signature		signed or verified is instead supplied directly to the signature
	algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with		algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with
	CMS, only the pure mode of those algorithms is specified. This is		CMS, only the pure mode of those algorithms is specified. This is
	because in most situations, CMS signatures are computed over a set of		because in most situations, CMS signatures are computed over a set of
	signed attributes that contain a hash of the content, rather than		signed attributes that contain a hash of the content, rather than
	being computed over the message content itself. Since signed		being computed over the message content itself. Since signed
	attributes are typically small, use of pre-hash modes in the CMS		attributes are typically small, use of pre-hash modes in the CMS
	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 320 ¶		skipping to change at line 319 ¶
	verification of a signature.		verification of a signature.
	4. Security Considerations		4. Security Considerations
	The security considerations in [RFC5652] and [RFC9881] apply to this		The security considerations in [RFC5652] and [RFC9881] apply to this
	specification.		specification.
	Security of the ML-DSA private key is critical. Compromise of the		Security of the ML-DSA private key is critical. Compromise of the
	private key will enable an adversary to forge arbitrary signatures.		private key will enable an adversary to forge arbitrary signatures.
	ML-DSA depends on high quality random numbers that are suitable for		ML-DSA depends on high-quality random numbers that are suitable for
	use in cryptography. The use of inadequate pseudo-random number		use in cryptography. The use of inadequate pseudo-random number
	generators (PRNGs) to generate such values can significantly		generators (PRNGs) to generate such values can significantly
	undermine the security properties offered by a cryptographic		undermine the security properties offered by a cryptographic
	algorithm. For instance, an attacker may find it much easier to		algorithm. For instance, an attacker may find it much easier to
	reproduce the PRNG environment that produced any private keys,		reproduce the PRNG environment that produced any private keys,
	searching the resulting small set of possibilities, rather than		searching the resulting small set of possibilities, rather than
	brute-force searching the whole key space. The generation of random		brute-force searching the whole key space. The generation of random
	numbers of a sufficient level of quality for use in cryptography is		numbers of a sufficient level of quality for use in cryptography is
	difficult; see Section 3.6.1 of [FIPS204] for some additional		difficult; see Section 3.6.1 of [FIPS204] for some additional
	information.		information.
	skipping to change at line 343 ¶		skipping to change at line 342 ¶
	sources: fresh random data generated during signature generation, and		sources: fresh random data generated during signature generation, and
	precomputed random data included in the signer's private key. This		precomputed random data included in the signer's private key. This
	is referred to as the "hedged" variant of ML-DSA. Inclusion of both		is referred to as the "hedged" variant of ML-DSA. Inclusion of both
	sources of random data can help mitigate against faulty random number		sources of random data can help mitigate against faulty random number
	generators, side-channel attacks, and fault attacks. [FIPS204] also		generators, side-channel attacks, and fault attacks. [FIPS204] also
	permits creating deterministic signatures using just the precomputed		permits creating deterministic signatures using just the precomputed
	random data in the signer's private key. The same verification		random data in the signer's private key. The same verification
	algorithm is used to verify both hedged and deterministic signatures,		algorithm is used to verify both hedged and deterministic signatures,
	so this choice does not affect interoperability. The signer SHOULD		so this choice does not affect interoperability. The signer SHOULD
	NOT use the deterministic variant of ML-DSA on platforms where side-		NOT use the deterministic variant of ML-DSA on platforms where side-
	channel attacks or fault attacks are a concern. Side channel attacks		channel attacks or fault attacks are a concern. Side-channel attacks
	and fault attacks against ML-DSA are an active area of research		and fault attacks against ML-DSA are an active area of research
	[WNGD2023] [KPLG2024]. Future protection against these styles of		[WNGD2023] [KPLG2024]. Future protection against these styles of
	attack may involve interoperable changes to the implementation of ML-		attack may involve interoperable changes to the implementation of ML-
	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. 9 change blocks.
	25 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.48.