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

[=JeffH <[e-mail]>]

> Do you think it would be reasonable to reference the Chromium +
> Mozilla CT policies but not define a particular policy in a normative
> way?

yep :)

> 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,

agreed.

> but I'm totally open to having the draft discuss some of the factors
> that browsers should consider when choosing a policy.

yes, I think that'd be good, at least to illustrate what UAs' CT 
policies might entail.



> On Wed, Nov 23, 2016 at 4:29 PM, =JeffH
> <[e-mail]> 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 <[e-mail]> 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" <[e-mail]>
>
> 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