Hi Jake, Panos, Sean, and Bas,

Thank you for the effort put into this specification.

Please find below some comments:

# Generic comments

## Examples validation

I appreciate that Russ indicated in the writeup that the ASN module compiles without error (assuming the IANA identifier is updated). However, were there any checks done against all the examples? Can we please confirm that these were checked as well? Thank you.

## Notation conventions

Please update your terminology section to explain the notation conventions for at least the following:

* || 

* id-ml-dsa-*

# Abstract: s/FIPS 204/US FIPS 204

# Introduction

s/a pure and a prehash/a pure and a pre-hash  (to be consistent with the use in FIPS 204)

# Section 2

Who/Where these identifiers (17/18/19) are assigned?

CURRENT:
      id-ml-dsa-44 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
               country(16) us(840) organization(1) gov(101) csor(3)
               nistAlgorithm(4) sigAlgs(3) id-ml-dsa-44(17) }

      id-ml-dsa-65 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
               country(16) us(840) organization(1) gov(101) csor(3)
               nistAlgorithm(4) sigAlgs(3) id-ml-dsa-65(18) }

      id-ml-dsa-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
               country(16) us(840) organization(1) gov(101) csor(3)
               nistAlgorithm(4) sigAlgs(3) id-ml-dsa-87(19) }

Can that be clarified in the text?

# Section 3

CURRENT:
   The identifiers defined in Section 2 can be used as the
   AlgorithmIdentifier in the signatureAlgorithm field in the sequence
   Certificate/CertificateList and the signature field in the sequence
   TBSCertificate/TBSCertList in certificates and CRLs, respectively,
   [RFC5280].  

draft-ietf-lamps-x509-slhdsa has the following:

==
8.  Operational Considerations

   SLH-DSA uses the same OID to identify a public key and a signature
   algorithm.  The implication of this is that, despite being
   mathematically possible, an SLH-DSA key identified by a Pure SLH-DSA
   OID is not permitted to be used to generate or verify a signature
   identified by an HashSLH-DSA OID, and vice-versa.
==

Does a similar consideration apply for ML-DSA?

If it is no sense, let me know :-)

# Section 5

OLD:
   If the keyUsage extension is present in a certificate that indicates
   id-ml-dsa-* in the SubjectPublicKeyInfo, then the following MUST NOT
   be present:

      keyEncipherment; or
      dataEncipherment; or
      keyAgreement; or
      encipherOnly; or
      decipherOnly.

NEW:
   If the keyUsage extension is present in a certificate that indicates
   id-ml-dsa-* in the SubjectPublicKeyInfo, then the following MUST NOT
   be present:

      keyEncipherment,
      dataEncipherment,
      keyAgreement,
      encipherOnly, and
      decipherOnly.

# Section 6

CURRENT:
       [[2: publicKey       [1] BIT STRING (CONTAINING
                                  PUBLIC-KEY.&Params({PublicKeySet}
                                    {@privateKeyAlgorithm.algorithm})
                                    OPTIONAL,
       ...

Aren’t closing «]]» missing?

# Suggest to position sections 8/9 as subsections of a new Operational Considerations section.

That section can also include the text about storage:

   When encoding an ML-DSA private key in a OneAsymmetricKey object, any
   of these three formats may be used, though the seed format is
   RECOMMENDED for storage efficiency.

The first two paragraphs in “10.1. Rationale for disallowing HashML-DSA” are more about interop than security. Suggest to move that text under that ops section as well.

Cheers,
Med

Thank you to Robert Sparks for the GENART review.