IETF Last Call Review of draft-ietf-lamps-cms-composite-sigs-04
review-ietf-lamps-cms-composite-sigs-04-artart-lc-turner-2026-04-13-00
| Request | Review of | draft-ietf-lamps-cms-composite-sigs |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | IETF Last Call Review | |
| Team | ART Area Review Team (artart) | |
| Deadline | 2026-04-13 | |
| Requested | 2026-03-30 | |
| Authors | Mike Ounsworth , John Gray , Jan Klaußner , Daniel Van Geest | |
| I-D last updated | 2026-05-29 (Latest revision 2026-05-22) | |
| Completed reviews |
Artart IETF Last Call review of -04
by Sean Turner
(diff)
Opsdir IETF Last Call review of -04 by Niclas Comstedt (diff) Genart IETF Last Call review of -04 by Paul Kyzivat (diff) Secdir IETF Last Call review of -04 by Yaroslav Rosomakho (diff) |
|
| Assignment | Reviewer | Sean Turner |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-lamps-cms-composite-sigs by ART Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/art/U9OR9RAWypcE8BGLyM5gWgGpUvs | |
| Reviewed revision | 04 (document currently at 05) | |
| Result | Ready w/issues | |
| Completed | 2026-04-13 |
review-ietf-lamps-cms-composite-sigs-04-artart-lc-turner-2026-04-13-00
Hi! I would say "Ready with an Issue", based on this question (and if I missed this somewhere in the deliberations I really, really do not want to re-open a can of worms): s3.4 requires that the message digest algorithm MUST be the same digest algorithm used by the Composite ML-DSA algorithm. Does this requirement extend RFC 5652 s5.6 (Signature Verification Process"? If the answer is "yes", then I think we should say that s5.6 is extended and that the signature is not valid if the two signatures are not made using the same algorithm. One nit (**there is NO impact on bits on the wire as this string is not transmitted**): To avoid an annoying errata later, use "identified-organization(3)" in s2's OID strings from draft-ietf-lamps-pq-composite-sigs instead of "org(3)". NOTE: I didn't verify the ASN.1 blobs in Appendix A.