Summary

  • Without signed attributes, RFC 9882 requires SHA-512 in SignerInfo.digestAlgorithm for interoperability but requires a verifier to ignore that field; pure ML-DSA signs the content octets directly.
  • With signed attributes, the content digest does matter: it sits in a signed attribute, must be recalculated and can limit the effective strength of the construction.
  • A useful assurance record must preserve the branch, exact signed bytes, parameter-set OID, digest comparison, algorithm protection, key and external-μ boundaries, authorization and downstream action as separate facts.

Imagine a compliance export with three green lines: digestAlgorithm = SHA-512, signatureAlgorithm = ML-DSA-65, and signature valid. The lines may all be accurate. They still do not establish that SHA-512 digested the content for the ML-DSA operation, that the private key stayed in a hardware module, or that the signer was entitled to approve the subsequent act.

The branch determines the meaning

RFC 9882, published as an IETF Proposed Standard in October 2025, specifies how the three FIPS 204 parameter sets—ML-DSA-44, ML-DSA-65 and ML-DSA-87—are used in the Cryptographic Message Syntax. Each has its own signature-algorithm object identifier, and parameters in that AlgorithmIdentifier must be absent. The document covers pure ML-DSA. It does not define CMS use of HashML-DSA. ML-DSA was formerly called Dilithium, but the two are not wire-compatible.

The operational centre of the specification is a fork created by signedAttrs.

When signed attributes are absent, the ML-DSA input is the octets that form the value of encapContentInfo eContent's OCTET STRING. The tag and length octets are not included. Pure ML-DSA processes that message directly. In this branch, RFC 9882 says the SignerInfo.digestAlgorithm field has no meaning for the signature calculation.

Yet the field cannot be left to chance. A signer must place SHA-512 there to minimise interoperability failures, and a verifier must ignore the field's contents. The required value is therefore a compatibility convention, not a trace of an external hashing step. A parser can report it correctly while an analyst interprets it incorrectly.

Signed attributes change the path. The signature input becomes the complete DER encoding of the SignedAttrs value, including tag and length, using the EXPLICIT SET OF tag rather than the IMPLICIT [0] tag carried in the final message. The attributes must include at least content-type and message-digest. The latter contains a hash of the content, so the recipient must compute that digest again and compare it. On this path the digest selection is consequential, and a weak digest can cap the strength of the wider construction. RFC 9882 mandates SHA-512 support and recommends SHAKE256 support; SHAKE256 parameters must be absent.

That difference is small in syntax and large in evidence. A verdict that does not first record whether signedAttrs existed cannot explain what the digest field meant, which bytes reached ML-DSA, or whether content-digest equality was checked. “Valid signature” collapses several decisions that the standard keeps separate.

The signature boundary is not the authority boundary

Algorithm identity needs its own proof. The verifier must read the ML-DSA parameter-set OID and reject prohibited parameters. RFC 6211's CMSAlgorithmProtection attribute places relevant algorithm identifiers inside signed attributes. RFC 9882 says it should be included to resist algorithm-substitution attacks. Its presence and consistency are distinct findings: neither can be inferred merely because the mathematical signature verified.

The private-key boundary is separate again. Compromise of an ML-DSA signing key permits forgery. FIPS 204 defines a default hedged signing mode that combines fresh randomness with private-key material, while also allowing deterministic signing. RFC 9882 cautions against deterministic signing on platforms exposed to side-channel or fault attacks. A CMS object does not reveal, by itself, which randomness policy was used or how well it was implemented.

Hardware does not collapse this distinction. With signed attributes, an application can send the smaller DER attribute set rather than the whole content to a hardware security module. Pure ML-DSA also allows the message representative μ to be calculated in another cryptographic module and supplied to the signer. That may be a sound architecture. It means, however, that “signature generated in the HSM” is not proof that the HSM saw the original content or computed μ. The interface and the binding to the retained bytes become part of the evidence.

A replayable evidence chain

The defensible record is a chain: retain the exact CMS object; parse content type and attribute presence; reconstruct the exact signature input; identify the parameter-set OID; reject forbidden parameters; where attributes exist, recalculate and compare the content digest; check algorithm protection; verify the signature; record randomness and μ boundaries where known; then evaluate certificate path, signer identity and application authorization. The final business action belongs after those steps, not inside the word “valid.”

Sources