Section 5, paragraph 1
>    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.
> 
>    Additionally, the pure variant of ML-DSA does support a form of pre-
>    hash via external calculation of 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.  Appendix D of
>    [I-D.ietf-lamps-dilithium-certificates] describes use of external mu
>    calculations in further detail.

I am happy to see that the authors decided to include an Operational Considerations section. Thanks for doing that.

Possible DOWNREF from this Standards Track doc to [CSOR]. If so, the IESG needs
to approve it.

Possible DOWNREF from this Standards Track doc to [FIPS204]. If so, the IESG
needs to approve it.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

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


s/in the CMS/In the CMS/

These URLs in the document did not return content:

 * https://www.ietf.org/mailman/listinfo/spasm/
 * https://doi.org/10.6028/nist.fips.180

Section 1, paragraph 1
> o the published RFCs. Prior to standardisation, ML-DSA was known as Dilithium
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("standardisation" and "standardization")
within a single text.

Section 3.3, paragraph 10
> important guidance in this area. By default ML-DSA signature generation uses 
>                                  ^^^^^^^^^^
Did you mean: "By default,"?

Hi Ben, Adam, and Daniel,

Thank you for the effort put into this specification. 

I trust that the examples were validated.

Please find below some few comments, ordered by the document flow: 

# Regional matters

Please make this change to the abstract:

OLD:
   The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as
   defined in FIPS 204, 

NEW:
   The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as
   defined in US FIPS 204, 

and the following one to the introduction:

OLD;
   The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a
   digital signature algorithm standardised by NIST as part of their

NEW:
   The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a
   digital signature algorithm standardised by US National Institute
   of Standards and Technology (NIST) as part of their

# Picky :-)

NEW:
      |  RFC EDITOR: Please replace
      |  [I-D.ietf-lamps-dilithium-certificates] and
      |  [I-D.ietf-lamps-cms-sphincs-plus] throughout this document with
      |  references to the published RFCs.

We don’t need a note for this as this is this is normal editing process, except for the embedded mention in the ASN module. You may reword as follows:

NEW:
      |  RFC EDITOR: Please replace
      |  [I-D.ietf-lamps-dilithium-certificates] in ASN module with
      |  references to the published RFC.

Alternatively, you may delete this note here and use the one right before the ASN module to convey that message.

# Point where the rationale for not covering the pre-hash mode is provided, e.g.,

OLD:
   [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.
NEW:
   [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 mor details.

draft-ietf-lamps-dilithium-certificates has a more detailed description of the rationale in its section 8.3.

# a nit in Section 2

OLD: identify cryptographic algorithms. in the CMS, 

NEW: identify cryptographic algorithms. In the CMS,

# Appendix A.  ASN.1 Module

## Note

CURRENT:
      |  RFC EDITOR: Please replace TBD2 with the value assigned by IANA
      |  during the publication of
      |  [I-D.ietf-lamps-dilithium-certificates].

Can be deleted as TBD2=119 was already assigned by IANA.

## Use the module name (X509-ML-DSA-2025) as registered by IANA (id-mod-x509-ml-dsa-2025) and the assigned value (119)

OLD:
==>  FROM X509-ML-DSA-2024 -- From [I-D.ietf-lamps-dilithium-certificates]
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
 ==>   id-mod-x509-ml-dsa-2024(TBD2) } ;
                               ^^^^

NEW:
     FROM X509-ML-DSA-2025 -- From [I-D.ietf-lamps-dilithium-certificates]
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-x509-ml-dsa-2025(119) } ;

Cheers,
Med

# Orie Steele, ART AD, comments for draft-ietf-lamps-cms-ml-dsa-05 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-cms-ml-dsa-05.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### Context not used?

```
244	   ML-DSA has a context string input that can be used to ensure that
245	   different signatures are generated for different application
246	   contexts.  When using ML-DSA as described in this document, the
247	   context string is not used.
```

I think you mean that the default context is used, which is empty per Section 5.2 of FIPS 204;

"By default, the context is the empty string, though applications may specify the use of a non-empty context string."

### Why not MUST?

```
266	      of the ML-DSA parameter set.  Verifiers MAY reject a signature if
267	      the signer's choice of digest algorithm does not meet the security
268	      requirements of their choice of ML-DSA parameter set.  Table 1
269	      shows appropriate SHA-2 and SHA-3 digest algorithms for each
270	      parameter set.
```

Seems weird for a verifier to accept such a signature.

Thank you to Stewart Bryant for the GENART review.

A lot of fiction references in this I-D (e.g., dilithium among others).

More seriously, authors may consider the following comments:

# Section 1

s/NIST/US National Institute of Standards and Technology (NIST)/

Should `SLH-DSA` be expanded ?