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