draft-ietf-httpbis-expect-ct-06.txt   draft-ietf-httpbis-expect-ct-07.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-06 draft-ietf-httpbis-expect-ct-07
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 3, line 4 skipping to change at page 2, line 51
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
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
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 -05 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.2. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.3. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.4. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.5. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.5. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 20
A.6. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.6. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 A.7. 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 16, line 24 skipping to change at page 16, line 24
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
6.1. Header Field Registry 6.1. Header Field Registry
This document registers the "Expect-CT" header field in the "Message This document registers the "Expect-CT" header field in the
Headers" registry located at https://www.iana.org/assignments/ "Permanent Message Header Field Names" registry located at
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: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): This document Specification document(s): This document
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 -05 A.1. Since -06
o Editorial changes
A.2. 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.2. Since -04 A.3. Since -04
o Editorial changes o Editorial changes
A.3. Since -03 A.4. Since -03
o Editorial changes o Editorial changes
A.4. Since -02 A.5. 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.5. Since -01 A.6. 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.6. Since -00 A.7. 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
 End of changes. 11 change blocks. 
24 lines changed or deleted 23 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/