Skip to main content

Last Call Review of draft-ietf-tls-subcerts-12

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 Snapshot
Review review-ietf-tls-subcerts-12-genart-lc-davies-2022-04-08
Posted at
Reviewed revision 12 (document currently at 15)
Result Ready w/nits
Completed 2022-04-08
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


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

Ready with nits.    Just a few editrial level nits.

Major issues:

Minor issues:

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:"