RFC 10082: Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for Use in the Cryptographic Message Syntax (CMS) | RFC Editor

The Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) defines combinations of ML-DSA with RSA, ECDSA, and EdDSA. This document specifies the conventions for using Composite ML-DSA algorithms within the Cryptographic Message Syntax (CMS).¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
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/rfc10082.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC10073] defines a collection of signature algorithms, referred to as Composite ML-DSA, which combine ML-DSA [FIPS.204] with RSASSA-PKCS1-v1.5 [RFC8017], RSASSA-PSS [RFC8017], ECDSA (Section 6 of [FIPS.186-5]), Ed25519 [RFC8410], and Ed448 [RFC8410]. This document acts as a companion to [RFC10073] by providing conventions for using Composite ML-DSA algorithms within the Cryptographic Message Syntax (CMS) [RFC5652].¶
CMS values are generated using ASN.1 [X.680], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The same AlgorithmIdentifier is used to identify a Composite ML-DSA public key and signature algorithm. The object identifiers (OIDs) for Composite ML-DSA algorithms are defined in [RFC10073] and are reproduced here for convenience. The parameters field of the AlgorithmIdentifier for the Composite ML-DSA public key and signature algorithm MUST be absent.¶
[RFC5652] 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 [RFC5652] was published, all signature algorithms supported in the 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 [RFC8032] and ML-DSA [FIPS.204] have also been standardized, and these algorithms support both a "pure" and a "pre-hash" mode, although their use in CMS has only been defined for "pure" mode.¶
Composite ML-DSA only provides a "pre-hash" mode. Unlike RSA and ECDSA, each Composite ML-DSA algorithm is defined to be used with a single digest algorithm, which is identified in the Composite ML-DSA algorithm name. For example, id-MLDSA87-ECDSA-P521-SHA512 uses SHA-512 as its pre-hash digest algorithm.¶
When Composite ML-DSA is used in CMS, the digest algorithm used by CMS SHALL be the same pre-hash digest algorithm used by the Composite ML-DSA algorithm. A Composite ML-DSA algorithm might use additional digest algorithms internally, e.g., in the case of id-MLDSA87-ECDSA-P384-SHA512, the ECDSA component uses SHA-384. These internal digest algorithms are irrelevant to Composite ML-DSA's use in CMS.¶
The SignedData digestAlgorithms field includes the identifiers of the message digest algorithms used by one or more signers. When signing with a Composite ML-DSA algorithm, this list of identifiers SHOULD include the corresponding digest algorithm from Table 1. The field is intended to list the message digest algorithms employed by all of the signers, to facilitate one-pass signature verification. If the corresponding digest algorithm from Table 1 is not listed, a one-pass verifier might not successfully verify the Composite ML-DSA signature.¶
[RFC5652] describes the two methods that are used to calculate and verify signatures in the 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. Use of signed attributes is preferred, but the conventions for the signed-data content type without signed attributes are also described below for completeness.¶
When signed attributes are absent, Composite ML-DSA signatures are 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 of the encapContentInfo eContent OCTET STRING. The tag and length octets are not included.¶
When signed attributes are included, Composite ML-DSA signatures are computed over the complete DER encoding of the SignedAttrs value contained in the SignerInfo's signedAttrs field. As described in 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 [0] tag that appears in the final message. At a minimum, the signedAttrs field MUST 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 case with absent signed attributes above. Recalculation of the hash value by the recipient is an important step in signature verification.¶
Composite ML-DSA has a context st