draft-ietf-httpbis-expect-ct-07.txt   draft-ietf-httpbis-expect-ct-08.txt 
HTTP E. Stark HTTP E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental July 16, 2018 Intended status: Experimental December 9, 2018
Expires: January 17, 2019 Expires: June 12, 2019
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-07 draft-ietf-httpbis-expect-ct-08
Abstract Abstract
This document defines a new HTTP header field, named Expect-CT, that This document defines a new HTTP header field named Expect-CT, which
allows web host operators to instruct user agents to expect valid allows web host operators to instruct user agents to expect valid
Signed Certificate Timestamps (SCTs) to be served on connections to Signed Certificate Timestamps (SCTs) to be served on connections to
these hosts. Expect-CT allows web host operators to discover these hosts. Expect-CT allows web host operators to discover
misconfigurations in their Certificate Transparency deployments and misconfigurations in their Certificate Transparency deployments.
ensure that misissued certificates accepted by UAs are discoverable Further, web host operaters can use Expect-CT to ensure that, if a UA
in Certificate Transparency logs. which supports Expect-CT accepts a misissued certificate, that
certificate will be discoverable 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/ [1]. 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/
[2]; 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 [3]. https://github.com/httpwg/http-extensions/labels/expect-ct [3].
skipping to change at page 1, line 46 skipping to change at page 1, line 47
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 https://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 January 17, 2019. This Internet-Draft will expire on June 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Server and Client Behavior . . . . . . . . . . . . . . . . . 5 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 5
2.1. Response Header Field Syntax . . . . . . . . . . . . . . 5 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 5
2.1.1. The report-uri Directive . . . . . . . . . . . . . . 6 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 6
2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 7
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. Host Processing Model . . . . . . . . . . . . . . . . . . 8
2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 8 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. Missing or Malformed Expect-CT Header Fields . . . . 8 2.3.1. Missing or Malformed Expect-CT Header Fields . . . . 9
2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 8 2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 9
2.3.3. Reporting . . . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Reporting . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 11
2.4.1. Skipping CT compliance checks . . . . . . . . . . . . 11 2.4.1. Skipping CT compliance checks . . . . . . . . . . . . 12
3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 12
3.1. Generating a violation report . . . . . . . . . . . . . . 12 3.1. Generating a violation report . . . . . . . . . . . . . . 12
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 14
3.3. Receiving a violation report . . . . . . . . . . . . . . 14 3.3. Receiving a violation report . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Usability Considerations . . . . . . . . . . . . . . . . . . 16
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15 5. Authoring Considerations . . . . . . . . . . . . . . . . . . 16
4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.1. Hostile header attacks . . . . . . . . . . . . . . . . . 17
6.1. Header Field Registry . . . . . . . . . . . . . . . . . . 16 7.2. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 17
6.2. Media Types Registry . . . . . . . . . . . . . . . . . . 16 7.3. Amplification attacks . . . . . . . . . . . . . . . . . . 18
7. Usability Considerations . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 17 8.1. Header Field Registry . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Media Types Registry . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 21
A.3. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 22
A.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.3. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 22
A.5. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 22
A.6. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.5. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 22
A.7. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.6. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 A.7. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 22
A.8. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document defines a new HTTP header field that enables UAs to This document defines a new HTTP header field that enables UAs to
identify web hosts that expect the presence of Signed Certificate identify web hosts that expect the presence of Signed Certificate
Timestamps (SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Timestamps (SCTs) [I-D.ietf-trans-rfc6962-bis] in subsequent
Layer Security (TLS) [RFC5246] connections. Transport Layer Security (TLS) [RFC8446] connections.
Web hosts that serve the Expect-CT HTTP header field are noted by the Web hosts that serve the Expect-CT HTTP header field are noted by the
UA as Known Expect-CT Hosts. The UA evaluates each connection to a UA as Known Expect-CT Hosts. The UA evaluates each connection to a
Known Expect-CT Host for compliance with the UA's Certificate Known Expect-CT Host for compliance with the UA's Certificate
Transparency (CT) Policy. If the connection violates the CT Policy, Transparency (CT) Policy. If the connection violates the CT Policy,
the UA sends a report to a URI configured by the Expect-CT Host and/ the UA sends a report to a URI configured by the Expect-CT Host and/
or fails the connection, depending on the configuration that the or fails the connection, depending on the configuration that the
Expect-CT Host has chosen. Expect-CT Host has chosen.
If misconfigured, Expect-CT can cause unwanted connection failures If misconfigured, Expect-CT can cause unwanted connection failures
(for example, if a host deploys Expect-CT but then switches to a (for example, if a host deploys Expect-CT but then switches to a
legitimate certificate that is not logged in Certificate Transparency legitimate certificate that is not logged in Certificate Transparency
logs, or if a web host operator believes their certificate to conform logs, or if a web host operator believes their certificate to conform
to all UAs' CT policies but is mistaken). Web host operators are to all UAs' CT policies but is mistaken). Web host operators are
advised to deploy Expect-CT with caution, by using the reporting advised to deploy Expect-CT with precautions, by using the reporting
feature and gradually increasing the interval where the UA remembers feature and gradually increasing the time interval during which the
the host as a Known Expect-CT Host. These precautions can help web UA regards the host as a Known Expect-CT Host. These precautions can
host operators gain confidence that their Expect-CT deployment is not help web host operators gain confidence that their Expect-CT
causing unwanted connection failures. deployment is not causing unwanted connection failures.
Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a
UA connects to a host, it lacks the information necessary to require UA connects to a host, it lacks the information necessary to require
SCTs for the connection. Thus, the UA will not be able to detect and SCTs for the connection. Thus, the UA will not be able to detect and
thwart an attack on the UA's first connection to the host. Still, thwart an attack on the UA's first connection to the host. Still,
Expect-CT provides value by 1) allowing UAs to detect the use of Expect-CT provides value by 1) allowing UAs to detect the use of
unlogged certificates after the initial communication, and 2) unlogged certificates after the initial communication, and 2)
allowing web hosts to be confident that UAs are only trusting allowing web hosts to be confident that UAs are only trusting
publicly-auditable certificates. publicly-auditable certificates.
Expect-CT is similar to HSTS [RFC6797] and HPKP [RFC7469]. HSTS
allows web sites to declare themselves accessible only via secure
connections, and HPKP allows web sites to declare their cryptographic
identifies. Similarly, Expect-CT allows web sites to declare
themselves accessible only via connections that are compliant with CT
policy.
This Expect-CT specification is compatible with [RFC6962] and
[I-D.ietf-trans-rfc6962-bis], but not with future versions of
Certificate Transparency. Expect-CT header fields will be ignore
from web hosts which use future versions of Certificate Transparency,
unless a future version of this document specifies how they should be
processed.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in BCP
2119 [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology 1.2. Terminology
Terminology is defined in this section. Terminology is defined in this section.
o "Certificate Transparency Policy" is a policy defined by the UA o "Certificate Transparency Policy" is a policy defined by the UA
concerning the number, sources, and delivery mechanisms of Signed concerning the number, sources, and delivery mechanisms of Signed
Certificate Timestamps that are served on TLS connections. The Certificate Timestamps that are associated with TLS connections.
policy defines the properties of a connection that must be met in The policy defines the properties of a connection that must be met
order for the UA to consider it CT-qualified. in order for the UA to consider it CT-qualified.
o "Certificate Transparency Qualified" describes a TLS connection o "Certificate Transparency Qualified" describes a TLS connection
for which the UA has determined that a sufficient quantity and for which the UA has determined that a sufficient quantity and
quality of Signed Certificate Timestamps have been provided. quality of Signed Certificate Timestamps have been provided.
o "CT-qualified" is an abbreviation for "Certificate Transparency o "CT-qualified" is an abbreviation for "Certificate Transparency
Qualified". Qualified".
o "CT Policy" is an abbreviation for "Certificate Transparency o "CT Policy" is an abbreviation for "Certificate Transparency
Policy". Policy".
skipping to change at page 5, line 16 skipping to change at page 5, line 32
2.1. Response Header Field Syntax 2.1. Response Header Field Syntax
The "Expect-CT" response header field is a new field defined in this The "Expect-CT" response header field is a new field 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 field for CT evaluate connections to the host emitting the header field 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 [RFC5234] and the rules header field, using the grammar defined in [RFC5234] and the rules
defined in Section 3.2 of [RFC7230]. defined in Section 3.2 of [RFC7230]. The "#" ABNF extension is
specified in Section 7 of [RFC7230].
Expect-CT = #expect-ct-directive Expect-CT = 1#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
[RFC7230]. "token" and "quoted-string" are used as defined in
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.
3. Directive names are case insensitive. 3. Directive names are case insensitive.
4. UAs MUST ignore any header fields containing directives, or other 4. UAs MUST ignore any header fields containing directives, or other
header field value data, that do not conform to the syntax header field value data that do not conform to the syntax defined
defined in this specification. In particular, UAs must not in this specification. In particular, UAs MUST NOT attempt to
attempt to fix malformed header fields. fix malformed header fields.
5. If a header field contains any directive(s) the UA does not 5. If a header field contains any directive(s) the UA does not
recognize, the UA MUST ignore those directives. recognize, the UA MUST ignore those directives.
6. If the Expect-CT header field otherwise satisfies the above 6. If the Expect-CT header field otherwise satisfies the above
requirements (1 through 5), the UA MUST process the directives it requirements (1 through 5), and Expect-CT is not disabled for
recognizes. local policy reasons (as discussed in Section 2.4.1), the UA MUST
process the directives it recognizes.
2.1.1. The report-uri Directive 2.1.1. The report-uri Directive
The OPTIONAL "report-uri" directive indicates the URI to which the UA The OPTIONAL "report-uri" directive indicates the URI to which the UA
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 [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 UAs MUST ignore "report-uri"s that do not use the HTTPS scheme. UAs
the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check MUST check Expect-CT compliance when the host in the "report-uri" is
Expect-CT compliance when the host in the "report-uri" is a Known a Known Expect-CT Host; similarly, UAs MUST apply HSTS [RFC6797] if
Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the 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
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 to the "report-uri" itself incurs an For example, if connecting to the "report-uri" itself incurs an
Expect-CT failure or other certificate validation failure, the UA Expect-CT failure or other certificate validation failure, the UA
MUST 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.
Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the host being reported about. Hosts are in
fact encouraged to use a separate host as the report-uri, so that CT
failures on the Expect-CT host do not prevent reports from being
sent.
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 in the same web browsing session.
2.1.2. The enforce Directive 2.1.2. The enforce Directive
The OPTIONAL "enforce" directive is a valueless directive that, if The OPTIONAL "enforce" directive is a valueless directive that, if
present (i.e., it is "asserted"), signals to the UA that compliance present (i.e., it is "asserted"), signals to the UA that compliance
to the CT Policy should be enforced (rather than report-only) and to the CT Policy should be enforced (rather than report-only) and
that the UA should refuse future connections that violate its CT that the UA should refuse future connections that violate its CT
Policy. When both the "enforce" directive and "report-uri" directive Policy. When both the "enforce" directive and "report-uri" directive
(as defined in Figure 2) are present, the configuration is referred (as defined in Figure 2) are present, the configuration is referred
to as an "enforce-and-report" configuration, signalling to the UA to as an "enforce-and-report" configuration, signalling to the UA
both that compliance to the CT Policy should be enforced and that both that compliance to the CT Policy should be enforced and that
violations should be reported. violations should be reported.
2.1.3. The max-age Directive 2.1.3. The max-age Directive
The "max-age" directive specifies the number of seconds after the The "max-age" directive specifies the number of seconds after the
reception of the Expect-CT header field during which the UA SHOULD reception of the Expect-CT header field during which the UA SHOULD
regard the host from whom the message was received as a Known Expect- regard the host from whom the message was received as a Known Expect-
CT Host. CT Host.
The "max-age" directive is REQUIRED to be present within an "Expect- If a response contains an "Expect-CT" header field, then the response
CT" header field. The "max-age" directive is REQUIRED to have a MUST contain an "Expect-CT" header field with a "max-age" directive.
directive value, for which the syntax (after quoted-string (A "max-age" directive need not appear in every "Expect-CT" header
field in the response.) The "max-age" directive is REQUIRED to have
a 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 [RFC7234]. "delta-seconds" is used as defined in Section 1.2.1 of [RFC7234].
2.1.4. Examples 2.1.4. Examples
skipping to change at page 7, line 41 skipping to change at page 8, line 14
Expect-CT: max-age=86400, enforce Expect-CT: max-age=86400, enforce
Expect-CT: max-age=86400,enforce Expect-CT: max-age=86400,enforce
Expect-CT: report-uri="https://foo.example/report" Expect-CT: report-uri="https://foo.example/report"
Expect-CT: max-age=86400,report-uri="https://foo.example/report" Expect-CT: max-age=86400,report-uri="https://foo.example/report"
Figure 4: Examples of valid Expect-CT response header fields Figure 4: Examples of valid Expect-CT response header fields
2.2. Server Processing Model 2.2. Host Processing Model
This section describes the processing model that Expect-CT Hosts This section describes the processing model that Expect-CT Hosts
implement. The model has 2 parts: (1) the processing rules for HTTP implement. The model has 2 parts: (1) the processing rules for HTTP
request messages received over a secure transport (e.g., request messages received over a secure transport (e.g.,
authenticated, non-anonymous TLS); and (2) the processing rules for authenticated, non-anonymous TLS); and (2) the processing rules for
HTTP request messages received over non-secure transports, such as HTTP request messages received over non-secure transports, such as
TCP. TCP.
2.2.1. HTTP-over-Secure-Transport Request Type 2.2.1. HTTP-over-Secure-Transport Request Type
skipping to change at page 8, line 23 skipping to change at page 8, line 41
1. Over the HTTP protocol running over secure transport, by 1. Over the HTTP protocol running over secure transport, by
correctly returning (per this specification) a valid Expect-CT correctly returning (per this specification) a valid Expect-CT
header field to the UA. header field to the UA.
2. Through other mechanisms, such as a client-side preloaded Expect- 2. Through other mechanisms, such as a client-side preloaded Expect-
CT Host list. CT Host list.
2.2.2. HTTP Request Type 2.2.2. HTTP Request Type
Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP
responses conveyed over non-secure transport. UAs MUST ignore any responses conveyed over non-secure transport.
Expect-CT header field received in an HTTP response conveyed over
non-secure transport.
2.3. User Agent Processing Model 2.3. User Agent Processing Model
The UA processing model relies on parsing domain names. Note that The UA processing model relies on parsing domain names. Note that
internationalized domain names SHALL be canonicalized according to internationalized domain names SHALL be canonicalized by the UA
the scheme in Section 10 of [RFC6797]. according to the scheme in Section 10 of [RFC6797].
The UA stores Known Expect-CT Hosts and their associated Expect-CT The UA stores Known Expect-CT Hosts and their associated Expect-CT
directives. This data is collectively known as a host's "Expect-CT" directives. This data is collectively known as a host's "Expect-CT"
metadata". metadata".
2.3.1. Missing or Malformed Expect-CT Header Fields 2.3.1. Missing or Malformed Expect-CT Header Fields
If an HTTP response does not include an Expect-CT header field that If an HTTP response does not include an Expect-CT header field that
conforms to the grammar specified in Section 2.1, then the UA MUST conforms to the grammar specified in Section 2.1, then the UA MUST
NOT update any Expect-CT metadata. NOT update any Expect-CT metadata.
2.3.2. Expect-CT Header Field Processing 2.3.2. Expect-CT Header Field Processing
If the UA receives, over a secure transport, an HTTP response that If the UA receives an HTTP response over a secure transport that
includes an Expect-CT header field conforming to the grammar includes an Expect-CT header field conforming to the grammar
specified in Section 2.1, the UA MUST evaluate the connection on specified in Section 2.1, the UA MUST evaluate the connection on
which the header field was received for compliance with the UA's CT which the header field was received for compliance with the UA's CT
Policy, and then process the Expect-CT header field as follows. Policy, and then process the Expect-CT header field as follows. UAs
MUST ignore any Expect-CT header field received in an HTTP response
conveyed over non-secure transport.
If the connection does not comply with the UA's CT Policy (i.e., the If the connection does not comply with the UA's CT Policy (i.e., the
connection is not CT-qualified), then the UA MUST NOT update any connection is not CT-qualified), then the UA MUST NOT update any
Expect-CT metadata. If the header field includes a "report-uri" Expect-CT metadata. If the header field includes a "report-uri"
directive, the UA SHOULD send a report to the specified "report-uri" directive, the UA SHOULD send a report to the specified "report-uri"
(Section 2.3.3). (Section 2.3.3).
If the connection complies with the UA's CT Policy (i.e., the If the connection complies with the UA's CT Policy (i.e., the
connection is CT-qualified), then the UA MUST either: connection is CT-qualified), then the UA MUST either:
skipping to change at page 9, line 22 skipping to change at page 9, line 41
noted (see Section 2.3.2.1), or noted (see Section 2.3.2.1), or
o Update the UA's cached information for the Known Expect-CT Host if o Update the UA's cached information for the Known Expect-CT Host if
the "enforce", "max-age", or "report-uri" header field value the "enforce", "max-age", or "report-uri" header field value
directives convey information different from that already directives convey information different from that already
maintained by the UA. If the "max-age" directive has a value of 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 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 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. this host as a Known Expect-CT Host if it is not already noted.
If a UA receives an Expect-CT header field over a CT-compliant
connection which uses a version of Certificate Transparency other
than [RFC6962] or [I-D.ietf-trans-rfc6962-bis], the UA MUST ignore
the Expect-CT header field and clear any Expect-CT metadata
associated with the host.
2.3.2.1. Noting Expect-CT 2.3.2.1. 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 (with X.509 certificate chain validation as
the UA MUST note the host as a Known Expect-CT Host, storing the described in [RFC5280], as well as the validation described in
host's domain name and its associated Expect-CT directives in non- Section 2.4), the UA MUST note the host as a Known Expect-CT Host,
volatile storage. storing the 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- 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 CT metadata in its Known Expect-CT Host cache (as specified in
header field, as specified in Section 2.3.2.2. Section 2.3.2.2, using the metadata given in the most recently
received valid Expect-CT header field.
For forward compatibility, the UA MUST ignore any unrecognized For forward compatibility, the UA MUST ignore any unrecognized
Expect-CT header field directives, while still processing those Expect-CT header field directives, while still processing those
directives it does recognize. Section 2.1 specifies the directives directives it does recognize. Section 2.1 specifies the directives
"enforce", "max-age", and "report-uri", but future specifications and "enforce", "max-age", and "report-uri", but future specifications and
implementations might use additional directives. implementations might use additional directives.
2.3.2.2. Storage Model 2.3.2.2. Storage Model
If the substring matching the host production from the Request-URI If the substring matching the host production from the Request-URI
(of the message to which the host responded) does not congruently (of the message to which the host responded) does not exactly match
match an existing Known Expect-CT Host's domain name, per the an existing Known Expect-CT Host's domain name, per the matching
matching procedure specified in Section 8.2 of [RFC6797], then the UA procedure for a Congruent Match specified in Section 8.2 of
MUST add this host to the Known Expect-CT Host cache. The UA caches: [RFC6797], then the UA MUST add this host to the Known Expect-CT Host
cache. The UA caches:
o the Expect-CT Host's domain name, o the Expect-CT Host's domain name,
o whether the "enforce" directive is present o whether the "enforce" directive is present
o the Effective Expiration Date, which is the Effective Expect-CT o the Effective Expiration Date, which is the Effective Expect-CT
Date plus the value of the "max-age" directive. Alternatively, Date plus the value of the "max-age" directive. Alternatively,
the UA MAY cache enough information to calculate the Effective the UA MAY cache enough information to calculate the Effective
Expiration Date. The Effective Expiration Date is calculated from Expiration Date. The Effective Expiration Date is calculated from
when the UA observed the Expect-CT header field and is independent when the UA observed the Expect-CT header field and is independent
of when the response was generated. of when the response was generated.
o the value of the "report-uri" directive, if present. o the value of the "report-uri" directive, if present.
If any other metadata from optional or future Expect-CT header If any other metadata from optional or future Expect-CT header
skipping to change at page 10, line 20 skipping to change at page 10, line 47
o the value of the "report-uri" directive, if present. o the value of the "report-uri" directive, if present.
If any other metadata from optional or future Expect-CT header If any other metadata from optional or future Expect-CT header
directives are present in the Expect-CT header field, and the UA directives are present in the Expect-CT header field, and the UA
understands them, the UA MAY note them as well. 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 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 have noted erroneous Expect-CT hosts (whether by accident or due to
attack) have some chance of recovering over time. If the server sets 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 a max-age greater than the UA's upper limit, the UA may behave as if
the server set the max-age to the UA's upper limit. For example, if the server set the max-age to the UA's upper limit. For example, if
the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT
Host sets a max- age directive of 90 days in its Expect-CT header Host sets a max- age directive of 90 days in its Expect-CT header
field, the UA MAY behave as if the max-age were effectively 60 days. field, the UA may behave as if the max-age were effectively 60 days.
(One way to achieve this behavior is for the UA to simply store a (One way to achieve this behavior is for the UA to simply store a
value of 60 days instead of the 90-day value provided by the Expect- value of 60 days instead of the 90-day value provided by the Expect-
CT host.) CT host.)
2.3.3. Reporting 2.3.3. Reporting
If the UA receives, over a secure transport, an HTTP response that If the UA receives, over a secure transport, an HTTP response that
includes an Expect-CT header field with a "report-uri" directive, and includes an Expect-CT header field with a "report-uri" directive, and
the connection does not comply with the UA's CT Policy (i.e., the the connection does not comply with the UA's CT Policy (i.e., the
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
skipping to change at page 10, line 51 skipping to change at page 11, line 31
host is a Known Expect-CT Host according to its Known Expect-CT Host host is a Known Expect-CT Host according to its Known Expect-CT Host
cache. An Expect-CT Host is "expired" if the effective expiration cache. An Expect-CT Host is "expired" if the effective expiration
date refers to a date in the past. The UA MUST ignore any expired date refers to a date in the past. The UA MUST ignore any expired
Expect-CT Hosts in its cache and not treat such hosts as Known Expect-CT Hosts in its cache and not treat such hosts as Known
Expect-CT hosts. Expect-CT hosts.
When a UA connects to a Known Expect-CT Host using a TLS connection, 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 if the TLS connection has no errors, then the UA will apply an
additional correctness check: compliance with a CT Policy. A UA additional correctness check: compliance with a CT Policy. A UA
should evaluate compliance with its CT Policy whenever connecting to should evaluate compliance with its CT Policy whenever connecting to
a Known Expect-CT Host, as soon as possible. However, the check can a Known Expect-CT Host. However, the check can be skipped for local
be skipped for local policy reasons (as discussed in Section 2.4.1), policy reasons (as discussed in Section 2.4.1), or in the event that
or in the event that other checks cause the UA to terminate the other checks cause the UA to terminate the connection before CT
connection before CT compliance is evaluated. For example, a Public compliance is evaluated. For example, a Public Key Pinning failure
Key Pinning failure [RFC7469] could cause the UA to terminate the [RFC7469] could cause the UA to terminate the connection before CT
connection before CT compliance is checked. Similarly, if the UA compliance is checked. Similarly, if the UA terminates the
terminates the connection due to an Expect-CT failure, this could connection due to an Expect-CT failure, this could cause the UA to
cause the UA to skip subsequent correctness checks. When the CT skip subsequent correctness checks. When the CT compliance check is
compliance check is skipped or bypassed, Expect-CT reports skipped or bypassed, Expect-CT reports (Section 3) will not be sent.
(Section 3) will not be sent.
When CT compliance is evaluted for a Known Expect-CT Host, the UA When CT compliance is evaluated for a Known Expect-CT Host, the UA
MUST evaluate compliance when setting up the TLS session, before MUST evaluate compliance when setting up the TLS session, before
beginning an HTTP conversation over the TLS channel. beginning an HTTP conversation over the TLS channel.
If a connection to a Known Expect-CT Host violates the UA's CT policy 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- (i.e., the connection is not CT-qualified), and if the Known Expect-
CT Host's Expect-CT metadata indicates an "enforce" configuration, CT Host's Expect-CT metadata indicates an "enforce" configuration,
the UA MUST treat the CT compliance failure as an error. the UA MUST treat the CT compliance failure as an error. The UA MAY
allow the user to bypass the error, unless connection errors should
have no user recourse due to other policies in effect (such as HSTS,
as described in Section 12.1 of [RFC6797].
If a connection to a Known Expect-CT Host violates the UA's CT If a connection to a Known Expect-CT Host violates the UA's CT
policy, and if the Known Expect-CT Host's Expect-CT metadata includes policy, and if the Known Expect-CT Host's Expect-CT metadata includes
a "report-uri", the UA SHOULD send an Expect-CT report to that a "report-uri", the UA SHOULD send an Expect-CT report to that
"report-uri" (Section 3). "report-uri" (Section 3).
2.4.1. Skipping CT compliance checks 2.4.1. Skipping CT compliance checks
It is acceptable for a UA to skip CT compliance checks for some hosts 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 according to local policy. For example, a UA MAY disable CT
compliance checks for hosts whose validated certificate chain compliance checks for hosts whose validated certificate chain
terminates at a user-defined trust anchor, rather than a trust anchor terminates at a user-defined trust anchor, rather than a trust anchor
built-in to the UA (or underlying platform). built-in to the UA (or underlying platform).
If the UA does not evaluate CT compliance, e.g., because the user has If the UA does not evaluate CT compliance, e.g., because the user has
elected to disable it, or because a presented certificate chain elected to disable it, or because a presented certificate chain
chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect- chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect-
CT reports. CT reports.
3. Reporting Expect-CT Failure 3. Reporting Expect-CT Failure
skipping to change at page 12, line 23 skipping to change at page 13, line 5
of [RFC3339]. of [RFC3339].
o "hostname": the value is the hostname to which the UA made the o "hostname": the value is the hostname to which the UA made the
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 "scheme": the value is the scheme with which the UA made the
original request that failed the CT compliance check. The value
is provided as a string. This key is optional and is assumed to
be "https" if not present.
o "effective-expiration-date": the value indicates the Effective o "effective-expiration-date": the value indicates the Effective
Expiration Date (see Section 2.3.2.2) for the Expect-CT Host that Expiration Date (see Section 2.3.2.2) for the Expect-CT Host that
failed the CT compliance check, in UTC. The value is provided as failed the CT compliance check, in UTC. The value is provided as
a string formatted according to Section 5.6 of [RFC3339] a string formatted according to Section 5.6 of [RFC3339]
("Internet Date/Time Format"). ("Internet Date/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.
(This may differ from the value of the "served-certificate-chain" (This may differ from the value of the "served-certificate-chain"
key.) The value is provided as an array of strings, which MUST key.) The value is provided as an array of strings, which MUST
appear in the order matching the chain that the UA validated; each appear in the order matching the chain that the UA validated; each
string in the array is the Privacy-Enhanced Mail (PEM) string in the array is the Privacy-Enhanced Mail (PEM)
representation of each X.509 certificate as described in representation of each X.509 certificate as described in
[RFC7468]. [RFC7468]. The first certificate in the chain represents the end-
entity certificate being verified. UAs that build certificate
chains in more than one way during the validation process SHOULD
send the last chain built.
o "scts": the value represents the SCTs (if any) that the UA o "scts": the value represents the SCTs (if any) that the UA
received for the Expect-CT host and their validation statuses. received for the Expect-CT host and their validation statuses.
The value is provided as an array of JSON objects. The SCTs may 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 appear in any order. Each JSON object in the array has the
following keys: following keys:
* A "version" key, with an integer value. The UA MUST set this * 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 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 of [RFC6962] and "2" if it is in the format defined in
Section 4.5 of [I-D.ietf-trans-rfc6962-bis]. Section 4.5 of [I-D.ietf-trans-rfc6962-bis].
* The "status" key, with a string value that the UA MUST set to * The "status" key, with a string value that the UA MUST set to
one of the following values: "unknown" (indicating that the UA one of the following values: "unknown" (indicating that the UA
does not have or does not trust the public key of the log from does not have or does not trust the public key of the log from
which the SCT was issued), "valid" (indicating that the UA which the SCT was issued), "valid" (indicating that the UA
successfully validated the SCT as described in Section 5.2 of 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 [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or
"invalid" (indicating that the SCT validation failed because "invalid" (indicating that the SCT validation failed because of
of, e.g., a bad signature). a bad signature or an invalid timestamp).
* The "source" key, with a string value that indicates from where * The "source" key, with a string value that indicates from where
the UA obtained the SCT, as defined in Section 3 of [RFC6962] 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 and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA MUST set
the value to one of "tls-extension", "ocsp", or "embedded". the value to one of "tls-extension", "ocsp", or "embedded".
These correspond to the three methods of delivering SCTs in the
TLS handshake that are described in Section 3.3 of [RFC6962].
* 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]. The base64 encoding is defined in Section 4 of
[RFC4648]. 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.5 of [I-D.ietf-trans-rfc6962-bis]. Section 4.5 of [I-D.ietf-trans-rfc6962-bis].
o "failure-mode": the value indicates whether the Expect-CT report o "failure-mode": the value indicates whether the Expect-CT report
was triggered by an Expect-CT policy in enforce or report-only 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 mode. The value is provided as a string. The UA MUST set this
value to "enforce" if the Expect-CT metadata indicates an value to "enforce" if the Expect-CT metadata indicates an
"enforce" configuration, and "report-only" otherwise. "enforce" configuration, and "report-only" otherwise.
o "test-report": the value is set to true if the report is being 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 sent by a testing client to verify that the report server behaves
behaves correctly. The value is provided as a boolean, and MUST correctly. The value is provided as a boolean, and MUST be set to
be set to true if the report serves to test the server's behavior true if the report serves to test the server's behavior and can be
and can be discarded. 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 Expect-CT failures for Known Expect-CT Hosts:
Known Expect-CT Host does not comply with the UA's CT Policy and the that is, when a connection to a Known Expect-CT Host does not comply
host's Expect-CT metadata contains a "report-uri". Additionally, the with the UA's CT Policy and the host's Expect-CT metadata contains a
UA SHOULD report an Expect-CT failure when it receives an Expect-CT "report-uri".
header field which contains the "report-uri" directive over a
connection that does not comply with the UA's CT Policy. Additionally, the UA SHOULD report Expect-CT failures for hosts for
which it does not have any stored Expect-CT metadata. That is, when
the UA connects to a host and receives an Expect-CT header field
which contains the "report-uri" directive, the UA SHOULD report an
Expect-CT failure if the the connection 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" be 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].
Future versions of this specification may need to modify or extend
the Expect-CT report format. They may do so by defining a new top-
level key to contain the report, replacing the "expect-ct-report"
key. Section 3.3 defines how report servers should handle report
formats that they do not support.
3.3. Receiving a violation report 3.3. Receiving a violation report
Upon receiving an Expect-CT violation report, the report server MUST Upon receiving an Expect-CT violation report, the report server MUST
respond with a 2xx (Successful) status code if it can parse the respond with a 2xx (Successful) status code if it can parse the
request body as valid JSON and recognizes the hostname in the request body as valid JSON, the report conforms to the format
"hostname" field of the report. If the report body cannot be parsed described in Section 3.1, and it recognizes the scheme, hostname, and
or the report server does not expect to receive reports for the port in the "scheme", "hostname", and "port" fields of the report.
hostname in the "hostname" field, the report server MUST respond with If the report body cannot be parsed, or the report does not conform
a 4xx (Client Error) status code. to the format described in Section 3.1, or the report server does not
expect to receive reports for the scheme, hostname, or port in the
report, then the report server MUST respond with a 400 Bad Request
status code.
As described in Section 3.2, future versions of this specification
may define new report formats that are sent with a different top-
level key. If the report server does not recognize the report
format, the report server MUST respond with a 501 Not Implemented
status code.
If the report's "test-report" key is set to true, the server MAY 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 discard the report without further processing but MUST still return a
2xx (Successful) status code. 2xx (Successful) status code. If the "test-report" key is absent or
set to false, the server SHOULD store the report for processing and
analysis by the owner of the Expect-CT Host.
4. Security Considerations 4. Usability Considerations
When the UA detects a Known Expect-CT Host in violation of the UA's
CT Policy, end users will experience denials of service. It is
advisable for UAs to explain to users why they cannot access the
Expect-CT Host, e.g., in a user interface that explains that the
host's certificate cannot be validated.
5. Authoring Considerations
Expect-CT could be specified as a TLS extension or X.509 certificate
extension instead of an HTTP response header field. Using an HTTP
header field as the mechanism for Expect-CT introduces a layering
mismatch: for example, the software that terminates TLS and validates
Certificate Transparency information might know nothing about HTTP.
Nevertheless, an HTTP header field was chosen primarily for ease of
deployment. In practice, deploying new certificate extensions
requires certificate authorities to support them, and new TLS
extensions require server software updates, including possibly to
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
for Expect-CT because it is intended as a temporary transition
mechanism for user agents that are transitioning to universal
Certificate Transparency requirements.
6. Privacy Considerations
Expect-CT can be used to infer what Certificate Transparency policy a
UA is using, by attempting to retrieve specially-configured websites
which pass one user agents' policies but not another's. Note that
this consideration is true of UAs which enforce CT policies without
Expect-CT as well.
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.
Implementations store state about Known Expect-CT Hosts, and hence
which domains the UA has contacted. Implementations may choose to
not store this state subject to local policy (e.g., in the private
browsing mode of a web browser).
Violation reports, as noted in Section 3, contain information about
the certificate chain that has violated the CT policy. In some
cases, such as organization-wide compromise of the end-to-end
security of TLS, this may include information about the interception
tools and design used by the organization that the organization would
otherwise prefer not be disclosed.
Because Expect-CT causes remotely-detectable behavior, it's advisable
that UAs offer a way for privacy-sensitive end users to clear
currently noted Expect-CT hosts, and allow users to query the current
state of Known Expect-CT Hosts.
7. Security Considerations
7.1. Hostile header attacks
When UAs support the Expect-CT header field, it becomes a potential When UAs support the Expect-CT header field, it becomes a potential
vector for hostile header attacks against site owners. If a site vector for hostile header attacks against site owners. If a site
owner uses a certificate issued by a certificate authority which does owner uses a certificate issued by a certificate authority which does
not embed SCTs nor serve SCTs via OCSP or TLS extension, a malicious not embed SCTs nor serve SCTs via OCSP or TLS extension, a malicious
server operator or attacker could temporarily reconfigure the host to server operator or attacker could temporarily reconfigure the host to
comply with the UA's CT policy, and add the Expect-CT header field in comply with the UA's CT policy, and add the Expect-CT header field in
enforcing mode with a long "max-age". Implementing user agents would enforcing mode with a long "max-age". Implementing user agents would
note this as an Expect-CT Host (see Section 2.3.2.1). After having note this as an Expect-CT Host (see Section 2.3.2.1). After having
done this, the configuration could then be reverted to not comply done this, the configuration could then be reverted to not comply
with the CT policy, prompting failures. Note this scenario would with the CT policy, prompting failures. Note this scenario would
require the attacker to have substantial control over the require the attacker to have substantial control over the
infrastructure in question, being able to obtain different infrastructure in question, being able to obtain different
certificates, change server software, or act as a man-in-the-middle certificates, change server software, or act as a man-in-the-middle
in connections. in connections.
Site operators could themselves only cure this situation by one of: Site operators can mitigate this situation by one of: reconfiguring
reconfiguring their web server to transmit SCTs using the TLS their web server to transmit SCTs using the TLS extension defined in
extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis], Section 6.5 of [I-D.ietf-trans-rfc6962-bis], obtaining a certificate
obtaining a certificate from an alternative certificate authority from an alternative certificate authority which provides SCTs by one
which provides SCTs by one of the other methods, or by waiting for of the other methods, or by waiting for the user agents' persisted
the user agents' persisted notation of this as an Expect-CT host to notation of this as an Expect-CT host to reach its "max-age". User
reach its "max-age". User agents may choose to implement mechanisms agents may choose to implement mechanisms for users to cure this
for users to cure this situation, as noted in Section 7. situation, as noted in Section 4.
4.1. Maximum max-age 7.2. Maximum max-age
There is a security trade-off in that low maximum values provide a There is a security trade-off in that low maximum values provide a
narrow window of protection for users that visit the Known Expect-CT narrow window of protection for users that visit the Known Expect-CT
Host only infrequently, while high maximum values might result in a Host only infrequently, while high maximum values might result in a
denial of service to a UA in the event of a hostile header attack, or denial of service to a UA in the event of a hostile header attack, or
simply an error on the part of the site-owner. simply an error on the part of the site-owner.
There is probably no ideal maximum for the "max-age" directive. There is probably no ideal maximum for the "max-age" directive.
Since Expect-CT is primarily a policy-expansion and investigation Since Expect-CT is primarily a policy-expansion and investigation
technology rather than an end-user protection, a value on the order technology rather than an end-user protection, a value on the order
of 30 days (2,592,000 seconds) may be considered a balance between of 30 days (2,592,000 seconds) may be considered a balance between
these competing security concerns. these competing security concerns.
4.2. Avoiding amplification attacks 7.3. Amplification attacks
Another kind of hostile header attack uses the "report-uri" mechanism Another kind of hostile header attack uses the "report-uri" mechanism
on many hosts not currently exposing SCTs as a method to cause a on many hosts not currently exposing SCTs as a method to cause a
denial-of-service to the host receiving the reports. If some highly- denial-of-service to the host receiving the reports. If some highly-
trafficked websites emitted a non-enforcing Expect-CT header field trafficked websites emitted a non-enforcing Expect-CT header field
with a "report-uri", implementing UAs' reports could flood the with a "report-uri", implementing UAs' reports could flood the
reporting host. It is noted in Section 2.1.1 that UAs should limit reporting host. It is noted in Section 2.1.1 that UAs should limit
the rate at which they emit reports, but an attacker may alter the the rate at which they emit reports, but an attacker may alter the
Expect-CT header's fields to induce UAs to submit different reports Expect-CT header's fields to induce UAs to submit different reports
to different URIs to still cause the same effect. to different URIs to still cause the same effect.
5. Privacy Considerations 8. IANA Considerations
Expect-CT can be used to infer what Certificate Transparency policy
is in use, by attempting to retrieve specially-configured websites
which pass one user agents' policies but not another's. Note that
this consideration is true of UAs which enforce CT policies without
Expect-CT as well.
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.
Implementations must store state about Known Expect-CT Hosts, and
hence which domains the UA has contacted.
Violation reports, as noted in Section 3, contain information about
the certificate chain that has violated the CT policy. In some
cases, such as organization-wide compromise of the end-to-end
security of TLS, this may include information about the interception
tools and design used by the organization that the organization would
otherwise prefer not be disclosed.
Because Expect-CT causes remotely-detectable behavior, it's advisable
that UAs offer a way for privacy-sensitive users to clear currently
noted Expect-CT hosts, and allow users to query the current state of
Known Expect-CT Hosts.
6. IANA Considerations
6.1. Header Field Registry 8.1. Header Field Registry
This document registers the "Expect-CT" header field in the This document registers the "Expect-CT" header field in the
"Permanent Message Header Field Names" registry located at "Permanent Message Header Field Names" registry located at
https://www.iana.org/assignments/message-headers [4]. https://www.iana.org/assignments/message-headers [4].
Header field name: Expect-CT Header field name: Expect-CT
Applicable protocol: http Applicable protocol: http
Status: standard Status: experimental
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): This document Specification document(s): This document
Related information: (empty) Related information: (empty)
6.2. Media Types Registry 8.2. Media Types Registry
The MIME media type for Expect-CT violation reports is "application/ The MIME media type for Expect-CT violation reports is "application/
expect-ct-report+json" (which uses the suffix established in expect-ct-report+json" (which uses the suffix established in
[RFC6839]). [RFC6839]).
Type name: application Type name: application
Subtype name: expect-ct-report+json Subtype name: expect-ct-report+json
Required parameters: n/a Required parameters: n/a
Optional parameters: n/a Optional parameters: n/a
Encoding considerations: binary Encoding considerations: binary
Security considerations: See Section 4 Security considerations: See Section 7
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: This document Published specification: This document
Applications that use this media type: UAs that implement Applications that use this media type: UAs that implement
Certificate Transparency compliance checks and reporting Certificate Transparency compliance checks and reporting
Additional information: Additional information:
skipping to change at page 17, line 36 skipping to change at page 19, line 36
Stark (estark@google.com) Stark (estark@google.com)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Emily Stark (estark@google.com) Author: Emily Stark (estark@google.com)
Change controller: IETF Change controller: IETF
7. Usability Considerations
When the UA detects a Known Expect-CT Host in violation of the UA's
CT Policy, users will experience denials of service. It is advisable
for UAs to explain the reason why.
8. Authoring Considerations
Expect-CT could be specified as a TLS extension or X.509 certificate
extension instead of an HTTP response header field. Using an HTTP
header field as the mechanism for Expect-CT introduces a layering
mismatch: for example, the software that terminates TLS and validates
Certificate Transparency information might know nothing about HTTP.
Nevertheless, an HTTP header field was chosen primarily for ease of
deployment. In practice, deploying new certificate extensions
requires certificate authorities to support them, and new TLS
extensions require server software updates, including possibly to
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
for Expect-CT because it is intended as a temporary transition
mechanism for user agents that are transitioning to universal
Certificate Transparency requirements.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-28 (work in progress), March 2018. ietf-trans-rfc6962-bis-30 (work in progress), November
2018.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
skipping to change at page 18, line 43 skipping to change at page 20, line 23
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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,
<https://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839, Structured Syntax Suffixes", RFC 6839,
DOI 10.17487/RFC6839, January 2013, DOI 10.17487/RFC6839, January 2013,
<https://www.rfc-editor.org/info/rfc6839>. <https://www.rfc-editor.org/info/rfc6839>.
skipping to change at page 19, line 23 skipping to change at page 21, line 9
[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,
<https://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, <https://www.rfc-editor.org/info/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
9.2. Informative References 9.2. Informative References
[FETCH] WHATWG, "Fetch - Living Standard", n.d., [FETCH] WHATWG, "Fetch - Living Standard", n.d.,
<https://fetch.spec.whatwg.org>. <https://fetch.spec.whatwg.org>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
(TLS) Protocol Version 1.2", RFC 5246, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc8446>.
<https://www.rfc-editor.org/info/rfc5246>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>.
9.3. URIs 9.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/expect-ct [3] https://github.com/httpwg/http-extensions/labels/expect-ct
[4] https://www.iana.org/assignments/message-headers [4] https://www.iana.org/assignments/message-headers
Appendix A. Changes Appendix A. Changes
A.1. Since -06 A.1. Since -07
o Editorial changes o Editorial changes
A.2. Since -05 o Specify that the end-entity certificate appears first in the
"validated-certificate-chain" field of an Expect-CT report.
o Define how report format can be extended by future versions of
this specification.
o Add optional "scheme" key to report format.
o Specify exact status codes for report server errors.
o Limit report-uris to HTTPS only.
o Note that this version of Expect-CT is only compatible with RFC
6962 and 6962-bis, not any future versions of CT.
A.2. Since -06
o Editorial changes
A.3. Since -05
o Remove SHOULD requirement that UAs disallow certificate error o Remove SHOULD requirement that UAs disallow certificate error
overrides for Known Expect-CT Hosts. overrides for Known Expect-CT Hosts.
o Remove restriction that Expect-CT Hosts cannot be IP addresses. o Remove restriction that Expect-CT Hosts cannot be IP addresses.
o Editorial changes o Editorial changes
A.3. Since -04 A.4. Since -04
o Editorial changes o Editorial changes
A.4. Since -03 A.5. Since -03
o Editorial changes o Editorial changes
A.5. Since -02 A.6. Since -02
o Add concept of test reports and specify that servers must respond o Add concept of test reports and specify that servers must respond
with 2xx status codes to valid reports. with 2xx status codes to valid reports.
o Add "failure-mode" key to reports to allow report servers to o Add "failure-mode" key to reports to allow report servers to
distinguish report-only from enforced failures. distinguish report-only from enforced failures.
A.6. Since -01 A.7. 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.
A.7. Since -00 A.8. 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
Author's Address Author's Address
Emily Stark Emily Stark
 End of changes. 71 change blocks. 
213 lines changed or deleted 313 lines changed or added

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