Subject: Re: CT-Policy (was: Comments on draft-stark-expect-ct-00)

From: =JeffH <[email-masked]>
Date: Wed, 23 Nov 2016 16:29:01 -0800

"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 <[email-masked]> 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/chromium.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-MCdTiNzYQus9e37HuVyafQvEeNro>
(see also: 
https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/waQ5oqg-USg)

And discussions of CT policy overall are occurring on: "Certificate 
Transparency Policy" <[email-masked]>

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

---

From: Emily Stark <[email-masked]>
Date: Wed, 23 Nov 2016 17:14:32 -0800

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 <[email-masked]>
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.
>
> <https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chro
> mium.org/dev/Home/chromium-security/root-ca-policy/
> CTPolicyMay2016edition.pdf>
>
> (see also: https://groups.google.com/a/chromium.org/forum/#!topic/ct-po
> licy/waQ5oqg-USg)
>
> 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
>