1. Introduction
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 identities. 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.
1.1. Requirements Language
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.
1.2. Terminology
Terminology is defined in this section.
"Certificate Transparency Policy"
A policy defined by the UA concerning the number, sources, and delivery mechanisms of Signed Certificate Timestamps that are associated with TLS connections. The policy defines the properties of a connection that must be met in order for the UA to consider it CT qualified.
"Certificate Transparency Qualified"
Describes a TLS connection for which the UA has determined that a sufficient quantity and quality of Signed Certificate Timestamps have been provided.
"CT Qualified"
An abbreviation for "Certificate Transparency Qualified".
"CT Policy"
An abbreviation for "Certificate Transparency Policy".
"Effective Expect-CT Date"
The time at which a UA observed a valid Expect-CT header field for a given host.
"Expect-CT Host"
A conformant host implementing the HTTP server aspects of Expect-CT. This means that an Expect-CT Host returns the Expect-CT response header field in its HTTP response messages sent over secure transport. The term "host" is equivalent to "server" in this specification.
"Known Expect-CT Host"
An Expect-CT Host that the UA has noted as such. See Section 2.3.2.1 for particulars.
"User Agent (UA)"
For the purposes of this specification, a UA is an HTTP client application typically actively manipulated by a user [RFC9110].
"Unknown Expect-CT Host"
An Expect-CT Host that the UA has not noted.