draft-ietf-httpbis-expect-ct-05.txt   draft-ietf-httpbis-expect-ct-06.txt 
HTTP Working Group E. Stark HTTP Working Group E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental July 11, 2018 Intended status: Experimental July 11, 2018
Expires: January 12, 2019 Expires: January 12, 2019
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-05 draft-ietf-httpbis-expect-ct-06
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, that
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. When configured in enforcement mode, user agents (UAs) these hosts. Expect-CT allows web host operators to discover
will remember that hosts expect SCTs and will refuse connections that
do not conform to the UA's Certificate Transparency policy. When
configured in report-only mode, UAs will report the lack of valid
SCTs to a URI configured by the host, but will allow the connection.
By turning on Expect-CT, web host operators can discover
misconfigurations in their Certificate Transparency deployments and 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/ [1]. https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
skipping to change at page 2, line 36 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . . 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 . . . . . . . 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. Expect-CT Header Field Processing . . . . . . . . . . 8 2.3.1. Missing or Malformed Expect-CT Header Fields . . . . 8
2.3.2. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9 2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 8
2.3.3. Storage Model . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Reporting . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10
2.4.1. Skipping CT compliance checks . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . 12
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
3.3. Receiving a violation report . . . . . . . . . . . . . . 14 3.3. Receiving a violation report . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15
4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Usability Considerations . . . . . . . . . . . . . . . . . . 16 6.1. Header Field Registry . . . . . . . . . . . . . . . . . . 16
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 16 6.2. Media Types Registry . . . . . . . . . . . . . . . . . . 16
8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16 7. Usability Considerations . . . . . . . . . . . . . . . . . . 17
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 18 A.3. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.4. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.4. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.5. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.5. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 A.6. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.7. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.8. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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 future Transport
Layer Security (TLS) [RFC5246] connections. Layer Security (TLS) [RFC5246] 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
skipping to change at page 4, line 38 skipping to change at page 4, line 40
o "CT Policy" is an abbreviation for "Certificate Transparency o "CT Policy" is an abbreviation for "Certificate Transparency
Policy". Policy".
o "Effective Expect-CT Date" is the time at which a UA observed a o "Effective Expect-CT Date" is the time at which a UA observed a
valid Expect-CT header field for a given host. valid Expect-CT header field for a given host.
o "Expect-CT Host" is a conformant host implementing the HTTP server o "Expect-CT Host" is a conformant host implementing the HTTP server
aspects of Expect-CT. This means that an Expect-CT Host returns aspects of Expect-CT. This means that an Expect-CT Host returns
the "Expect-CT" HTTP response header field in its HTTP response the "Expect-CT" HTTP response header field in its HTTP response
messages sent over secure transport. messages sent over secure transport. The term "host" is
equivalent to "server" in this specification.
o "Known Expect-CT Host" is an Expect-CT Host that the UA has noted o "Known Expect-CT Host" is an Expect-CT Host that the UA has noted
as such. See Section 2.3.2 for particulars. as such. See Section 2.3.2.1 for particulars.
o UA is an acronym for "user agent". For the purposes of this o UA is an acronym for "user agent". For the purposes of this
specification, a UA is an HTTP client application typically specification, a UA is an HTTP client application typically
actively manipulated by a user [RFC7230]. actively manipulated by a user [RFC7230].
o "Unknown Expect-CT Host" is an Expect-CT Host that the UA has not o "Unknown Expect-CT Host" is an Expect-CT Host that the UA has not
noted. noted.
2. Server and Client Behavior 2. Server and Client Behavior
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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
When replying to an HTTP request that was conveyed over a secure An Expect-CT Host includes an Expect-CT header field in its response.
transport, an Expect-CT Host SHOULD include in its response exactly The header field MUST satisfy the grammar specified in Section 2.1.
one Expect-CT header field. The header field MUST satisfy the
grammar specified in Section 2.1.
Establishing a given host as an Expect-CT Host, in the context of a Establishing a given host as an Expect-CT Host, in the context of a
given UA, is accomplished as follows: given UA, is accomplished as follows:
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) at least one valid correctly returning (per this specification) a valid Expect-CT
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. UAs MUST ignore any
Expect-CT header field received in an HTTP response conveyed over Expect-CT header field received in an HTTP response conveyed over
non-secure transport. 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 according to
the scheme in Section 10 of [RFC6797]. the scheme in Section 10 of [RFC6797].
2.3.1. Expect-CT Header Field Processing The UA stores Known Expect-CT Hosts and their associated Expect-CT
directives. This data is collectively known as a host's "Expect-CT"
metadata".
2.3.1. Missing or Malformed Expect-CT Header Fields
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
NOT update any Expect-CT metadata.
2.3.2. Expect-CT Header Field Processing
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 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.
If the connection complies 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
Expect-CT metadata. If the header field includes a "report-uri"
directive, the UA SHOULD send a report to the specified "report-uri"
(Section 2.3.3).
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:
o Note the host as a Known Expect-CT Host if it is not already so o Note the host as a Known Expect-CT Host if it is not already so
noted (see Section 2.3.2), 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 the connection does not comply with the UA's CT Policy (i.e. is 2.3.2.1. Noting Expect-CT
not CT-qualified), then the UA MUST NOT note this host as a Known
Expect-CT Host.
If the header field includes a "report-uri" directive, and 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
Expect-CT report for this connection, then the UA SHOULD send a
report to the specified "report-uri" as specified in Section 3.
The UA MUST ignore any Expect-CT header field not conforming to the
grammar specified in Section 2.1.
2.3.2. 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.
directives are collectively known as "Expect-CT metadata".
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 given in the most recently received valid Expect-CT
header field, as specified in Section 2.3.3. header field, as specified in Section 2.3.2.2.
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.3. Storage Model 2.3.2.2. Storage Model
Known Expect-CT Hosts are identified only by domain names, and never
IP addresses. If the substring matching the host production from the
Request-URI (of the message to which the host responded)
syntactically matches the IP-literal or IPv4address productions from
Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a
Known Expect-CT Host.
Otherwise, if the substring does not congruently match an existing If the substring matching the host production from the Request-URI
Known Expect-CT Host's domain name, per the matching procedure (of the message to which the host responded) does not congruently
specified in Section 8.2 of [RFC6797], then the UA MUST add this host match an existing Known Expect-CT Host's domain name, per the
to the Known Expect-CT Host cache. The UA caches: matching procedure specified in Section 8.2 of [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. Expiration Date. The Effective Expiration Date is calculated from
when the UA observed the Expect-CT header field and is independent
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
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
If the UA receives, over a secure transport, an HTTP response that
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
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
report to the specified "report-uri" as specified in Section 3.
2.4. Evaluating Expect-CT Connections for CT Compliance 2.4. Evaluating Expect-CT Connections for CT Compliance
When a UA sets up a TLS connection, the UA determines whether the
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
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.
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 errors, the UA MUST terminate the if the TLS connection has no errors, then the UA will apply an
connection without allowing the user to proceed anyway. (This additional correctness check: compliance with a CT Policy. A UA
behavior is the same as that required by [RFC6797].) should evaluate compliance with its CT Policy whenever connecting to
a Known Expect-CT Host, as soon as possible. However, the check can
be skipped for local policy reasons (as discussed in Section 2.4.1),
or in the event that other checks cause the UA to terminate the
connection before CT compliance is evaluated. For example, a Public
Key Pinning failure [RFC7469] could cause the UA to terminate the
connection before CT compliance is checked. Similarly, if the UA
terminates the connection due to an Expect-CT failure, this could
cause the UA to skip subsequent correctness checks. When the CT
compliance check is skipped or bypassed, Expect-CT reports
(Section 3) will not be sent.
If the connection has no errors, then the UA will apply an additional When CT compliance is evaluted for a Known Expect-CT Host, the UA
correctness check: compliance with a CT Policy. A UA should evaluate MUST evaluate compliance when setting up the TLS session, before
compliance with its CT Policy whenever connecting to a Known Expect- beginning an HTTP conversation over the TLS channel.
CT Host, as soon as possible. It is acceptable to skip this CT
compliance check for some hosts according to local policy. For
example, a UA may disable CT compliance checks for hosts whose
validated certificate chain terminates at a user-defined trust
anchor, rather than a trust anchor built-in to the UA (or underlying
platform).
An Expect-CT Host is "expired" if the effective expiration date If a connection to a Known Expect-CT Host violates the UA's CT policy
refers to a date in the past. The UA MUST ignore any expired Expect- (i.e., the connection is not CT-qualified), and if the Known Expect-
CT Hosts in its cache and not treat such hosts as Known Expect-CT CT Host's Expect-CT metadata indicates an "enforce" configuration,
hosts. the UA MUST treat the CT compliance failure as an error.
If a connection to a Known CT Host violates the UA's CT policy (i.e. If a connection to a Known Expect-CT Host violates the UA's CT
the connection is not CT-qualified), and if the Known Expect-CT policy, and if the Known Expect-CT Host's Expect-CT metadata includes
Host's Expect-CT metadata indicates an "enforce" configuration, the a "report-uri", the UA SHOULD send an Expect-CT report to that
UA MUST treat the CT compliance failure as a non-recoverable error. "report-uri" (Section 3).
If a connection to a Known CT Host violates the UA's CT policy, and 2.4.1. Skipping CT compliance checks
if the Known Expect-CT Host's Expect-CT metadata includes a "report-
uri", the UA SHOULD send an Expect-CT report to that "report-uri"
(Section 3).
A UA that has previously noted a host as a Known Expect-CT Host MUST It is acceptable for a UA to skip CT compliance checks for some hosts
evaluate CT compliance when setting up the TLS session, before according to local policy. For example, a UA may disable CT
beginning an HTTP conversation over the TLS channel. compliance checks for hosts whose validated certificate chain
terminates at a user-defined trust anchor, rather than a trust anchor
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
When the UA attempts to connect to a Known Expect-CT Host and the When the UA attempts to connect to a Known Expect-CT Host and the
connection is not CT-qualified, the UA SHOULD report Expect-CT connection is not CT-qualified, the UA SHOULD report Expect-CT
failures to the "report-uri", if any, in the Known Expect-CT Host's failures to the "report-uri", if any, in the Known Expect-CT Host's
Expect-CT metadata. Expect-CT metadata.
When the UA receives an Expect-CT response header field over a When the UA receives an Expect-CT response header field over a
connection that is not CT-qualified, if the UA has not already sent connection that is not CT-qualified, if the UA has not already sent
an Expect-CT report for this connection, then the UA SHOULD report an Expect-CT report for this connection, then the UA SHOULD report
Expect-CT failures to the configured "report-uri", if any. Expect-CT failures to the configured "report-uri", if any.
3.1. Generating a violation report 3.1. Generating a violation report
To generate a violation report object, the UA constructs a JSON To generate a violation report object, the UA constructs a JSON
object with the following keys and values: [RFC8259] object with the following keys and values:
o "date-time": the value for this key indicates the time the UA o "date-time": the value for this key indicates the UTC time that
observed the CT compliance failure. The value is a string the UA observed the CT compliance failure. The value is a string
formatted according to Section 5.6, "Internet Date/Time Format", formatted according to Section 5.6, "Internet Date/Time Format",
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 "effective-expiration-date": the value indicates the Effective o "effective-expiration-date": the value indicates the Effective
Expiration Date (see Section 2.3.3) 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. The value is provided as a string failed the CT compliance check, in UTC. The value is provided as
formatted according to Section 5.6 of [RFC3339] ("Internet Date/ a string formatted according to Section 5.6 of [RFC3339]
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.
skipping to change at page 12, line 44 skipping to change at page 13, line 5
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.6 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, e.g., a bad signature). of, e.g., a bad signature).
* 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 or [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".
* 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.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 reporting server
behaves correctly. The value is provided as a boolean, and MUST behaves correctly. The value is provided as a boolean, and MUST
skipping to change at page 14, line 35 skipping to change at page 14, line 44
4. Security Considerations 4. Security Considerations
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). 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 could themselves only cure this situation by one of:
reconfiguring their web server to transmit SCTs using the TLS reconfiguring their web server to transmit SCTs using the TLS
extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis], extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis],
skipping to change at page 16, line 14 skipping to change at page 16, line 22
tools and design used by the organization that the organization would tools and design used by the organization that the organization would
otherwise prefer not be disclosed. otherwise prefer not be disclosed.
Because Expect-CT causes remotely-detectable behavior, it's advisable Because Expect-CT causes remotely-detectable behavior, it's advisable
that UAs offer a way for privacy-sensitive users to clear currently 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 noted Expect-CT hosts, and allow users to query the current state of
Known Expect-CT Hosts. Known Expect-CT Hosts.
6. IANA Considerations 6. IANA Considerations
This document registers the "Expect-CT" header field in the "Message 6.1. Header Field Registry
Headers" registry located at https://www.iana.org/assignments/
message-headers [4]. This document registers the "Expect-CT" header field in the
"Permanent Message Header Field Names" registry located at
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: standard
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
The MIME media type for Expect-CT violation reports is "application/
expect-ct-report+json" (which uses the suffix established in
[RFC6839]).
Type name: application
Subtype name: expect-ct-report+json
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary
Security considerations: See Section 4
Interoperability considerations: n/a
Published specification: This document
Applications that use this media type: UAs that implement
Certificate Transparency compliance checks and reporting
Additional information:
Deprecated alias names for this type: n/a
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Person & email address to contact for further information: Emily
Stark (estark@google.com)
Intended usage: COMMON
Restrictions on usage: none
Author: Emily Stark (estark@google.com)
Change controller: IETF
7. Usability Considerations 7. Usability Considerations
When the UA detects a Known Expect-CT Host in violation of the UA's 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 CT Policy, users will experience denials of service. It is advisable
for UAs to explain the reason why. for UAs to explain the reason why.
8. Authoring Considerations 8. Authoring Considerations
8.1. HTTP Header
Expect-CT could be specified as a TLS extension or X.509 certificate Expect-CT could be specified as a TLS extension or X.509 certificate
extension instead of an HTTP response header field. Using an HTTP extension instead of an HTTP response header field. Using an HTTP
header field as the mechanism for Expect-CT introduces a layering header field as the mechanism for Expect-CT introduces a layering
mismatch: for example, the software that terminates TLS and validates mismatch: for example, the software that terminates TLS and validates
Certificate Transparency information might know nothing about HTTP. Certificate Transparency information might know nothing about HTTP.
Nevertheless, an HTTP header field was chosen primarily for ease of Nevertheless, an HTTP header field was chosen primarily for ease of
deployment. In practice, deploying new certificate extensions deployment. In practice, deploying new certificate extensions
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
skipping to change at page 17, line 44 skipping to change at page 18, line 48
[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>.
[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
Structured Syntax Suffixes", RFC 6839,
DOI 10.17487/RFC6839, January 2013,
<https://www.rfc-editor.org/info/rfc6839>.
[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,
<https://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,
<https://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,
<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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<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 [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,
<https://www.rfc-editor.org/info/rfc5246>. <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 -04 A.1. Since -07
o None yet
A.2. Since -06
o Editorial changes o Editorial changes
A.2. Since -03 A.3. Since -05
o Remove SHOULD requirement that UAs disallow certificate error
overrides for Known Expect-CT Hosts.
o Remove restriction that Expect-CT Hosts cannot be IP addresses.
o Editorial changes o Editorial changes
A.3. Since -02 A.4. Since -04
o Editorial changes
A.5. Since -03
o Editorial changes
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.4. 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.5. 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
Google Google
Email: estark@google.com Email: estark@google.com
 End of changes. 48 change blocks. 
118 lines changed or deleted 207 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/