draft-ietf-httpbis-expect-ct-07.txt   draft-ietf-httpbis-expect-ct-latest.txt 
HTTP Working Group E. Stark HTTP Working Group E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental July 16, 2018 Intended status: Experimental August 8, 2018
Expires: January 17, 2019 Expires: February 9, 2019
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-07 draft-ietf-httpbis-expect-ct-latest
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. 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 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.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 February 9, 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 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 5
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 . . . . . . . 7
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 . . . . 8
2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 8 2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 8
2.3.3. Reporting . . . . . . . . . . . . . . . . . . . . . . 10 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 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 . . . . . . . . . . . . . . 12 3.1. Generating a violation report . . . . . . . . . . . . . . 12
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 9 skipping to change at page 3, line 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Header Field Registry . . . . . . . . . . . . . . . . . . 16 6.1. Header Field Registry . . . . . . . . . . . . . . . . . . 16
6.2. Media Types Registry . . . . . . . . . . . . . . . . . . 16 6.2. Media Types Registry . . . . . . . . . . . . . . . . . . 16
7. Usability Considerations . . . . . . . . . . . . . . . . . . 17 7. Usability Considerations . . . . . . . . . . . . . . . . . . 17
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 17 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.3. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.5. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.5. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.6. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.6. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.7. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.7. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.8. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 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
skipping to change at page 5, line 25 skipping to change at page 5, line 25
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].
Expect-CT = #expect-ct-directive Expect-CT = #expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ] expect-ct-directive = directive-name [ "=" directive-value ]
directive-name = token directive-name = token
directive-value = token / quoted-string directive-value = token / quoted-string
Figure 1: Syntax of the Expect-CT header field Figure 1: Syntax of the Expect-CT header field
Optional white space ("OWS") is used as defined in Section 3.2.3 of
[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.
skipping to change at page 6, line 23 skipping to change at page 6, line 17
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 Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme in
the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check
Expect-CT compliance when the host in the "report-uri" is a Known Expect-CT compliance when the host in the "report-uri" is a Known
Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the Expect-CT Host; similarly, UAs MUST apply HSTS [RFC6797] if the host
"report-uri" is a Known HSTS Host. in the "report-uri" is a Known HSTS Host.
Note that the report-uri need not necessarily be in the same Internet Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the host being reported about. domain or web origin as the host being reported about.
UAs SHOULD make their best effort to report Expect-CT failures to the UAs SHOULD make their best effort to report Expect-CT failures to the
"report-uri", but they may fail to report in exceptional conditions. "report-uri", but they may fail to report in exceptional conditions.
For example, if connecting 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.
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
skipping to change at page 16, line 32 skipping to change at page 16, line 32
6.1. Header Field Registry 6.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 6.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/
skipping to change at page 20, line 7 skipping to change at page 20, line 7
[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 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
Google Google
Email: estark@google.com Email: estark@google.com
 End of changes. 18 change blocks. 
29 lines changed or deleted 29 lines changed or added

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