idnits 2.17.1
draft-stark-expect-ct-00.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
-- The document date (October 30, 2016) is 2735 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '1' on line 616
-- Looks like a reference, but probably isn't: '2' on line 618
** 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: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 October 30, 2016
5 Expires: May 3, 2017
7 Expect-CT
8 draft-stark-expect-ct-00
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 May 3, 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 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 3
62 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 3
63 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 4
64 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 5
65 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 5
66 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 6
67 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 6
68 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 6
69 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 6
70 2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 7
71 2.3.2. Noting an Expect-CT Host - Storage Model . . . . . . 7
72 2.3.3. HTTP-Equiv Element Attribute . . . . . . . . . 8
73 2.4. Noting Expect-CT . . . . . . . . . . . . . . . . . . . . 9
74 2.5. Evaluating Expect-CT Connections for CT Compliance . . . 9
75 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 10
76 3.1. Generating a violation report . . . . . . . . . . . . . . 10
77 3.2. Sending a violation report . . . . . . . . . . . . . . . 12
78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
79 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 12
80 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
82 7. Usability Considerations . . . . . . . . . . . . . . . . . . 12
83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
84 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
85 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
88 1. Introduction
90 This document defines a new HTTP header that enables UAs to identify
91 web hosts that expect the presence of Signed Certificate Timestamps
92 (SCTs) [RFC6962] in future Transport Layer Security (TLS) [RFC5246]
93 connections.
95 Web hosts that serve the Expect-CT HTTP header are noted by the UA as
96 Expect-CT hosts. The UA evaluates each connection to an Expect-CT
97 host for compliance with the UA's Certificate Transparency (CT)
98 policy. If the connection violates the CT policy, the UA sends a
99 report to a URI configured by the Expect-CT host and/or fails the
100 connection, depending on the configuration that the Expect-CT host
101 has chosen.
103 If misconfigured, Expect-CT can cause unwanted connection failures
104 (for example, if a host deploys Expect-CT but then switches to a
105 legitimate certificate that is not logged in Certificate Transparency
106 logs, or if a web host operator believes their certificate to conform
107 to all UAs' CT policies but is mistaken). Web host operators are
108 advised to deploy Expect-CT with caution, by using the reporting
109 feature and gradually increasing the interval for the UA remembers
110 the host as an Expect-CT host. These precautions can help web host
111 operators gain confidence that their Expect-CT deployment is not
112 causing unwanted connection failures.
114 Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a
115 UA connects to a host, it lacks the information necessary to require
116 SCTs for the connection. Thus, the UA will not be able to detect and
117 thwart an attack on the UA's first connection to the host. Still,
118 Expect-CT provides value by allowing UAs to detect the use of
119 unlogged certificates after the initial communication.
121 1.1. Requirements Language
123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
125 "OPTIONAL" in this document are to be interpreted as described in RFC
126 2119 [RFC2119].
128 2. Server and Client Behavior
130 2.1. Response Header Field Syntax
132 The "Expect-CT" header field is a new response header defined in this
133 specification. It is used by a server to indicate that UAs should
134 evaluate connections to the host emitting the header for CT
135 compliance (Section 2.5).
137 Figure 1 describes the syntax (Augmented Backus-Naur Form) of the
138 header field, using the grammar defined in RFC 5234 [RFC5234] and the
139 rules defined in Section 3.2 of RFC 7230 [RFC7230].
141 Expect-CT-Directives = directive *( OWS ";" OWS directive )
142 directive = directive-name [ "=" directive-value ]
143 directive-name = token
144 directive-value = token / quoted-string
146 Figure 1: Syntax of the Expect-CT header field
148 Optional white space ("OWS") is used as defined in Section 3.2.3 of
149 RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined
150 in Section 3.2.6 of RFC 7230 [RFC7230].
152 The directives defined in this specification are described below.
153 The overall requirements for directives are:
155 1. The order of appearance of directives is not significant.
157 2. A given directive MUST NOT appear more than once in a given
158 header field. Directives are either optional or required, as
159 stipulated in their definitions.
161 3. Directive names are case insensitive.
163 4. UAs MUST ignore any header fields containing directives, or other
164 header field value data, that do not conform to the syntax
165 defined in this specification. In particular, UAs must not
166 attempt to fix malformed header fields.
168 5. If a header field contains any directive(s) the UA does not
169 recognize, the UA MUST ignore those directives.
171 6. If the Expect-CT header field otherwise satisfies the above
172 requirements (1 through 5), the UA MUST process the directives it
173 recognizes.
175 2.1.1. The report-uri Directive
177 The OPTIONAL "report-uri" directive indicates the URI to which the UA
178 SHOULD report Expect-CT failures (Section 2.5). The UA POSTs the
179 reports to the given URI as described in Section 3.
181 The "report-uri" directive is REQUIRED to have a directive value, for
182 which the syntax is defined in Figure 2.
184 report-uri-value = absolute-URI
186 Figure 2: Syntax of the report-uri directive value
188 "absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986].
190 Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme in
191 the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check
192 Expect-CT compliance when the host in the "report-uri" is an Expect-
193 CT host; similarly, UAs MUST apply HSTS if the host in the "report-
194 uri" is a Known HSTS Host.
196 Note that the report-uri need not necessarily be in the same Internet
197 domain or web origin as the host being reported about.
199 UAs SHOULD make their best effort to report Expect-CT failures to the
200 "report-uri", but they may fail to report in exceptional conditions.
201 For example, if connecting the "report-uri" itself incurs an Expect-
202 CT failure or other certificate validation failure, the UA MUST
203 cancel the connection. Similarly, if Expect-CT Host A sets a
204 "report-uri" referring to Expect-CT Host B, and if B sets a "report-
205 uri" referring to A, and if both hosts fail to comply to the UA's CT
206 policy, the UA SHOULD detect and break the loop by failing to send
207 reports to and about those hosts.
209 UAs SHOULD limit the rate at which they send reports. For example,
210 it is unnecessary to send the same report to the same "report-uri"
211 more than once.
213 2.1.2. The enforce Directive
215 The OPTIONAL "enforce" directive is a valueless directive that, if
216 present (i.e., it is "asserted"), signals to the UA that compliance
217 to the CT policy should be enforced (rather than report-only) and
218 that the UA should refuse future connections that violate its CT
219 policy.
221 2.1.3. The max-age Directive
223 The "max-age" directive specifies the number of seconds after the
224 reception of the Expect-CT header field during which the UA SHOULD
225 regard the host from whom the message was received as an Expect-CT
226 host.
228 The "max-age" directive is REQUIRED to be present within an "Expect-
229 CT" header field if and only if the "enforce" directive is present.
230 The "max-age" directive is meaningless if no "enforce" directive is
231 present (i.e., if the Expect-CT policy is report-only). UAs MUST
232 ignore the "max-age" directive if the "enforce" directive is not
233 present and not cache the header.
235 The "max-age" directive is REQUIRED to have a directive value, for
236 which the syntax (after quoted-string unescaping, if necessary) is
237 defined in Figure 3.
239 max-age-value = delta-seconds
240 delta-seconds = 1*DIGIT
242 Figure 3: Syntax of the max-age directive value
244 "delta-seconds" is used as defined in Section 1.2.1 of RFC 7234
245 [RFC7234].
247 2.2. Server Processing Model
249 This section describes the processing model that Expect-CT hosts
250 implement. The model has 2 parts: (1) the processing rules for HTTP
251 request messages received over a secure transport (e.g.,
252 authenticated, non-anonymous TLS); and (2) the processing rules for
253 HTTP request messages received over non-secure transports, such as
254 TCP.
256 2.2.1. HTTP-over-Secure-Transport Request Type
258 When replying to an HTTP request that was conveyed over a secure
259 transport, an Expect-CT host SHOULD include in its response exactly
260 one Expect-CT header field. The header field MUST satisfy the
261 grammar specified in Section 2.1.
263 Establishing a given host as an Expect-CT host, in the context of a
264 given UA, is accomplished as follows:
266 1. Over the HTTP protocol running over secure transport, by
267 correctly returning (per this specification) at least one valid
268 Expect-CT header field to the UA.
270 2. Through other mechanisms, such as a client-side preloaded Expect-
271 CT host list.
273 2.2.2. HTTP Request Type
275 Expect-CT hosts SHOULD NOT include the Expect-CT header field in HTTP
276 responses conveyed over non-secure transport. UAs MUST ignore any
277 Expect-CT header received in an HTTP response conveyed over non-
278 secure transport.
280 2.3. User Agent Processing Model
282 The UA processing model relies on parsing domain names. Note that
283 internationalized domain names SHALL be canonicalized according to
284 the scheme in Section 10 of [RFC6797].
286 2.3.1. Expect-CT Header Field Processing
288 If the UA receives, over a secure transport, an HTTP response that
289 includes an Expect-CT header field conforming to the grammar
290 specified in Section 2.1, the UA MUST evaluate the connection on
291 which the header was received for compliance with the UA's CT policy,
292 and then process the Expect-CT header field as follows.
294 If the header field includes a "report-uri" directive, and the
295 connection does not comply with the UA's CT policy, then the UA MUST
296 send a report to the specified "report-uri" as specified in
297 Section 3.
299 If the header field contains the "enforce" directive and the
300 connection complies with the UA's CT policy, then the UA MUST either:
302 o Note the host as an Expect-CT host if it is not already so noted
303 (see Section 2.4), or
305 o Update the UA's cached information for the Expect-CT host if the
306 "max-age" or "report-uri" header field value directives convey
307 information different from that already maintained by the UA. If
308 the "max-age" directive has a value of 0, the UA MUST remove its
309 cached Expect-CT information if the host was previously noted as
310 an Expect-CT host, and MUST NOT note this host as an Expect-CT
311 host if it is not already noted.
313 If the header field contains the "enforce" directive and the
314 connection does not comply with the UA's CT policy, then the UA MUST
315 NOT note this host as an Expect-CT host.
317 If a UA receives more than one Expect-CT header field in an HTTP
318 response message over secure transport, then the UA MUST process only
319 the first Expect-CT header field.
321 The UA MUST ignore any Expect-CT header field not conforming to the
322 grammar specified in Section 2.1.
324 2.3.2. Noting an Expect-CT Host - Storage Model
326 The "effective Expect-CT date" of an Expect-CT host is the time that
327 the UA observed a valid Expect-CT header for the host. The
328 "effective expiration date" of a known Expect-CT host is the
329 effective Expect-CT date plus the max-age. An Expect-CT host is
330 "expired" if the effective expiration date refers to a date in the
331 past. The UA MUST ignore any expired Expect-CT hosts in its cache.
333 Expect-CT hosts are identified only by domain names, and never IP
334 addresses. If the substring matching the host production from the
335 Request-URI (of the message to which the host responded)
336 syntactically matches the IP-literal or IPv4address productions from
337 Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as an
338 Expect-CT host.
340 Otherwise, if the substring does not congruently match an existing
341 Expect-CT host's domain name, per the matching procedure specified in
342 Section 8.2 of [RFC6797], then the UA MUST add this host to the
343 Expect-CT host cache. The UA caches:
345 o the Expect-CT host's domain name,
347 o the effective expiration date, or enough information to calculate
348 it (the effective Expect-CT date and the value of the "max-age"
349 directive),
351 o the value of the "report-uri" directive, if present.
353 If any other metadata from optional or future Expect-CT header
354 directives are present in the Expect-CT header, and the UA
355 understands them, the UA MAY note them as well.
357 UAs MAY set an upper limit on the value of max-age, so that UAs that
358 have noted erroneous Expect-CT hosts (whether by accident or due to
359 attack) have some chance of recovering over time. If the server sets
360 a max-age greater than the UA's upper limit, the UA MAY behave as if
361 the server set the max-age to the UA's upper limit. For example, if
362 the UA caps max-age at 5,184,000 seconds (60 days), and a Pinned Host
363 sets a max- age directive of 90 days in its Expect-CT header, the UA
364 MAY behave as if the max-age were effectively 60 days. (One way to
365 achieve this behavior is for the UA to simply store a value of 60
366 days instead of the 90-day value provided by the Expect-CT host.)
368 The UA MUST NOT cache information from an Expect-CT header that does
369 not include the "enforce" directive. (Report-only headers are useful
370 only at the time of receipt and processing.)
372 2.3.3. HTTP-Equiv Element Attribute
374 UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
375 "" elements [W3C.REC-html401-19991224] in received content.
377 2.4. Noting Expect-CT
379 Upon receipt of the Expect-CT response header field containing an
380 "enforce" directive, the UA notes the host as an Expect-CT host,
381 storing the host's domain name and its associated Expect-CT
382 directives in non-volatile storage. The domain name and associated
383 Expect-CT directives are collectively known as "Expect-CT metadata".
385 The UA MUST note a host as an Expect-CT host if and only if it
386 received the Expect-CT response header field over an error-free TLS
387 connection, inluding the validation added in Section 2.5, that
388 included the "enforce" directive.
390 To note a host as an Expect-CT host, the UA MUST set its Expect-CT
391 metadata to the effective expiration date and report-uri (if any)
392 given in the most recently received valid Expect-CT header.
394 For forward compatibility, the UA MUST ignore any unrecognized
395 Expect-CT header directives, while still processing those directives
396 it does recognize. Section 2.1 specifies the directives "enforce",
397 "max-age", and "report-uri", but future specifications and
398 implementations might use additional directives.
400 2.5. Evaluating Expect-CT Connections for CT Compliance
402 When a UA connects to an Expect-CT host using a TLS connection, if
403 the TLS connection has errors, the UA MUST terminate the connection
404 without allowing the user to proceed anyway. (This behavior is the
405 same as that required by [RFC6797].)
407 If the connection has no errors, then the UA will apply an additional
408 correctness check: compliance with a CT policy. A UA should evaluate
409 compliance with its CT policy whenever connecting to an Expect-CT
410 host, as soon as possible. It is acceptable to skip this CT
411 compliance check for some hosts according to local policy. For
412 example, a UA may disable CT compliance checks for hosts whose
413 validated certificate chain terminates at a user-defined trust
414 anchor, rather than a trust anchor built-in to the UA (or underlying
415 platform).
417 A UA that has previously noted a host as an Expect-CT host MUST
418 evaluate evaluate CT compliance when setting up the TLS session,
419 before beginning an HTTP conversation over the TLS channel.
421 If the UA does not evaluate CT compliance, e.g. because the user has
422 elected to disable it, or because a presented certificate chain
423 chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect-
424 CT reports.
426 3. Reporting Expect-CT Failure
428 When the UA receives an Expect-CT header with a "report-uri"
429 directive that does not comply with the UA's CT policy, or when the
430 UA connects to a noted Expect-CT host that does not comply with the
431 CT policy, the UA SHOULD report Expect-CT failures to the configured
432 "report-uri".
434 3.1. Generating a violation report
436 To generate a violation report object, the UA constructs a JSON
437 message of the following form:
439 {
440 "date-time": date-time,
441 "hostname": hostname,
442 "port": port,
443 "effective-expiration-date": expiration-date,
444 "served-certificate-chain": [ (MUST be in the order served)
445 pem1, ... pemN
446 ],
447 "validated-certificate-chain":
448 pem1, ... pemN
449 ],
450 "scts": [
451 sct1, ... sctN
452 ]
453 }
455 Figure 4: JSON format of a violation report object
457 Whitespace outside of quoted strings is not significant. The key/
458 value pairs may appear in any order, but each MUST appear only once.
460 The "date-time" indicates the time the UA observed the CT compliance
461 failure. It is provided as a string formatted according to
462 Section 5.6, "Internet Date/Time Format", of RFC 3339 [RFC3339].
464 The "hostname" is the hostname to which the UA made the original
465 request that failed the CT compliance check. It is provided as a
466 string.
468 The "port" is the port to which the UA made the original request that
469 failed the CT compliance check. It is provided as an integer.
471 The "effective-expiration-date" is the Effective Expiration Date for
472 the Expect-CT host that failed the CT compliance check. It is
473 provided as a string formatted according to Section 5.6, "Internet
474 Date/Time Format", of RFC 3339 [RFC3339].
476 The "served-certificate-chain" is the certificate chain, as served by
477 the Expect-CT host during TLS session setup. It is provided as an
478 array of strings, which MUST appear in the order that the
479 certificates were served; each string "pem1", ... "pemN" is the
480 Privacy-Enhanced Mail (PEM) representation of each X.509 certificate
481 as described in RFC 7468 [RFC7468].
483 The "validated-certificate-chain" is the certificate chain, as
484 constructed by the UA during certificate chain verification. (This
485 may differ from the "served-certificate-chain".) It is provided as
486 an array of strings, which MUST appear in the order matching the
487 chain that the UA validated; each string "pem1", ... "pemN" is the
488 Privacy-Enhanced Mail (PEM) representation of each X.509 certificate
489 as described in RFC 7468 [RFC7468].
491 The "scts" are JSON messages representing the SCTs (if any) that the
492 UA received for the Expect-CT host and their validation statuses.
493 The format of "sct1", ... "sctN" is shown in Figure 5. The SCTs may
494 appear in any order.
496 {
497 "sct": sct,
498 "status": status,
499 "source": source
500 }
502 Figure 5: JSON format of an SCT object
504 The "sct" is as defined in Section 4.1 of RFC 6962 [RFC6962].
506 The "status" is a string that the UA MUST set to one of the following
507 values: "unknown" (indicating that the UA does not have or does not
508 trust the public key of the log from which the SCT was issued),
509 "valid" (indicating that the UA successfully validated the SCT as
510 described in Section 5.2 of [RFC6962]), or "invalid" (indicating that
511 the SCT validation failed because of, e.g., a bad signature).
513 The "source" is a string that indicates from where the UA obtained
514 the SCT, as defined in Section 3.3 of RFC 6962 [RFC6962]. The UA
515 MUST set "source" to one of the following values: "tls-extension",
516 "ocsp", or "embedded".
518 3.2. Sending a violation report
520 When an Expect-CT header field contains the "report-uri" directive,
521 and the connection does not comply with the UA's CT policy, the UA
522 SHOULD report the failure as follows:
524 1. Prepare a JSON object "report object" with the single key
525 "expect-ct-report", whose value is the result of generating a
526 violation report object as described in Figure 4.
528 2. Let "report body" by the JSON stringification of "report object".
530 3. Let "report-uri" be the value of the "report-uri" directive in
531 the Expect-CT header field.
533 4. Queue a task [1] to fetch [2] "report-uri", with the synchronous
534 flag not set, using HTTP method "POST", with a "Content-Type"
535 header field of "application/expect-ct-report", and an entity
536 body consisting of "report body".
538 4. Security Considerations
540 4.1. Maximum max-age
542 1 year?
544 5. Privacy Considerations
546 6. IANA Considerations
548 7. Usability Considerations
550 When the UA detects an Expect-CT host in violation of the UA's CT
551 policy, users will experience denials of service. It is advisable
552 for UAs to explain the reason why.
554 It is advisable that UAs have a way for users to clear noted Expect-
555 CT hosts and that UAs allow users to query noted Expect-CT hosts.
557 8. References
559 8.1. Normative References
561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
562 Requirement Levels", BCP 14, RFC 2119,
563 DOI 10.17487/RFC2119, March 1997,
564 .
566 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
567 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
568 .
570 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
571 Resource Identifier (URI): Generic Syntax", STD 66,
572 RFC 3986, DOI 10.17487/RFC3986, January 2005,
573 .
575 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
576 Specifications: ABNF", STD 68, RFC 5234,
577 DOI 10.17487/RFC5234, January 2008,
578 .
580 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
581 (TLS) Protocol Version 1.2", RFC 5246,
582 DOI 10.17487/RFC5246, August 2008,
583 .
585 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
586 Transport Security (HSTS)", RFC 6797,
587 DOI 10.17487/RFC6797, November 2012,
588 .
590 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
591 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
592 .
594 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
595 Protocol (HTTP/1.1): Message Syntax and Routing",
596 RFC 7230, DOI 10.17487/RFC7230, June 2014,
597 .
599 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
600 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
601 RFC 7234, DOI 10.17487/RFC7234, June 2014,
602 .
604 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
605 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
606 April 2015, .
608 [W3C.REC-html401-19991224]
609 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
610 Specification", World Wide Web Consortium Recommendation
611 REC-html401-19991224, December 1999,
612 .
614 8.2. URIs
616 [1] https://html.spec.whatwg.org/#queue-a-task
618 [2] https://fetch.spec.whatwg.org/#fetching
620 Author's Address
622 Emily Stark
623 Google
625 Email: estark@google.com