Summary

  • RFC 9882 specifies pure ML-DSA-44, ML-DSA-65, and ML-DSA-87 for CMS SignedData, but does not specify HashML-DSA.
  • The two SignerInfo paths sign different bytes: eContent value octets without signedAttrs, or complete DER SignedAttrs when signedAttrs exists.

The complete OIDs are 2.16.840.1.101.3.4.3.17, 2.16.840.1.101.3.4.3.18, and 2.16.840.1.101.3.4.3.19; ML-DSA AlgorithmIdentifier parameters MUST be omitted. The ML-DSA context string is empty.

With signedAttrs, a digest must provide the parameter set's lambda bits against both second-preimage and collision attacks and produce at least 2*lambda output bits. The lower of digest and ML-DSA strength caps the signature. Table 1 is complete: 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. SHA-512 support is mandatory and SHAKE256 support is recommended; both identifiers omit parameters.

Two-path byte fixture. Path A exists when signedAttrs is absent. It signs only the eContent OCTET STRING value octets: the tag and length octets are excluded. For interoperability, the signer encodes SHA-512 in digestAlgorithm, although that field has no cryptographic meaning on Path A; the verifier ignores its content. Path A has no content-type, no message-digest, and no signed-attribute message-digest or content-hash recalculation requirement. Path B exists when signedAttrs is present. It signs the complete DER encoding of SignedAttrs, including tag and length and the explicit SET OF tag, never the final implicit [0]. Path B includes at least content-type and message-digest; only Path B requires the recipient to recalculate the content hash and compare it with message-digest.

CMSAlgorithmProtection SHOULD be included in signedAttrs to resist algorithm substitution. This is a normative recommendation, not a deployment claim. Large content may remain outside an HSM signing boundary. External computation of pure-mode message representative mu is permitted and detailed by RFC 9881 Appendix D and FIPS 204 Section 6.2. HSM interface controls and rollout proposals are Theo March analysis. Hedged and deterministic signatures use the same verifier; deterministic signing SHOULD NOT be used where side-channel or fault attacks are a concern.

Operational reading

The normative boundary is RFC 9882, RFC 5652, RFC 6211, RFC 9881, and FIPS 204. Theo March analysis proposes capturing path, byte hashes and lengths, OID, omitted parameters, wrapper tag, attribute presence, digest identifier, content-hash comparison, HSM result, and verification outcome. Staged enablement, shadow verification, rollback tests, and ownership controls are recommendations, not RFC mandates or adoption evidence. RFC 9881 concerns PKIX certificate and key-container encoding, not this CMS SignerInfo byte-domain rule; RFC 9879 is outside this briefing's scope.

Sources