RFC 9882: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
Author: Ben Salter
Description: 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.

RFC 9882 | ML-DSA in the CMS | October 2025
Salter, et al. | Standards Track | [Page]

Stream:
  Internet Engineering Task Force (IETF)
RFC:
  9882
Category:
  Standards Track
Published:
  October 2025
ISSN:
  2070-1721
Authors:
  B. Salter
  UK National Cyber Security Centre
  A. Raine
  UK National Cyber Security Centre
  D. Van Geest
  CryptoNext Security

# RFC 9882

# Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)

## Abstract

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.¶

## Status of This Memo

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/rfc9882.¶

## Copyright Notice

Copyright (c) 2025 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.¶

## 1. Introduction

The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a post-quantum digital signature algorithm standardised by the US National Institute of Standards and Technology (NIST) as part of their post-quantum cryptography standardisation process. It offers smaller signatures and significantly faster runtimes than SLH-DSA [FIPS205], an alternative post-quantum signature algorithm also standardised by NIST. This document specifies the use of ML-DSA in the CMS at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. See Appendix B of [RFC9881] for more information on the security levels and key sizes of ML-DSA.¶

Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Dilithium are not compatible.¶

For each of the ML-DSA parameter sets, an algorithm identifier OID has been specified.¶

[FIPS204] also specifies a pre-hashed variant of ML-DSA, called HashML-DSA. Use of HashML-DSA in the CMS is not specified in this document. See Section 3.1 for more details.¶

### 1.1. Conventions and Definitions

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.¶

## 2. ML-DSA Algorithm Identifiers

Many ASN.1 data structure types use the AlgorithmIdentifier type to identify cryptographic algorithms. In the CMS, AlgorithmIdentifiers are used to identify ML-DSA signatures in the signed-data content type. They may also appear in X.509 certificates used to verify those signatures. The same AlgorithmIdentifiers are used to identify ML-DSA public keys and signature algorithms. [RFC9881] describes the use of ML-DSA in X.509 certificates. The AlgorithmIdentifier type is defined as follows:¶

    AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
            SEQUENCE {
                algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
                parameters  ALGORITHM-TYPE.
                       &Params({AlgorithmSet}{@algorithm}) OPTIONAL
            }

¶

NOTE: The above syntax is from [RFC5911] and is compatible with the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 syntax.¶

The fields in the AlgorithmIdentifier type have the following meanings:¶

algorithm:

  The algorithm field contains an OID that identifies the cryptographic algorithm in use. The OIDs for ML-DSA are described below.¶

parameters:

  The parameters field contains parameter information for the algorithm identified by the OID in the algorithm field. Each ML-DSA parameter set is identified by its own algorithm OID, so there is no relevant information to include in this field. As such, parameters MUST be omitted when encoding an ML-DSA AlgorithmIdentifier.¶

The object identifiers for ML-DSA are defined in the NIST Computer Security Objects Register [CSOR], and are reproduced here for convenience.¶

    sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
        us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 3 }

    id-ml-dsa-44 OBJECT IDENTIFIER ::= { sigAlgs 17 }

    id-ml-dsa-65 OBJECT IDENTIFIER ::= { sigAlgs 18 }

    id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 }

¶

## 3. Signed-Data Conventions

### 3.1. Pure Mode Versus Pre-Hash Mode

[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 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 [RFC8032], SLH-DSA [FIPS205] and ML-DSA have also been standardised, and these algorithms support both a "pure" and a "pre-hash" mode. In the pre-hash mode, a message digest (the "pre-hash") is calculated separately and supplied to the signature algorithm as described above. In the pure mode, the message to be signed or verified is instead supplied directly to the signature algorithm. When EdDSA [RFC8419] and SLH-DSA [RFC9814] are used with CMS, only the pure mode of those algorithms is specified. This is because in most situations, CMS signatures are computed over a set of signed attributes that contain a hash of the content, rather than being computed over the message content itself. Since signed attributes are typically small, use of pre-hash modes in the CMS wouldn't significantly reduce the size of the data to be signed, and hence offers no benefit. This document follows that convention and does not specify the use of ML-DSA's pre-hash mode ("HashML-DSA") in the CMS.¶

### 3.2. Signature Generation and Verification

[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. Each method produces a different "message digest" to be supplied to the signature algorithm in question, but because the pure mode of ML-DSA is used, the "message digest" is in fact the entire message. 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, ML-DSA (pure mode) 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, ML-DSA (pure mode) 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 absent signed attributes case above. Recalculation of the hash value by the recipient is an important step in signature verification.¶

Section 4 of [RFC9814] describes how, when the content of a signed-data is large, performance may be improved by including signed attributes. This is as true for ML-DSA as it is for SLH-DSA, although ML-DSA signature generation and verification is significantly faster than SLH-DSA.¶

ML-DSA has a context string input that can be used to ensure that different signatures are generated for different application contexts. When using ML-DSA as specified in this document, the context string is set to the empty string.¶

### 3.3. SignerInfo Content

When using ML-DSA, the fields of a SignerInfo are used as follows:¶

digestAlgorithm:

  Per Section 5.3 of [RFC5652], the digestAlgorithm field identifies the message digest algorithm used by the signer and any associated parameters. Each ML-DSA parameter set has a collision strength parameter, represented by the "λ" (GREEK SMALL LETTER LAMDA, U+03BB) symbol in [FIPS204]. When signers utilise signed attributes, their choice of digest algorithm may impact the overall security level of their signature. Selecting a digest algorithm that offers λ bits of security strength against second preimage attacks and collision attacks is sufficient to meet the security level offered by a given parameter set, so long as the digest algorithm produces at least 2 * λ bits of output. The overall security strength offered by an ML-DSA signature calculated over signed attributes is constrained by either the digest algorithm's strength or the strength of the ML-DSA parameter set, whichever is lower. Verifiers MAY reject a signature if the signer's choice of digest algorithm does not meet the security requirements of their choice of ML-DSA parameter set. Table 1 shows appropriate SHA-2 and SHA-3 digest algorithms for each parameter set.¶

  SHA-512 [FIPS180] MUST be supported for use with the variants of ML-DSA in this document. SHA-512 is suitable for all ML-DSA parameter sets and provides an interoperable option for legacy CMS implementations that wish to migrate to use post-quantum cryptography, but that may not support use of SHA-3 derivatives at the CMS layer. However, other hash functions MAY also be supported; in particular, SHAKE256 SHOULD be supported, as this is the digest algorithm used internally in ML-DSA. When SHA-512 is used, the id-sha512 [RFC5754] digest algorithm identifier is used and the parameters field MUST be omitted. When SHAKE256 is used, the id-shake256 [RFC8702] digest algorithm identifier is used and the parameters field MUST be omitted. SHAKE256 produces 512 bits of output when used as a message digest algorithm in the CMS.¶

  When signing using ML-DSA without including signed attributes, the algorithm specified in the digestAlgorithm field has no meaning, as ML-DSA computes signatures over entire messages rather than externally computed digests. As such, the considerations above and in Table 1 do not apply. Nonetheless, in this case implementations MUST specify SHA-512 as the digestAlgorithm in order to minimise the likelihood of an interoperability failure. When processing a SignerInfo signed using ML-DSA, if no signed attributes are present, implementations MUST ignore the content of the digestAlgorithm field.¶

  Table 1: Suitable Digest Algorithms for ML-DSA
  Signature Algorithm | Digest Algorithms
  --- | ---
  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

signatureAlgorithm:

  The signatureAlgorithm field MUST contain one of the ML-DSA signature algorithm OIDs, and the parameters field MUST be absent. The algorithm OID MUST be one of the following OIDs described in Section 2:¶

  Table 2: Signature Algorithm Identifier OIDs for ML-DSA
  Signature Algorithm | Algorithm Identifier OID
  --- | ---
  ML-DSA-44 | id-ml-dsa-44
  ML-DSA-65 | id-ml-dsa-65
  ML-DSA-87 | id-ml-dsa-87

signature:

  The signature field contains the signature value resulting from the use of the ML-DSA signature algorithm identified by the signatureAlgorithm field. The ML-DSA (pure mode) signature-generation operation is specified in Section 5.2 of [FIPS204], and the signature-verification operation is specified in Section 5.3 of [FIPS204]. Note that Section 5.6 of [RFC5652] places further requirements on the successful verification of a signature.¶

## 4. Security Considerations

The security considerations in [RFC5652] and [RFC9881] apply to this specification.¶

Security of the ML-DSA private key is critical. Compromise of the private key will enable an adversary to forge arbitrary signatures.¶

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 [FIPS204] for some additional information.¶

By default, ML-DSA signature generation uses randomness from two sources: fresh random data generated during signature generation, and precomputed random data included in the signer's private key. This is referred to as the "hedged" variant of ML-DSA. Inclusion of both sources of random data can help mitigate against faulty random number generators, side-channel attacks, and fault attacks. [FIPS204] also permits creating deterministic signatures using just the precomputed random data in the signer's private key. The same verification algorithm is used to verify both hedged and deterministic signatures, so this choice does not affect interoperability. The signer SHOULD NOT use the deterministic variant of ML-DSA on platforms where side-channel attacks or fault attacks are a concern. Side-channel attacks and fault attacks against ML-DSA are an active area of research [WNGD2023] [KPLG2024]. Future protection against these styles of attack may involve interoperable changes to the implementation of ML-DSA's internal functions. Implementers SHOULD consider implementing such protection measures if it would be beneficial for their particular use cases.¶

To avoid algorithm substitution attacks, the CMSAlgorithmProtection attribute defined in [RFC6211] SHOULD be included in signed attributes.¶

## 5. Operational Considerations

If ML-DSA signing is implemented in a hardware device such as a hardware security module (HSM) or a portable cryptographic token, implementers might want to avoid sending the full content to the device for performance reasons. By including signed attributes, which necessarily includes the message-digest attribute and the content-type attribute as described in Section 5.3 of [RFC5652], the much smaller set of signed attributes are sent to the device for signing.¶

Additionally, the pure variant of ML-DSA does support a form of pre-hash via external calculation of the "μ" (GREEK SMALL LETTER MU, U+03BC) "message representative" value described in Section 6.2 of [FIPS204]. This value may "optionally be computed in a different cryptographic module" and supplied to the hardware device, rather than requiring the entire message to be transmitted. Appendix D of [RFC9881] describes use of external μ calculations in further detail.¶

## 6. IANA Considerations

For the ASN.1 module in Appendix A, IANA has assigned the following object identifier in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:¶

Table 3: Object Identifier Assignments
Decimal | Description | Reference
--- | --- | ---
83 | id-mod-ml-dsa-2024 | RFC 9882

## 7. References

### 7.1. Normative References

[CSOR]
  NIST, "Computer Security Objects Register (CSOR)", 13 June 2025, <https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration>.
[FIPS204]
  NIST, "Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf>.
[RFC2119]
  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC5652]
  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5754]
  Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC6211]
  Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute", RFC 6211, DOI 10.17487/RFC6211, April 2011, <https://www.rfc-editor.org/info/rfc6211>.
[RFC8174]
  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8702]
  Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)", RFC 8702, DOI 10.17487/RFC8702, January 2020, <https://www.rfc-editor.org/info/rfc8702>.
[RFC9881]
  Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025, <https://www.rfc-editor.org/info/rfc9881>.

### 7.2. Informative References

[FIPS180]
  NIST, "Secure Hash Standard", NIST FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.
[FIPS205]
  NIST, "Stateless Hash-Based Digital Signature Standard", NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf>.
[KPLG2024]
  Krahmer, E., Pessl, P., Land, G., and T. Güneysu, "Correction Fault Attacks on Randomized CRYSTALS-Dilithium", Cryptology ePrint Archive, Paper 2024/138, 2024, <https://ia.cr/2024/138>.
[RFC5280]
  Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5911]
  Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, June 2010, <https://www.rfc-editor.org/info/rfc5911>.
[RFC8032]
  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8419]
  Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, <https://www.rfc-editor.org/info/rfc8419>.
[RFC9814]
  Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", RFC 9814, DOI 10.17487/RFC9814, July 2025, <https://www.rfc-editor.org/info/rfc9814>.
[WNGD2023]
  Wang, R., Ngo, K., Gärtner, J., and E. Dubrova, "Single-Trace Side-Channel Attacks on CRYSTALS-Dilithium: Myth or Reality?", Cryptology ePrint Archive, Paper 2023/1931, 2023, <https://ia.cr/2023/1931>.
[X680]
  ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.680>.

## Appendix A. ASN.1 Module

    <CODE BEGINS>
    ML-DSA-Module-2024
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        id-smime(16) id-mod(0) id-mod-ml-dsa-2024(83) }

    DEFINITIONS IMPLICIT TAGS ::= BEGIN

    EXPORTS ALL;

    IMPORTS SIGNATURE-ALGORITHM, SMIME-CAPS
      FROM AlgorithmInformation-2009 -- in [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-ml-dsa-44, sa-ml-dsa-65, sa-ml-dsa-87
      FROM X509-ML-DSA-2024 -- From [RFC9881]
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-x509-ml-dsa-2024(119) } ;

    --
    -- Expand the signature algorithm set used by CMS [RFC5911]
    --

    SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= {
      sa-ml-dsa-44 |
      sa-ml-dsa-65 |
      sa-ml-dsa-87,
      ... }

    SMimeCaps SMIME-CAPS ::= {
      sa-ml-dsa-44.&smimeCaps |
      sa-ml-dsa-65.&smimeCaps |
      sa-ml-dsa-87.&smimeCaps,
      ... }

    END
    <CODE ENDS>

¶

## Appendix B. Examples

This appendix contains example signed-data encodings. They can be verified using the example public keys and certificates specified in Appendix C of [RFC9881].¶

The following is an example of a signed-data with a single ML-DSA-44 signer, with signed attributes included:¶

    -----BEGIN CMS-----
    MIIKsAYJKoZIhvcNAQcCoIIKoTCCCp0CAQExDTALBglghkgBZQMEAgMwQwYJKoZI
    hvcNAQcBoDYENE1MLURTQS00NCBzaWduZWQtZGF0YSBleGFtcGxlIHdpdGggc2ln
    bmVkIGF0dHJpYnV0ZXMxggpCMIIKPgIBATA6MCIxDTALBgNVBAoTBElFVEYxETAP
    BgNVBAMTCExBTVBTIFdHAhQVn/5vIv1cxCxSTfb9XijQ3jjzTjALBglghkgBZQME
    AgOgazAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBME8GCSqGSIb3DQEJBDFCBEAL
    v5NoEkfE3OkMRW4rKXw97hdFLivtQ/OVU4Pc/DrfWm3d7POpIxNQ4WCwyGDTWKwi
    dWwcHZ9E3CT0Twj2gI/UMAsGCWCGSAFlAwQDEQSCCXTzX9ZSUYiiAjJ2USF/0b1K
    fyTnaJTCFymSXY/ZOE0++0F6BZ9HUQweqTlrfXUmpOLlYK+8Hd/zCmyjboKZZmCA
    KY4rPlbI4W9ndcowgSgawGixVsOvOBimudg4B5Tbo43cORwIPW6FdDrCa9eKgcGh
    bMIFTYFF7f9J3suzYmcj7H99nDJd3d9POqPW0J2NWz64UoxZP8iHOu78gd46yIwB
    Rz9VYerDOBSOkZiU2kQUXGhCKmOogOES8Vg1TfV3esn7xeLbOhn4uyrpSOBx5bdC
    3BLRxvWdic+haOSFQns5uSrduRjXTaLi88tnVWknzfidCzKubzIxJ/7CMcEcXxu+
    L+dUOVXZvATV3FIddk9re8x54Z7gb0kHEyemJnf9uq+084pGB/LrIH5x+ZyYdzlZ
    Ys1a7XqEONK/VIuwD2E7UHcYDSROZAYRMFGoyqGKdwVD6/W1ElDYND6eX7Vqss4H
    jDuDi7qsha2j4oHet5JQWYeCSxSUsmwp+5E9S6p3g/30w4iAlEGQLGZV1H76m+4+
    JYWnHapiFFPQ4nxly+C6c6+hDaX+KONzdM/lt0eaJnxq9Nzrprw/ieIqX8A7Ov9t
    1MLVwd7W8Gc4auZec/8WrnDI/f7qaSU0Kt+kNN0oK2maZvLYbDyaDSlUyK4IXvqA
    FR5fbSgFmy7SY2TDc4k8JJ/KdBqSg8k0/tRemBiXE/YfltddyZqsD+vhoz5RXhl0
    DvyZbQwxW67bdgr6TgRKexRuWOQTR9CAWNitmPzmZDRqIxIhtbg3jtoXuJTg4OO3
    /tjhr+ZxCv5zsgcbUiJBiCsHRhuc1W1erOCRu+fknwXZBgF73WtFhDfDq8u9a00e
    jBTW4xMAXVfv3coIaknsDP+Di9LtvsXxhLsMaRr9bFZnfhcfU4/O0w+rGWbZ8l14
    y8ECh//OPjYQxmFvXaqV9r2Fz6KkslzwlerMq/MjFUjt6vNcxHaGEID/m+xzSJAB
    5/BzW0qkIBFoWIDHTkYo9wie7QI6cbgM7qbpTxJAbauPU0VYf2VUTTuGxVtb4aNQ
    zMDYSBjHVDjZ3/o+kmkjrlBxl+Jvx7QelOGOVNhKMP7OwMIXj50txvWqRVlTXIvm
    p5Qv/NFJWQTJWDv608Mt5/4lbGqJBO7v9T7gfxvd1LWXmmd1X/T8oPg9rFI6rGNP
    Nz7xoxs8xkAa+sBcoPmNQyk9q9srER8Fwi3eBGnUFuAq8nKfn+2LXh/Iuhxk6BFc
    a1wC4Qa5PV4uiKjsUrKyWwux12Z3dAbtLIf9HNStu1l57KaiJ/XLkCsUsDVAcq8L
    GJHpuT0OOY/2Ai/JkE6CjJH9nEXQLgxWHadD0gJrQA8rnwVOccex7RjX7xkhh/0d
    b3HxLf2fOFt6lyWgFK1uZKpLrp1fk6+U1hxk+EuUfdayrTOt5poNolRXaohINP7m
    ZZj1yqGhWlbq0xkZt7xantZ5FB1QuT9hT5FiY4TFoB1Z5LJlXvLpM/QFB/4n9ZJi
    fqqjKA6wMCWxBpsu4+ZOfaQkwvRZ+9+O8QIMlQaRqyMoZeSVh622QmUjuAw7EyYY
    KRR/sPkLe1SFXwFg6mcqrnABRGy2kHs2a63j4MIpev1DonKNWPbbBSzkqncPYpb6
    MHXQTiL1/uqbl/vUElNucQxvzsaCIDP0ULQiZLS5PUO18rjWa3BbEOner4MyAT2s
    QXj5fxHYmuT69JppafV9omZa30d2mUDDtz9Wy2xGRE8MvSrawsRNE5Hucc/tXZul
    BzOGPARtzKB3lgrXuQU9CyYSM3T387tM1o1AXmOJO/H4bhAbAqFeFnL1Wm/gFWFr
    ocpVPNwAWRQj7NdteRMX/qE8nWMjGl1ax7wl3BPa8pDwC+6lpnVfGDzBNlwBzTHz
    oXtjGTTRuFi1Zpy6BgvAPuVZcxXC6Pg8EeodO1XH4pPKtPJ+tkCWLrnxzMur7oAP
    i5P3UZ/AEXrLiMw/f6oltVVDWvGD9T5OeemgB4fRzSG/0Sxu1WpMBm1va1v56Gym
    UOu59MHb6jR2NpsGBRu1J/5FVoxghvitSA4ggAhkLmlndoNcW0ThHJx67WBJH78h
    gVHhjqBuaXwRlfocyqdrNw4B9iVAEx/sxldvF9pIvlsnRXKore8RF9p40fYz7GGc
    2+cbtdgCVyfpnt2u2reyvPgOAzw/Moms+AXs+LaxzHt6mrWIJOsuNtLwrwTEJu1t
    GkQiBwZwDlG+wb885YvMxAoAXU9s88jSWzEyfUS4ksMgG2CVrmfewHeFuLIFR9D1
    LZkFSmQTgWLKwdJw73XUgFOqHxzMTBkLoTAIQasTZKjC16OzCbwZv5e/PT7hqvQk
    ic07PJLIjA41uhGnSyaN2ELYQYKQFcTAky5eHYaDHdJgMZTTKMn+k1SHYHCBYkzH
    ToSoodOW7ezgjzkMJMAp3A/egYFrCHpOdmiCkE6ot2OCW8Ju9vxKQMWAXXelFOa7
    j3tVSqIUdvTjzyAGINsVU8ihKaSStO8khnOftb/aUj7eN36FHMwMeNH2LhXbwSJI
    ++u4GWW3woD8ZUyo1mpH7xLmBrci7Phs7gFpHtJeIZpPBeG5MuEDpvzCHHBBrvUA
    Ek8zuLLGYdlbb2PWGM6A3M+efSnjaY6JQS3GURQLA9BWMtuS5L3+ytm0FOOwOVCA
    hq2BN+vNwXm1XWqlEG1sbpAUbngWkpyipUT3GBBvjp+Ak3RIlciLQGcZ1IlXeg1E
    W9K8YhhLo49Oh3GDuf4CZgPULsHXqKcCr9lVDpff/kcxwVeXITQiFVykwjfEllXT
    gnxR3zQRP61P3aisQxwsaKgHKGzD5idGAzGQuwVgAs95xA/ka1ccMe8a5da+bKP/
    9QqnAFFtArVZpso0Xcy2D/iusW2bcBjiSANM4GnZwsyphF0WIK89aq/411WIz3zc
    XflJIW80fAy47VF8W340bSgc24AOrQlz38TEGLIcvqPvSMTQRVUdl2S9PgGo8cpP
    J5+lm7FzJftRSTwYsaSwtOUM1hvvXbvcWfO3g8XMJbof8cWH7QeEPcan+ygxqbtt
    ArQ5Dk+BE4Rv/MBJUVi5E30IBHxWXx6OTwSljFDjBwt8bPVk7YMaBWMMY4KZw5jU
    nRakavONHDQDizfy7U0IRAEjKTxKTFaRk56+y839PF2Tlp63wO0UFzAyQVVkZ2uR
    zs/Q7xYbHEBpepGfq7C0w9Tp7fgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    DhYkNA==
    -----END CMS-----

¶

    SEQUENCE {
      # signedData
      OBJECT_IDENTIFIER { 1.2.840.113549.1.7.2 }
      [0] {
        SEQUENCE {
          INTEGER { 1 }
          SET {
            SEQUENCE {
              # sha512
              OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.2.3 }
            }
          }
          SEQUENCE {
            # data
            OBJECT_IDENTIFIER { 1.2.840.113549.1.7.1 }
            [0] {
              OCTET_STRING { "ML-DSA-44 signed-data example with sig
    ned attributes" }
            }
          }
          SET {
            SEQUENCE {
              INTEGER { 1 }
              SEQUENCE {
                SEQUENCE {
                  SET {
                    SEQUENCE {
                      # organizationName
                      OBJECT_IDENTIFIER { 2.5.4.10 }
                      PrintableString { "IETF" }
                    }
                  }
                  SET {
                    SEQUENCE {
                      # commonName
                      OBJECT_IDENTIFIER { 2.5.4.3 }
                      PrintableString { "LAMPS WG" }
                    }
                  }
                }
                INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e`
     }
              }
              SEQUENCE {
                # sha512
                OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.2.3 }
              }
              [0] {
                SEQUENCE {
                  # contentType
                  OBJECT_IDENTIFIER { 1.2.840.113549.1.9.3 }
                  SET {
                    # data
                    OBJECT_IDENTIFIER { 1.2.840.113549.1.7.1 }
                  }
                }
                SEQUENCE {
                  # messageDigest
                  OBJECT_IDENTIFIER { 1.2.840.113549.1.9.4 }
                  SET {
                    OCTET_STRING { `0bbf93681247c4dce90c456e2b297c3d
    ee17452e2bed43f3955383dcfc3adf5a6dddecf3a9231350e160b0c860d358ac
    22756c1c1d9f44dc24f44f08f6808fd4` }
                  }
                }
              }
              SEQUENCE {
                OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 }
              }
              OCTET_STRING { `f35fd6525188a202327651217fd1bd4a7f24e7
    [encoded data, 4875 characters]
    34` }
            }
          }
        }
      }
    }

¶

The following is an example of a signed-data with a single ML-DSA-65 signer, with signed attributes included:¶

    -----BEGIN CMS-----
    [encoded data, 4875 characters]
    YKOx3QAAAAAAAAAAAAAAAAAAAAAAAAAECxASHiQ=
    -----END CMS-----

¶

    SEQUENCE {
      # signedData
      OBJECT_IDENTIFIER { 1.2.840.113549.1.7.2 }
      [0] {
        SEQUENCE {
          INTEGER { 1 }
          SET {
            SEQUENCE {
              # sha512
              OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.2.3 }
            }
          }
          SEQUENCE {
            # data
            OBJECT_IDENTIFIER { 1.2.840.113549.1.7.1 }
            [0] {
              OCTET_STRING { "ML-DSA-65 signed-data example with sig
    ned attributes" }
            }
          }
          SET {
            SEQUENCE {
              INTEGER { 1 }
              SEQUENCE {
                SEQUENCE {
                  SET {
                    SEQUENCE {
                      # organizationName
                      OBJECT_IDENTIFIER { 2.5.4.10 }
                      PrintableString { "IETF" }
                    }
                  }
                  SET {
                    SEQUENCE {
                      # commonName
                      OBJECT_IDENTIFIER { 2.5.4.3 }
                      PrintableString { "LAMPS WG" }
                    }
                  }
                }
                INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e`
     }
              }
              SEQUENCE {
                # sha512
                OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.2.3 }
              }
              [0] {
                SEQUENCE {
                  # contentType
                  OBJECT_IDENTIFIER { 1.2.840.113549.1.9.3 }
                  SET {
                    # data
                    OBJECT_IDENTIFIER { 1.2.840.113549.1.7.1 }
                  }
                }
                SEQUENCE {
                  # messageDigest
                  OBJECT_IDENTIFIER { 1.2.840.113549.1.9.4 }
                  SET {
                    OCTET_STRING { `d5740888352a0e92a69df3eb1a1ce555
    60ac3f2d2f8281ce3f06a56d3a8285cb24ee6404757129a17aef477cdf1a443a
    12220e30cfde2308f7b88142ce9e3aa8` }
                  }
                }
              }
              SEQUENCE {
                OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 }
              }
              OCTET_STRING { `529c9039cce0a4fc9d267e4967892860063cc4
    [encoded data, 6630 characters]
    dd00000000000000000000000000000000000000040b10121e24` }
            }
          }
        }
      }
    }

¶

The following is an example of a signed-data with a single ML-DSA-87 signer, with signed attributes included:¶

    -----BEGIN CMS-----
    [encoded data, 6695 characters]
    KDI8
    -----END CMS-----

¶

    SEQUENCE {
      # signedData
      OBJECT_IDENTIFIER { 1.2.840.113549.1.7.2 }
      [0] {
        SEQUENCE {
          INTEGER { 1 }
          SET {
            SEQUENCE {
              # sha512
              OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.2.3 }
            }
          }
          SEQUENCE {
            # data
            OBJECT_IDENTIFIER { 1.2.840.113549.1.7.1 }
            [0] {
              OCTET_STRING { "ML-DSA-87 signed-data example with sig
    ned attributes" }
            }
          }
          SET {
            SEQUENCE {
              INTEGER { 1 }
              SEQUENCE {
                SEQUENCE {
                  SET {
                    SEQUENCE {
                      # organizationName
                      OBJECT_IDENTIFIER { 2.5.4.10 }
                      PrintableString { "IETF" }
                    }
                  }
                  SET {
                    SEQUENCE {
                      # commonName
                      OBJECT_IDENTIFIER { 2.5.4.3 }
                      PrintableString { "LAMPS WG" }
                    }
                  }
                }
                INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e`
     }
              }
              SEQUENCE {
                # sha512
                OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.2.3 }
              }
              [0] {
                SEQUENCE {
                  # contentType
                  OBJECT_IDENTIFIER { 1.2.840.113549.1.9.3 }
                  SET {
                    # data
                    OBJECT_IDENTIFIER { 1.2.840.113549.1.7.1 }
                  }
                }
                SEQUENCE {
                  # messageDigest
                  OBJECT_IDENTIFIER { 1.2.840.113549.1.9.4 }
                  SET {
                    OCTET_STRING { `024f5ef2846bda2220e542208acfd715
    ddd3b8e111e8390d62864b1dc128c0a2c9b74567b0b955c617f002204d27d887
    95699e065f016ae31c6d0a4b42662264` }
                  }
                }
              }
              SEQUENCE {
                OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 }
              }
              OCTET_STRING { `9863de9a87725f55d7963b509e9a5496df4646
    [encoded data, 9360 characters]
    ` }
            }
          }
        }
      }
    }

¶

## Acknowledgments

The authors would like to thank the following people for their contributions and reviews that helped shape this document: Viktor Dukhovni, Russ Housley, Panos Kampanakis, Mike Ounsworth, Falko Strenzke, Sean Turner, and Wei-Jun Wang.¶

This document was heavily influenced by [RFC8419], [RFC9814], and [RFC9881]. Thanks go to the authors of those documents.¶

## Authors' Addresses