Thanks to Sean Turner for the ARTART review. And thanks to the authors for discussing the points in his review.

Thanks to Sean Turner for the ARTART review and to Russ Housley for highlighting the running code from the Hackathon.

Thank you to Yaroslav R. for his SECDIR review and to Paul K. for his GENART review.  Thanks to Russ H. for a very complete shepherd write up.

I will echo the statement from Yaroslav in his SECDIR review and request that the authors consider this change:

Section 3.4 requires ("MUST") digestAlgorithm from SignerInfo to match digest
algorithm used by the Composite ML-DSA. I believe it is worth spelling out that
violation of this MUST result in rejection of the CMS object. Perhaps it is
worth adding this to security considerations.

Thanks for the work done in this document. Please find below some non-blocking comments:

# Section 4

As RFC 5911 is the reference in the ASN.1 module, it must be added as normative reference for this draft.

# Use of SHOULD in sections 3.2 6

When using "SHOULD" as in BCP14, the IESG statement requires additional guidance:
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Thanks for providing this document. I do not see any transport-protocol related concerns.

Gorry

Thanks for the write-up. I observed that the document is well written and contains no routing area complications.

Section 1.1, paragraph 0
>    CMS values are generated using ASN.1 [X680], using the Basic Encoding
>    Rules (BER) and the Distinguished Encoding Rules (DER) [X690].

I support Med's DISCUSS here on making X680, X690 and RFC 9794 normative
as well as Eric and Mike's COMMENT on making RFC 5911 normative.

Section 2, paragraph 1
>    id-MLDSA44-RSA2048-PSS-SHA256 OBJECT IDENTIFIER ::= {
>       iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5)
>       pkix(7) alg(6) 37 }

Should the OID notation org(3) be identified-organization(3) as
pointed out by Sean Turner (thanks, Sean)? The same question
applies to Section 4 also.

Sean noted that the ITU-T designation for this arc is 
identified-organization(3), not org(3). The companion draft uses 
org(3), and this document reproduces those OIDs consistently. 
While the wire-format encoding is identical, using org(3) in 
published RFC text deviates from the authoritative notation 
and creates a latent errata risk. The authors should use 
identified-organization(3) in both this document and coordinate 
with the companion draft.

Section 3.2, paragraph 0
>    The SignedData digestAlgorithms field includes the identifiers of the
>    message digest algorithms used by one or more signer.  When signing
>    with a Composite ML-DSA algorithm, this list of identifiers SHOULD
>    include the corresponding digest algorithm from Table 1.

When is the SHOULD not a MUST? I support Eric here. In other words, ...

When a SHOULD is used, there must be a clear indication of the circumstances 
in which an implementation may choose not to follow the recommendation. 
The document currently offers none. When would it be legitimate to omit 
the required digest algorithm from digestAlgorithms? If there is no valid 
reason for omission, this SHOULD should be strengthened to MUST. 
If there is a valid reason (e.g., when generating data for a specific 
profile that constrains the algorithms externally), that reason should be 
stated explicitly.

Section 3.4, paragraph 1
>    digestAlgorithm:  Per Section 5.3 of [RFC5652], the digestAlgorithm
>       field identifies the message digest algorithm used by the signer
>       and any associated parameters.  This MUST be the same digest
>       algorithm used by the Composite ML-DSA algorithm.  Per [RFC8933],
>       if the signedAttrs field is present in the SignerInfo, then the
>       same digest algorithm MUST be used to compute both the digest of
>       the SignedData encapContentInfo eContent, which is carried in the
>       message-digest attribute, and the digest of the DER-encoded
>       signedAttrs, which is passed to the signature algorithm.  See
>       Table 1 for exact algorithm mappings.

I support Chris' DISCUSS here.

Section 5, paragraph 0
> 5.  IANA Considerations

I also support Med's DISCUSS and the need to include Operational
Considerations in this document from RFC 9882 Section 5. RFC 9882, 
the CMS document for pure ML-DSA, addresses performance implications 
and deployment considerations that are equally applicable here. 
The present document has no operational considerations section at all.
At a minimum, a brief section noting performance trade-offs, 
the implications of carrying larger signatures in CMS structures, 
and migration considerations from traditional CMS to composite CMS 
would benefit implementers.

Section 6, paragraph 0
>    All security considerations from [I-D.ietf-lamps-pq-composite-sigs]
>    apply.

Beyond the normative requirement for verifiers, this section should 
explain the threat model for mismatched digest algorithms. Specifically: 
an implementation that accepts and processes a CMS object using a digest
algorithm different from the one the Composite ML-DSA algorithm was 
designed for may produce an invalid composite signature validation result, 
potentially leading to a false positive. This is the security rationale 
for the MUST requirement in Section 3.4. The SECDIR reviewer 
Yaroslav Rosomakho (thanks, Yaroslav) recommended this addition.

No reference entry found for this items, which were mentioned in the text:
[RFC5911].

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

 * Term "his"; alternatives might be "they", "them", "their"
 * 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"

# IESG review of draft-ietf-lamps-cms-composite-sigs-04

CC @MikeBishop

## Comments

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC5911]`

## Nits

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.

### Typos

#### "Acknowledgements", paragraph 2
```
-    Thanks to the co-authors of [RFC9882], Ben Salter and Adam Raine,
-                                                                    ^
+    Thanks to the co-authors of [RFC9882], Ben Salter and Adam Raine;
+                                                                    ^
```

Hi Mike, John, Jan, Daniel, and Russ,

Thank you of the clarifications provided by email and the changes made in -05 [1]. These address all points raised in my previous ballot [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-cms-composite-sigs-04&url2=draft-ietf-lamps-cms-composite-sigs-05&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/spasm/dD3uh4hDk6wu3B1shB1yl-VBLmQ/

Thank you to Paul Kyzivat for the GENART review.