draft-ietf-httpbis-expect-ct-01.txt   draft-ietf-httpbis-expect-ct-02.txt 
HTTP Working Group E. Stark HTTP Working Group E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental May 24, 2017 Intended status: Experimental August 14, 2017
Expires: November 25, 2017 Expires: February 15, 2018
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-01 draft-ietf-httpbis-expect-ct-02
Abstract Abstract
This document defines a new HTTP header, named Expect-CT, that allows This document defines a new HTTP header, named Expect-CT, that allows
web host operators to instruct user agents to expect valid Signed web host operators to instruct user agents to expect valid Signed
Certificate Timestamps (SCTs) to be served on connections to these Certificate Timestamps (SCTs) to be served on connections to these
hosts. When configured in enforcement mode, user agents (UAs) will hosts. When configured in enforcement mode, user agents (UAs) will
remember that hosts expect SCTs and will refuse connections that do remember that hosts expect SCTs and will refuse connections that do
not conform to the UA's Certificate Transparency policy. When not conform to the UA's Certificate Transparency policy. When
configured in report-only mode, UAs will report the lack of valid 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. SCTs to a URI configured by the host, but will allow the connection.
By turning on Expect-CT, web host operators can discover 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/ . https://lists.w3.org/Archives/Public/ietf-http-wg/.
Working Group information can be found at http://httpwg.github.io/ ; Working Group information can be found at http://httpwg.github.io/;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/expect-ct . https://github.com/httpwg/http-extensions/labels/expect-ct.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 25, 2017. This Internet-Draft will expire on February 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 5 skipping to change at page 3, line 5
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14
4.2. Avoiding amplification attacks . . . . . . . . . . . . . 14 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 14
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Usability Considerations . . . . . . . . . . . . . . . . . . 15 7. Usability Considerations . . . . . . . . . . . . . . . . . . 15
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 15 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 15
8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 15
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document defines a new HTTP header that enables UAs to identify This document defines a new HTTP header that enables UAs to identify
web hosts that expect the presence of Signed Certificate Timestamps web hosts that expect the presence of Signed Certificate Timestamps
(SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer (SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer
Security (TLS) [RFC5246] connections. Security (TLS) [RFC5246] connections.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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].
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:
* The "sct" key, with a value as defined in Section 4.6 of * A "version" key, with an integer value. The UA MUST set this
[I-D.ietf-trans-rfc6962-bis]. 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
Section 4.6 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 8.2.3 of successfully validated the SCT as described in Section 5.2 of
[I-D.ietf-trans-rfc6962-bis]), or "invalid" (indicating that [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or
the SCT validation failed because of, e.g., a bad signature). "invalid" (indicating that the SCT validation failed because
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 6 of the UA obtained the SCT, as defined in Section 3 or [RFC6962]
[I-D.ietf-trans-rfc6962-bis]. The UA MUST set the value to one and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA MUST set
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 "version" key is "1", the UA MUST set this value to the
base64 encoded [RFC4648] serialized
"SignedCertificateTimestamp" structure from Section 3.2 of
[RFC6962]. If the value of the "version" key is "2", the UA
MUST set this value to the base64 encoded [RFC4648] serialized
"TransItem" structure representing the SCT, as defined in
Section 4.6 of [I-D.ietf-trans-rfc6962-bis].
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 an Expect-CT failure when a connection to a
Known Expect-CT Host does not comply with the UA's CT Policy and the Known Expect-CT Host does not comply with the UA's CT Policy and the
host's Expect-CT metadata contains a "report-uri". Additionally, the host's Expect-CT metadata contains a "report-uri". Additionally, the
UA SHOULD report an Expect-CT failure when it receives an Expect-CT UA SHOULD report an Expect-CT failure when it receives an Expect-CT
header field which contains the "report-uri" directive over a header field which contains the "report-uri" directive over a
connection that does not comply with the UA's CT Policy. connection that does not comply with the UA's CT Policy.
skipping to change at page 15, line 48 skipping to change at page 16, line 9
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
case of a third-party CDN). Ease of deployment is a high priority case of a third-party CDN). Ease of deployment is a high priority
for Expect-CT because it is intended as a temporary transition for Expect-CT because it is intended as a temporary transition
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. Changes 9. Changes
9.1. Since -00 9.1. Since -01
o Change SCT reporting format to support both RFC 6962 and 6962-bis
SCTs.
9.2. 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
10. Normative References 10. Normative References
[FETCH] van Kesteren, A., "Fetch", n.d., [FETCH] van Kesteren, A., "Fetch", n.d.,
skipping to change at page 16, line 23 skipping to change at page 16, line 37
[FETCH] van Kesteren, A., "Fetch", n.d., [FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
P., and D. Denicola, "HTML", n.d., P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>. <https://html.spec.whatwg.org/>.
[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-24 (work in progress), December ietf-trans-rfc6962-bis-26 (work in progress), July 2017.
2016.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://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,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[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,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[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,
<http://www.rfc-editor.org/info/rfc6797>. <http://www.rfc-editor.org/info/rfc6797>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://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,
<http://www.rfc-editor.org/info/rfc7230>. <http://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,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
 End of changes. 15 change blocks. 
20 lines changed or deleted 46 lines changed or added

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