]> UK National Cyber Security Centre

ben.s3@ncsc.gov.uk

UK National Cyber Security Centre

adam.r@ncsc.gov.uk

CryptoNext Security

daniel.vangeest@cryptonext-security.com

Security Limited Additional Mechanisms for PKIX and SMIME cms ml-dsa dilithium The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a digital signature algorithm standardised by NIST as part of their post-quantum cryptography standardization process. It is intended to be secure against both "traditional" cryptographic attacks, as well as attacks utilising a quantum computer. It offers smaller signatures and significantly faster runtimes than SLH-DSA , an alternative post-quantum signature algorithm also standardised by NIST. This document specifies the use of the ML-DSA in CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See 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 Dilithium are not compatible. For each of the ML-DSA parameter sets, an algorithm identifier OID has been specified. also specifies a pre-hashed variant of ML-DSA, called HashML-DSA. Use of HashML-DSA in CMS is not specified in this document.

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 when, and only when, they appear in all capitals, as shown here.

ML-DSA Algorithm Identifiers Many ASN.1 data structure types use the AlgorithmIdentifier type to identify cryptographic algorithms. In CMS, AlgorithmIdentifiers are used to identify ML-DSA signatures in the signed-data content type. They may also appear in X.509 certificates used to verify those signatures. The same AlgorithmIdentifiers are used to identify ML-DSA public keys and signature algorithms. describes the use of ML-DSA in X.509 certificates. The AlgorithmIdentifier type is defined as follows: The fields in the AlgorithmIdentifier type have the following meanings:

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 AlgorithmIdentifier.

The object identifiers for ML-DSA are defined in the NIST Computer Security Objects Register , and are reproduced here for convenience.

Signed-data Conventions

Pure mode vs pre-hash mode 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 of publication of that RFC, all signature algorithms supported in 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 , SLH-DSA and ML-DSA have also been standardised, and these algorithms support both a "pure" and "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 and SLH-DSA 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 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 CMS.

Signature generation and verification describes the two methods that are used to calculate and verify signatures in 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 , the "content" of a signed-data is the value of the encapContentInfo eContent OCTET STRING. The tag and length octets are not included. 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 , 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. The signedAttrs field MUST at minimum 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. 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 described in this document, the context string is not used.

SignerInfo content When using ML-DSA, the fields of a SignerInfo are used as follows:

digestAlgorithm:

Per , 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 λ (lambda) symbol in . 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 λ (lambda) 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λ (twice lambda) bits of output. The overall security strength offered by an ML-DSA signature calculated over signed attributes is the floor of the digest algorithm's strength and the strength of the ML-DSA parameter set. 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. shows appropriate SHA-2 and SHA-3 digest algorithms for each parameter set.

SHA-512 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 digest algorithm identifier is used and the parameters field MUST be omitted. When SHAKE256 is used, the id-shake256 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 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 do not apply. Nonetheless, in this case implementations MUST specify SHA-512 as the digestAlgorithm in order to minimise the likelihood of an interoperability failure. When processing a SignerInfo signed using ML-DSA, if no signed attributes are present, implementations MUST ignore the content of the digestAlgorithm field.

Suitable digest algorithms for ML-DSA

Signature algorithm	Digest Algorithms
ML-DSA-44	SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256
ML-DSA-65	SHA-384, SHA-512, SHA3-384, SHA3-512, SHAKE256
ML-DSA-87	SHA-512, SHA3-512, SHAKE256

signatureAlgorithm:

The signatureAlgorithm 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 :

Signature algorithm identifier OIDs for ML-DSA

Signature algorithm	Algorithm Identifier OID
ML-DSA-44	id-ml-dsa-44
ML-DSA-65	id-ml-dsa-65
ML-DSA-87	id-ml-dsa-87

signature:

The signature field contains the signature value resulting from the use of the ML-DSA signature algorithm identified by the signatureAlgorithm field. The ML-DSA (pure mode) signature generation operation is specified in Section 5.2 of , and the signature verification operation is specified in Section 5.3 of . Note that places further requirements on the successful verification of a signature.

Security Considerations The security considerations and apply to this specification as well. 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, and offers important guidance in this area. 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 can help mitigate against faulty random number generators, side-channel attacks and fault attacks. 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 interoperability. The signer SHOULD NOT use the deterministic variant of ML-DSA on platforms where side-channel attacks or fault attacks are a concern. Side channel attacks and fault attacks against ML-DSA are an active area of research . Future protection against these styles of attack may involve interoperable changes to the implementation of ML-DSA's internal functions. Implementers SHOULD consider implementing such protection measures if it would be beneficial for their particular use cases. To avoid algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in SHOULD be included in signed attributes.

Operational Considerations If ML-DSA signing is implemented in a hardware device such as hardware security module (HSM) or portable cryptographic token, implementers might want to avoid sending the full content to the device for performance reasons. By including signed attributes, which necessarily include the message-digest attribute and the content-type attribute as described in Section 5.3 of , 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 𝜇 (mu) "message representative" value described in Section 6.2 of . 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 describes use of external 𝜇 (mu) calculations in further detail.

IANA Considerations For the ASN.1 module found in , IANA is requested to assign an object identifier for the module identifier (TBD1) with a description of "id-mod-ml-dsa-2024". This should be allocated in the "SMI Security for S/MIME Module Identifier" registry (1.2.840.113549.1.9.16.0).

Acknowledgments This document was heavily influenced by , , and . Thanks go to the authors of those documents.

References Normative References National Institute of Standards and Technology (U.S.) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK] This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described. The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK] Informative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. ITU-T This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. Vigil Security, LLC Cisco Systems Amazon Web Services Cloudflare SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

ASN.1 Module ML-DSA-Module-2024 { 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) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS SIGNATURE-ALGORITHM, SMIME-CAPS FROM AlgorithmInformation-2009 -- in [RFC5911] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } sa-ml-dsa-44, sa-ml-dsa-65, sa-ml-dsa-87 FROM X509-ML-DSA-2024 -- From [I-D.ietf-lamps-dilithium-certificates] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-x509-ml-dsa-2024(TBD2) } ; -- -- Expand the signature algorithm set used by CMS [RFC5911] -- SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { sa-ml-dsa-44 | sa-ml-dsa-65 | sa-ml-dsa-87, ... } SMimeCaps SMIME-CAPS ::= { sa-ml-dsa-44.&smimeCaps | sa-ml-dsa-65.&smimeCaps | sa-ml-dsa-87.&smimeCaps, ... } END ]]>

Examples This appendix contains example signed-data encodings. They can be verified using the example public keys and certificates specified in Appendix C of . 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: