draft-ietf-httpbis-expect-ct-02.txt   draft-ietf-httpbis-expect-ct-03.txt 
HTTP Working Group E. Stark HTTP E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental August 14, 2017 Intended status: Experimental February 26, 2018
Expires: February 15, 2018 Expires: August 30, 2018
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-02 draft-ietf-httpbis-expect-ct-03
Abstract Abstract
This document defines a new HTTP header, named Expect-CT, that allows This document defines a new HTTP header, named Expect-CT, that allows
web host operators to instruct user agents to expect valid Signed web host operators to instruct user agents to expect valid Signed
Certificate Timestamps (SCTs) to be served on connections to these Certificate Timestamps (SCTs) to be served on connections to these
hosts. When configured in enforcement mode, user agents (UAs) will hosts. When configured in enforcement mode, user agents (UAs) will
remember that hosts expect SCTs and will refuse connections that do remember that hosts expect SCTs and will refuse connections that do
not conform to the UA's Certificate Transparency policy. When not conform to the UA's Certificate Transparency policy. When
configured in report-only mode, UAs will report the lack of valid 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. SCTs to a URI configured by the host, but will allow the connection.
By turning on Expect-CT, web host operators can discover By turning on Expect-CT, web host operators can discover
misconfigurations in their Certificate Transparency deployments and misconfigurations in their Certificate Transparency deployments and
ensure that misissued certificates accepted by UAs are discoverable ensure that misissued certificates accepted by UAs are discoverable
in Certificate Transparency logs. in Certificate Transparency logs.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/. https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
Working Group information can be found at http://httpwg.github.io/; Working Group information can be found at http://httpwg.github.io/
source code and issues list for this draft can be found at [2]; source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/expect-ct. https://github.com/httpwg/http-extensions/labels/expect-ct [3].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2018. This Internet-Draft will expire on August 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Server and Client Behavior . . . . . . . . . . . . . . . . . 4 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 5
2.1. Response Header Field Syntax . . . . . . . . . . . . . . 4 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 5
2.1.1. The report-uri Directive . . . . . . . . . . . . . . 5 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 6
2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6
2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 7 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 7
2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7
2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 8
2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8
2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8
2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 8 2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 8
2.3.2. HTTP-Equiv <meta> Element Attribute . . . . . . . . . 9 2.3.2. HTTP-Equiv <meta> Element Attribute . . . . . . . . . 9
2.3.3. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9 2.3.3. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9
2.3.4. Storage Model . . . . . . . . . . . . . . . . . . . . 9 2.3.4. Storage Model . . . . . . . . . . . . . . . . . . . . 9
2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10
3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11
3.1. Generating a violation report . . . . . . . . . . . . . . 11 3.1. Generating a violation report . . . . . . . . . . . . . . 11
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 3.3. Receiving a violation report . . . . . . . . . . . . . . 14
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.2. Avoiding amplification attacks . . . . . . . . . . . . . 14 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
7. Usability Considerations . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 15 7. Usability Considerations . . . . . . . . . . . . . . . . . . 16
8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 15 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 16
8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 9.3. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines a new HTTP header that enables UAs to identify This document defines a new HTTP header that enables UAs to identify
web hosts that expect the presence of Signed Certificate Timestamps web hosts that expect the presence of Signed Certificate Timestamps
(SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer (SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer
Security (TLS) [RFC5246] connections. Security (TLS) [RFC5246] connections.
Web hosts that serve the Expect-CT HTTP header are noted by the UA as Web hosts that serve the Expect-CT HTTP header are noted by the UA as
Known Expect-CT Hosts. The UA evaluates each connection to a Known Known Expect-CT Hosts. The UA evaluates each connection to a Known
skipping to change at page 5, line 8 skipping to change at page 5, line 15
2. Server and Client Behavior 2. Server and Client Behavior
2.1. Response Header Field Syntax 2.1. Response Header Field Syntax
The "Expect-CT" header field is a new response header defined in this The "Expect-CT" header field is a new response header defined in this
specification. It is used by a server to indicate that UAs should specification. It is used by a server to indicate that UAs should
evaluate connections to the host emitting the header for CT evaluate connections to the host emitting the header for CT
compliance (Section 2.4). compliance (Section 2.4).
Figure 1 describes the syntax (Augmented Backus-Naur Form) of the Figure 1 describes the syntax (Augmented Backus-Naur Form) of the
header field, using the grammar defined in RFC 5234 [RFC5234] and the header field, using the grammar defined in [RFC5234] and the rules
rules defined in Section 3.2 of RFC 7230 [RFC7230]. defined in Section 3.2 of [RFC7230].
Expect-CT = #expect-ct-directive Expect-CT = #expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ] expect-ct-directive = directive-name [ "=" directive-value ]
directive-name = token directive-name = token
directive-value = token / quoted-string directive-value = token / quoted-string
Figure 1: Syntax of the Expect-CT header field Figure 1: Syntax of the Expect-CT header field
Optional white space ("OWS") is used as defined in Section 3.2.3 of Optional white space ("OWS") is used as defined in Section 3.2.3 of
RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined [RFC7230]. "token" and "quoted-string" are used as defined in
in Section 3.2.6 of RFC 7230 [RFC7230]. Section 3.2.6 of [RFC7230].
The directives defined in this specification are described below. The directives defined in this specification are described below.
The overall requirements for directives are: The overall requirements for directives are:
1. The order of appearance of directives is not significant. 1. The order of appearance of directives is not significant.
2. A given directive MUST NOT appear more than once in a given 2. A given directive MUST NOT appear more than once in a given
header field. Directives are either optional or required, as header field. Directives are either optional or required, as
stipulated in their definitions. stipulated in their definitions.
skipping to change at page 6, line 12 skipping to change at page 6, line 18
SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the
reports to the given URI as described in Section 3. reports to the given URI as described in Section 3.
The "report-uri" directive is REQUIRED to have a directive value, for The "report-uri" directive is REQUIRED to have a directive value, for
which the syntax is defined in Figure 2. which the syntax is defined in Figure 2.
report-uri-value = absolute-URI report-uri-value = absolute-URI
Figure 2: Syntax of the report-uri directive value Figure 2: Syntax of the report-uri directive value
"absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986]. "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 Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme in
the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check
Expect-CT compliance when the host in the "report-uri" is a Known Expect-CT compliance when the host in the "report-uri" is a Known
Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the
"report-uri" is a Known HSTS Host. "report-uri" is a Known HSTS Host.
Note that the report-uri need not necessarily be in the same Internet Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the host being reported about. domain or web origin as the host being reported about.
UAs SHOULD make their best effort to report Expect-CT failures to the UAs SHOULD make their best effort to report Expect-CT failures to the
"report-uri", but they may fail to report in exceptional conditions. "report-uri", but they may fail to report in exceptional conditions.
For example, if connecting the "report-uri" itself incurs an Expect- For example, if connecting to the "report-uri" itself incurs an
CT failure or other certificate validation failure, the UA MUST Expect-CT failure or other certificate validation failure, the UA
cancel the connection. Similarly, if Expect-CT Host A sets a MUST cancel the connection. Similarly, if Expect-CT Host A sets a
"report-uri" referring to Expect-CT Host B, and if B sets a "report- "report-uri" referring to Expect-CT Host B, and if B sets a "report-
uri" referring to A, and if both hosts fail to comply to the UA's CT uri" referring to A, and if both hosts fail to comply to the UA's CT
Policy, the UA SHOULD detect and break the loop by failing to send Policy, the UA SHOULD detect and break the loop by failing to send
reports to and about those hosts. reports to and about those hosts.
UAs SHOULD limit the rate at which they send reports. For example, 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" it is unnecessary to send the same report to the same "report-uri"
more than once. more than once.
2.1.2. The enforce Directive 2.1.2. The enforce Directive
skipping to change at page 7, line 22 skipping to change at page 7, line 24
The "max-age" directive is REQUIRED to be present within an "Expect- The "max-age" directive is REQUIRED to be present within an "Expect-
CT" header field. The "max-age" directive is REQUIRED to have a CT" header field. The "max-age" directive is REQUIRED to have a
directive value, for which the syntax (after quoted-string directive value, for which the syntax (after quoted-string
unescaping, if necessary) is defined in Figure 3. unescaping, if necessary) is defined in Figure 3.
max-age-value = delta-seconds max-age-value = delta-seconds
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Figure 3: Syntax of the max-age directive value Figure 3: Syntax of the max-age directive value
"delta-seconds" is used as defined in Section 1.2.1 of RFC 7234 "delta-seconds" is used as defined in Section 1.2.1 of [RFC7234].
[RFC7234].
2.1.4. Examples 2.1.4. Examples
The following examples demonstrate valid Expect-CT response header The following examples demonstrate valid Expect-CT response header
fields: fields:
Expect-CT: max-age=86400,enforce Expect-CT: max-age=86400,enforce
Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report" Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"
skipping to change at page 9, line 17 skipping to change at page 9, line 24
connection is not CT-qualified), and the UA has not already sent an connection is not CT-qualified), and the UA has not already sent an
Expect-CT report for this connection, then the UA SHOULD send a Expect-CT report for this connection, then the UA SHOULD send a
report to the specified "report-uri" as specified in Section 3. report to the specified "report-uri" as specified in Section 3.
The UA MUST ignore any Expect-CT header field not conforming to the The UA MUST ignore any Expect-CT header field not conforming to the
grammar specified in Section 2.1. grammar specified in Section 2.1.
2.3.2. HTTP-Equiv <meta> Element Attribute 2.3.2. HTTP-Equiv <meta> Element Attribute
UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
"<meta>" elements [W3C.REC-html401-19991224] in received content. "<meta>" elements [W3C.REC-html51-20161101] in received content.
2.3.3. Noting Expect-CT 2.3.3. Noting Expect-CT
Upon receipt of the Expect-CT response header field over an error- Upon receipt of the Expect-CT response header field over an error-
free TLS connection (including the validation adding in Section 2.4), free TLS connection (including the validation adding in Section 2.4),
the UA MUST note the host as a Known Expect-CT Host, storing the the UA MUST note the host as a Known Expect-CT Host, storing the
host's domain name and its associated Expect-CT directives in non- host's domain name and its associated Expect-CT directives in non-
volatile storage. The domain name and associated Expect-CT volatile storage. The domain name and associated Expect-CT
directives are collectively known as "Expect-CT metadata". directives are collectively known as "Expect-CT metadata".
skipping to change at page 12, line 8 skipping to change at page 12, line 16
original request that failed the CT compliance check. The value original request that failed the CT compliance check. The value
is provided as a string. is provided as a string.
o "port": the value is the port to which the UA made the original o "port": the value is the port to which the UA made the original
request that failed the CT compliance check. The value is request that failed the CT compliance check. The value is
provided as an integer. provided as an integer.
o "effective-expiration-date": the value indicates the Effective o "effective-expiration-date": the value indicates the Effective
Expiration Date (see Section 2.3.4) for the Expect-CT Host that Expiration Date (see Section 2.3.4) for the Expect-CT Host that
failed the CT compliance check. The value is provided as a string failed the CT compliance check. The value is provided as a string
formatted according to Section 5.6, "Internet Date/Time Format", formatted according to Section 5.6 of [RFC3339] ("Internet Date/
of [RFC3339]. Time Format").
o "served-certificate-chain": the value is the certificate chain as o "served-certificate-chain": the value is the certificate chain as
served by the Expect-CT Host during TLS session setup. The value served by the Expect-CT Host during TLS session setup. The value
is provided as an array of strings, which MUST appear in the order is provided as an array of strings, which MUST appear in the order
that the certificates were served; each string in the array is the that the certificates were served; each string in the array is the
Privacy-Enhanced Mail (PEM) representation of each X.509 Privacy-Enhanced Mail (PEM) representation of each X.509
certificate as described in [RFC7468]. certificate as described in [RFC7468].
o "validated-certificate-chain": the value is the certificate chain o "validated-certificate-chain": the value is the certificate chain
as constructed by the UA during certificate chain verification. as constructed by the UA during certificate chain verification.
skipping to change at page 13, line 14 skipping to change at page 13, line 21
* The "serialized_sct" key, with a string value. If the value of * The "serialized_sct" key, with a string value. If the value of
the "version" key is "1", the UA MUST set this value to the the "version" key is "1", the UA MUST set this value to the
base64 encoded [RFC4648] serialized base64 encoded [RFC4648] serialized
"SignedCertificateTimestamp" structure from Section 3.2 of "SignedCertificateTimestamp" structure from Section 3.2 of
[RFC6962]. If the value of the "version" key is "2", the UA [RFC6962]. If the value of the "version" key is "2", the UA
MUST set this value to the base64 encoded [RFC4648] serialized MUST set this value to the base64 encoded [RFC4648] serialized
"TransItem" structure representing the SCT, as defined in "TransItem" structure representing the SCT, as defined in
Section 4.6 of [I-D.ietf-trans-rfc6962-bis]. Section 4.6 of [I-D.ietf-trans-rfc6962-bis].
o "failure-mode": the value indicates whether the Expect-CT report
was triggered by an Expect-CT policy in enforce or report-only
mode. The value is provided as a string. The UA MUST set this
value to "enforce" if the Expect-CT metadata indicates an
"enforce" configuration, and "report-only" otherwise.
o "test-report": the value is set to true if the report is being
sent by a testing client to verify that the reporting server
behaves correctly. The value is provided as a boolean, and MUST
be set to true if the report serves to test the server's behavior
and can be discarded.
3.2. Sending a violation report 3.2. Sending a violation report
The UA SHOULD report an Expect-CT failure when a connection to a 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 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 host's Expect-CT metadata contains a "report-uri". Additionally, the
UA SHOULD report an Expect-CT failure when it receives an Expect-CT UA SHOULD report an Expect-CT failure when it receives an Expect-CT
header field which contains the "report-uri" directive over a header field which contains the "report-uri" directive over a
connection that does not comply with the UA's CT Policy. connection that does not comply with the UA's CT Policy.
The steps to report an Expect-CT failure are as follows. The steps to report an Expect-CT failure are as follows.
1. Prepare a JSON object "report object" with the single key 1. Prepare a JSON object "report object" with the single key
"expect-ct-report", whose value is the result of generating a "expect-ct-report", whose value is the result of generating a
violation report object as described in Section 3.1. violation report object as described in Section 3.1.
2. Let "report body" by the JSON stringification of "report object". 2. Let "report body" be the JSON stringification of "report object".
3. Let "report-uri" be the value of the "report-uri" directive in 3. Let "report-uri" be the value of the "report-uri" directive in
the Expect-CT header field. the Expect-CT header field.
4. Send an HTTP POST request to "report-uri" with a "Content-Type" 4. Send an HTTP POST request to "report-uri" with a "Content-Type"
header field of "application/expect-ct-report+json", and an header field of "application/expect-ct-report+json", and an
entity body consisting of "report body". entity body consisting of "report body".
The UA MAY perform other operations as part of sending the HTTP POST The UA MAY perform other operations as part of sending the HTTP POST
request, for example sending a CORS preflight as part of [FETCH]. request, for example sending a CORS preflight as part of [FETCH].
3.3. Receiving a violation report
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. 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.
If the report's "test-report" key is set to true, the server MAY
discard the report without further processing but MUST still return a
2xx (Successful) status code.
4. Security Considerations 4. Security Considerations
When UAs support the Expect-CT header, it becomes a potential vector When UAs support the Expect-CT header, it becomes a potential vector
for hostile header attacks against site owners. If a site owner uses for hostile header attacks against site owners. If a site owner uses
a certificate issued by a certificate authority which does not embed a certificate issued by a certificate authority which does not embed
SCTs nor serve SCTs via OCSP or TLS extension, a malicious server SCTs nor serve SCTs via OCSP or TLS extension, a malicious server
operator or attacker could temporarily reconfigure the host to comply operator or attacker could temporarily reconfigure the host to comply
with the UA's CT policy, and add the Expect-CT header in enforcing with the UA's CT policy, and add the Expect-CT header in enforcing
mode with a long "max-age". Implementing user agents would note this mode with a long "max-age". Implementing user agents would note this
as an Expect-CT Host (see Section 2.3.3). After having done this, as an Expect-CT Host (see Section 2.3.3). After having done this,
skipping to change at page 16, line 9 skipping to change at page 16, line 43
requires certificate authorities to support them, and new TLS requires certificate authorities to support them, and new TLS
extensions require server software updates, including possibly to extensions require server software updates, including possibly to
servers outside of the site owner's direct control (such as in the servers outside of the site owner's direct control (such as in the
case of a third-party CDN). Ease of deployment is a high priority case of a third-party CDN). Ease of deployment is a high priority
for Expect-CT because it is intended as a temporary transition for Expect-CT because it is intended as a temporary transition
mechanism for user agents that are transitioning to universal mechanism for user agents that are transitioning to universal
Certificate Transparency requirements. Certificate Transparency requirements.
9. Changes 9. Changes
9.1. Since -01 9.1. Since -02
o Add concept of test reports and specify that servers must respond
with 2xx status codes to valid reports.
o Add "failure-mode" key to reports to allow report servers to
distinguish report-only from enforced failures.
9.2. Since -01
o Change SCT reporting format to support both RFC 6962 and 6962-bis o Change SCT reporting format to support both RFC 6962 and 6962-bis
SCTs. SCTs.
9.2. Since -00 9.3. Since -00
o Editorial changes o Editorial changes
o Change Content-Type header of reports to 'application/expect-ct- o Change Content-Type header of reports to 'application/expect-ct-
report+json' report+json'
o Update header field syntax to match convention (issue #327) o Update header field syntax to match convention (issue #327)
o Reference RFC 6962-bis instead of RFC 6962 o Reference RFC 6962-bis instead of RFC 6962
10. Normative References 10. References
10.1. Normative References
[FETCH] van Kesteren, A., "Fetch", n.d., [FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
P., and D. Denicola, "HTML", n.d., P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>. <https://html.spec.whatwg.org/>.
[I-D.ietf-trans-rfc6962-bis] [I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency Version 2.0", draft- Stradling, "Certificate Transparency Version 2.0", draft-
ietf-trans-rfc6962-bis-26 (work in progress), July 2017. ietf-trans-rfc6962-bis-27 (work in progress), October
2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <http://www.rfc-editor.org/info/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[W3C.REC-html401-19991224] [W3C.REC-html51-20161101]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Faulkner, S., Eicholz, A., Leithead, T., and A. Danilo,
Specification", World Wide Web Consortium Recommendation "HTML 5.1", World Wide Web Consortium Recommendation REC-
REC-html401-19991224, December 1999, html51-20161101, November 2016,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <https://www.w3.org/TR/2016/REC-html51-20161101>.
10.2. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/expect-ct
Author's Address Author's Address
Emily Stark Emily Stark
Google Google
Email: estark@google.com Email: estark@google.com
 End of changes. 41 change blocks. 
64 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/