draft-ietf-httpbis-expect-ct-06.txt   draft-ietf-httpbis-expect-ct-07.txt 
HTTP E. Stark HTTP E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental June 29, 2018 Intended status: Experimental July 16, 2018
Expires: December 31, 2018 Expires: January 17, 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 2, line 4 skipping to change at page 1, line 45
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 December 31, 2018.
This Internet-Draft will expire on January 17, 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 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
A.7. 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 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 18, line 18 skipping to change at page 18, line 18
mechanism for user agents that are transitioning to universal mechanism for user agents that are transitioning to universal
Certificate Transparency requirements. Certificate Transparency requirements.
9. 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-27 (work in progress), October ietf-trans-rfc6962-bis-28 (work in progress), March 2018.
2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<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 20, line 11 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. 14 change blocks. 
28 lines changed or deleted 27 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/