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

coalescing replies to the three prior msgs in this thread...

On Wednesday, November 23, 2016 at 7:42 PM Martin Thomson 
<martin.thomson@gmail.com> wrote:
 >
 >> On 24 November 2016 at 13:33, =JeffH
 >> <Jeff.Hodges@kingsmountain.com> wrote:
 >> Emily had written:
 >>> 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 :)
 >
 > If HSTS is our benchmark, and that benchmark is so nebulous then it's
 > a bad one.

HSTS is actually not "nebulous" about this, I did not intend to imply that.

HSTS does define a "particular normative policy", though the HSTS spec 
was not required to prescribe the underlying details beyond what's below 
at [1] -- specifically section 8.4 where the one single normative 
(policy-enforcement-wise) "MUST" resides.


 > The objection that ekr raised was fair

Agreed.

Note that I had originally suggested including such context in the HTTP 
Expect-CT I-D:
 > [...]
 > A first draft of the Mozilla CT Policy is here:
 > 
<https://docs.google.com/document/d/1rnqYYwscAx8WhS-MCdTiNzYQus9e37HuVyafQvEeNro>
 > [...]
 >
 > 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" ... -- 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.


On Thursday, November 24, 2016 at 4:55 PM Martin Thomson 
<martin.thomson@gmail.com> wrote:
 >> On 25 November 2016 at 02:52, Emily Stark <estark@google.com> wrote:
 >> But I do think it would be reasonable to advise site operators of
 >> the shape that a CT policy generally takes and what the moving
 >> parts are in practice (which is maybe what your point below is
 >> getting at).
 >
 > Yes.  This.

Agreed.


 > Ideally it would also describe the maximal policy, so an operator
 > could know where the bar is.  But that's impossible without
 > enumerating the set of possible log operators and I don't think we
 > want that.

Agreed, have the browsers vendors' CT-Policy specs address such details [2].

=JeffH


[1] https://tools.ietf.org/html/rfc6797#section-2.2

2.2.  HTTP Strict Transport Security Policy Effects

    The effects of the HSTS Policy, as applied by a conformant UA in
    interactions with a web resource host wielding such policy (known as
    an HSTS Host), are summarized as follows:

    1.  UAs transform insecure URI references to an HSTS Host into secure
        URI references before dereferencing them.

    2.  The UA terminates any secure transport connection attempts upon
        any and all secure transport errors or warnings.


  https://tools.ietf.org/html/rfc6797#section-5.2

  5.2.  HSTS Policy

    An HSTS Policy directs UAs to communicate with a Known HSTS Host only
    over secure transport and specifies policy retention time duration.

    HSTS Policy explicitly overrides the UA processing of URI references,
    user input (e.g., via the "location bar"), or other information that,
    in the absence of HSTS Policy, might otherwise cause UAs to
    communicate insecurely with the Known HSTS Host.

    An HSTS Policy may contain an optional directive -- includeSubDomains
    -- specifying that this HSTS Policy also applies to any hosts whose
    domain names are subdomains of the Known HSTS Host's domain name.


  https://tools.ietf.org/html/rfc6797#section-8.4

  8.4.  Errors in Secure Transport Establishment

    When connecting to a Known HSTS Host, the UA MUST terminate the
    connection (see also Section 12 ("User Agent Implementation Advice"))
    if there are any errors, whether "warning" or "fatal" or any other
    error level, with the underlying secure transport.  For example, this
    includes any errors found in certificate validity checking that UAs
    employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
    via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
    as via TLS server identity checking [RFC6125].



[2] Google and Mozilla are discussing "certificate transparency policy" 
here: <https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy>
(aka  <ct-policy@chromium.org>)

Received on Friday, 25 November 2016 02:50:10 UTC