Francesca and Christian, Thank you for the review. Answers inline below and changes in Github ( https://github.com/tlswg/tls-subcerts/pull/108/files).
Best, Nick On Tue, May 31, 2022 at 11:49 AM Francesca Palombini via Datatracker < nore...@ietf.org> wrote: > Francesca Palombini has entered the following ballot position for > draft-ietf-tls-subcerts-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work on this document. > > Many thanks to Christian Amsüss for his ART ART review: > https://mailarchive.ietf.org/arch/msg/art/7lzdOaiccRnXFtSuX3aUyh9ffV8/. > Authors, please take a look at Christian's comments (also reported below), > especially the one about the "delegated_credential" usage in the > Certificate > message. > > Francesca > > -- > > Reviewer: Christian Amsüss > Review result: Ready with Nits > > Thanks for this well-written document > > ART topics: > > The document does not touch on any of the typical ART review issues; times > are > relative in well understood units, and versioning, formal language (ASN.1, > which is outside of my experience to check) and encoding infrastructure > (struct) follows TLS practices. > > General comments: > > * The introduction of this mechanism gives the impression of a band-aid > applied > to a PKI ecosystem that has accumulated many limitations as outlined in > section > 3.1. The present solution appears good, but if there is ongoing work on the > underlying issues (even experimentally), I'd appreciate a careful > reference to > it. > Unfortunately, there are no good references for alternative approaches. > > * Section 7.6 hints at the front end querying the back-end for creation of > new > DCs -- other than that, DC distribution (neither push- nor pull-based) is > discussed. If there are any mechanisms brewing, I'd appreciate a reference > as > well. > There are no formal mechanisms moving towards standardization at this time. > > Please check: > > * The IANA considerations list "delegated_credential" for CH, CR and CT > messages. I did not find a reference in the text for Ct, only for CH and > CR. > See section 4.1.2, where it states: "The client MUST send the DC as an extension in the CertificateEntry of its end-entity certificate" which is where CT extensions live. > > Editorial comments: > > * (p5) "result for the peer.." -- extraneous period. > * (p9, p15, p16) The "7 days" are introduced as the default for a > profilable > prarameter, but later used without further comment. > > Addressed
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
