Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-08

[Ballot comment]
My Discuss point is resolved in the editor's copy, so clearing.

Original Comment preserved below.

Some section-by-section comments:

Section 1

I should probably defer to the HTTP experts in the room, but I was not sure
if it is better to say that we are defining a new "HTTP header field" or a
new "HTTP response header field".

Section 1.1

RFC 8174 has updated BCP 14 boilerplate text.

Section 1.2

The "Certificate Transparency Policy" definition implicitly assumes that
SCTs will be served on TLS connections, as opposed to obtained out of band
(perhaps via a UA-side cache).  This doesn't seem immediately problematic,
but perhaps a more generic definition is advisable.

Section 2.1

Please also note that the '#' ABNF extension is specified in Section 7 of
RFC 7230.
Also, since the 'max-age' directive is required, are the semantics actually
just "#" or would "1#" be more accurate?

  4.  UAs MUST ignore any header fields containing directives, or other
      header field value data, that do not conform to the syntax
      defined in this specification.  In particular, UAs must not
      attempt to fix malformed header fields.

seems like a candidate for RFC2119 "MUST NOT".

Section 2.3.2.2

  If the substring matching the host production from the Request-URI
  (of the message to which the host responded) does not congruently
  match an existing Known Expect-CT Host's domain name, [...]

I'm having trouble parsing "production" -- is this a term of art I need to
look up?

Section 3.1

What's the extension model for the JSON report objects (e.g., if a new
"source" value needs to be defined, or a new CT version is published)?

Also, for the base64 encoded fields, are trailing '='s stripped (or do we
not care)?

Section 3.3

It's strange to say that the server MAY discard reports with "test-report"
set to true, and then not say at all what the server is supposed to do when
"test-report" is false or absent.

Section 5

  Expect-CT can be used to infer what Certificate Transparency policy
  is in use, [...]

In use by whom; the UA?

[Ballot discuss]
Thanks for the work done on defining this mechanism! I think it's quite
useful, and I plan to ballot "Yes" as soon as the minor but important issue
below is fixed.

§6.1:

>  Status:  standard

My reading of RFC 3864 does not allow Experimental RFCs to register HTTP header
fields as "Status: Standard."

[Ballot comment]
I also have a number of non-blocking comments that range from editorial to
substantial-but-not-critical. They appear below in document order.

---------------------------------------------------------------------------

ID Nits reports:

  -- Obsolete informational reference (is this intentional?): RFC 5246
    (Obsoleted by RFC 8446)

Given that this document doesn't seem to be tied to any specific version of TLS,
I suspect this should be updated.

---------------------------------------------------------------------------

§1.1:

This document makes use of non-captialized versions of terms like "should."
Please consider using the RFC 8174 boilerplate.

---------------------------------------------------------------------------

§2.1:

>  Expect-CT          = #expect-ct-directive
>  expect-ct-directive = directive-name [ "=" directive-value ]
>  directive-name      = token
>  directive-value    = token / quoted-string

I note that there is no registry for directive names in the IANA section, so
presumably there is a small, closed set of directives allowed here. Typically,
when this is the case, the ABNF includes the permissible values; e.g.:

  directive-name      = "report-uri" / "enforce" / "max-age"

...although I also note that list item (5) under the ABNF implies that the
intention here is to be extensible. If such is the case, I would suggest
adding an IANA registry that records Expect-CT directives, and specifying the
ABNF as:

  directive-name      = "report-uri" / "enforce" / "max-age" / token

NOTE that not specifying a registry in this document is practically identical to
specifying a registry with a policy of "RFC Required," as adding new values will
require a new RFC that updates this one. That's an exceptionally restrictive
policy, and I would hope that the working group would make such a decision with
intention rather than letting it happen through inaction.

---------------------------------------------------------------------------

§2.1.3:

>  The "max-age" directive is REQUIRED to be present within an "Expect-
>  CT" header field.

This doesn't appear to be true as stated; or, at least, it is stated in a
somewhat confusing way. A casual reading of this requirement is that an
"Expect-CT" header field is noncompliant if it is missing this directive.
Based on the examples given, the actual requirement here is that a response
that contains an Expect-CT header field MUST contain an Expect-CT header field
with a max-age directive, although that directive does not necessarily need to
appear in each Expect-CT header field. This should probably be clarified.

---------------------------------------------------------------------------

§3.1:

These reports indicate hostname and port, but omit scheme. RFC 6454 defines
origin (which is what you're really getting at here) as scheme/host/port.
Clearly, it doesn't make sense to report on http, so I presume that the
thought process here is that "https" is the only scheme in play. The worry I
have is that the current design is not particularly future-proof. For example,
it would take only a modest adaptation for this mechanism to work with "coaps"
URIs, except that the collecting server wouldn't be able to distinguish
between "coaps" and "https" resources on the same device. Note that port
number isn't necessarily a valid distinguisher here, as both HTTP and COAP use
ALPN, and could conceivably run on the same port as a consequence.

It seems that it would be easy to add "scheme" as an optional field at this
point in time, to head off potential confusion in the future.

---------------------------------------------------------------------------

§3.3:

>  Upon receiving an Expect-CT violation report, the report server MUST
>  respond with a 2xx (Successful) status code if it can parse the
>  request body as valid JSON and recognizes the hostname in the
>  "hostname" field of the report.

It seems to me that "port" should be treated the same as "hostname" here -- that
is, if the host:port combination (or scheme:host:port, if you make changes
based on my preceding comment) isn't expected, then the result should be a 4xx.

>  If the report body cannot be parsed
>  or the report server does not expect to receive reports for the
>  hostname in the "hostname" field, the report server MUST respond with
>  a 4xx (Client Error) status code.

Which one?

---------------------------------------------------------------------------

§5:

>  Implementations must store state about Known Expect-CT Hosts, and
>  hence which domains the UA has contacted.

The "must" here (even if non-normative) seems to overstep a boundary. For
example, when in Incognito/Private Browsing mode, browsers will take special
pains not to persistently store any information related to the domains visited.
It should probably be noted that persistent caching of this information is
subject to local policy (either here or elsewhere), and the "must" in this
sentence should be softened or qualified.

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4579


This generally seems like a sound mechanism, but I believe there are
some points here that are sufficiently unclear they might create
interop problems,s o I am balloting DISCUSS.

Most importantly, this document just says you support CT, but that
creates a potential interop problem if say 6962-tris had a different
way of delivering CT information or a different syntax. I'm not saying
you need a version here, but you need to indicate that it's not
forward-looking.

Also, see below.

DETAIL
S 2.4.
>      beginning an HTTP conversation over the TLS channel.
> 
>      If a connection to a Known Expect-CT Host violates the UA's CT policy
>      (i.e., the connection is not CT-qualified), and if the Known Expect-
>      CT Host's Expect-CT metadata indicates an "enforce" configuration,
>      the UA MUST treat the CT compliance failure as an error.

Is this supposed to be a hard failure, as with HSTS. If not, how does
it interact with HSTS's hard failure reqs.


S 3.1.
>        (This may differ from the value of the "served-certificate-chain"
>        key.)  The value is provided as an array of strings, which MUST
>        appear in the order matching the chain that the UA validated; each
>        string in the array is the Privacy-Enhanced Mail (PEM)
>        representation of each X.509 certificate as described in
>        [RFC7468].

What happens if you try to construct multiple paths?


S 3.1.
>            does not have or does not trust the public key of the log from
>            which the SCT was issued), "valid" (indicating that the UA
>            successfully validated the SCT as described in Section 5.2 of
>            [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or
>            "invalid" (indicating that the SCT validation failed because
>            of, e.g., a bad signature).

Is "invalid" anything other than the specific cases listed above?

[Ballot comment]

>      allows web host operators to instruct user agents to expect valid
>      Signed Certificate Timestamps (SCTs) to be served on connections to
>      these hosts.  Expect-CT allows web host operators to discover
>      misconfigurations in their Certificate Transparency deployments and
>      ensure that misissued certificates accepted by UAs are discoverable
>      in Certificate Transparency logs.

I don't believe that it does this. Consider a client which simply did
not support CT, then it would (a) accept a misissued certificate that
(b) was not discoverable


S 2.1.1.
> 
>              Figure 2: Syntax of the report-uri directive value
> 
>      "absolute-URI" is defined in Section 4.3 of [RFC3986].
> 
>      Hosts may set "report-uri"s that use HTTP or HTTPS.  If the scheme in

Why are you allowing HTTP?


S 2.3.2.
>        the "enforce", "max-age", or "report-uri" header field value
>        directives convey information different from that already
>        maintained by the UA.  If the "max-age" directive has a value of
>        0, the UA MUST remove its cached Expect-CT information if the host
>        was previously noted as a Known Expect-CT Host, and MUST NOT note
>        this host as a Known Expect-CT Host if it is not already noted.

As noted above, I think you need to clear the cache when you upgrade
to a potentially incompatible CT version, or otherwise reconfigure the
client.


S 2.3.2.1.
>        this host as a Known Expect-CT Host if it is not already noted.
> 
>  2.3.2.1.  Noting Expect-CT
> 
>      Upon receipt of the Expect-CT response header field over an error-
>      free TLS connection (including the validation adding in Section 2.4),

s/adding/added/?


S 2.3.2.1.
>      host's domain name and its associated Expect-CT directives in non-
>      volatile storage.
> 
>      To note a host as a Known Expect-CT Host, the UA MUST set its Expect-
>      CT metadata given in the most recently received valid Expect-CT
>      header field, as specified in Section 2.3.2.2.

This seems ungrammatical. Set it where?


S 2.3.2.2.
> 
>  2.3.2.2.  Storage Model
> 
>      If the substring matching the host production from the Request-URI
>      (of the message to which the host responded) does not congruently
>      match an existing Known Expect-CT Host's domain name, per the

I would say "exactly match" rather than "congruently match" unless
this ia term of art somewhere.


S 2.3.2.2.
>      understands them, the UA MAY note them as well.
> 
>      UAs MAY set an upper limit on the value of max-age, so that UAs that
>      have noted erroneous Expect-CT hosts (whether by accident or due to
>      attack) have some chance of recovering over time.  If the server sets
>      a max-age greater than the UA's upper limit, the UA MAY behave as if

This MAY seems out of place, given that you already said MAY.


S 2.4.
> 
>      When a UA connects to a Known Expect-CT Host using a TLS connection,
>      if the TLS connection has no errors, then the UA will apply an
>      additional correctness check: compliance with a CT Policy.  A UA
>      should evaluate compliance with its CT Policy whenever connecting to
>      a Known Expect-CT Host, as soon as possible.  However, the check can

What does "as soon as possible" mean?


S 2.4.
>      terminates the connection due to an Expect-CT failure, this could
>      cause the UA to skip subsequent correctness checks.  When the CT
>      compliance check is skipped or bypassed, Expect-CT reports
>      (Section 3) will not be sent.
> 
>      When CT compliance is evaluted for a Known Expect-CT Host, the UA

Nit: evaluated


S 2.4.1.
>      "report-uri" (Section 3).
> 
>  2.4.1.  Skipping CT compliance checks
> 
>      It is acceptable for a UA to skip CT compliance checks for some hosts
>      according to local policy.  For example, a UA may disable CT

Should this be MAY?


S 3.1.
> 
>      o  "scts": the value represents the SCTs (if any) that the UA
>        received for the Expect-CT host and their validation statuses.
>        The value is provided as an array of JSON objects.  The SCTs may
>        appear in any order.  Each JSON object in the array has the
>        following keys:

So these just apply to the EE cert? What about CT for the non-EE
certs?




S 3.1.
>            of, e.g., a bad signature).
> 
>        *  The "source" key, with a string value that indicates from where
>            the UA obtained the SCT, as defined in Section 3 of [RFC6962]
>            and Section 6 of [I-D.ietf-trans-rfc6962-bis].  The UA MUST set
>            the value to one of "tls-extension", "ocsp", or "embedded".

What do these mean? They seem obvious, but you don't say.

[Ballot comment]
S 2.1.4.
  "Expect-CT: max-age=86400, enforce"

Is the whitespace after the comma intentional?

S 3.1.
      "*  The "status" key, with a string value that the UA MUST set to
        one of the following values: "unknown" (indicating that the UA
        does not have or does not trust the public key of the log from
        which the SCT was issued), "valid" (indicating that the UA
        successfully validated the SCT as described in Section 5.2 of
        [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or
        "invalid" (indicating that the SCT validation failed because
        of, e.g., a bad signature)."

I'm surprised that the state of "does not have public key" and "does
not trust public key" don't have independent value from each other
such that a single status value is sufficient to cover both. Are there
no cases where the difference between these states would be material?
I guess this information could be gleaned in other ways aside from
this kind of report, but I'm still curious about this.

S 4.2.
    "4.2.  Avoiding amplification attacks"

This title seems like a bit of a misnomer given that the attacks can't
be fully avoided.

S 5.
  "Additionally, reports submitted to the "report-uri" could reveal
  information to a third party about which webpage is being accessed
  and by which IP address, by using individual "report-uri" values for
  individually-tracked pages.  This information could be leaked even if
  client-side scripting were disabled."

Isn't there a more generalized potential privacy exposure here if the
report-uri uses HTTP rather than HTTPS? That is, the whole report
could be exposed to any observer even without individual report-uri
values for individual pages.

[Ballot comment]
Firstly, thank you for writing this, it is a useful document and provides an important method.
Also thanks to Qin Wu for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-httpbis-expect-ct-07-opsdir-lc-wu-2018-08-07/

I had a few comments and questions:
Section 2.1.  Response Header Field Syntax
Bullet 4: "In particular, UAs must not attempt to fix malformed header fields."
Yah, I fully agree, but it seems like that should be a MUST NOT - I guess the "UAs MUST ignore..." mitigates this, but any reason not to have it stronger?

Section 2.1.1.  The report-uri Directive
HSTS seems to be undefined -- this leads me to a larger point -- I think that it would be very valuable to draw a comparison between HSTS and Expect-CT in the introduction -- they work in a somewhat related manner, and would make it easier (IMO) for newcomers to understand the utility of this.

"UAs SHOULD make their best effort to report Expect-CT failures to the "report-uri", but they may fail to report in exceptional conditions.
For example, if connecting to the "report-uri" itself incurs an  Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. "
This might be the bad-idea fariy visiting, but perhaps reporting under an Expect-CT failure should be allowed. e.g: www.example.com implments Expect-CT -- the "obvious" report-uri is www.example.com/ct-failed - but this won't actully get reports of failures, because, well, failures :-P
If you don't like the above (and I **fully** see why you might not), perhaps a strong operational recommendation to have the report-uri be some other host is in order? Preventing foot cannons good....

"UAs SHOULD limit the rate at which they send reports.  For example,
  it is unnecessary to send the same report to the same "report-uri"
  more than once."  - once in what period? Connection? Before it gets expired?

Section 2.2.  Server Processing Model
Should this be "Host Processing Model" for consistency?


Section 3.2.  Sending a violation report
"The UA SHOULD report an Expect-CT failure when a connection to a
Known Expect-CT Host does not comply with the UA’s CT Policy and the
host’s Expect-CT metadata contains a "report-uri".  Additionally, the
UA SHOULD report an Expect-CT failure when it receives an Expect-CT
header field which contains the "report-uri" directive over a
connection that does not comply with the UA’s CT Policy."

Can this be reworded somehow? I don't have a suggestion because I read it multiple times and am not sure I understand the difference between the first and second sentence. I started writing it down and drawing circles and arrows and a paragraph on the back of each one before decided this means it isn't clear.

[Ballot comment]
Firstly, thank you for writing this, it is a useful document and provides an important method.

I had a few comments and questions:
Section 2.1.  Response Header Field Syntax
Bullet 4: "In particular, UAs must not attempt to fix malformed header fields."
Yah, I fully agree, but it seems like that should be a MUST NOT - I guess the "UAs MUST ignore..." mitigates this, but any reason not to have it stronger?

Section 2.1.1.  The report-uri Directive
HSTS seems to be undefined -- this leads me to a larger point -- I think that it would be very valuable to draw a comparison between HSTS and Expect-CT in the introduction -- they work in a somewhat related manner, and would make it easier (IMO) for newcomers to understand the utility of this.

"UAs SHOULD make their best effort to report Expect-CT failures to the "report-uri", but they may fail to report in exceptional conditions.
For example, if connecting to the "report-uri" itself incurs an  Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. "
This might be the bad-idea fariy visiting, but perhaps reporting under an Expect-CT failure should be allowed. e.g: www.example.com implments Expect-CT -- the "obvious" report-uri is www.example.com/ct-failed - but this won't actully get reports of failures, because, well, failures :-P
If you don't like the above (and I **fully** see why you might not), perhaps a strong operational recommendation to have the report-uri be some other host is in order? Preventing foot cannons good....

"UAs SHOULD limit the rate at which they send reports.  For example,
  it is unnecessary to send the same report to the same "report-uri"
  more than once."  - once in what period? Connection? Before it gets expired?

Section 2.2.  Server Processing Model
Should this be "Host Processing Model" for consistency?


Section 3.2.  Sending a violation report
"The UA SHOULD report an Expect-CT failure when a connection to a
Known Expect-CT Host does not comply with the UA’s CT Policy and the
host’s Expect-CT metadata contains a "report-uri".  Additionally, the
UA SHOULD report an Expect-CT failure when it receives an Expect-CT
header field which contains the "report-uri" directive over a
connection that does not comply with the UA’s CT Policy."

Can this be reworded somehow? I don't have a suggestion because I read it multiple times and am not sure I understand the difference between the first and second sentence. I started writing it down and drawing circles and arrows and a paragraph on the back of each one before decided this means it isn't clear.

[Ballot discuss]
This should be a trivial discuss to resolve, but affects interoperability
so is still balloted as such.  In Section 3.1:

  o  "validated-certificate-chain": the value is the certificate chain
      as constructed by the UA during certificate chain verification.
      (This may differ from the value of the "served-certificate-chain"
      key.)  The value is provided as an array of strings, which MUST
      appear in the order matching the chain that the UA validated; each
      string in the array is the Privacy-Enhanced Mail (PEM)
      representation of each X.509 certificate as described in
      [RFC7468].

This needs to say whether the end-entity certificate appears first or last
(that is, without assuming what order the UA's chain-validation code uses).
I believe we usually say something like "the first certificate in the chain
represents the end-entity certificate being verified".

[Ballot comment]
Some section-by-section comments:

Section 1

I should probably defer to the HTTP experts in the room, but I was not sure
if it is better to say that we are defining a new "HTTP header field" or a
new "HTTP response header field".

Section 1.1

RFC 8174 has updated BCP 14 boilerplate text.

Section 1.2

The "Certificate Transparency Policy" definition implicitly assumes that
SCTs will be served on TLS connections, as opposed to obtained out of band
(perhaps via a UA-side cache).  This doesn't seem immediately problematic,
but perhaps a more generic definition is advisable.

Section 2.1

Please also note that the '#' ABNF extension is specified in Section 7 of
RFC 7230.
Also, since the 'max-age' directive is required, are the semantics actually
just "#" or would "1#" be more accurate?

  4.  UAs MUST ignore any header fields containing directives, or other
      header field value data, that do not conform to the syntax
      defined in this specification.  In particular, UAs must not
      attempt to fix malformed header fields.

seems like a candidate for RFC2119 "MUST NOT".

Section 2.3.2.2

  If the substring matching the host production from the Request-URI
  (of the message to which the host responded) does not congruently
  match an existing Known Expect-CT Host's domain name, [...]

I'm having trouble parsing "production" -- is this a term of art I need to
look up?

Section 3.1

What's the extension model for the JSON report objects (e.g., if a new
"source" value needs to be defined, or a new CT version is published)?

Also, for the base64 encoded fields, are trailing '='s stripped (or do we
not care)?

Section 3.3

It's strange to say that the server MAY discard reports with "test-report"
set to true, and then not say at all what the server is supposed to do when
"test-report" is false or absent.

Section 5

  Expect-CT can be used to infer what Certificate Transparency policy
  is in use, [...]

In use by whom; the UA?

[Ballot comment]
Thanks for this work. I'm balloting "Yes", but I have a few minor comments.

Substantive:

§2.1, step 6: Is there no room for local policy here?

§2.1.3: The guidance for max-age in the security considerations section suggests 30 days is a good value. But the directive is specified in seconds. Does that make sense? Would a 1 second max-age ever be reasonable? Or even 30 days + 1 second?


Editorial:

- General: This uses a non-standard section order towards the end. Conventionally the last 2 sections should be security considerations and IANA considerations (although the order between those two varies.)

§2.2.2: The second sentence is about UA behavior. It seems like that belongs somewhere under §2.3.

§2.3: "SHALL be canonicalized"
By the UA?  (The use of passive voice here obscures the actor.)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-expect-ct-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single new header field name will be registered as follows:

Header Field Name: Expect-CT
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

Name:  expect-ct-report+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

# Shepherd Writeup for draft-ietf-httpbis-expect-ct

## 1. Summary

Mark Nottingham is the document shepherd. Alexey Melnikov is the responsible Area Director.

This document defines a new HTTP header field, 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. Expect-CT allows web host operators to discover misconfigurations in
their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs
are discoverable in Certificate Transparency logs.

## 2. Review and Consensus

This document did not see a tremendous amount of discussion after the Working Group agreed to adopt it, but did see a number of reviews from within the community. Given its intended status as Experimental, we believe this is appropriate.

## 3. Intellectual Property

The author has confirmed that to her direct, personal knowledge, all IPR related to this document has already been disclosed.

## 4. Other

Note that this document has a normative reference to draft-ietf-trans-rfc6962-bis, which is not yet in IESG review.

The following Last Call announcement was sent out (ends 2018-08-14):

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, draft-ietf-httpbis-expect-ct@ietf.org, Mark Nottingham , mnot@mnot.net, ietf-http-wg@w3.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Expect-CT Extension for HTTP) to Experimental RFC


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document: - 'Expect-CT Extension for HTTP'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a new HTTP header field, 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.  Expect-CT allows web host operators to discover
  misconfigurations in their Certificate Transparency deployments and
  ensure that misissued certificates accepted by UAs are discoverable
  in Certificate Transparency logs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/ballot/


No IPR declarations have been submitted directly on this I-D.

I have some non blocking comments which I will send to the WG mailing list. In the meantime, I can start IETF LC on the document.

# Shepherd Writeup for draft-ietf-httpbis-expect-ct

## 1. Summary

Mark Nottingham is the document shepherd. Alexey Melnikov is the responsible Area Director.

This document defines a new HTTP header field, 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. Expect-CT allows web host operators to discover misconfigurations in
their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs
are discoverable in Certificate Transparency logs.

## 2. Review and Consensus

This document did not see a tremendous amount of discussion after the Working Group agreed to adopt it, but did see a number of reviews from within the community. Given its intended status as Experimental, we believe this is appropriate.

## 3. Intellectual Property

The author has confirmed that to her direct, personal knowledge, all IPR related to this document has already been disclosed.