idnits 2.17.1
draft-stark-expect-ct-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 135 has weird spacing: '... Policy is a ...'
== Line 141 has weird spacing: '...alified descr...'
== Line 154 has weird spacing: '...CT Host is a ...'
== Line 159 has weird spacing: '...CT Host is an...'
== Line 166 has weird spacing: '...CT Host is an...'
-- The document date (December 01, 2016) is 2697 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 675
-- Looks like a reference, but probably isn't: '2' on line 677
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162)
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111)
Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Stark
3 Internet-Draft Google
4 Intended status: Experimental December 01, 2016
5 Expires: June 4, 2017
7 Expect-CT Extension for HTTP
8 draft-stark-expect-ct-01
10 Abstract
12 This document defines a new HTTP header, named Expect-CT, that allows
13 web host operators to instruct user agents to expect valid Signed
14 Certificate Timestamps (SCTs) to be served on connections to these
15 hosts. When configured in enforcement mode, user agents (UAs) will
16 remember that hosts expect SCTs and will refuse connections that do
17 not conform to the UA's Certificate Transparency policy. When
18 configured in report-only mode, UAs will report the lack of valid
19 SCTs to a URI configured by the host, but will allow the connection.
20 By turning on Expect-CT, web host operators can discover
21 misconfigurations in their Certificate Transparency deployments and
22 ensure that misissued certificates accepted by UAs are discoverable
23 in Certificate Transparency logs.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on June 4, 2017.
42 Copyright Notice
44 Copyright (c) 2016 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 4
63 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 4
64 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 5
65 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6
66 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 6
67 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7
68 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7
69 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 7
70 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 7
71 2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 7
72 2.3.2. Noting an Expect-CT Host - Storage Model . . . . . . 8
73 2.3.3. HTTP-Equiv Element Attribute . . . . . . . . . 9
74 2.4. Noting Expect-CT . . . . . . . . . . . . . . . . . . . . 9
75 2.5. Evaluating Expect-CT Connections for CT Compliance . . . 10
76 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11
77 3.1. Generating a violation report . . . . . . . . . . . . . . 11
78 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
80 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 13
81 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
83 7. Usability Considerations . . . . . . . . . . . . . . . . . . 13
84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
85 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
86 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
89 1. Introduction
91 This document defines a new HTTP header that enables UAs to identify
92 web hosts that expect the presence of Signed Certificate Timestamps
93 (SCTs) [RFC6962] in future Transport Layer Security (TLS) [RFC5246]
94 connections.
96 Web hosts that serve the Expect-CT HTTP header are noted by the UA as
97 Known Expect-CT Hosts. The UA evaluates each connection to a Known
98 Expect-CT Host for compliance with the UA's Certificate Transparency
99 (CT) Policy. If the connection violates the CT Policy, the UA sends
100 a report to a URI configured by the Expect-CT Host and/or fails the
101 connection, depending on the configuration that the Expect-CT Host
102 has chosen.
104 If misconfigured, Expect-CT can cause unwanted connection failures
105 (for example, if a host deploys Expect-CT but then switches to a
106 legitimate certificate that is not logged in Certificate Transparency
107 logs, or if a web host operator believes their certificate to conform
108 to all UAs' CT policies but is mistaken). Web host operators are
109 advised to deploy Expect-CT with caution, by using the reporting
110 feature and gradually increasing the interval where the UA remembers
111 the host as a Known Expect-CT Host. These precautions can help web
112 host operators gain confidence that their Expect-CT deployment is not
113 causing unwanted connection failures.
115 Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a
116 UA connects to a host, it lacks the information necessary to require
117 SCTs for the connection. Thus, the UA will not be able to detect and
118 thwart an attack on the UA's first connection to the host. Still,
119 Expect-CT provides value by 1) allowing UAs to detect the use of
120 unlogged certificates after the initial communication, and 2)
121 allowing web hosts to be confident that UAs are only trusting
122 publicly-auditable certificates.
124 1.1. Requirements Language
126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
128 "OPTIONAL" in this document are to be interpreted as described in RFC
129 2119 [RFC2119].
131 1.2. Terminology
133 Terminology is defined in this section.
135 Certificate Transparency Policy is a policy defined by the UA
136 concerning the number, sources, and delivery mechanisms of Signed
137 Certificate Timestamps that are served on TLS connections. The
138 policy defines the properties of a connection that must be met in
139 order for the UA to consider it CT-qualified.
141 Certificate Transparency Qualified describes a TLS connection for
142 which the UA has determined that a sufficient quantity and quality
143 of Signed Certificate Timestamps have been provided.
145 CT-qualified See Certificate Transparency Qualified.
147 CT Policy See Certificate Transparency Policy.
149 Expect-CT Host See HTTP Expect-CT Host.
151 HTTP Expect-CT is the overall name for the combined UA- and server-
152 side security policy defined by this specification.
154 HTTP Expect-CT Host is a conformant host implementing the HTTP
155 server aspects of HTTP Expect-CT. This means that an Expect-CT
156 Host returns the "Expect-CT" HTTP response header field in its
157 HTTP response messages sent over secure transport.
159 Known Expect-CT Host is an Expect-CT Host that the UA has noted as
160 such. See Section 2.4 for particulars.
162 UA is an acronym for "user agent". For the purposes of this
163 specification, a UA is an HTTP client application typically
164 actively manipulated by a user [RFC2616].
166 Unknown Expect-CT Host is an Expect-CT Host that the UA has not
167 noted.
169 2. Server and Client Behavior
171 2.1. Response Header Field Syntax
173 The "Expect-CT" header field is a new response header defined in this
174 specification. It is used by a server to indicate that UAs should
175 evaluate connections to the host emitting the header for CT
176 compliance (Section 2.5).
178 Figure 1 describes the syntax (Augmented Backus-Naur Form) of the
179 header field, using the grammar defined in RFC 5234 [RFC5234] and the
180 rules defined in Section 3.2 of RFC 7230 [RFC7230].
182 Expect-CT-Directives = directive *( OWS ";" OWS directive )
183 directive = directive-name [ "=" directive-value ]
184 directive-name = token
185 directive-value = token / quoted-string
187 Figure 1: Syntax of the Expect-CT header field
189 Optional white space ("OWS") is used as defined in Section 3.2.3 of
190 RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined
191 in Section 3.2.6 of RFC 7230 [RFC7230].
193 The directives defined in this specification are described below.
194 The overall requirements for directives are:
196 1. The order of appearance of directives is not significant.
198 2. A given directive MUST NOT appear more than once in a given
199 header field. Directives are either optional or required, as
200 stipulated in their definitions.
202 3. Directive names are case insensitive.
204 4. UAs MUST ignore any header fields containing directives, or other
205 header field value data, that do not conform to the syntax
206 defined in this specification. In particular, UAs must not
207 attempt to fix malformed header fields.
209 5. If a header field contains any directive(s) the UA does not
210 recognize, the UA MUST ignore those directives.
212 6. If the Expect-CT header field otherwise satisfies the above
213 requirements (1 through 5), the UA MUST process the directives it
214 recognizes.
216 2.1.1. The report-uri Directive
218 The OPTIONAL "report-uri" directive indicates the URI to which the UA
219 SHOULD report Expect-CT failures (Section 2.5). The UA POSTs the
220 reports to the given URI as described in Section 3.
222 The "report-uri" directive is REQUIRED to have a directive value, for
223 which the syntax is defined in Figure 2.
225 report-uri-value = absolute-URI
227 Figure 2: Syntax of the report-uri directive value
229 "absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986].
231 Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme in
232 the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check
233 Expect-CT compliance when the host in the "report-uri" is a Known
234 Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the
235 "report-uri" is a Known HSTS Host.
237 Note that the report-uri need not necessarily be in the same Internet
238 domain or web origin as the host being reported about.
240 UAs SHOULD make their best effort to report Expect-CT failures to the
241 "report-uri", but they may fail to report in exceptional conditions.
242 For example, if connecting the "report-uri" itself incurs an Expect-
243 CT failure or other certificate validation failure, the UA MUST
244 cancel the connection. Similarly, if Expect-CT Host A sets a
245 "report-uri" referring to Expect-CT Host B, and if B sets a "report-
246 uri" referring to A, and if both hosts fail to comply to the UA's CT
247 Policy, the UA SHOULD detect and break the loop by failing to send
248 reports to and about those hosts.
250 UAs SHOULD limit the rate at which they send reports. For example,
251 it is unnecessary to send the same report to the same "report-uri"
252 more than once.
254 2.1.2. The enforce Directive
256 The OPTIONAL "enforce" directive is a valueless directive that, if
257 present (i.e., it is "asserted"), signals to the UA that compliance
258 to the CT Policy should be enforced (rather than report-only) and
259 that the UA should refuse future connections that violate its CT
260 Policy. When both the "enforce" directive and "report-uri" directive
261 (as defined in Figure 2) are present, the configuration is referred
262 to as an "enforce-and-report" configuration, signalling to the UA
263 both that compliance to the CT Policy should be enforced and that
264 violations should be reported.
266 2.1.3. The max-age Directive
268 The "max-age" directive specifies the number of seconds after the
269 reception of the Expect-CT header field during which the UA SHOULD
270 regard the host from whom the message was received as a Known Expect-
271 CT Host.
273 The "max-age" directive is REQUIRED to be present within an "Expect-
274 CT" header field. The "max-age" directive is REQUIRED to have a
275 directive value, for which the syntax (after quoted-string
276 unescaping, if necessary) is defined in Figure 3.
278 max-age-value = delta-seconds
279 delta-seconds = 1*DIGIT
281 Figure 3: Syntax of the max-age directive value
283 "delta-seconds" is used as defined in Section 1.2.1 of RFC 7234
284 [RFC7234].
286 2.2. Server Processing Model
288 This section describes the processing model that Expect-CT Hosts
289 implement. The model has 2 parts: (1) the processing rules for HTTP
290 request messages received over a secure transport (e.g.,
291 authenticated, non-anonymous TLS); and (2) the processing rules for
292 HTTP request messages received over non-secure transports, such as
293 TCP.
295 2.2.1. HTTP-over-Secure-Transport Request Type
297 When replying to an HTTP request that was conveyed over a secure
298 transport, an Expect-CT Host SHOULD include in its response exactly
299 one Expect-CT header field. The header field MUST satisfy the
300 grammar specified in Section 2.1.
302 Establishing a given host as an Expect-CT Host, in the context of a
303 given UA, is accomplished as follows:
305 1. Over the HTTP protocol running over secure transport, by
306 correctly returning (per this specification) at least one valid
307 Expect-CT header field to the UA.
309 2. Through other mechanisms, such as a client-side preloaded Expect-
310 CT Host list.
312 2.2.2. HTTP Request Type
314 Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP
315 responses conveyed over non-secure transport. UAs MUST ignore any
316 Expect-CT header received in an HTTP response conveyed over non-
317 secure transport.
319 2.3. User Agent Processing Model
321 The UA processing model relies on parsing domain names. Note that
322 internationalized domain names SHALL be canonicalized according to
323 the scheme in Section 10 of [RFC6797].
325 2.3.1. Expect-CT Header Field Processing
327 If the UA receives, over a secure transport, an HTTP response that
328 includes an Expect-CT header field conforming to the grammar
329 specified in Section 2.1, the UA MUST evaluate the connection on
330 which the header was received for compliance with the UA's CT Policy,
331 and then process the Expect-CT header field as follows.
333 If the connection complies with the UA's CT Policy (i.e. the
334 connection is CT-qualified), then the UA MUST either:
336 o Note the host as a Known Expect-CT Host if it is not already so
337 noted (see Section 2.4), or
339 o Update the UA's cached information for the Known Expect-CT Host if
340 the "enforce", "max-age", or "report-uri" header field value
341 directives convey information different from that already
342 maintained by the UA. If the "max-age" directive has a value of
343 0, the UA MUST remove its cached Expect-CT information if the host
344 was previously noted as a Known Expect-CT Host, and MUST NOT note
345 this host as a Known Expect-CT Host if it is not already noted.
347 If the connection does not comply with the UA's CT Policy (i.e. is
348 not CT-qualified), then the UA MUST NOT note this host as a Known
349 Expect-CT Host.
351 If the header field includes a "report-uri" directive, and the
352 connection does not comply with the UA's CT Policy (i.e. the
353 connection is not CT-qualified), and the UA has not already sent an
354 Expect-CT report for this connection, then the UA SHOULD send a
355 report to the specified "report-uri" as specified in Section 3.
357 If a UA receives more than one Expect-CT header field in an HTTP
358 response message over secure transport, then the UA MUST process only
359 the first Expect-CT header field.
361 The UA MUST ignore any Expect-CT header field not conforming to the
362 grammar specified in Section 2.1.
364 2.3.2. Noting an Expect-CT Host - Storage Model
366 The "effective Expect-CT date" of a Known Expect-CT Host is the time
367 that the UA observed a valid Expect-CT header for the host. The
368 "effective expiration date" of a Known Expect-CT Host is the
369 effective Expect-CT date plus the max-age. An Expect-CT Host is
370 "expired" if the effective expiration date refers to a date in the
371 past. The UA MUST ignore any expired Expect-CT Hosts in its cache.
373 Known Expect-CT Hosts are identified only by domain names, and never
374 IP addresses. If the substring matching the host production from the
375 Request-URI (of the message to which the host responded)
376 syntactically matches the IP-literal or IPv4address productions from
377 Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a
378 Known Expect-CT Host.
380 Otherwise, if the substring does not congruently match an existing
381 Known Expect-CT Host's domain name, per the matching procedure
382 specified in Section 8.2 of [RFC6797], then the UA MUST add this host
383 to the Known Expect-CT Host cache. The UA caches:
385 o the Expect-CT Host's domain name,
387 o whether the "enforce" directive is present
389 o the effective expiration date, or enough information to calculate
390 it (the effective Expect-CT date and the value of the "max-age"
391 directive),
393 o the value of the "report-uri" directive, if present.
395 If any other metadata from optional or future Expect-CT header
396 directives are present in the Expect-CT header, and the UA
397 understands them, the UA MAY note them as well.
399 UAs MAY set an upper limit on the value of max-age, so that UAs that
400 have noted erroneous Expect-CT hosts (whether by accident or due to
401 attack) have some chance of recovering over time. If the server sets
402 a max-age greater than the UA's upper limit, the UA MAY behave as if
403 the server set the max-age to the UA's upper limit. For example, if
404 the UA caps max-age at 5,184,000 seconds (60 days), and a Pinned Host
405 sets a max- age directive of 90 days in its Expect-CT header, the UA
406 MAY behave as if the max-age were effectively 60 days. (One way to
407 achieve this behavior is for the UA to simply store a value of 60
408 days instead of the 90-day value provided by the Expect-CT host.)
410 2.3.3. HTTP-Equiv Element Attribute
412 UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
413 "" elements [W3C.REC-html401-19991224] in received content.
415 2.4. Noting Expect-CT
417 Upon receipt of the Expect-CT response header field, the UA notes the
418 host as a Known Expect-CT Host, storing the host's domain name and
419 its associated Expect-CT directives in non-volatile storage. The
420 domain name and associated Expect-CT directives are collectively
421 known as "Expect-CT metadata".
423 The UA MUST note a host as a Known Expect-CT Host if and only if it
424 received the Expect-CT response header field over an error-free TLS
425 connection, including the validation added in Section 2.5.
427 To note a host as a Known Expect-CT Host, the UA MUST set its Expect-
428 CT metadata given in the most recently received valid Expect-CT
429 header.
431 For forward compatibility, the UA MUST ignore any unrecognized
432 Expect-CT header directives, while still processing those directives
433 it does recognize. Section 2.1 specifies the directives "enforce",
434 "max-age", and "report-uri", but future specifications and
435 implementations might use additional directives.
437 2.5. Evaluating Expect-CT Connections for CT Compliance
439 When a UA connects to a Known Expect-CT Host using a TLS connection,
440 if the TLS connection has errors, the UA MUST terminate the
441 connection without allowing the user to proceed anyway. (This
442 behavior is the same as that required by [RFC6797].)
444 If the connection has no errors, then the UA will apply an additional
445 correctness check: compliance with a CT Policy. A UA should evaluate
446 compliance with its CT Policy whenever connecting to a Known Expect-
447 CT Host, as soon as possible. It is acceptable to skip this CT
448 compliance check for some hosts according to local policy. For
449 example, a UA may disable CT compliance checks for hosts whose
450 validated certificate chain terminates at a user-defined trust
451 anchor, rather than a trust anchor built-in to the UA (or underlying
452 platform).
454 If a connection to a Known CT Host violates the UA's CT policy (i.e.
455 the connection is not CT-qualified), and if the Known Expect-CT
456 Host's Expect-CT metadata indicates an "enforce" configuration, the
457 UA MUST treat the CT compliance failure as a non-recoverable error.
459 If a connection to a Known CT Host violates the UA's CT policy, and
460 if the Known Expect-CT Host's Expect-CT metadata includes a "report-
461 uri", the UA SHOULD send an Expect-CT report to that "report-uri"
462 (Section 3).
464 A UA that has previously noted a host as a Known Expect-CT Host MUST
465 evaluate CT compliance when setting up the TLS session, before
466 beginning an HTTP conversation over the TLS channel.
468 If the UA does not evaluate CT compliance, e.g. because the user has
469 elected to disable it, or because a presented certificate chain
470 chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect-
471 CT reports.
473 3. Reporting Expect-CT Failure
475 When the UA attempts to connect to a Known Expect-CT Host and the
476 connection is not CT-qualified, the UA SHOULD report Expect-CT
477 failures to the "report-uri", if any, in the Known Expect-CT Host's
478 Expect-CT metadata.
480 When the UA receives an Expect-CT response header field over a
481 connection that is not CT-qualified, if the UA has not already sent
482 an Expect-CT report for this connection, then the UA SHOULD report
483 Expect-CT failures to the configured "report-uri", if any.
485 3.1. Generating a violation report
487 To generate a violation report object, the UA constructs a JSON
488 message of the following form:
490 {
491 "date-time": date-time,
492 "hostname": hostname,
493 "port": port,
494 "effective-expiration-date": expiration-date,
495 "served-certificate-chain": [ (MUST be in the order served)
496 pem1, ... pemN
497 ],
498 "validated-certificate-chain": [
499 pem1, ... pemN
500 ],
501 "scts": [
502 sct1, ... sctN
503 ]
504 }
506 Figure 4: JSON format of a violation report object
508 Whitespace outside of quoted strings is not significant. The key/
509 value pairs may appear in any order, but each MUST appear only once.
511 The "date-time" indicates the time the UA observed the CT compliance
512 failure. It is provided as a string formatted according to
513 Section 5.6, "Internet Date/Time Format", of RFC 3339 [RFC3339].
515 The "hostname" is the hostname to which the UA made the original
516 request that failed the CT compliance check. It is provided as a
517 string.
519 The "port" is the port to which the UA made the original request that
520 failed the CT compliance check. It is provided as an integer.
522 The "effective-expiration-date" is the Effective Expiration Date for
523 the Expect-CT Host that failed the CT compliance check. It is
524 provided as a string formatted according to Section 5.6, "Internet
525 Date/Time Format", of RFC 3339 [RFC3339].
527 The "served-certificate-chain" is the certificate chain, as served by
528 the Expect-CT Host during TLS session setup. It is provided as an
529 array of strings, which MUST appear in the order that the
530 certificates were served; each string "pem1", ... "pemN" is the
531 Privacy-Enhanced Mail (PEM) representation of each X.509 certificate
532 as described in RFC 7468 [RFC7468].
534 The "validated-certificate-chain" is the certificate chain, as
535 constructed by the UA during certificate chain verification. (This
536 may differ from the "served-certificate-chain".) It is provided as
537 an array of strings, which MUST appear in the order matching the
538 chain that the UA validated; each string "pem1", ... "pemN" is the
539 Privacy-Enhanced Mail (PEM) representation of each X.509 certificate
540 as described in RFC 7468 [RFC7468].
542 The "scts" are JSON messages representing the SCTs (if any) that the
543 UA received for the Expect-CT host and their validation statuses.
544 The format of "sct1", ... "sctN" is shown in Figure 5. The SCTs may
545 appear in any order.
547 {
548 "sct": sct,
549 "status": status,
550 "source": source
551 }
553 Figure 5: JSON format of an SCT object
555 The "sct" is as defined in Section 4.1 of RFC 6962 [RFC6962].
557 The "status" is a string that the UA MUST set to one of the following
558 values: "unknown" (indicating that the UA does not have or does not
559 trust the public key of the log from which the SCT was issued),
560 "valid" (indicating that the UA successfully validated the SCT as
561 described in Section 5.2 of [RFC6962]), or "invalid" (indicating that
562 the SCT validation failed because of, e.g., a bad signature).
564 The "source" is a string that indicates from where the UA obtained
565 the SCT, as defined in Section 3.3 of RFC 6962 [RFC6962]. The UA
566 MUST set "source" to one of the following values: "tls-extension",
567 "ocsp", or "embedded".
569 3.2. Sending a violation report
571 When an Expect-CT header field contains the "report-uri" directive,
572 and the connection does not comply with the UA's CT Policy, or when
573 the UA connects to a Known Expect-CT Host with Expect-CT metadata
574 that contains a "report-uri", the UA SHOULD report the failure as
575 follows:
577 1. Prepare a JSON object "report object" with the single key
578 "expect-ct-report", whose value is the result of generating a
579 violation report object as described in Figure 4.
581 2. Let "report body" by the JSON stringification of "report object".
583 3. Let "report-uri" be the value of the "report-uri" directive in
584 the Expect-CT header field.
586 4. Queue a task [1] to fetch [2] "report-uri", with the synchronous
587 flag not set, using HTTP method "POST", with a "Content-Type"
588 header field of "application/expect-ct-report", and an entity
589 body consisting of "report body".
591 4. Security Considerations
593 4.1. Maximum max-age
595 1 year?
597 5. Privacy Considerations
599 6. IANA Considerations
601 7. Usability Considerations
603 When the UA detects a Known Expect-CT Host in violation of the UA's
604 CT Policy, users will experience denials of service. It is advisable
605 for UAs to explain the reason why.
607 It is advisable that UAs have a way for users to clear Known Expect-
608 CT Hosts and that UAs allow users to query Known Expect-CT Hosts.
610 8. References
612 8.1. Normative References
614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
615 Requirement Levels", BCP 14, RFC 2119,
616 DOI 10.17487/RFC2119, March 1997,
617 .
619 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
620 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
621 Transfer Protocol -- HTTP/1.1", RFC 2616,
622 DOI 10.17487/RFC2616, June 1999,
623 .
625 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
626 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
627 .
629 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
630 Resource Identifier (URI): Generic Syntax", STD 66,
631 RFC 3986, DOI 10.17487/RFC3986, January 2005,
632 .
634 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
635 Specifications: ABNF", STD 68, RFC 5234,
636 DOI 10.17487/RFC5234, January 2008,
637 .
639 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
640 (TLS) Protocol Version 1.2", RFC 5246,
641 DOI 10.17487/RFC5246, August 2008,
642 .
644 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
645 Transport Security (HSTS)", RFC 6797,
646 DOI 10.17487/RFC6797, November 2012,
647 .
649 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
650 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
651 .
653 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
654 Protocol (HTTP/1.1): Message Syntax and Routing",
655 RFC 7230, DOI 10.17487/RFC7230, June 2014,
656 .
658 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
659 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
660 RFC 7234, DOI 10.17487/RFC7234, June 2014,
661 .
663 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
664 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
665 April 2015, .
667 [W3C.REC-html401-19991224]
668 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
669 Specification", World Wide Web Consortium Recommendation
670 REC-html401-19991224, December 1999,
671 .
673 8.2. URIs
675 [1] https://html.spec.whatwg.org/#queue-a-task
677 [2] https://fetch.spec.whatwg.org/#fetching
679 Author's Address
681 Emily Stark
682 Google
684 Email: estark@google.com