Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-ml-dsa-01

Limited Additional Mechanisms for PKIX and SMIME               B. Salter
Internet-Draft                                                  A. Raine
Intended status: Standards Track       UK National Cyber Security Centre
Expires: 26 May 2025                                        D. Van Geest
                                                     CryptoNext Security
                                                        22 November 2024

   Use of the ML-DSA Signature Algorithm in the Cryptographic Message
                              Syntax (CMS)
                     draft-ietf-lamps-cms-ml-dsa-01

Abstract

   The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as
   defined 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 and public key syntax are provided.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://lamps-
   wg.github.io/cms-ml-dsa/draft-ietf-lamps-cms-ml-dsa.html.  Status
   information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-ml-dsa/.

   Discussion of this document takes place on the Limited Additional
   Mechanisms for PKIX and SMIME Working Group mailing list
   (mailto:spasm@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/spasm/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/spasm/.

   Source for this draft and an issue tracker can be found at
   https://github.com/lamps-wg/cms-ml-dsa.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Salter, et al.             Expires 26 May 2025                  [Page 1]
Internet-Draft                ML-DSA in CMS                November 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 May 2025.

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   3
   2.  ML-DSA Algorithm Identifiers  . . . . . . . . . . . . . . . .   3
   3.  ML-DSA Key Encoding . . . . . . . . . . . . . . . . . . . . .   4
   4.  Signed-data Conventions . . . . . . . . . . . . . . . . . . .   6
     4.1.  Pure mode vs pre-hash mode  . . . . . . . . . . . . . . .   6
     4.2.  Signature generation and verification . . . . . . . . . .   6
     4.3.  SignerInfo content  . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Salter, et al.             Expires 26 May 2025                  [Page 2]
Internet-Draft                ML-DSA in CMS                November 2024

1.  Introduction

   The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a
   digital signature algorithm standardised by NIST as part of their
   post-quantum cryptography standardization process.  It is intended to
   be secure against both "traditional" cryptographic attacks, as well
   as attacks utilising a quantum computer.  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 the ML-DSA in CMS at three
   security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87.  See Appendix B
   of [I-D.ietf-lamps-dilithium-certificates] 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.  HashML-DSA is not used in CMS.

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 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.
   [I-D.ietf-lamps-dilithium-certificates] describes the use of ML-DSA
   in X.509 certificates.  The AlgorithmIdentifier type is defined as
   follows:

Salter, et al.             Expires 26 May 2025                  [Page 3]
Internet-Draft                ML-DSA in CMS                November 2024

   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.  ML-DSA Key Encoding

   [RFC5280] defines the SubjectPublicKeyInfo ASN.1 type.  In X.509
   certificates [RFC5280] and Certificate Management over CMS [RFC5272],
   the SubjectPublicKeyInfo type is used to encode public keys.  It has
   the following syntax:

Salter, et al.             Expires 26 May 2025                  [Page 4]
Internet-Draft                ML-DSA in CMS                November 2024

     SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE {
         algorithm        AlgorithmIdentifier {PUBLIC-KEY, {IOSet}},
         subjectPublicKey BIT STRING
     }

      |  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 PUBLIC-KEY ASN.1 types for ML-DSA are defined here:

   pk-ml-dsa-44 PUBLIC-KEY ::= {
     IDENTIFIER id-ml-dsa-44
     -- KEY no ASN.1 wrapping --
     CERT-KEY-USAGE
       { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
     -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-ml-dsa-65 PUBLIC-KEY ::= {
     IDENTIFIER id-ml-dsa-65
     -- KEY no ASN.1 wrapping --
     CERT-KEY-USAGE
       { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
     -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-ml-dsa-87 PUBLIC-KEY ::= {
     IDENTIFIER id-ml-dsa-87
     -- KEY no ASN.1 wrapping --
     CERT-KEY-USAGE
       { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
     -- PRIVATE-KEY no ASN.1 wrapping -- }

   ML-DSA-PublicKey ::= OCTET STRING (SIZE (1312 | 1952 | 2592))

   ML-DSA-PrivateKey ::= OCTET STRING (SIZE (32))

   Algorithm 22 in Section 7.2 of [FIPS204] defines the raw byte string
   encoding of an ML-DSA public key.  When used in a
   SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains
   the raw byte string encoding of the public key.

   When an ML-DSA public key appears outside of a SubjectPublicKeyInfo
   type in an environment that uses ASN.1 encoding, it can be encoded as
   an OCTET STRING by using the ML-DSA-PublicKey type.

Salter, et al.             Expires 26 May 2025                  [Page 5]
Internet-Draft                ML-DSA in CMS                November 2024

   [RFC5958] describes the Asymmetric Key Package CMS content type, and
   the OneAsymmetricKey type for encoding asymmetric keypairs.  When an
   ML-DSA private key or keypair is encoded as a OneAsymmetricKey, it
   follows the description in Section 6 of
   [I-D.ietf-lamps-dilithium-certificates].

   When the ML-DSA private key appears outside of an Asymmetric Key
   Package in an environment that uses ASN.1 encoding, it can be encoded
   as an OCTET STRING by using the ML-DSA-PrivateKey type.

4.  Signed-data Conventions

4.1.  Pure mode vs 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 of publication of that RFC, all signature
   algorithms supported in 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 SLH-DSA [FIPS205] have
   also been standardised, and these algorithms support both a "pure"
   and "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.  ML-DSA also supports a pre-hash and pure mode, though
   this document follows the convention set by EdDSA in CMS [RFC8419]
   and SLH-DSA in CMS [I-D.ietf-lamps-cms-sphincs-plus] and only
   specifies use of the pure mode of ML-DSA in CMS.

4.2.  Signature generation and verification

   [RFC5652] describes the two methods that are used to calculate and
   verify signatures in 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.

Salter, et al.             Expires 26 May 2025                  [Page 6]
Internet-Draft                ML-DSA in CMS                November 2024

   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.  The signedAttrs field
   MUST at minimum 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 [I-D.ietf-lamps-cms-sphincs-plus] 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 described in this document, the
   context string is not used.

4.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.  To ensure collision resistance,
      the identified message digest algorithm SHOULD produce a hash
      value of a size that is at least twice the collision strength of
      the internal commitment hash used by ML-DSA.  SHA-512 [FIPS180]
      MUST be supported for use with the variants of SLH-DSA in this
      document; however, other hash functions MAY also be supported.
      When SHA-512 is used, the id-sha512 [RFC5754] digest algorithm
      identifier is used and the parameters field MUST be omitted.  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.  Nonetheless, it SHOULD specify a
      digest algorithm that otherwise would have been used if signed
      attributes were present, such as SHA-512.  When processing a
      SignerInfo signed using ML-DSA, if no signed attributes are
      present, implementations MUST ignore the content of the
      digestAlgorithm field.

   signatureAlgorithm:  When signing a signed-data using ML-DSA, the

Salter, et al.             Expires 26 May 2025                  [Page 7]
Internet-Draft                ML-DSA in CMS                November 2024

      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:

            +=====================+==========================+
            | 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             |
            +---------------------+--------------------------+

               Table 1: Signature algorithm identifier OIDs
                                for ML-DSA

   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.

5.  Security Considerations

   The security considerations [RFC5652] and
   [I-D.ietf-lamps-dilithium-certificates] apply to this specification
   as well.

   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, and [RFC4086] offers important guidance in this area.

Salter, et al.             Expires 26 May 2025                  [Page 8]
Internet-Draft                ML-DSA in CMS                November 2024

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

6.  Operational Considerations

   If ML-DSA signing is implemented in a hardware device such as
   hardware security module (HSM) or portable cryptographic token,
   implementers might want to avoid sending the full content to the
   device for performance reasons.  By including signed attributes,
   which necessarily include 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.

   This approach addresses the use case for HashML-DSA, and is one
   reason why HashML-DSA is not specified for use with CMS in this
   document.  Additionally, the pure variant of ML-DSA does support a
   form of pre-hash via the _mu_ "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.

Salter, et al.             Expires 26 May 2025                  [Page 9]
Internet-Draft                ML-DSA in CMS                November 2024

7.  IANA Considerations

   For the ASN.1 module found in Appendix A, IANA is requested to assign
   an object identifier for the module identifier (TBD) with a
   description of "id-mod-ml-dsa-2024".  This should be allocated in the
   "SMI Security for S/MIME Module Identifier" registry
   (1.2.840.113549.1.9.16.0).

8.  Acknowledgments

   This document was heavily influenced by [RFC8419],
   [I-D.ietf-lamps-cms-sphincs-plus], and
   [I-D.ietf-lamps-dilithium-certificates].  Thanks go to the authors of
   those documents.

9.  References

9.1.  Normative References

   [CSOR]     NIST, "Computer Security Objects Register", 20 August
              2024, <https://csrc.nist.gov/projects/computer-security-
              objects-register/algorithm-registration>.

   [FIPS204]  "Module-Lattice-Based Digital Signature Standard",
              National Institute of Standards and Technology,
              DOI 10.6028/nist.fips.204, August 2024,
              <https://doi.org/10.6028/nist.fips.204>.

   [I-D.ietf-lamps-dilithium-certificates]
              Massimo, J., Kampanakis, P., Turner, S., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure:
              Algorithm Identifiers for ML-DSA", Work in Progress,
              Internet-Draft, draft-ietf-lamps-dilithium-certificates-
              05, 4 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              dilithium-certificates-05>.

   [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/rfc/rfc2119>.

   [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/rfc/rfc5280>.

Salter, et al.             Expires 26 May 2025                 [Page 10]
Internet-Draft                ML-DSA in CMS                November 2024

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
              2010, <https://www.rfc-editor.org/rfc/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/rfc/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/rfc/rfc8174>.

9.2.  Informative References

   [FIPS180]  "Secure hash standard", National Institute of Standards
              and Technology (U.S.), DOI 10.6028/nist.fips.180, 1993,
              <https://doi.org/10.6028/nist.fips.180>.

   [FIPS205]  "Stateless Hash-Based Digital Signature Standard",
              National Institute of Standards and Technology,
              DOI 10.6028/nist.fips.205, August 2024,
              <https://doi.org/10.6028/nist.fips.205>.

   [I-D.ietf-lamps-cms-sphincs-plus]
              Housley, R., Fluhrer, S., Kampanakis, P., and B.
              Westerbaan, "Use of the SLH-DSA Signature Algorithm in the
              Cryptographic Message Syntax (CMS)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-cms-sphincs-plus-16, 18
              November 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-lamps-cms-sphincs-plus-16>.

   [KPLG2024] Krahmer, E., Pessl, P., Land, G., and T. Güneysu,
              "Correction Fault Attacks on Randomized CRYSTALS-
              Dilithium", 2024, <https://ia.cr/2024/138>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
              <https://www.rfc-editor.org/rfc/rfc5272>.

Salter, et al.             Expires 26 May 2025                 [Page 11]
Internet-Draft                ML-DSA in CMS                November 2024

   [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/rfc/rfc5911>.

   [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958,
              DOI 10.17487/RFC5958, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5958>.

   [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/rfc/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/rfc/rfc8419>.

   [WNGD2023] Wang, R., Ngo, K., Gärtner, J., and E. Dubrova, "Single-
              Trace Side-Channel Attacks on CRYSTALS-Dilithium: Myth or
              Reality?", 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 (2021) | 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(TBD) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   EXPORTS ALL;

   IMPORTS PUBLIC-KEY, 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) } ;

   --
   -- Object Identifiers
   --

Salter, et al.             Expires 26 May 2025                 [Page 12]
Internet-Draft                ML-DSA in CMS                November 2024

   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 }

   --
   -- Signature Algorithm Identifiers
   --

   sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {
     IDENTIFIER id-ml-dsa-44
     PARAMS ARE absent
     PUBLIC-KEYS { pk-ml-dsa-44 }
     SMIME-CAPS { IDENTIFIED BY id-ml-dsa-44 } }

   sa-ml-dsa-65 SIGNATURE-ALGORITHM ::= {
     IDENTIFIER id-ml-dsa-65
     PARAMS ARE absent
     PUBLIC-KEYS { pk-ml-dsa-65 }
     SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 } }

   sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
     IDENTIFIER id-ml-dsa-87
     PARAMS ARE absent
     PUBLIC-KEYS { pk-ml-dsa-87 }
     SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 } }

   --
   -- Public Keys
   --

   pk-ml-dsa-44 PUBLIC-KEY ::= {
     IDENTIFIER id-ml-dsa-44
     -- KEY no ASN.1 wrapping --
     CERT-KEY-USAGE
       { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
     -- PRIVATE-KEY no ASN.1 wrapping -- }

   pk-ml-dsa-65 PUBLIC-KEY ::= {
     IDENTIFIER id-ml-dsa-65
     -- KEY no ASN.1 wrapping --
     CERT-KEY-USAGE
       { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
     -- PRIVATE-KEY no ASN.1 wrapping -- }

Salter, et al.             Expires 26 May 2025                 [Page 13]
Internet-Draft                ML-DSA in CMS                November 2024

   pk-ml-dsa-87 PUBLIC-KEY ::= {
     IDENTIFIER id-ml-dsa-87
     -- KEY no ASN.1 wrapping --
     CERT-KEY-USAGE
       { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
     -- PRIVATE-KEY no ASN.1 wrapping -- }

   ML-DSA-PublicKey ::= OCTET STRING (SIZE (1312 | 1952 | 2592))

   ML-DSA-PrivateKey ::= OCTET STRING (SIZE (32))

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

Authors' Addresses

   Ben Salter
   UK National Cyber Security Centre
   Email: ben.s3@ncsc.gov.uk

   Adam Raine
   UK National Cyber Security Centre
   Email: adam.r@ncsc.gov.uk

   Daniel Van Geest
   CryptoNext Security
   Email: daniel.vangeest@cryptonext-security.com

Salter, et al.             Expires 26 May 2025                 [Page 14]