Expect-CT Extension for HTTPGoogleestark@google.comThis document defines a new HTTP header, named Expect-CT, that allows web host
operators to instruct user agents to expect valid Signed Certificate Timestamps
(SCTs) to be served on connections to these hosts. When configured in
enforcement mode, user agents (UAs) will remember that hosts expect SCTs and
will refuse connections that do not conform to the UA’s Certificate Transparency
policy. When configured in report-only mode, UAs will report the lack of valid
SCTs to a URI configured by the host, but will allow the connection. By turning
on Expect-CT, web host operators can discover misconfigurations in their
Certificate Transparency deployments and ensure that misissued certificates
accepted by UAs are discoverable in Certificate Transparency logs.This document defines a new HTTP header that enables UAs to identify web hosts
that expect the presence of Signed Certificate Timestamps (SCTs) in
future Transport Layer Security (TLS) connections.Web hosts that serve the Expect-CT HTTP header 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 caution, by
using the reporting feature and gradually increasing the interval where the UA
remembers 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.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 RFC 2119 .Terminology is defined in this section.
is a policy defined by the UA concerning the number, sources, and delivery
mechanisms of Signed Certificate Timestamps that are served on TLS
connections. The policy defines the properties of a connection that must be
met in order for the UA to consider it CT-qualified.
describes a TLS connection for which the UA has determined that a sufficient
quantity and quality of Signed Certificate Timestamps have been provided.
See Certificate Transparency Qualified.
See Certificate Transparency Policy.
See HTTP Expect-CT Host.
is the overall name for the combined UA- and server-side security policy
defined by this specification.
is a conformant host implementing the HTTP server aspects of HTTP
Expect-CT. This means that an Expect-CT Host returns the “Expect-CT” HTTP
response header field in its HTTP response messages sent over secure
transport.
is an Expect-CT Host that the UA has noted as such. See
for particulars.
is an acronym for “user agent”. For the purposes of this specification, a UA
is an HTTP client application typically actively manipulated by a user
.
is an Expect-CT Host that the UA has not noted.The “Expect-CT” header field is a new response header defined in this
specification. It is used by a server to indicate that UAs should evaluate
connections to the host emitting the header for CT compliance
(). describes the syntax (Augmented Backus-Naur Form) of the header field,
using the grammar defined in RFC 5234 and the rules defined in
Section 3.2 of RFC 7230 .Optional white space (OWS) is used as defined in Section 3.2.3 of RFC 7230
. token and quoted-string are used as defined in Section 3.2.6
of RFC 7230 .The directives defined in this specification are described below. The overall
requirements for directives are:The order of appearance of directives is not significant.A given directive MUST NOT appear more than once in a given header
field. Directives are either optional or required, as stipulated in their
definitions.Directive names are case insensitive.UAs MUST ignore any header fields containing directives, or other header
field value data, that do not conform to the syntax defined in this
specification. In particular, UAs must not attempt to fix malformed header
fields.If a header field contains any directive(s) the UA does not recognize, the
UA MUST ignore those directives.If the Expect-CT header field otherwise satisfies the above requirements (1
through 5), the UA MUST process the directives it recognizes.The OPTIONAL report-uri directive indicates the URI to which the UA SHOULD
report Expect-CT failures (). The UA POSTs the reports
to the given URI as described in .The report-uri directive is REQUIRED to have a directive value, for which the
syntax is defined in .absolute-URI is defined in Section 4.3 of RFC 3986 .Hosts may set report-uris that use HTTP or HTTPS. If the scheme in the
report-uri is one that uses TLS (e.g., HTTPS), UAs MUST check Expect-CT
compliance when the host in the report-uri is a Known Expect-CT Host;
similarly, UAs MUST apply HSTS if the host in the report-uri is a Known HSTS
Host.Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the host being reported about.UAs SHOULD make their best effort to report Expect-CT failures to the
report-uri, but they may fail to report in exceptional conditions. For
example, if connecting the report-uri itself incurs an Expect-CT failure or
other certificate validation failure, the UA MUST cancel the connection.
Similarly, if Expect-CT Host A sets a report-uri referring to Expect-CT Host
B, and if B sets a report-uri referring to A, and if both hosts fail to comply
to the UA’s CT Policy, the UA SHOULD detect and break the loop by failing to
send reports to and about those hosts.UAs SHOULD limit the rate at which they send reports. For example, it is
unnecessary to send the same report to the same report-uri more than once.The OPTIONAL enforce directive is a valueless directive that, if present
(i.e., it is “asserted”), signals to the UA that compliance to the CT Policy
should be enforced (rather than report-only) and that the UA should refuse
future connections that violate its CT Policy. When both the enforce directive
and report-uri directive (as defined in ) are present, the
configuration is referred to as an “enforce-and-report” configuration,
signalling to the UA both that compliance to the CT Policy should be enforced
and that violations should be reported.The max-age directive specifies the number of seconds after the reception of
the Expect-CT header field during which the UA SHOULD regard the host from whom
the message was received as a Known Expect-CT Host.The max-age directive is REQUIRED to be present within an “Expect-CT” header
field. The max-age directive is REQUIRED to have a directive value, for which
the syntax (after quoted-string unescaping, if necessary) is defined in
.delta-seconds is used as defined in Section 1.2.1 of RFC 7234 .This section describes the processing model that Expect-CT Hosts implement. The
model has 2 parts: (1) the processing rules for HTTP request messages received
over a secure transport (e.g., authenticated, non-anonymous TLS); and (2) the
processing rules for HTTP request messages received over non-secure transports,
such as TCP.When replying to an HTTP request that was conveyed over a secure transport, an
Expect-CT Host SHOULD include in its response exactly one Expect-CT header
field. The header field MUST satisfy the grammar specified in
.Establishing a given host as an Expect-CT Host, in the context of a given UA,
is accomplished as follows:Over the HTTP protocol running over secure transport, by correctly returning
(per this specification) at least one valid Expect-CT header field to the
UA.Through other mechanisms, such as a client-side preloaded Expect-CT Host
list.Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP responses
conveyed over non-secure transport. UAs MUST ignore any Expect-CT header
received in an HTTP response conveyed over non-secure transport.The UA processing model relies on parsing domain names. Note that
internationalized domain names SHALL be canonicalized according to
the scheme in Section 10 of .If the UA receives, over a secure transport, an HTTP response that includes an
Expect-CT header field conforming to the grammar specified in
, the UA MUST evaluate the connection on which
the header was received for compliance with the UA’s CT Policy, and then process
the Expect-CT header field as follows.If the connection complies with the UA’s CT Policy (i.e. the connection is
CT-qualified), then the UA MUST either:Note the host as a Known Expect-CT Host if it is not already so noted (see
), orUpdate the UA’s cached information for the Known Expect-CT Host if the
enforce, max-age, or report-uri header field value directives convey
information different from that already maintained by the UA. If the max-age
directive has a value of 0, the UA MUST remove its cached Expect-CT
information if the host was previously noted as a Known Expect-CT Host, and
MUST NOT note this host as a Known Expect-CT Host if it is not already noted.If the connection does not comply with the UA’s CT Policy (i.e. is not
CT-qualified), then the UA MUST NOT note this host as a Known Expect-CT Host.If the header field includes a report-uri directive, and the connection does
not 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, then
the UA SHOULD send a report to the specified report-uri as specified in
.If a UA receives more than one Expect-CT header field in an HTTP response
message over secure transport, then the UA MUST process only the first Expect-CT
header field.The UA MUST ignore any Expect-CT header field not conforming to the grammar
specified in .The “effective Expect-CT date” of a Known Expect-CT Host is the time that the UA
observed a valid Expect-CT header for the host. The “effective expiration date”
of a Known Expect-CT Host is the effective Expect-CT date plus the max-age. An
Expect-CT Host is “expired” if the effective expiration date refers to a date in
the past. The UA MUST ignore any expired Expect-CT Hosts in its cache.Known Expect-CT Hosts are identified only by domain names, and never IP
addresses. If the substring matching the host production from the Request-URI
(of the message to which the host responded) syntactically matches the
IP-literal or IPv4address productions from Section 3.2.2 of , then
the UA MUST NOT note this host as a Known Expect-CT Host.Otherwise, if the substring does not congruently match an existing Known
Expect-CT Host’s domain name, per the matching procedure specified in Section
8.2 of , then the UA MUST add this host to the Known Expect-CT Host
cache. The UA caches:the Expect-CT Host’s domain name,whether the enforce directive is presentthe effective expiration date, or enough information to calculate it (the
effective Expect-CT date and the value of the max-age directive),the value of the report-uri directive, if present.If any other metadata from optional or future Expect-CT header directives are
present in the Expect-CT header, and the UA understands them, the UA MAY note
them as well.UAs MAY set an upper limit on the value of max-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 a max-age greater than the
UA’s upper limit, the UA MAY behave as if the server set the max-age to the UA’s
upper limit. For example, if the UA caps max-age at 5,184,000 seconds (60
days), and a Pinned Host sets a max- age directive of 90 days in its Expect-CT
header, the UA MAY behave as if the max-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.)UAs MUST NOT heed http-equiv="Expect-CT" attribute settings on <meta>
elements in received content.Upon receipt of the Expect-CT response header field, the UA notes the host as a
Known Expect-CT Host, storing the host’s domain name and its associated
Expect-CT directives in non-volatile storage. The domain name and associated
Expect-CT directives are collectively known as “Expect-CT metadata”.The UA MUST note a host as a Known Expect-CT Host if and only if it received the
Expect-CT response header field over an error-free TLS connection, including the
validation added in .To note a host as a Known Expect-CT Host, the UA MUST set its Expect-CT metadata
given in the most recently received valid Expect-CT header.For forward compatibility, the UA MUST ignore any unrecognized Expect-CT header
directives, while still processing those directives it does
recognize. specifies the directives enforce,
max-age, and report-uri, but future specifications and implementations might
use additional directives.When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS
connection has errors, the UA MUST terminate the connection without allowing the
user to proceed anyway. (This behavior is the same as that required by
.)If the 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, as soon as
possible. It is acceptable to skip this CT compliance check for some hosts
according to local policy. For example, a UA may 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 a connection to a Known 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 an enforce configuration, the UA MUST treat the CT
compliance failure as a non-recoverable error.If a connection to a Known CT Host violates the UA’s CT policy, and if the Known
Expect-CT Host’s Expect-CT metadata includes a report-uri, the UA SHOULD send
an Expect-CT report to that report-uri ().A UA that has previously noted a host as a Known Expect-CT Host MUST evaluate CT
compliance when setting up the TLS session, before beginning an HTTP
conversation over the TLS channel.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, UAs SHOULD 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 UA SHOULD report Expect-CT failures to the report-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 that
is not CT-qualified, if the UA has not already sent an Expect-CT report for this
connection, then the UA SHOULD report Expect-CT failures to the configured
report-uri, if any.To generate a violation report object, the UA constructs a JSON message of the
following form:Whitespace outside of quoted strings is not significant. The key/value pairs
may appear in any order, but each MUST appear only once.The date-time indicates the time the UA observed the CT compliance failure.
It is provided as a string formatted according to Section 5.6, “Internet
Date/Time Format”, of RFC 3339 .The hostname is the hostname to which the UA made the original request that
failed the CT compliance check. It is provided as a string.The port is the port to which the UA made the original request that failed the
CT compliance check. It is provided as an integer.The effective-expiration-date is the Effective Expiration Date for the
Expect-CT Host that failed the CT compliance check. It is provided as a string
formatted according to Section 5.6, “Internet Date/Time Format”, of RFC 3339
.The served-certificate-chain is the certificate chain, as served by the
Expect-CT Host during TLS session setup. It is provided as an array of strings,
which MUST appear in the order that the certificates were served; each string
pem1, … pemN is the Privacy-Enhanced Mail (PEM) representation of each
X.509 certificate as described in RFC 7468 .The validated-certificate-chain is the certificate chain, as constructed by
the UA during certificate chain verification. (This may differ from the
served-certificate-chain.) It is provided as an array of strings, which MUST
appear in the order matching the chain that the UA validated; each string
pem1, … pemN is the Privacy-Enhanced Mail (PEM) representation of each
X.509 certificate as described in RFC 7468 .The scts are JSON messages representing the SCTs (if any) that the UA received
for the Expect-CT host and their validation statuses. The format of sct1,
… sctN is shown in . The SCTs may appear in any order.The sct is as defined in Section 4.1 of RFC 6962 .The status is a string that the UA MUST set to one of the following values:
“unknown” (indicating that the UA does not have or does not trust the public key
of the log from which the SCT was issued), “valid” (indicating that the UA
successfully validated the SCT as described in Section 5.2 of ), or
“invalid” (indicating that the SCT validation failed because of, e.g., a bad
signature).The source is a string that indicates from where the UA obtained the SCT, as
defined in Section 3.3 of RFC 6962 . The UA MUST set source to one
of the following values: “tls-extension”, “ocsp”, or “embedded”.When an Expect-CT header field contains the report-uri directive, and the
connection does not comply with the UA’s CT Policy, or when the UA connects to a
Known Expect-CT Host with Expect-CT metadata that contains a report-uri, the
UA SHOULD report the failure as follows:Prepare a JSON object report object with the single key expect-ct-report,
whose value is the result of generating a violation report object as
described in .Let report body by the JSON stringification of report object.Let report-uri be the value of the report-uri directive in the Expect-CT
header field.Queue a task to
fetchreport-uri, with the
synchronous flag not set, using HTTP method POST, with a Content-Type
header field of application/expect-ct-report, and an entity body consisting
of report body.1 year?When the UA detects a Known Expect-CT Host in violation of the UA’s CT Policy,
users will experience denials of service. It is advisable for UAs to explain the
reason why.It is advisable that UAs have a way for users to clear Known Expect-CT Hosts and
that UAs allow users to query Known Expect-CT Hosts.Certificate TransparencyThis document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Hypertext Transfer Protocol -- HTTP/1.1HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]Hypertext Transfer Protocol (HTTP/1.1): CachingThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.HTTP Strict Transport Security (HSTS)This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]HTML 4.01 SpecificationDate and Time on the Internet: TimestampsTextual Encodings of PKIX, PKCS, and CMS StructuresThis document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.