rfc9882.original   rfc9882.txt 
Limited Additional Mechanisms for PKIX and SMIME B. Salter Internet Engineering Task Force (IETF) B. Salter
Internet-Draft A. Raine Request for Comments: 9882 A. Raine
Intended status: Standards Track UK National Cyber Security Centre Category: Standards Track UK National Cyber Security Centre
Expires: 5 April 2026 D. Van Geest ISSN: 2070-1721 D. Van Geest
CryptoNext Security CryptoNext Security
2 October 2025 October 2025
Use of the ML-DSA Signature Algorithm in the Cryptographic Message Use of the ML-DSA Signature Algorithm in the Cryptographic Message
Syntax (CMS) Syntax (CMS)
draft-ietf-lamps-cms-ml-dsa-07
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 and public key syntax are provided.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://lamps-
wg.github.io/cms-ml-dsa/draft-ietf-lamps-cms-ml-dsa.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/.
Discussion of this document takes place on the Limited Additional
Mechanisms for PKIX and SMIME 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-ml-dsa.
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 5 April 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/rfc9882.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 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 Definitions . . . . . . . . . . . . . . . 3 1.1. Conventions and Definitions
2. ML-DSA Algorithm Identifiers . . . . . . . . . . . . . . . . 3 2. ML-DSA Algorithm Identifiers
3. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 4 3. Signed-Data Conventions
3.1. Pure mode vs pre-hash mode . . . . . . . . . . . . . . . 4 3.1. Pure Mode Versus Pre-Hash Mode
3.2. Signature generation and verification . . . . . . . . . . 5 3.2. Signature Generation and Verification
3.3. SignerInfo content . . . . . . . . . . . . . . . . . . . 6 3.3. SignerInfo Content
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations
5. Operational Considerations . . . . . . . . . . . . . . . . . 9 5. Operational Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. ASN.1 Module
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Examples
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 digital signature algorithm standardised by the US National Institute
of Standards and Technology (NIST) as part of their post-quantum of Standards and Technology (NIST) as part of their post-quantum
cryptography standardisation process. It is intended to be secure cryptography standardisation process. It is intended to be secure
against both "traditional" cryptographic attacks, as well as attacks against both "traditional" cryptographic attacks, as well as attacks
utilising a quantum computer. It offers smaller signatures and utilising a quantum computer. It offers smaller signatures and
significantly faster runtimes than SLH-DSA [FIPS205], an alternative significantly faster runtimes than SLH-DSA [FIPS205], an alternative
post-quantum signature algorithm also standardised by NIST. This post-quantum signature algorithm also standardised by NIST. This
document specifies the use of the ML-DSA in the CMS at three security document specifies the use of the ML-DSA in the CMS at three security
levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See Appendix B of levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See Appendix B of
[I-D.ietf-lamps-dilithium-certificates] for more information on the [RFC9881] for more information on the security levels and key sizes
security levels and key sizes of ML-DSA. 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 page 3, line 45 skipping to change at line 111
BCP 14 [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.
2. ML-DSA Algorithm Identifiers 2. ML-DSA Algorithm Identifiers
Many ASN.1 data structure types use the AlgorithmIdentifier type to Many ASN.1 data structure types use the AlgorithmIdentifier type to
identify cryptographic algorithms. In the CMS, AlgorithmIdentifiers identify cryptographic algorithms. In the CMS, AlgorithmIdentifiers
are used to identify ML-DSA signatures in the signed-data content are used to identify ML-DSA signatures in the signed-data content
type. They may also appear in X.509 certificates used to verify type. They may also appear in X.509 certificates used to verify
those signatures. The same AlgorithmIdentifiers are used to identify those signatures. The same AlgorithmIdentifiers are used to identify
ML-DSA public keys and signature algorithms. ML-DSA public keys and signature algorithms. [RFC9881] describes the
[I-D.ietf-lamps-dilithium-certificates] describes the use of ML-DSA use of ML-DSA in X.509 certificates. The AlgorithmIdentifier type is
in X.509 certificates. The AlgorithmIdentifier type is defined as defined as follows:
follows:
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE { SEQUENCE {
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}), algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE. parameters ALGORITHM-TYPE.
&Params({AlgorithmSet}{@algorithm}) OPTIONAL &Params({AlgorithmSet}{@algorithm}) OPTIONAL
} }
| NOTE: The above syntax is from [RFC5911] and is compatible with | NOTE: The above syntax is from [RFC5911] and is compatible with
| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 | the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
skipping to change at page 4, line 43 skipping to change at line 153
sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 3 } us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 3 }
id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 } id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 }
id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 } id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 }
id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 } id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 }
3. Signed-data Conventions 3. Signed-Data Conventions
3.1. Pure mode vs 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 of publication of that RFC, all signature key. At the time RFC 5652 was published, all signature algorithms
algorithms supported in the CMS required a message digest to be supported in the CMS required a message digest to be calculated
calculated externally to that algorithm, which would then be supplied externally to that algorithm, which would then be supplied to the
to the algorithm implementation when calculating and verifying algorithm implementation when calculating and verifying signatures.
signatures. Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML- Since then, EdDSA [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also
DSA have also been standardised, and these algorithms support both a been standardised, and these algorithms support both a "pure" and
"pure" and "pre-hash" mode. In the pre-hash mode, a message digest "pre-hash" mode. In the pre-hash mode, a message digest (the "pre-
(the "pre-hash") is calculated separately and supplied to the hash") is calculated separately and supplied to the signature
signature algorithm as described above. In the pure mode, the algorithm as described above. In the pure mode, the message to be
message to be signed or verified is instead supplied directly to the signed or verified is instead supplied directly to the signature
signature algorithm. When EdDSA [RFC8419] and SLH-DSA algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with
[I-D.ietf-lamps-cms-sphincs-plus] are used with CMS, only the pure CMS, only the pure mode of those algorithms is specified. This is
mode of those algorithms is specified. This is because in most because in most situations, CMS signatures are computed over a set of
situations, CMS signatures are computed over a set of signed signed attributes that contain a hash of the content, rather than
attributes that contain a hash of the content, rather than being being computed over the message content itself. Since signed
computed over the message content itself. Since signed attributes attributes are typically small, use of pre-hash modes in the CMS
are typically small, use of pre-hash modes in the CMS wouldn't wouldn't significantly reduce the size of the data to be signed, and
significantly reduce the size of the data to be signed, and hence hence offers no benefit. This document follows that convention and
offers no benefit. This document follows that convention and does does not specify the use of ML-DSA's pre-hash mode ("HashML-DSA") in
not specify the use of ML-DSA's pre-hash mode ("HashML-DSA") in the the CMS.
CMS.
3.2. Signature generation and verification 3.2. Signature Generation and Verification
[RFC5652] describes the two methods that are used to calculate and [RFC5652] describes the two methods that are used to calculate and
verify signatures in the CMS. One method is used when signed verify signatures in the CMS. One method is used when signed
attributes are present in the signedAttrs field of the relevant attributes are present in the signedAttrs field of the relevant
SignerInfo, and another is used when signed attributes are absent. SignerInfo, and another is used when signed attributes are absent.
Each method produces a different "message digest" to be supplied to Each method produces a different "message digest" to be supplied to
the signature algorithm in question, but because the pure mode of ML- 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 DSA is used, the "message digest" is in fact the entire message. Use
of signed attributes is preferred, but the conventions for signed- of signed attributes is preferred, but the conventions for signed-
data without signed attributes is also described below for data without signed attributes is also described below for
skipping to change at page 5, line 46 skipping to change at line 204
computed over the content of the signed-data. As described in 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 Section 5.4 of [RFC5652], the "content" of a signed-data is the value
of the encapContentInfo eContent OCTET STRING. The tag and length of the encapContentInfo eContent OCTET STRING. The tag and length
octets are not included. octets are not included.
When signed attributes are included, ML-DSA (pure mode) signatures When signed attributes are included, ML-DSA (pure mode) signatures
are computed over the complete DER encoding of the SignedAttrs value are computed over the complete DER encoding of the SignedAttrs value
contained in the SignerInfo's signedAttrs field. As described in contained in the SignerInfo's signedAttrs field. As described in
Section 5.4 of [RFC5652], this encoding includes the tag and length 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 octets, but an EXPLICIT SET OF tag is used rather than the IMPLICIT
[0] tag that appears in the final message. The signedAttrs field [0] tag that appears in the final message. At a minimum, the
MUST at minimum include a content-type attribute and a message-digest signedAttrs field MUST include a content-type attribute and a
attribute. The message-digest attribute contains a hash of the message-digest attribute. The message-digest attribute contains a
content of the signed-data, where the content is as described for the hash of the content of the signed-data, where the content is as
absent signed attributes case above. Recalculation of the hash value described for the absent signed attributes case above. Recalculation
by the recipient is an important step in signature verification. of the hash value by the recipient is an important step in signature
verification.
Section 4 of [I-D.ietf-lamps-cms-sphincs-plus] describes how, when Section 4 of [RFC9814] describes how, when the content of a signed-
the content of a signed-data is large, performance may be improved by data is large, performance may be improved by including signed
including signed attributes. This is as true for ML-DSA as it is for attributes. This is as true for ML-DSA as it is for SLH-DSA,
SLH-DSA, although ML-DSA signature generation and verification is although ML-DSA signature generation and verification is
significantly faster than SLH-DSA. significantly faster than SLH-DSA.
ML-DSA has a context string input that can be used to ensure that ML-DSA has a context string input that can be used to ensure that
different signatures are generated for different application different signatures are generated for different application
contexts. When using ML-DSA as specified in this document, the contexts. When using ML-DSA as specified in this document, the
context string is set to the empty string. context string is set to the empty string.
3.3. SignerInfo content 3.3. SignerInfo Content
When using ML-DSA, the fields of a SignerInfo are used as follows: When using ML-DSA, the fields of a SignerInfo are used as follows:
digestAlgorithm: Per Section 5.3 of [RFC5652], the digestAlgorithm digestAlgorithm: Per Section 5.3 of [RFC5652], the digestAlgorithm
field identifies the message digest algorithm used by the signer, field identifies the message digest algorithm used by the signer
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 λ (lambda) symbol collision strength parameter, represented by the "λ" (GREEK SMALL
in [FIPS204]. When signers utilise signed attributes, their LETTER LAMDA, U+03BB) symbol in [FIPS204]. When signers utilise
choice of digest algorithm may impact the overall security level signed attributes, their choice of digest algorithm may impact the
of their signature. Selecting a digest algorithm that offers λ overall security level of their signature. Selecting a digest
bits of security strength against second preimage attacks and algorithm that offers λ bits of security strength against second
collision attacks is sufficient to meet the security level offered preimage attacks and collision attacks is sufficient to meet the
by a given parameter set, so long as the digest algorithm produces security level offered by a given parameter set, so long as the
at least 2 * λ bits of output. The overall security strength digest algorithm produces at least 2 * λ bits of output. The
offered by an ML-DSA signature calculated over signed attributes overall security strength offered by an ML-DSA signature
is the floor of the digest algorithm's strength and the strength calculated over signed attributes is the floor of the digest
of the ML-DSA parameter set. Verifiers MAY reject a signature if algorithm's strength and is the strength of the ML-DSA parameter
the signer's choice of digest algorithm does not meet the security set. Verifiers MAY reject a signature if the signer's choice of
requirements of their choice of ML-DSA parameter set. Table 1 digest algorithm does not meet the security requirements of their
shows appropriate SHA-2 and SHA-3 digest algorithms for each choice of ML-DSA parameter set. Table 1 shows appropriate SHA-2
parameter set. 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 page 7, line 16 skipping to change at line 271
algorithm specified in the digestAlgorithm field has no meaning, algorithm specified in the digestAlgorithm field has no meaning,
as ML-DSA computes signatures over entire messages rather than as ML-DSA computes signatures over entire messages rather than
externally computed digests. As such, the considerations above externally computed digests. As such, the considerations above
and in Table 1 do not apply. Nonetheless, in this case and in Table 1 do not apply. Nonetheless, in this case
implementations MUST specify SHA-512 as the digestAlgorithm in implementations MUST specify SHA-512 as the digestAlgorithm in
order to minimise the likelihood of an interoperability failure. order to minimise the likelihood of an interoperability failure.
When processing a SignerInfo signed using ML-DSA, if no signed When processing a SignerInfo signed using ML-DSA, if no signed
attributes are present, implementations MUST ignore the content of attributes are present, implementations MUST ignore the content of
the digestAlgorithm field. the digestAlgorithm field.
+=====================+========================================+ +=====================+========================================+
| Signature algorithm | Digest Algorithms | | Signature Algorithm | Digest Algorithms |
+=====================+========================================+ +=====================+========================================+
| ML-DSA-44 | SHA-256, SHA-384, SHA-512, SHA3-256, | | ML-DSA-44 | SHA-256, SHA-384, SHA-512, SHA3-256, |
| | SHA3-384, SHA3-512, SHAKE128, SHAKE256 | | | SHA3-384, SHA3-512, SHAKE128, SHAKE256 |
+---------------------+----------------------------------------+ +---------------------+----------------------------------------+
| ML-DSA-65 | SHA-384, SHA-512, SHA3-384, SHA3-512, | | ML-DSA-65 | SHA-384, SHA-512, SHA3-384, SHA3-512, |
| | SHAKE256 | | | SHAKE256 |
+---------------------+----------------------------------------+ +---------------------+----------------------------------------+
| ML-DSA-87 | SHA-512, SHA3-512, SHAKE256 | | ML-DSA-87 | SHA-512, SHA3-512, SHAKE256 |
+---------------------+----------------------------------------+ +---------------------+----------------------------------------+
Table 1: Suitable digest algorithms for ML-DSA Table 1: Suitable Digest Algorithms for ML-DSA
signatureAlgorithm: The signatureAlgorithm field MUST contain one of signatureAlgorithm: The signatureAlgorithm field MUST contain one of
the ML-DSA signature algorithm OIDs, and the parameters field MUST the ML-DSA signature algorithm OIDs, and the parameters field MUST
be absent. The algorithm OID MUST be one of the following OIDs be absent. The algorithm OID MUST be one of the following OIDs
described in Section 2: described in Section 2:
+=====================+==========================+ +=====================+==========================+
| Signature algorithm | Algorithm Identifier OID | | Signature Algorithm | Algorithm Identifier OID |
+=====================+==========================+ +=====================+==========================+
| ML-DSA-44 | id-ml-dsa-44 | | ML-DSA-44 | id-ml-dsa-44 |
+---------------------+--------------------------+ +---------------------+--------------------------+
| ML-DSA-65 | id-ml-dsa-65 | | ML-DSA-65 | id-ml-dsa-65 |
+---------------------+--------------------------+ +---------------------+--------------------------+
| ML-DSA-87 | id-ml-dsa-87 | | ML-DSA-87 | id-ml-dsa-87 |
+---------------------+--------------------------+ +---------------------+--------------------------+
Table 2: Signature algorithm identifier OIDs Table 2: Signature Algorithm Identifier OIDs
for ML-DSA for ML-DSA
signature: The signature field contains the signature value signature: The signature field contains the signature value
resulting from the use of the ML-DSA signature algorithm resulting from the use of the ML-DSA signature algorithm
identified by the signatureAlgorithm field. The ML-DSA (pure identified by the signatureAlgorithm field. The ML-DSA (pure
mode) signature generation operation is specified in Section 5.2 mode) signature-generation operation is specified in Section 5.2
of [FIPS204], and the signature verification operation is of [FIPS204], and the signature-verification operation is
specified in Section 5.3 of [FIPS204]. Note that Section 5.6 of specified in Section 5.3 of [FIPS204]. Note that Section 5.6 of
[RFC5652] places further requirements on the successful [RFC5652] places further requirements on the successful
verification of a signature. verification of a signature.
4. Security Considerations 4. Security Considerations
The security considerations in [RFC5652] and The security considerations in [RFC5652] and [RFC9881] apply to this
[I-D.ietf-lamps-dilithium-certificates] 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 brute searching the resulting small set of possibilities, rather than
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.
By default, ML-DSA signature generation uses randomness from two By default, ML-DSA signature generation uses randomness from two
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 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 If ML-DSA signing is implemented in a hardware device such as the
hardware security module (HSM) or portable cryptographic token, hardware security module (HSM) or 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 include 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 μ (mu) "message representative" hash via external calculation of the "μ" (GREEK SMALL LETTER MU,
value described in Section 6.2 of [FIPS204]. This value may U+03BC) "message representative" value described in Section 6.2 of
"optionally be computed in a different cryptographic module" and [FIPS204]. This value may "optionally be computed in a different
supplied to the hardware device, rather than requiring the entire cryptographic module" and supplied to the hardware device, rather
message to be transmitted. Appendix D of than requiring the entire message to be transmitted. Appendix D of
[I-D.ietf-lamps-dilithium-certificates] describes use of external μ [RFC9881] describes use of external μ calculations in further detail.
calculations in further detail.
6. IANA Considerations 6. IANA Considerations
For the ASN.1 module found in Appendix A, IANA is requested to assign For the ASN.1 module in Appendix A, IANA has assigned the following
an object identifier for the module identifier (TBD1) with a object identifier in the "SMI Security for S/MIME Module Identifier
description of "id-mod-ml-dsa-2024". This should be allocated in the (1.2.840.113549.1.9.16.0)" registry:
"SMI Security for S/MIME Module Identifier" registry
(1.2.840.113549.1.9.16.0).
7. Acknowledgments
The authors would like to thank the following people for their +=========+====================+===========+
contributions and reviews that helped shape this document: Viktor | Decimal | Description | Refernece |
Dukhovni, Russ Housley, Panos Kampanakis, Mike Ounsworth, Falko +=========+====================+===========+
Strenzke, Sean Turner, and Wei-Jun Wang. | 83 | id-mod-ml-dsa-2024 | RFC 9882 |
+---------+--------------------+-----------+
This document was heavily influenced by [RFC8419], Table 3
[I-D.ietf-lamps-cms-sphincs-plus], and
[I-D.ietf-lamps-dilithium-certificates]. Thanks go to the authors of
those documents.
8. References 7. References
8.1. Normative References 7.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>.
[FIPS204] "Module-lattice-based digital signature standard", [FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard",
National Institute of Standards and Technology (U.S.), NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
DOI 10.6028/nist.fips.204, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
<https://doi.org/10.6028/nist.fips.204>. NIST.FIPS.204.pdf>.
[I-D.ietf-lamps-dilithium-certificates]
Massimo, J., Kampanakis, P., Turner, S., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", Work in Progress, Internet-
Draft, draft-ietf-lamps-dilithium-certificates-13, 30
September 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-dilithium-certificates-13>.
[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>.
[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>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/rfc/rfc5754>. 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm [RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm
Identifier Protection Attribute", RFC 6211, Identifier Protection Attribute", RFC 6211,
DOI 10.17487/RFC6211, April 2011, DOI 10.17487/RFC6211, April 2011,
<https://www.rfc-editor.org/rfc/rfc6211>. <https://www.rfc-editor.org/info/rfc6211>.
[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>.
[RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash
Functions in the Cryptographic Message Syntax (CMS)", Functions in the Cryptographic Message Syntax (CMS)",
RFC 8702, DOI 10.17487/RFC8702, January 2020, RFC 8702, DOI 10.17487/RFC8702, January 2020,
<https://www.rfc-editor.org/rfc/rfc8702>. <https://www.rfc-editor.org/info/rfc8702>.
8.2. Informative References [RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
[FIPS180] "Secure hash standard", National Institute of Standards 7.2. Informative References
and Technology (U.S.), DOI 10.6028/nist.fips.180-4, 2015,
<https://doi.org/10.6028/nist.fips.180-4>.
[FIPS205] "Stateless hash-based digital signature standard", [FIPS180] NIST, "Secure Hash Standard", NIST FIPS 180-4,
National Institute of Standards and Technology (U.S.), DOI 10.6028/NIST.FIPS.180-4, August 2015,
DOI 10.6028/nist.fips.205, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
<https://doi.org/10.6028/nist.fips.205>. NIST.FIPS.180-4.pdf>.
[I-D.ietf-lamps-cms-sphincs-plus] [FIPS205] NIST, "Stateless Hash-Based Digital Signature Standard",
Housley, R., Fluhrer, S., Kampanakis, P., and B. NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024,
Westerbaan, "Use of the SLH-DSA Signature Algorithm in the <https://nvlpubs.nist.gov/nistpubs/FIPS/
Cryptographic Message Syntax (CMS)", Work in Progress, NIST.FIPS.205.pdf>.
Internet-Draft, draft-ietf-lamps-cms-sphincs-plus-19, 13
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-cms-sphincs-plus-19>.
[KPLG2024] Krahmer, E., Pessl, P., Land, G., and T. Güneysu, [KPLG2024] Krahmer, E., Pessl, P., Land, G., and T. Güneysu,
"Correction Fault Attacks on Randomized CRYSTALS- "Correction Fault Attacks on Randomized CRYSTALS-
Dilithium", 2024, <https://ia.cr/2024/138>. Dilithium", Cryptology ePrint Archive, Paper 2024/138,
2024, <https://ia.cr/2024/138>.
[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>.
[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>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature
Algorithm (EdDSA) Signatures in the Cryptographic Message Algorithm (EdDSA) Signatures in the Cryptographic Message
Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
2018, <https://www.rfc-editor.org/rfc/rfc8419>. 2018, <https://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/RFC9814, July 2025,
<https://www.rfc-editor.org/info/rfc9814>.
[WNGD2023] Wang, R., Ngo, K., Gärtner, J., and E. Dubrova, "Single- [WNGD2023] Wang, R., Ngo, K., Gärtner, J., and E. Dubrova, "Single-
Trace Side-Channel Attacks on CRYSTALS-Dilithium: Myth or Trace Side-Channel Attacks on CRYSTALS-Dilithium: Myth or
Reality?", 2023, <https://ia.cr/2023/1931>. Reality?", Cryptology ePrint Archive, Paper 2023/1931,
2023, <https://ia.cr/2023/1931>.
[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 (2021) | ISO/IEC 8824-1:2021.", Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
February 2021, <https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
| RFC EDITOR: Please replace the reference to
| [I-D.ietf-lamps-dilithium-certificates] in the ASN.1 module
| below with a reference the corresponding published RFC.
<CODE BEGINS> <CODE BEGINS>
ML-DSA-Module-2024 ML-DSA-Module-2024
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-mod(0) id-mod-ml-dsa-2024(TBD1) } id-smime(16) id-mod(0) id-mod-ml-dsa-2024(83) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS SIGNATURE-ALGORITHM, SMIME-CAPS IMPORTS SIGNATURE-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [RFC5911] FROM AlgorithmInformation-2009 -- in [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) }
sa-ml-dsa-44, sa-ml-dsa-65, sa-ml-dsa-87 sa-ml-dsa-44, sa-ml-dsa-65, sa-ml-dsa-87
FROM X509-ML-DSA-2024 -- From [I-D.ietf-lamps-dilithium-certificates] FROM X509-ML-DSA-2024 -- From [RFC9881]
{ 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-x509-ml-dsa-2024(119) } ; id-mod-x509-ml-dsa-2024(119) } ;
-- --
-- Expand the signature algorithm set used by CMS [RFC5911] -- Expand the signature algorithm set used by CMS [RFC5911]
-- --
SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= {
sa-ml-dsa-44 | sa-ml-dsa-44 |
skipping to change at page 13, line 9 skipping to change at line 535
sa-ml-dsa-87.&smimeCaps, sa-ml-dsa-87.&smimeCaps,
... } ... }
END END
<CODE ENDS> <CODE ENDS>
Appendix B. Examples Appendix B. Examples
This appendix contains example signed-data encodings. They can be This appendix contains example signed-data encodings. They can be
verified using the example public keys and certificates specified in verified using the example public keys and certificates specified in
Appendix C of [I-D.ietf-lamps-dilithium-certificates]. Appendix C of [RFC9881].
The following is an example of a signed-data with a single ML-DSA-44 The following is an example of a signed-data with a single ML-DSA-44
signer, with signed attributes included: signer, with signed attributes included:
-----BEGIN CMS----- -----BEGIN CMS-----
MIIKsAYJKoZIhvcNAQcCoIIKoTCCCp0CAQExDTALBglghkgBZQMEAgMwQwYJKoZI MIIKsAYJKoZIhvcNAQcCoIIKoTCCCp0CAQExDTALBglghkgBZQMEAgMwQwYJKoZI
hvcNAQcBoDYENE1MLURTQS00NCBzaWduZWQtZGF0YSBleGFtcGxlIHdpdGggc2ln hvcNAQcBoDYENE1MLURTQS00NCBzaWduZWQtZGF0YSBleGFtcGxlIHdpdGggc2ln
bmVkIGF0dHJpYnV0ZXMxggpCMIIKPgIBATA6MCIxDTALBgNVBAoTBElFVEYxETAP bmVkIGF0dHJpYnV0ZXMxggpCMIIKPgIBATA6MCIxDTALBgNVBAoTBElFVEYxETAP
BgNVBAMTCExBTVBTIFdHAhQVn/5vIv1cxCxSTfb9XijQ3jjzTjALBglghkgBZQME BgNVBAMTCExBTVBTIFdHAhQVn/5vIv1cxCxSTfb9XijQ3jjzTjALBglghkgBZQME
AgOgazAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBME8GCSqGSIb3DQEJBDFCBEAL AgOgazAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBME8GCSqGSIb3DQEJBDFCBEAL
skipping to change at page 29, line 50 skipping to change at line 1345
593310d2fb29ce08f1eb39195a000e18868d9ab0b2d3b2e7f901086aa3bec320 593310d2fb29ce08f1eb39195a000e18868d9ab0b2d3b2e7f901086aa3bec320
5161818e98aeb1bdccd2d943b6d7e5093b63bfc4de0112292d4f6c8dd0dcec1a 5161818e98aeb1bdccd2d943b6d7e5093b63bfc4de0112292d4f6c8dd0dcec1a
32444e5e6f8e99c4ff000000000000000000000000000000090c121e2228323c 32444e5e6f8e99c4ff000000000000000000000000000000090c121e2228323c
` } ` }
} }
} }
} }
} }
} }
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.
Authors' Addresses Authors' Addresses
Ben Salter Ben Salter
UK National Cyber Security Centre UK National Cyber Security Centre
Email: ben.s3@ncsc.gov.uk Email: ben.s3@ncsc.gov.uk
Adam Raine Adam Raine
UK National Cyber Security Centre UK National Cyber Security Centre
Email: adam.r@ncsc.gov.uk Email: adam.r@ncsc.gov.uk
Daniel Van Geest Daniel Van Geest
CryptoNext Security CryptoNext Security
 End of changes. 61 change blocks. 
228 lines changed or deleted 205 lines changed or added

This html diff was produced by rfcdiff 1.48.