Great! I'll push it on over and continue reviewing.
> On Feb 14, 2020, at 11:36 AM, Nick Sullivan > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> > 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, [email protected] > > <mailto:[email protected]> 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 > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > _______________________________________________ > TLS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
