Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Nick Sullivan <[e-mail]>]

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 <
[e-mail]> 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