]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Bundesdruckerei GmbH

Kommandantenstr. 18 Berlin 10969 Germany jan.klaussner@bdr.de

CryptoNext Security

‍16, Boulevard Saint-Germain Paris 75007 France daniel.vangeest@cryptonext-security.com

Security LAMPS cms composite ml-dsa Composite 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). 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 LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines a collection of signature algorithms, referred to as Composite ML-DSA, which combine ML-DSA with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. This document acts as a companion to by providing conventions for using Composite ML-DSA algorithms within the Cryptographic Message Syntax (CMS) .

Conventions and Terminology 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. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This document is consistent with the terminology defined in .

Composite ML-DSA Algorithm Identifiers The same AlgorithmIdentifier is used to identify a Composite ML-DSA public key and signature algorithm. The object identifiers for Composite ML-DSA algorithms are defined in , 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.

Signed-Data Conventions

Pre-Hashing 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 RFC 5652 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 and ML-DSA have also been standardized, and these algorithms support both a "pure" and "pre-hash" mode, although their use in CMS has only been defined for "pure" mode. Composite ML-DSA operates only in a "pre-hash" mode. However, 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 for the internal component algorithms, e.g., in the case of id-MLDSA87-ECDSA-P384-SHA512 the traditional component uses SHA-384. These internal digest algorithms are irrelevant to Composite ML-DSA's use in CMS.

SignedData digestAlgorithms The SignedData digestAlgorithms field includes the identifiers of the message digest algorithms used by one or more signer. When signing with a Composite ML-DSA algorithm, this list of identifiers SHOULD include the corresponding digest algorithm from .

Signature Generation and Verification 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 signed-data without signed attributes is 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 , 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 , 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 absent signed attributes case above. Recalculation of the hash value by the recipient is an important step in signature verification. Composite ML-DSA has a context string input that can be used to ensure that different signatures are generated for different application contexts. When using Composite ML-DSA as specified in this document, the context string is set to the empty string.

SignerInfo Content When using Composite 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. This MUST be the same digest algorithm used by the Composite ML-DSA algorithm. Per , if the signedAttrs field is present in the SignerInfo, then the same digest algorithm MUST be used to compute both the digest of the SignedData encapContentInfo eContent, which is carried in the message-digest attribute, and the digest of the DER-encoded signedAttrs, which is passed to the signature algorithm. See for exact algorithm mappings.

defines the use of SHA-256 (id-sha256) and SHA-512 (id-sha512) in CMS. defines the use of SHAKE256 in CMS (id-shake256). When id-sha256 or id-sha512 is used, the parameters field MUST be omitted. When id-shake256 is used the parameters field MUST be omitted and the digest length MUST be 64 bytes.

Digest Algorithms for Composite ML-DSA

Signature Algorithm	Digest Algorithms
id-MLDSA44-RSA2048-PSS-SHA256	id-sha256
id-MLDSA44-RSA2048-PKCS15-SHA256	id-sha256
id-MLDSA44-Ed25519-SHA512	id-sha512
id-MLDSA44-ECDSA-P256-SHA256	id-sha256
id-MLDSA65-RSA3072-PSS-SHA512	id-sha512
id-MLDSA65-RSA3072-PKCS15-SHA512	id-sha512
id-MLDSA65-RSA4096-PSS-SHA512	id-sha512
id-MLDSA65-RSA4096-PKCS15-SHA512	id-sha512
id-MLDSA65-ECDSA-P256-SHA512	id-sha512
id-MLDSA65-ECDSA-P384-SHA512	id-sha512
id-MLDSA65-ECDSA-brainpoolP256r1-SHA512	id-sha512
id-MLDSA65-Ed25519-SHA512	id-sha512
id-MLDSA87-ECDSA-P384-SHA512	id-sha512
id-MLDSA87-ECDSA-brainpoolP384r1-SHA512	id-sha512
id-MLDSA87-Ed448-SHAKE256	id-shake256
id-MLDSA87-RSA3072-PSS-SHA512	id-sha512
id-MLDSA87-RSA4096-PSS-SHA512	id-sha512
id-MLDSA87-ECDSA-P521-SHA512	id-sha512

signatureAlgorithm:

The signatureAlgorithm field MUST contain one of the Composite ML-DSA signature algorithm OIDs, and the parameters field MUST be absent. The algorithm OID MUST be one of the OIDs described in .

signature:

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

ASN.1 Module Composite-MLDSA-CMS-2026 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-composite-mldsa-cms-2026(TBDMOD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS SIGNATURE-ALGORITHM, SMIME-CAPS FROM AlgorithmInformation-2009 -- [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-MLDSA44-RSA2048-PSS-SHA256, sa-MLDSA44-RSA2048-PKCS15-SHA256, sa-MLDSA44-Ed25519-SHA512, sa-MLDSA44-ECDSA-P256-SHA256, sa-MLDSA65-RSA3072-PSS-SHA512, sa-MLDSA65-RSA3072-PKCS15-SHA512, sa-MLDSA65-RSA4096-PSS-SHA512, sa-MLDSA65-RSA4096-PKCS15-SHA512, sa-MLDSA65-ECDSA-P256-SHA512, sa-MLDSA65-ECDSA-P384-SHA512, sa-MLDSA65-ECDSA-brainpoolP256r1-SHA512, sa-MLDSA65-Ed25519-SHA512, sa-MLDSA87-ECDSA-P384-SHA512, sa-MLDSA87-ECDSA-brainpoolP384r1-SHA512, sa-MLDSA87-Ed448-SHAKE256, sa-MLDSA87-RSA3072-PSS-SHA512, sa-MLDSA87-RSA4096-PSS-SHA512, sa-MLDSA87-ECDSA-P521-SHA512 FROM Composite-MLDSA-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-composite-mldsa-2025(TBDCompositeMOD) } ; -- -- Expand the signature algorithm set used by CMS [RFC5911] -- SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { sa-MLDSA44-RSA2048-PSS-SHA256 | sa-MLDSA44-RSA2048-PKCS15-SHA256 | sa-MLDSA44-Ed25519-SHA512 | sa-MLDSA44-ECDSA-P256-SHA256 | sa-MLDSA65-RSA3072-PSS-SHA512 | sa-MLDSA65-RSA3072-PKCS15-SHA512 | sa-MLDSA65-RSA4096-PSS-SHA512 | sa-MLDSA65-RSA4096-PKCS15-SHA512 | sa-MLDSA65-ECDSA-P256-SHA512 | sa-MLDSA65-ECDSA-P384-SHA512 | sa-MLDSA65-ECDSA-brainpoolP256r1-SHA512 | sa-MLDSA65-Ed25519-SHA512 | sa-MLDSA87-ECDSA-P384-SHA512 | sa-MLDSA87-ECDSA-brainpoolP384r1-SHA512 | sa-MLDSA87-Ed448-SHAKE256 | sa-MLDSA87-RSA3072-PSS-SHA512 | sa-MLDSA87-RSA4096-PSS-SHA512 | sa-MLDSA87-ECDSA-P521-SHA512, ... } -- -- Expand the S/MIME capabilities set used by CMS [RFC5911] -- SMimeCaps SMIME-CAPS ::= { sa-MLDSA44-RSA2048-PSS-SHA256.&smimeCaps | sa-MLDSA44-RSA2048-PKCS15-SHA256.&smimeCaps | sa-MLDSA44-Ed25519-SHA512.&smimeCaps | sa-MLDSA44-ECDSA-P256-SHA256.&smimeCaps | sa-MLDSA65-RSA3072-PSS-SHA512.&smimeCaps | sa-MLDSA65-RSA3072-PKCS15-SHA512.&smimeCaps | sa-MLDSA65-RSA4096-PSS-SHA512.&smimeCaps | sa-MLDSA65-RSA4096-PKCS15-SHA512.&smimeCaps | sa-MLDSA65-ECDSA-P256-SHA512.&smimeCaps | sa-MLDSA65-ECDSA-P384-SHA512.&smimeCaps | sa-MLDSA65-ECDSA-brainpoolP256r1-SHA512.&smimeCaps | sa-MLDSA65-Ed25519-SHA512.&smimeCaps | sa-MLDSA87-ECDSA-P384-SHA512.&smimeCaps | sa-MLDSA87-ECDSA-brainpoolP384r1-SHA512.&smimeCaps | sa-MLDSA87-Ed448-SHAKE256.&smimeCaps | sa-MLDSA87-RSA3072-PSS-SHA512.&smimeCaps | sa-MLDSA87-RSA4096-PSS-SHA512.&smimeCaps | sa-MLDSA87-ECDSA-P521-SHA512.&smimeCaps, ... } END ]]>

IANA Considerations IANA is requested to allocate a value from the "SMI Security for PKIX Module Identifier" registry for the included ASN.1 module.

• Decimal: IANA Assigned - Replace TBDCompositeMOD
• Description: Composite-Signatures-CMS-2026 - id-mod-composite-mldsa-cms-2026
• References: This Document

Security Considerations All security considerations from apply. Security of the Composite ML-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures. Composite 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; see Section 3.6.1 of for some additional information. To avoid algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in SHOULD be included in signed attributes.

References Normative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) Entrust Entrust OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST ML-DSA in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. 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. This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected. 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 ITU-T One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. 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. The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST 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 syntax is provided. When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.

Examples This appendix contains an example signed-data encoding with the id-MLDSA65-ECDSA-P256-SHA512 signature algorithm. It can be verified using the example public keys and certificates specified in . Specifically, the following example:

• tcId: id-MLDSA65-ECDSA-P256-SHA512
• x5c: Base64 of the DER encoding of the certificate. Wrap this in PEM headers and footers to get a PEM certificate.

To keep example size down, the signing certificate is not included in the CMS encoding. The example certificate from used to sign the CMS content is self-signed. The following is an example of a signed-data with a single id-MLDSA65-ECDSA-P256-SHA512 signer, with signed attributes included:

Acknowledgements The authors wish to thank Piotr Popis (Enigma) for his valuable feedback on this document. Thanks to the co-authors of , Ben Salter and Adam Raine, this document borrows heavily from that one. "Copying always makes things easier and less error prone" - .