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 05)
Type 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 2024-05-15
Completed reviews Artart Last Call review of -05 by Robert Sparks
Secdir Last Call review of -05 by Scott G. Kelly
Assignment Reviewer Robert Sparks
State Completed
Request 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
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.