Last Call Review of draft-ietf-lamps-cert-binding-for-multi-auth-05
review-ietf-lamps-cert-binding-for-multi-auth-05-artart-lc-sparks-2024-05-15-00

Request Review of draft-ietf-lamps-cert-binding-for-multi-auth
Requested revision No specific revision (document currently at 06)
Type IETF Last Call Review
Team ART Area Review Team (artart)
Deadline 2024-05-16
Requested 2024-05-02
Authors Alison Becker , Rebecca Guthrie , Michael J. Jenkins
I-D last updated 2025-06-13 (Latest revision 2024-12-10)
Completed reviews Artart IETF Last Call review of -05 by Robert Sparks (diff)
Secdir IETF Last Call review of -05 by Scott G. Kelly (diff)
Assignment Reviewer Robert Sparks
State Completed
Request IETF Last Call review on draft-ietf-lamps-cert-binding-for-multi-auth by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/MQE0qzwbpavjAW73aAS0n2H8aM8
Reviewed revision 05 (document currently at 06)
Result Ready
Completed 2024-05-15
review-ietf-lamps-cert-binding-for-multi-auth-05-artart-lc-sparks-2024-05-15-00
Summary: Ready for publication as a Proposed Standard RFC

I did not find any artart specific issues to point to in this document.

I did not re-verify the ASN, trusting that the shepherd (who has much sharper
skills there than I) got that right. (The shepherd report is very good - thank
you for that).

Some editorial suggestions:

More detail in the motivation would have been nice.

There is evidence in the security considerations section of earlier concern
expressed with the requirement that a CA processing a CSR MUST fetch a provided
URL. I'll add to that and suggest that framing the set of requirements more
carefully to "If the CA is willing to process the CSR" to leave room for common
sense operational decisions to not appear to conflict with the requirement.

I also found the "ED Note" calling out (I assume) the discussion of _not using_
SCVPCertID instead of this extension, but quoting the structure anyway, pretty
confusing. Please consider if it will stimulate implementor error.