Subject: Fwd: New Version Notification for draft-ietf-httpbis-expect-ct-02.txt

From: Emily Stark <[email-masked]>
Date: Mon, 14 Aug 2017 15:46:34 -0700

This version expands the Expect-CT reporting format to support both RFC
6962 and 6962-bis SCTs.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Aug 14, 2017 at 3:43 PM
Subject: New Version Notification for draft-ietf-httpbis-expect-ct-02.txt
To: "[email-masked]" <[email-masked]>

A new version of I-D, draft-ietf-httpbis-expect-ct-02.txt
has been successfully submitted by Emily Stark and posted to the
IETF repository.

Name:           draft-ietf-httpbis-expect-ct
Revision:       02
Title:          Expect-CT Extension for HTTP
Document date:  2017-08-14
Group:          httpbis
Pages:          18
URL:            https://www.ietf.org/internet-drafts/draft-ietf-httpbis-expe
ct-ct-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-
ct/
Htmlized:       https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-ex
pect-ct-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-expect
-ct-02

Abstract:
   This document defines a new HTTP header, named Expect-CT, that allows
   web host operators to instruct user agents to expect valid Signed
   Certificate Timestamps (SCTs) to be served on connections to these
   hosts.  When configured in enforcement mode, user agents (UAs) will
   remember that hosts expect SCTs and will refuse connections that do
   not conform to the UA's Certificate Transparency policy.  When
   configured in report-only mode, UAs will report the lack of valid
   SCTs to a URI configured by the host, but will allow the connection.
   By turning on Expect-CT, web host operators can discover
   misconfigurations in their Certificate Transparency deployments and
   ensure that misissued certificates accepted by UAs are discoverable
   in Certificate Transparency logs.

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.

The IETF Secretariat

---

From: Tom Ritter <[email-masked]>
Date: Mon, 21 Aug 2017 14:30:59 -0500

*  A "version" key, with an integer value.  The UA MUST set this
         value to "1" if the SCT is in the format defined in Section 3.2
         of [RFC6962] and "2" if it is in the format defined in
         Section 4.6 of [I-D.ietf-trans-rfc6962-bis].

I feel like it would be better to match the version field from the
SCT; which starts numbering at 0.  Otherwise Version 1 in Expect-CT
corresponds to Version 0 SCTs, and Version 1 SCTs use Version 2 in
Expect-CT.

-tom

On 14 August 2017 at 17:46, Emily Stark <[email-masked]> wrote:
> This version expands the Expect-CT reporting format to support both RFC 6962
> and 6962-bis SCTs.
>
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-httpbis-expect-ct-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-expect-ct-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-expect-ct-02
>
> Abstract:

---

From: Emily Stark <[email-masked]>
Date: Mon, 21 Aug 2017 17:49:17 -0700

Hm, RFC 6962 is a bit weird, the enum name is v1 but it has value 0.

I don't feel strongly either way, but changing this will have a bit of a
compat cost because we've already shipped "1" in Chrome.

On Mon, Aug 21, 2017 at 12:30 PM, Tom Ritter <[email-masked]> wrote:

> 6962