Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
Extracted elements (24)
HashML-DSA (the pre-hash variant of ML-DSA) is not specified for CMS use. Since CMS signed attributes are typically small and already embed a hash of the content, supplying a pre-hash to ML-DSA would not meaningfully reduce the data signed by the algorithm and thus provides no benefit.
Including signed attributes when using ML-DSA in hardware devices (HSMs, tokens) is recommended for performance: only the small signed-attributes set needs to be transmitted to the device rather than the full content. Alternatively, the internal 'μ' message representative defined in FIPS 204 Section 6.2 may be computed externally and supplied to the device.
This document specifies only the pure mode of ML-DSA (not HashML-DSA pre-hash mode) for use with CMS, following the precedent of EdDSA and SLH-DSA. CMS signatures are typically computed over signed attributes (which are small and already contain a hash of the content), so pre-hash mode offers no meaningful size reduction and hence no benefit.
ML-DSA and its predecessor Dilithium are not compatible. Implementations migrating from Dilithium cannot interoperate directly with ML-DSA implementations.
SHA-512 is designated as the mandatory-to-implement digest algorithm to provide an interoperable baseline for legacy CMS implementations that support existing hash functions but may not yet support SHA-3 derivatives at the CMS layer.
The same AlgorithmIdentifier OIDs are used for ML-DSA public keys, signature algorithms in X.509 certificates, and CMS signed-data; RFC 9881 governs the X.509 certificate usage while this document governs CMS usage.
At minimum, the signedAttrs field MUST include a content-type attribute and a message-digest attribute. The message-digest attribute contains a hash of the encapContentInfo eContent, and recalculation by the recipient is an important step in signature verification.
SHA-512 MUST be supported for use with all ML-DSA variants in this document, providing an interoperable option for legacy CMS implementations migrating to post-quantum cryptography. When SHA-512 is used, the parameters field MUST be omitted.
SHAKE256 SHOULD be supported as the digest algorithm, as it is the digest used internally in ML-DSA. When SHAKE256 is used, the id-shake256 identifier is used and the parameters field MUST be omitted; SHAKE256 produces 512 bits of output in this context.
The ML-DSA context string input is set to the empty string when using ML-DSA as specified in this document.
The parameters field MUST be omitted when encoding an ML-DSA AlgorithmIdentifier, because each ML-DSA parameter set is identified by its own OID and there is no relevant parameter information.
Verifiers MAY reject a signature if the signer's choice of digest algorithm does not meet the security requirements of the chosen ML-DSA parameter set. A suitable digest algorithm must offer λ bits of security against second-preimage and collision attacks and produce at least 2×λ bits of output.
When signed attributes are absent, ML-DSA pure mode signatures are computed over the value of the encapContentInfo eContent OCTET STRING (tag and length octets not included). When signed attributes are present, signatures are computed over the complete DER encoding of SignedAttrs with an EXPLICIT SET OF tag.
When signing without signed attributes, implementations MUST specify SHA-512 as the digestAlgorithm to minimize interoperability failures. When processing such a SignerInfo, implementations MUST ignore the content of the digestAlgorithm field, since ML-DSA operates over the entire message.
ML-DSA is specified for use in CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87, each identified by a distinct OID assigned from the NIST CSOR registry (id-ml-dsa-44 = sigAlgs 17, id-ml-dsa-65 = sigAlgs 18, id-ml-dsa-87 = sigAlgs 19).
Suitable digest algorithms are parameterized by the collision strength λ of each ML-DSA variant: ML-DSA-44 supports SHA-256/384/512, SHA3-256/384/512, SHAKE128/256; ML-DSA-65 supports SHA-384/512, SHA3-384/512, SHAKE256; ML-DSA-87 supports SHA-512, SHA3-512, SHAKE256.
The ASN.1 module ML-DSA-Module-2024 expands the CMS SignatureAlgorithmSet to include sa-ml-dsa-44, sa-ml-dsa-65, and sa-ml-dsa-87 (imported from RFC 9881), and similarly extends SMimeCaps with the corresponding smimeCaps values.
The signatureAlgorithm field in SignerInfo MUST contain one of the three ML-DSA OIDs (id-ml-dsa-44, id-ml-dsa-65, id-ml-dsa-87) and the parameters field MUST be absent. The signature field contains the raw ML-DSA signature value per FIPS 204 Sections 5.2 and 5.3.
IANA has assigned OID decimal 83 (id-mod-ml-dsa-2024) in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for the ASN.1 module defined in this document.
By default ML-DSA uses a 'hedged' signing mode combining fresh random data with precomputed private-key randomness to mitigate faulty RNGs, side-channel attacks, and fault attacks. The signer SHOULD NOT use the deterministic variant on platforms where side-channel or fault attacks are a concern.
ML-DSA private key security is critical; compromise enables forgery of arbitrary signatures. ML-DSA requires high-quality cryptographic random numbers, and inadequate PRNGs can significantly undermine security by reducing the effective key space an attacker needs to search.
Side-channel and fault attacks against ML-DSA are an active research area. Implementers SHOULD consider implementing protection measures such as hedged signing and other countermeasures against these attack styles if relevant to their use case.
To prevent algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in RFC 6211 SHOULD be included in signed attributes when using ML-DSA in CMS.
The AlgorithmIdentifier for ML-DSA is an ASN.1 SEQUENCE containing an algorithm OID field (one of id-ml-dsa-44/65/87) and an OPTIONAL parameters field that MUST be omitted for ML-DSA.