Last Call Review of draft-ietf-tls-subcerts-12
review-ietf-tls-subcerts-12-genart-lc-davies-2022-04-08-01
| Request | Review of | draft-ietf-tls-subcerts |
|---|---|---|
| Requested revision | No specific revision (document currently at 15) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2022-04-08 | |
| Requested | 2022-03-19 | |
| Authors | Richard Barnes , Subodh Iyengar , Nick Sullivan , Eric Rescorla | |
| I-D last updated | 2022-04-08 | |
| Completed reviews |
Artart Last Call review of -12
by Christian Amsüss
(diff)
Genart Last Call review of -12 by Elwyn B. Davies (diff) |
|
| Assignment | Reviewer | Elwyn B. Davies |
| State | Completed | |
| Request | Last Call review on draft-ietf-tls-subcerts by General Area Review Team (Gen-ART) Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s | |
| Reviewed revision | 12 (document currently at 15) | |
| Result | Ready w/nits | |
| Completed | 2022-04-08 |
review-ietf-tls-subcerts-12-genart-lc-davies-2022-04-08-01
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Just a few editrial level nits. Major issues: None Minor issues: None. Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expected_cert_verify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:"