RFC 9882: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
- B. Salter,
- A. Raine,
- D. Van Geest
Abstract
The Module
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
The Module
Prior to standardisation
For each of the ML-DSA parameter sets, an algorithm identifier OID has been specified.¶
[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 document. See Section 3.1 for more details.¶
1.1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2. ML-DSA Algorithm Identifiers
Many ASN.1 data structure types use the Algorithm
The fields in the Algorithm
- algorithm:
-
The algorithm field contains an OID that identifies the cryptographic algorithm in use. The OIDs for ML-DSA are described below.¶
- parameters:
-
The parameters field contains parameter information for the algorithm identified by the OID in the algorithm field. Each ML-DSA parameter set is identified by its own algorithm OID, so there is no relevant information to include in this field. As such, parameters MUST be omitted when encoding an ML-DSA Algorithm
Identifier .¶
The object identifiers for ML-DSA are defined in the NIST Computer Security Objects Register [CSOR], and are reproduced here for convenience.¶
3. Signed-Data Conventions
3.1. Pure Mode Versus Pre-Hash Mode
[RFC5652] specifies that digital signatures for CMS are produced 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 supported in the CMS required a message digest to be calculated externally to that algorithm, which would then be supplied to the algorithm implementation when calculating and verifying signatures. Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also been standardised, and these algorithms support both a "pure" and a "pre-hash" mode. In the pre-hash mode, a message digest (the "pre-hash") is calculated separately and supplied to the signature algorithm as described above. In the pure mode, the message to be signed or verified is instead supplied directly to the signature algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with CMS, only the pure mode of those algorithms is specified. This is because in most situations, CMS signatures are computed over a set of signed attributes that contain a hash of the content, rather than being computed over the message content itself. Since signed attributes are typically small, use of pre-hash modes in the CMS wouldn't significantly reduce the size of the data to be signed, and hence offers no benefit. This document follows that convention and does not specify the use of ML-DSA's pre-hash mode ("HashML-DSA") in the CMS.¶
3.2. Signature Generation and Verification
[RFC5652] describes the two methods that are used to calculate and verify signatures in the CMS. One method is used when signed attributes are present in the signedAttrs field of the relevant SignerInfo, and another is used when signed attributes are absent. Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of ML-DSA is used, the "message digest" is in fact the entire message. Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness.¶
When signed attributes are absent, ML-DSA (pure mode) signatures are computed over the content of the signed-data.
As described in Section 5.4 of [RFC5652], the "content" of a signed-data is the value of the encap
When signed attributes are included, ML-DSA (pure mode) signatures are computed over the complete DER encoding of the SignedAttrs value contained in the SignerInfo's signedAttrs field. As described in Section 5.4 of [RFC5652], this encoding includes the tag and length octets, but an EXPLICIT SET OF tag is used rather than the IMPLICIT [0] tag that appears in the final message. At a minimum, the signedAttrs field MUST include a content-type attribute and a message-digest attribute. The message-digest attribute contains a hash of the content of the signed-data, where the content is as described for the absent signed attributes case above. Recalculation of the hash value by the recipient is an important step in signature verification.¶
Section 4 of [RFC9814] describes how, when the content of a signed-data is large, performance may be improved by including signed attributes. This is as true for ML-DSA as it is for SLH-DSA, although ML-DSA signature generation and verification is significantly faster than SLH-DSA.¶
ML-DSA has a context string input that can be used to ensure that different signatures are generated for different application contexts. When using ML-DSA as specified in this document, the context string is set to the empty string.¶
3.3. SignerInfo Content
When using ML-DSA, the fields of a SignerInfo are used as follows:¶
- digestAlgorithm:
-
Per Section 5.3 of [RFC5652], the digestAlgorithm field identifies the message digest algorithm used by the signer and any associated parameters. Each ML-DSA parameter set has a collision strength parameter, represented by the "λ" (GREEK SMALL LETTER LAMDA, U+03BB) symbol in [FIPS204]. When signers utilise signed attributes, their choice of digest algorithm may impact the overall security level of their signature. Selecting a digest algorithm that offers λ bits of security strength against second preimage attacks and collision attacks is sufficient to meet the security level offered by a given parameter set, so long as the digest algorithm produces at least 2 * λ bits of output. The overall security strength offered by an ML-DSA signature calculated over signed attributes is constrained by either the digest algorithm's strength or the strength of the ML-DSA parameter set, whichever is lower. Verifiers MAY reject a signature if the signer's choice of digest algorithm does not meet the security requirements of their choice of ML-DSA 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 ML-DSA in this document. SHA-512 is suitable for all ML-DSA parameter sets and provides an interoperable option for legacy CMS implementations that wish to migrate to use post-quantum cryptography, but that may not support use of SHA-3 derivatives at the CMS layer. However, other hash functions MAY also be supported; in particular, SHAKE256 SHOULD be supported, as this is the digest algorithm used internally in ML-DSA. When SHA-512 is used, the id-sha512 [RFC5754] digest algorithm identifier is used and the parameters field MUST be omitted. When SHAKE256 is used, the id-shake256 [RFC8702] digest algorithm identifier is used and the parameters field MUST be omitted. SHAKE256 produces 512 bits of output when used as a message digest algorithm in the CMS.¶
When signing using ML-DSA without including signed attributes, the algorithm specified in the digestAlgorithm field has no meaning, as ML-DSA computes signatures over entire messages rather than externally computed digests. As such, the considerations above and in Table 1 do not apply. Nonetheless, in this case implementations MUST specify SHA-512 as the digestAlgorithm in order to minimise the likelihood of an interoperabilit
y failure. When processing a SignerInfo signed using ML-DSA, if no signed attributes are present, implementations MUST ignore the content of the digestAlgorithm field.¶ - signature
Algorithm : -
The signature
Algorithm field MUST contain one of the ML-DSA signature algorithm OIDs, and the parameters field MUST be absent. The algorithm OID MUST be one of the following OIDs described in Section 2:¶ - signature:
-
The signature field contains the signature value resulting from the use of the ML-DSA signature algorithm identified by the signature
Algorithm field. The ML-DSA (pure mode) signature -generation operation is specified in Section 5.2 of [FIPS204], and the signature -verification operation is specified in Section 5.3 of [FIPS204]. Note that Section 5.6 of [RFC5652] places further requirements on the successful verification of a signature.¶
4. Security Considerations
The security considerations in [RFC5652] and [RFC9881] apply to this specification.¶
Security of the ML-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures.¶
ML-DSA depends on high-quality random numbers that are suitable for use in cryptography. The use of inadequate pseudo-random number generators (PRNGs) to generate such values can significantly undermine the security properties offered by a cryptographic algorithm. For instance, an attacker may find it much easier to reproduce the PRNG environment that produced any private keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of random numbers of a sufficient level of quality for use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for some additional information.¶
By default, ML-DSA signature generation uses randomness from two sources: fresh random data generated during signature generation, and precomputed random data included in the signer's private key.
This is referred to as the "hedged" variant of ML-DSA.
Inclusion of both sources of random data can help mitigate against faulty random number generators, side-channel attacks, and fault attacks.
[FIPS204] also permits creating deterministic signatures using just the precomputed random data in the signer's private key.
The same verification algorithm is used to verify both hedged and deterministic signatures, so this choice does not affect interoperabilit
To avoid algorithm substitution attacks, the CMSAlgorithm
5. Operational Considerations
If ML-DSA signing is implemented in a hardware device such as a hardware security module (HSM) or a portable cryptographic token, implementers might want to avoid sending the full content to the device for performance reasons. By including signed attributes, which necessarily includes the message-digest attribute and 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 signing.¶
Additionally, the pure variant of ML-DSA does support a form of pre-hash via external calculation of the "μ" (GREEK SMALL LETTER MU, U+03BC) "message representative" value described in Section 6.2 of [FIPS204]. This value may "optionally be computed in a different cryptographic module" and supplied to the hardware device, rather than requiring the entire message to be transmitted. Appendix D of [RFC9881] describes use of external μ calculations in further detail.¶
6. IANA Considerations
For the ASN.1 module in Appendix A, IANA has assigned the following object identifier in the "SMI Security for S/MIME Module Identifier
7. References
7.1. Normative References
- [CSOR]
-
NIST, "Computer Security Objects Register (CSOR)", , <https://
csrc >..nist .gov /projects /computer -security -objects -register /algorithm -registration - [FIPS204]
-
NIST, "Module
-Lattice , NIST FIPS 204, DOI 10-Based Digital Signature Standard" .6028 , , <https:///NIST .FIPS .204 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .204 .pdf - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC5652]
-
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10
.17487 , , <https:///RFC5652 www >..rfc -editor .org /info /rfc5652 - [RFC5754]
-
Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10
.17487 , , <https:///RFC5754 www >..rfc -editor .org /info /rfc5754 - [RFC6211]
-
Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute", RFC 6211, DOI 10
.17487 , , <https:///RFC6211 www >..rfc -editor .org /info /rfc6211 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8702]
-
Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)", RFC 8702, DOI 10
.17487 , , <https:///RFC8702 www >..rfc -editor .org /info /rfc8702 - [RFC9881]
-
Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module
-Lattice , RFC 9881, DOI 10-Based Digital Signature Algorithm (ML-DSA)" .17487 , , <https:///RFC9881 www >..rfc -editor .org /info /rfc9881
7.2. Informative References
- [FIPS180]
-
NIST, "Secure Hash Standard", NIST FIPS 180-4, DOI 10
.6028 , , <https:///NIST .FIPS .180 -4 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .180 -4 .pdf - [FIPS205]
-
NIST, "Stateless Hash-Based Digital Signature Standard", NIST FIPS 205, DOI 10
.6028 , , <https:///NIST .FIPS .205 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .205 .pdf - [KPLG2024]
-
Krahmer, E., Pessl, P., Land, G., and T. Güneysu, "Correction Fault Attacks on Randomized CRYSTALS
-Dilithium" , Cryptology ePrint Archive, Paper 2024/138, , <https://ia >..cr /2024 /138 - [RFC5280]
-
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10
.17487 , , <https:///RFC5280 www >..rfc -editor .org /info /rfc5280 - [RFC5911]
-
Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10
.17487 , , <https:///RFC5911 www >..rfc -editor .org /info /rfc5911 - [RFC8032]
-
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10
.17487 , , <https:///RFC8032 www >..rfc -editor .org /info /rfc8032 - [RFC8419]
-
Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10
.17487 , , <https:///RFC8419 www >..rfc -editor .org /info /rfc8419 - [RFC9814]
-
Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", RFC 9814, DOI 10
.17487 , , <https:///RFC9814 www >..rfc -editor .org /info /rfc9814 - [WNGD2023]
-
Wang, R., Ngo, K., Gärtner, J., and E. Dubrova, "Single-Trace Side-Channel Attacks on CRYSTALS
-Dilithium , Cryptology ePrint Archive, Paper 2023/1931, , <https://: Myth or Reality?" ia >..cr /2023 /1931 - [X680]
-
ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, , <https://
www >..itu .int /rec /T -REC -X .680
Appendix B. Examples
This appendix contains example signed-data encodings. They can be verified using the example public keys and certificates specified in Appendix C of [RFC9881].¶
The following is an example of a signed-data with a single ML-DSA-44 signer, with signed attributes included:¶
The following is an example of a signed-data with a single ML-DSA-65 signer, with signed attributes included:¶
The following is an example of a signed-data with a single ML-DSA-87 signer, with signed attributes included:¶
Acknowledgments
The authors would like to thank the following people for their contributions and reviews that helped shape this document: Viktor Dukhovni, Russ Housley, Panos Kampanakis, Mike Ounsworth, Falko Strenzke, Sean Turner, and Wei-Jun Wang.¶
This document was heavily influenced by [RFC8419], [RFC9814], and [RFC9881]. Thanks go to the authors of those documents.¶