draft-ietf-httpbis-expect-ct-04.txt   draft-ietf-httpbis-expect-ct-05.txt 
HTTP E. Stark HTTP E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental May 19, 2018 Intended status: Experimental May 30, 2018
Expires: November 20, 2018 Expires: December 1, 2018
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-04 draft-ietf-httpbis-expect-ct-05
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. When configured in enforcement mode, user agents (UAs)
will remember that hosts expect SCTs and will refuse connections that will remember that hosts expect SCTs and will refuse connections that
do not conform to the UA's Certificate Transparency policy. When do 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
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 November 20, 2018. This Internet-Draft will expire on December 1, 2018.
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 37 skipping to change at page 2, line 37
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. Expect-CT Header Field Processing . . . . . . . . . . 8
2.3.2. HTTP-Equiv <meta> Element Attribute . . . . . . . . . 9 2.3.2. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9
2.3.3. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9 2.3.3. Storage Model . . . . . . . . . . . . . . . . . . . . 9
2.3.4. Storage Model . . . . . . . . . . . . . . . . . . . . 9
2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10
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 . . . . . . . . . . . . . . 11
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 7. Usability Considerations . . . . . . . . . . . . . . . . . . 16
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 16 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 16
8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 18 A.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.4. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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 4, line 41 skipping to change at page 4, line 41
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.
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.3 for particulars. as such. See Section 2.3.2 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 7, line 28 skipping to change at page 7, line 28
max-age-value = delta-seconds max-age-value = delta-seconds
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Figure 3: Syntax of the max-age directive value Figure 3: Syntax of the max-age directive value
"delta-seconds" is used as defined in Section 1.2.1 of [RFC7234]. "delta-seconds" is used as defined in Section 1.2.1 of [RFC7234].
2.1.4. Examples 2.1.4. Examples
The following examples demonstrate valid Expect-CT response header The following three examples demonstrate valid Expect-CT response
fields: header fields (where the second splits the directives into two field
instances):
Expect-CT: max-age=86400, enforce Expect-CT: max-age=86400, enforce
Expect-CT: max-age=86400,enforce,report-uri="https://foo.example/report" Expect-CT: max-age=86400,enforce
Expect-CT: report-uri="https://foo.example/report"
Expect-CT: max-age=86400,report-uri="https://foo.example/report" Expect-CT: max-age=86400,report-uri="https://foo.example/report"
Figure 4: Examples of valid Expect-CT response header fields Figure 4: Examples of valid Expect-CT response header fields
2.2. Server Processing Model 2.2. Server Processing Model
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
skipping to change at page 8, line 47 skipping to change at page 8, line 47
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 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.3), or noted (see Section 2.3.2), 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 If the connection does not comply with the UA's CT Policy (i.e. is
skipping to change at page 9, line 21 skipping to change at page 9, line 21
If the header field includes a "report-uri" directive, and the 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 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 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 Expect-CT report for this connection, then the UA SHOULD send a
report to the specified "report-uri" as specified in Section 3. report to the specified "report-uri" as specified in Section 3.
The UA MUST ignore any Expect-CT header field not conforming to the The UA MUST ignore any Expect-CT header field not conforming to the
grammar specified in Section 2.1. grammar specified in Section 2.1.
2.3.2. HTTP-Equiv <meta> Element Attribute 2.3.2. Noting Expect-CT
UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
"<meta>" elements [HTML] [HTML5] in received content.
2.3.3. 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. The domain name and associated Expect-CT
directives are collectively known as "Expect-CT metadata". 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.4. header field, as specified in Section 2.3.3.
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.4. Storage Model 2.3.3. Storage Model
Known Expect-CT Hosts are identified only by domain names, and never Known Expect-CT Hosts are identified only by domain names, and never
IP addresses. If the substring matching the host production from the IP addresses. If the substring matching the host production from the
Request-URI (of the message to which the host responded) Request-URI (of the message to which the host responded)
syntactically matches the IP-literal or IPv4address productions from 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 Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a
Known Expect-CT Host. Known Expect-CT Host.
Otherwise, if the substring does not congruently match an existing Otherwise, if the substring does not congruently match an existing
Known Expect-CT Host's domain name, per the matching procedure Known Expect-CT Host's domain name, per the matching procedure
skipping to change at page 12, line 16 skipping to change at page 12, line 14
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.4) for the Expect-CT Host that Expiration Date (see Section 2.3.3) for the Expect-CT Host that
failed the CT compliance check. The value is provided as a string failed the CT compliance check. The value is provided as a string
formatted according to Section 5.6 of [RFC3339] ("Internet Date/ formatted according to Section 5.6 of [RFC3339] ("Internet Date/
Time Format"). 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].
skipping to change at page 14, line 38 skipping to change at page 14, line 35
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.3). After having note this as an Expect-CT Host (see Section 2.3.2). 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 16 skipping to change at page 16, line 14
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
TBD This document registers the "Expect-CT" header field in the "Message
Headers" registry located at https://www.iana.org/assignments/
message-headers [4].
Header field name: Expect-CT
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document(s): This document
Related information: (empty)
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 8.1. HTTP Header
skipping to change at page 18, line 10 skipping to change at page 18, line 24
[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>.
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>.
[HTML] WHATWG, "HTML - Living Standard", n.d.,
<https://html.spec.whatwg.org>.
[HTML5] Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and
S. Moon, "HTML 5.2", World Wide Web Consortium
Recommendation REC-html52-20171214, December 2017,
<https://www.w3.org/TR/2017/REC-html52-20171214>.
[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>.
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
Appendix A. Changes Appendix A. Changes
A.1. Since -03 A.1. Since -04
o Editorial changes o Editorial changes
A.2. Since -02 A.2. Since -03
o Editorial changes
A.3. 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.3. Since -01 A.4. 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.4. Since -00 A.5. 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. 24 change blocks. 
43 lines changed or deleted 53 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/