- From: Emily Stark <estark@google.com>
- Date: Wed, 23 Nov 2016 17:14:32 -0800
- To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
- Cc: IETF HTTP WG <ietf-http-wg@w3.org>, Eric Rescorla <ekr@rtfm.com>
- Message-ID: <CAPP_2SY_C3eToX0UXv2ymzaCDaEqAbSX_x-=-=8mzsZb4n4WEA@mail.gmail.com>
Jeff -- thanks for the comments. Do you think it would be reasonable to reference the Chromium + Mozilla CT policies but not define a particular policy in a normative way? I maintain that it isn't Expect-CT's place to define a CT policy just as it isn't HSTS's place to define what goes in a trust store, but I'm totally open to having the draft discuss some of the factors that browsers should consider when choosing a policy. On Wed, Nov 23, 2016 at 4:29 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > "Expect-CT" <https://tools.ietf.org/html/draft-stark-expect-ct> (aka "the > I-D" in the below) uses the term "CT policy" in many places but does not > define the meaning of the term, as noted by EKR. > > On Tuesday, November 15, 2016 at 1:53 PM EKR wrote: > > > > I'm arguing that we shouldn't define a header that says "you must > > enforce CT" without defining what "enforce CT" means. > > Agreed. > > Emily Stark <estark@google.com> also wrote on Monday, November 21, > 2016 at 3:28 PM: > > > > - Policy: One can draw an analogy to HSTS, where a site promises to > > provide a certificate that is valid according to the client's > > definition of valid, including factors that vary across clients > > (variations in trust stores, SHA1 deprecation, etc.). > > Although I would not characterize HSTS policy in that fashion (i.e., see > <https://tools.ietf.org/html/rfc6797#section-5.2>), I agree there are > (some) variations in UAs' contextual determination of whether any error > conditions arise during secure channel establishment. > > > In practice, I don't think CT will be more of a foot-gun than HSTS > > (and certainly much less than HPKP) because browsers are in close > > collaboration to work out policies that play nicely with each other. > > Hopefully that is the case. > > I note the present Chrome CT Policy is here: > > Certificate Transparency in Chrome > <https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chro > mium.org/dev/Home/chromium-security/root-ca-policy/ > CTPolicyMay2016edition.pdf> > > A first draft of the Mozilla CT Policy is here: > <https://docs.google.com/document/d/1rnqYYwscAx8WhS-MCdTiNzY > Qus9e37HuVyafQvEeNro> > (see also: https://groups.google.com/a/chromium.org/forum/#!topic/ct-po > licy/waQ5oqg-USg) > > And discussions of CT policy overall are occurring on: "Certificate > Transparency Policy" <ct-policy@chromium.org> > > The I-D should reference them in some fashion. The Moz draft has CT and CT > background info that may be useful to borrow for the I-D or explicitly > reference. > > > Hm, it seems the term "CT qualified" (or "CT-qualified" (sigh)) -- as in a > "CT qualified certificate" -- has traction with both GOOG and Moz, perhaps > it ought to be employed as appropriate in the I-D. > > > HTH, > > =JeffH >
Received on Thursday, 24 November 2016 01:15:25 UTC