| RFC 9163 | Expect-CT | June 2022 |
| Stark | Experimental | [Page] |
This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.¶
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.¶
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9163.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document defines a new HTTP header field ([RFC9110],Section 6.3) that enables UAs to identify web hosts that expect the presence of Signed Certificate Timestamps (SCTs)[RFC9162] in subsequent Transport Layer Security (TLS)[RFC8446] connections.¶
Web hosts that serve the Expect-CT header field are noted by the UA as "Known Expect-CT Hosts". The UA evaluates each connection to a Known Expect-CT Host for compliance with the UA's Certificate Transparency (CT) Policy. If the connection violates the CT Policy, the UA sends a report to a URI configured by the Expect-CT Host and/or fails the connection, depending on the configuration that the Expect-CT Host has chosen.¶
If misconfigured, Expect-CT can cause unwanted connection failures (for example, if a host deploys Expect-CT but then switches to a legitimate certificate that is not logged in Certificate Transparency logs or if a web host operator believes their certificate to conform to all UAs' CT policies but is mistaken). Web host operators are advised to deploy Expect-CT with precautions by using the reporting feature and gradually increasing the time interval during which the UA regards the host as a Known Expect-CT Host. These precautions can help web host operators gain confidence that their Expect-CT deployment is not causing unwanted connection failures.¶
Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to require SCTs for the connection. Thus, the UA will not be able to detect and thwart an attack on the UA's first connection to the host. Still, Expect-CT provides value by 1) allowing UAs to detect the use of unlogged certificates after the initial communication, and 2) allowing web hosts to be confident that UAs are only trusting publicly auditable certificates.¶
Expect-CT is similar to HTTP Strict Transport Security (HSTS)[RFC6797] and HTTP Public Key Pinning (HPKP)[RFC7469]. HSTS allows websites to declare themselves accessible only via secure connections, and HPKP allows websites to declare their cryptographic identifies. Similarly, Expect-CT allows websites to declare themselves accessible only via connections that are compliant with CT Policy.¶
This Expect-CT specification is compatible with[RFC6962] and[RFC9162], but not necessarily with future versions of Certificate Transparency. UAs will ignore Expect-CT header fields from web hosts that use future versions of Certificate Transparency, unless a future version of this document specifies how they should be processed.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Terminology is defined in this section.¶
The Expect-CT response header field is a new field defined in this specification. It is used by a server to indicate that UAs should evaluate connections to the host emitting the header field for CT compliance (Section 2.4).¶
Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in[RFC5234] and the rules defined inSection 5 of [RFC9110]. The "#" ABNF extension is specified inSection 5.6.1 of [RFC9110].¶
Expect-CT = 1#expect-ct-directiveexpect-ct-directive = directive-name [ "=" directive-value ]directive-name = tokendirective-value = token / quoted-string
The directives defined in this specification are described below. The overallrequirements for directives are:¶
TheOPTIONALreport-uri directive indicates the URI to which the UASHOULD report Expect-CT failures (Section 2.4). The UA POSTs the reports to the given URI as described inSection 3.¶
Thereport-uri directive isREQUIRED to have a directive value, for which the syntax is defined inFigure 2.¶
report-uri-value = (DQUOTE absolute-URI DQUOTE) / absolute-URI
The 'report-uri-value'MUST be quoted if it contains any character not allowed in 'token'.¶
absolute-URI is defined inSection 4.3 of [RFC3986].¶
UAsMUST ignore anyreport-uri that does not use the HTTPS scheme. UAsMUST check Expect-CT compliance when the host in thereport-uri is a Known Expect-CT Host; similarly, UAsMUST apply HSTS[RFC6797] if the host in thereport-uri is a Known HSTS Host.¶
UAsSHOULD make their best effort to report Expect-CT failures to thereport-uri, but they may fail to report in exceptional conditions. For example, if connecting to thereport-uri itself incurs an Expect-CT failure or other certificate validation failure, the UAMUST cancel the connection. Similarly, if Expect-CT Host A sets areport-uri referring to Expect-CT Host B, and if B sets areport-uri referring to A, and if both hosts fail to comply to the UA's CT Policy, the UASHOULD detect and break the loop by failing to send reports to and about those hosts.¶
Note that thereport-uri need not necessarily be in the same Internet domain or web origin as the host being reported about. Hosts are in fact encouraged to use a separate host as thereport-uri so that CT failures on the Expect-CT Host do not prevent reports from being sent.¶
UAsSHOULD limit the rate at which they send reports. For example, it isunnecessary to send the same report to the samereport-uri more than once inthe same web-browsing session.¶
TheOPTIONALenforce directive is a valueless directive that, if present(i.e., it is "asserted"), signals to the UA that compliance to the CT Policyshould be enforced (rather than report-only) and that the UA should refusefuture connections that violate its CT Policy. When both theenforce directiveandreport-uri directive (as defined inFigure 2) are present, theconfiguration is referred to as an "enforce-and-report" configuration,signaling to the UA that both compliance to the CT Policy should be enforcedand violations should be reported.¶
Themax-age directive specifies the number of seconds after the reception ofthe Expect-CT header field during which the UASHOULD regard the host from whomthe message was received as a Known Expect-CT Host.¶
If a response contains an Expect-CT header field, then the responseMUSTcontain an Expect-CT header field with amax-age directive. (Amax-agedirective need not appear in every Expect-CT header field in the response.)Themax-age directive isREQUIRED to have a directive value, for which thesyntax (after quoted-string unescaping, if necessary) is defined inFigure 3.¶
max-age-value = delta-secondsdelta-seconds = 1*DIGIT
delta-seconds is used as defined inSection 1.3 of [RFC9111].¶
The following three examples demonstrate valid Expect-CT response header fields(where the second splits the directives into two field instances):¶
Expect-CT: max-age=86400, enforceExpect-CT: max-age=86400,enforceExpect-CT: report-uri="https://foo.example/report"Expect-CT: max-age=86400,report-uri="https://foo.example/report"
This section describes the processing model that Expect-CT Hosts implement. Themodel has 2 parts: (1) the processing rules for HTTP request messages receivedover a secure transport (e.g., authenticated, non-anonymous TLS); and (2) theprocessing rules for HTTP request messages received over non-secure transports,such as TCP.¶
An Expect-CT Host includes an Expect-CT header field in its response. The headerfieldMUST satisfy the grammar specified inSection 2.1.¶
Establishing a given host as an Expect-CT Host, in the context of a given UA,is accomplished as follows:¶
Expect-CT HostsSHOULD NOT include the Expect-CT header field in HTTP responsesconveyed over non-secure transport.¶
The UA processing model relies on parsing domain names. Note thatinternationalized domain namesSHALL be canonicalized by the UA according to thescheme inSection 10 of [RFC6797].¶
The UA stores Known Expect-CT Hosts and their associated Expect-CTdirectives. This data is collectively known as a host's "Expect-CT metadata".¶
If an HTTP response does not include an Expect-CT header field that conforms tothe grammar specified inSection 2.1, then the UAMUST NOTupdate any Expect-CT metadata.¶
If the UA receives an HTTP response over a secure transport that includes anExpect-CT header field conforming to the grammar specified inSection 2.1, the UAMUST evaluate the connection on whichthe header field was received for compliance with the UA's CT Policy, and thenprocess the Expect-CT header field as follows. UAsMUST ignore any Expect-CTheader field received in an HTTP response conveyed over non-secure transport.¶
If the connection does not comply with the UA's CT Policy (i.e., the connectionis not CT qualified), then the UAMUST NOT update any Expect-CT metadata. If theheader field includes areport-uri directive, the UASHOULD send a report tothe specifiedreport-uri (Section 2.3.3).¶
If the connection complies with the UA's CT Policy (i.e., the connection is CT qualified), then the UAMUST either:¶
enforce,max-age, orreport-uri header field value directives convey information different from that already maintained by the UA. If themax-age directive has a value of 0, the UAMUST remove its cached Expect-CT information if the host was previously noted as a Known Expect-CT Host andMUST NOT note this host as a Known Expect-CT Host if it is not already noted.¶If a UA receives an Expect-CT header field over a CT-compliant connection that uses a version of Certificate Transparency other than[RFC6962] or[RFC9162], the UAMUST ignore the Expect-CT header field and clear any Expect-CT metadata associated with the host.¶
Upon receipt of the Expect-CT response header field over an error-free TLSconnection (with X.509 certificate chain validation as described in[RFC5280], as well as the validation described inSection 2.4 of this document),the UAMUST note the host as a Known Expect-CT Host, storing the host's domainname and its associated Expect-CT directives in non-volatile storage.¶
To note a host as a Known Expect-CT Host, the UAMUST set its Expect-CT metadata in its Known Expect-CT Host cache (as specified inSection 2.3.2.2), using the metadata given in the most recently received valid Expect-CT header field.¶
For forward compatibility, the UAMUST ignore any unrecognized Expect-CT headerfield directives while still processing those directives it doesrecognize.Section 2.1 specifies the directivesenforce,max-age, andreport-uri, but future specifications and implementations mightuse additional directives.¶
If the substring matching the host production from the Request-URI (of themessage to which the host responded) does not exactly match an existing KnownExpect-CT Host's domain name, per the matching procedure for a Congruent Matchspecified inSection 8.2 of [RFC6797], then the UAMUST add this host to the Known Expect-CT Host cache. The UA caches:¶
enforce directive is present.¶max-age directive. Alternatively, the UAMAY cache enough information to calculate the Effective Expiration Date. The Effective Expiration Date is calculated from when the UA observed the Expect-CT header field and is independent of when the response was generated.¶report-uri directive, if present.¶If any other metadata from optional or future Expect-CT header directives are present in the Expect-CT header field, and the UA understands them, the UAMAY note them as well.¶
UAsMAY set an upper limit on the value ofmax-age so that UAs that have noted erroneous Expect-CT Hosts (whether by accident or due to attack) have some chance of recovering over time. If the server sets amax-age greater than the UA's upper limit, the UA may behave as if the server set themax-age to the UA's upper limit. For example, if the UA capsmax-age at 5,184,000 seconds (60 days), and an Expect-CT Host sets amax-age directive of 90 days in its Expect-CT header field, the UA may behave as if themax-age were effectively 60 days. (One way to achieve this behavior is for the UA to simply store a value of 60 days instead of the 90-day value provided by the Expect-CT Host.)¶
If the UA receives, over a secure transport, an HTTP response that includes anExpect-CT header field with areport-uri directive, and the connection doesnot comply with the UA's CT Policy (i.e., the connection is not CT qualified),and the UA has not already sent an Expect-CT report for this connection, thenthe UASHOULD send a report to the specifiedreport-uri as specified inSection 3.¶
When a UA sets up a TLS connection, the UA determines whether the host is a Known Expect-CT Host according to its Known Expect-CT Host cache. An Expect-CT Host is "expired" if the Effective Expiration Date refers to a date in the past. The UAMUST ignore any expired Expect-CT Hosts in its cache and not treat such hosts as Known Expect-CT Hosts.¶
When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS connection has no errors, then the UA will apply an additional correctness check: compliance with a CT Policy. A UA should evaluate compliance with its CT Policy whenever connecting to a Known Expect-CT Host. However, the check can be skipped for local policy reasons (as discussed inSection 2.4.1) or in the event that other checks cause the UA to terminate the connection before CT compliance is evaluated. For example, a Public Key Pinning failure[RFC7469] could cause the UA to terminate the connection before CT compliance is checked. Similarly, if the UA terminates the connection due to an Expect-CT failure, this could cause the UA to skip subsequent correctness checks. When the CT compliance check is skipped or bypassed, Expect-CT reports (Section 3) will not be sent.¶
When CT compliance is evaluated for a Known Expect-CT Host, the UAMUST evaluate compliance when setting up the TLS session, before beginning an HTTP conversation over the TLS channel.¶
If a connection to a Known Expect-CT Host violates the UA's CT Policy (i.e., the connection is not CT qualified), and if the Known Expect-CT Host's Expect-CT metadata indicates anenforce configuration, the UAMUST treat the CT compliance failure as an error. The UAMAY allow the user to bypass the error unless connection errors should have no user recourse due to other policies in effect (such as HSTS, as described inSection 12.1 of [RFC6797]).¶
If a connection to a Known Expect-CT Host violates the UA's CT Policy, and if the Known Expect-CT Host's Expect-CT metadata includes areport-uri, the UASHOULD send an Expect-CT report to thatreport-uri (Section 3).¶
It is acceptable for a UA to skip CT compliance checks for some hosts according to local policy. For example, a UAMAY disable CT compliance checks for hosts whose validated certificate chain terminates at a user-defined trust anchor rather than a trust anchor built in to the UA (or underlying platform).¶
If the UA does not evaluate CT compliance, e.g., because the user has elected to disable it, or because a presented certificate chain chains up to a user-defined trust anchor, UAsSHOULD NOT send Expect-CT reports.¶
When the UA attempts to connect to a Known Expect-CT Host and the connection is not CT qualified, the UASHOULD report Expect-CT failures to thereport-uri, if any, in the Known Expect-CT Host's Expect-CT metadata.¶
When the UA receives an Expect-CT response header field over a connection thatis not CT qualified, if the UA has not already sent an Expect-CT report for thisconnection, then the UASHOULD report Expect-CT failures to the configuredreport-uri, if any.¶
To generate a violationreport object, the UA constructs a JSON[RFC8259] object with the following keys and values:¶
SignedCertificateTimestamp structure fromSection 3.2 of [RFC6962]. The base64 encoding is defined inSection 4 of [RFC4648]. If the value of the "version" key is 2, the UAMUST set this value to the base64-encoded[RFC4648] serializedTransItem structure representing the SCT, as defined inSection 4.5 of [RFC9162].¶enforce configuration, and "report-only" otherwise.¶The UASHOULD report Expect-CT failures for Known Expect-CT Hosts: that is, when a connection to a Known Expect-CT Host does not comply with the UA's CT Policy and the host's Expect-CT metadata contains areport-uri.¶
Additionally, the UASHOULD report Expect-CT failures for hosts for which it does not have any stored Expect-CT metadata; that is, when the UA connects to a host and receives an Expect-CT header field that contains thereport-uri directive, the UASHOULD report an Expect-CT failure if the connection does not comply with the UA's CT Policy.¶
The steps to report an Expect-CT failure are as follows.¶
report object with the single key "expect-ct-report", whose value is the result of generating a violationreport object as described inSection 3.1.¶report body be the JSON stringification ofreport object.¶report-uri be the value of thereport-uri directive in the Expect-CTheader field.¶report-uri with aContent-Type header field ofapplication/expect-ct-report+json and an entity body consisting ofreport body.¶The UAMAY perform other operations as part of sending the HTTP POST request, such as sending a Cross-Origin Resource Sharing (CORS) preflight as part of[FETCH].¶
Future versions of this specification may need to modify or extend the Expect-CT report format. They may do so by defining a new top-level key to contain the report, replacing the "expect-ct-report" key.Section 3.3 defines how report servers should handle report formats that they do not support.¶
Upon receiving an Expect-CT violation report, the report serverMUST respond with a 2xx (Successful) status code if it can parse the request body as valid JSON, the report conforms to the format described inSection 3.1, and it recognizes the scheme, hostname, and port in the "scheme", "hostname", and "port" fields of the report. If thereport body cannot be parsed or does not conform to the format described inSection 3.1, or the report server does not expect to receive reports for the scheme, hostname, or port in the report, then the report serverMUST respond with a 400 Bad Request status code.¶
As described inSection 3.2, future versions of this specification may define new report formats that are sent with a different top-level key. If the report server does not recognize the report format, the report serverMUST respond with a 501 Not Implemented status code.¶
If the report's "test-report" key is set to true, the serverMAY discard thereport without further processing butMUST still return a 2xx (Successful)status code. If the "test-report" key is absent or set to false, the serverSHOULD store the report for processing and analysis by the owner of theExpect-CT Host.¶
When the UA detects a Known Expect-CT Host in violation of the UA's CT Policy,end users will experience denials of service. It is advisable for UAs to explainto users why they cannot access the Expect-CT Host, e.g., in a user interfacethat explains that the host's certificate cannot be validated.¶
Expect-CT could be specified as a TLS extension or X.509 certificate extension instead of an HTTP response header field. Using an HTTP header field as the mechanism for Expect-CT introduces a layering mismatch; for example, the software that terminates TLS and validates Certificate Transparency information might know nothing about HTTP. Nevertheless, an HTTP header field was chosen primarily for ease of deployment. In practice, deploying new certificate extensions requires certificate authorities to support them, and new TLS extensions require server software updates, including possibly to servers outside of the site owner's direct control (such as in the case of a third-party Content Delivery Network (CDN)). Ease of deployment is a high priority for Expect-CT because it is intended as a temporary transition mechanism for user agents that are transitioning to universal Certificate Transparency requirements.¶
Expect-CT can be used to infer what Certificate Transparency Policy a UA is using by attempting to retrieve specially configured websites that pass one user agent's policies but not another's. Note that this consideration is true of UAs that enforce CT policies without Expect-CT as well.¶
Additionally, reports submitted to thereport-uri could reveal information to a third party about which web page is being accessed and by which IP address, by using individualreport-uri values for individually tracked pages. This information could be leaked even if client-side scripting were disabled.¶
Implementations store state about Known Expect-CT Hosts and, hence, which domains the UA has contacted. Implementations may choose to not store this state subject to local policy (e.g., in the private browsing mode of a web browser).¶
Violation reports, as noted inSection 3, containinformation about the certificate chain that has violated the CT Policy. In somecases, such as an organization-wide compromise of the end-to-end security of TLS,this may include information about the interception tools and design used by theorganization that the organization would otherwise prefer not be disclosed.¶
Because Expect-CT causes remotely detectable behavior, it's advisable that UAs offer a way for privacy-sensitive end users to clear currently noted Expect-CT Hosts and allow users to query the current state of Known Expect-CT Hosts.¶
When UAs support the Expect-CT header field, it becomes a potential vector for hostile header attacks against site owners. If a site owner uses a certificate issued by a certificate authority that does not embed SCTs nor serve SCTs via the Online Certificate Status Protocol (OCSP) or TLS extension, a malicious 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 enforcing mode with a longmax-age. Implementing user agents would note this as an Expect-CT Host (seeSection 2.3.2.1). After having done this, the configuration could then be reverted to not comply with the CT Policy, prompting failures. Note that this scenario would require the attacker to have substantial control over the infrastructure in question, being able to obtain different certificates, change server software, or act as a man in the middle in connections.¶
Site operators can mitigate this situation by one of the following: reconfiguring their web server to transmit SCTs using the TLS extension defined inSection 6.5 of [RFC9162]; obtaining a certificate from an alternative certificate authority that provides SCTs by one of the other methods; or by waiting for the user agent's persisted notation of this as an Expect-CT Host to reach itsmax-age. User agents may choose to implement mechanisms for users to cure this situation, as noted inSection 4.¶
There is a security trade-off in that low maximum values provide a narrow window of protection for users that visit the Known Expect-CT Host only infrequently, while high maximum values might result in a denial of service to a UA in the event of a hostile header attack or simply an error on the part of the site owner.¶
There is probably no ideal maximum for themax-age directive. Since Expect-CT is primarily a policy-expansion and investigation technology rather than an end-user protection, a value on the order of 30 days (2,592,000 seconds) may be considered a balance between these competing security concerns.¶
Another kind of hostile header attack uses thereport-uri mechanism on manyhosts not currently exposing SCTs as a method to cause a denial of service tothe host receiving the reports. If some highly trafficked websites emitteda non-enforcing Expect-CT header field with areport-uri, implementing UAs' reportscould flood the reporting host. It is noted inSection 2.1.1 that UAsshould limit the rate at which they emit reports, but an attacker may alter theExpect-CT header fields to induce UAs to submit different reports to differentURIs to still cause the same effect.¶
This document registers the "Expect-CT" header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry located at<https://www.iana.org/assignments/http-fields>.¶
This document registers theapplication/expect-ct-report+json media type (which uses the suffix established in[RFC6839]) for Expect-CT violation reports in the "Media Types" registry as follows.¶