ML-DSA for JOSE and COSE
draft-ietf-cose-dilithium-11

# Éric Vyncke, INT AD, comments for draft-ietf-cose-dilithium-09
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Lucas Prabel for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract & section 1
 
s/This document describes/This document *specifies*/

### Section 3

Should `JWK` be expanded ? Or a reference be added ?

### Section 4

s/by NIST so/by US NIST so/ as not every reader lives in the USA.

### Section 5

Sentence such as `This document requests the registration` should rather be in the IANA considerations. Let's use here "This document specifies..." or similar.

Let's be consistent and use double quotes around parameter names, e.g., in `The ctx parameter` (this could happen in other places as well) while `The "pub" parameter` is also used.

Out of curiosity, where are the -44, -65, and -87 come from ? These numbers do not seem to be linked to key sizes.

### Section 9.2

As indicated by idnits, reference NIST-PQC-2022 is never used, so, let's remove it.

This document does not describe a transport protocol change, and I have no related concerns.

I see:  draft-ietf-cose-key-thumbprint is alreday published as an RFC (and that draft-ietf-lamps-dilithium-certificates is in the RFC-Ed queue.

I have no additional review comments.

Thanks to the authors and the WG for their work on this document and for the updates to address my previous comments.

In Section 5, the reference for the registry where the registrations should be made is to the entire COSE/JOSE registry groups, and the particular registries are not specified until Section 8. I initially thought the values requested were incorrect but then realized I was looking at the wrong registry on that page. In Section 8, however, the registries are referenced by name and the link to the registry is omitted. I think this could be made clearer by putting all the registration information in Section 8 (including links to specific registries) and focusing Section 5 on the use of the registered values.

In Section 7.3, the normative requirement represented by "only a length check MUST be performed" is unclear. Should this be read "MUST NOT perform any checks other than length" or "MUST perform a length check and MAY perform additional checks as appropriate"? Or is this instead reflecting that a requirement already exists elsewhere and should be "a length check is required by Section x.y of [RFCabcd]"?

===NITS FOLLOW===
- Section 5, "needed, see" => "needed; see"
- Section 7, "specification, see" => "specification; see"

Hi Michael and Orie, 

Thanks for the effort put into this specification. 

Thanks also to Tiru Tirumaleswar Reddy for the OPSDIR review and to the authors for engaging and proposing changes. I went through https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/25/files and trust this PR will be merged. The explanation about the seed only design choice and also calling out some ML-DSA deployment challenges are appreciated.

I also trust the examples were validated.

I have very minor comments:

# Redundant IANA considerations

Not sure why IANA requests are repeated twice in the document (Sections 3/4/5 and then IANA Section). I think it is better to have this in one single place. 

# Who is the target of this guidance?

CURRENT:
   When registering new algorithms, use of multiple key type parameters
   for private information is NOT RECOMMENDED.

# Citations 

Several RFCs are provided in the text but are not cited as references, e.g., RFC 9054 and RFC 7518. Please check through the doc. 

# Regional Matters

Please s/FIPS 204/US FIPS 204 in the abstract and s/NIST/US NIST in Section 4

Cheers,
Med

Thank you to Russ Housley for the GENART review.

** Editorial.  A number of references in the document are not formal references.  For example:

-- Section 4, “FIPS 204” vs. “[FIPS 204]” (multiple instances)

-- Section 8.1.1, “RFC 9053 and RFC 9054” vs. “[RFC9053] and [RFC9054]” (multiple instances)

** Section 8.1.1.* -- Why is the change control entity specific named here, but it is in the JOSE registrations?

** Section 8.1.4.4.*  -- These registration have a row with “Value registry: [IANA.jose] Algorithms”.  That is not in the RFC7518 template or in the production https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms registry