Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

[Carrick Bartle <[e-mail]>]

Great! I'll push it on over and continue reviewing.


> On Feb 14, 2020, at 11:36 AM, Nick Sullivan <nick=[e-mail]> wrote:
> 
> Carrick,
> 
> Thank you for reading the document and identifying an embarrassingly difficult to parse motivating paragraph (with an annoying unclosed parenthesis to boot). You've correctly identified the meaning it was trying to convey and we'll happily review this as a PR here: https://github.com/tlswg/tls-subcerts/ <https://github.com/tlswg/tls-subcerts/>. I've noticed a few other readability issues in the document, if you find anything else, we'll happily look at those too.
> 
> Nick
> 
> On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle <cbartle891=[e-mail] <mailto:[e-mail]>> wrote:
> TL;DR: I find it difficult to understand the second-to-last paragraph of the Introduction, so I took a stab at revising it. Let me know if I should put it in a pull request.
> 
> 
> This is the paragraph I'm referring to:
> 
> "These dependencies cause problems in practice. Server operators often want to create short-lived certificates for servers in low- trust zones such as Content Delivery Network (CDNs) or remote data centers. This allows server operators to limit the exposure of keys in cases that they do not realize a compromise has occurred. The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials. In Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446], if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance. On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk."
> 
> Here are my issues with it:
> 
> - I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.
> 
> - I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.
> 
> - The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.
> 
> Taking all these points together, here's my suggestion for a revision to make what I think the thrust of the paragraph is more clear:
> 
> "These dependencies cause problems in practice. Server operators often want to create short-lived certificates for servers in low-trust zones such as Content Delivery Network (CDNs) or remote data centers. This allows server operators to limit the exposure of keys in cases where they do not realize a compromise has occurred. But the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short-lived credentials. For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled response. While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates is even worse: the service that depends on those certificates would go down entirely. Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service."
> 
> 
> Carrick
> 
> 
> 
> > On Feb 5, 2020, at 12:36 PM, [e-mail] <mailto:[e-mail]> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> > 
> >        Title           : Delegated Credentials for TLS
> >        Authors         : Richard Barnes
> >                          Subodh Iyengar
> >                          Nick Sullivan
> >                          Eric Rescorla
> >       Filename        : draft-ietf-tls-subcerts-06.txt
> >       Pages           : 15
> >       Date            : 2020-02-05
> > 
> > Abstract:
> >   The organizational separation between the operator of a TLS endpoint
> >   and the certification authority can create limitations.  For example,
> >   the lifetime of certificates, how they may be used, and the
> >   algorithms they support are ultimately determined by the
> >   certification authority.  This document describes a mechanism by
> >   which operators may delegate their own credentials for use in TLS,
> >   without breaking compatibility with peers that do not support this
> >   specification.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ <https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/>
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tls-subcerts-06 <https://tools.ietf.org/html/draft-ietf-tls-subcerts-06>
> > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06 <https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06>
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06>
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls