As specified by RFC 6962, Certificate Transparency includes a multi-party protocol for providing cryptographically-verifiable proofs to audit the issuance and security practices of Certificate Authorities.
To support such auditing, Chrome includes a list of Logs that have passed an application process and are recognized to be operating in the public interest. This Certificate Transparency Log Policy (“Policy”) sets forth how a Certificate Transparency Log Operator may have its Log recognized within Chrome as well as the ongoing expectations of these Log Operators. This policy may be updated by Google from time to time.
Before applying for their first CT Logs to be added to Chrome, new CT Log Operators should first read and fully comprehend the ongoing requirements for CT Logs specified in this Policy. Once a Log Operator is confident they can meet these requirements and has deployed a set of temporally-sharded CT Logs ready for application, they should follow the below process for adding these Logs to Chrome.
New CT Log Operators should begin their application process by first filing a new CT Log Operator bug on the Chromium Issue Tracker, and provide:
This bug will be used to track all CT Logs operated by this Log Operator for as long as any Logs operated by this organization are Pending, Qualified, Usable, ReadOnly, or Retired. By creating a new CT Log Operator bug, applicants are asserting they are organizationally independent from all existing CT Log Operators, which can be observed in the log_list.json file hosted by Google. If an organizational change occurs that alters this independence, CT Log Operators are required to notify Chrome at chrome-certificate-transparency@google.com as soon as possible.
Once the Chrome team has confirmed the Log Operator’s contact information, or if an existing Log Operator is applying for additional CT Logs to be added to Chrome, the CT Log Operator must next provide the following information about the new CT Logs in their existing CT Log Operator bug:
After acceptance, Google will monitor the Logs, including random compliance testing, prior to its inclusion within Chrome. Such compliance testing will include, but is not limited to, verifying the Logs’ conformance to RFC 6962, confirming the Logs’ availability meets the requirements of this Policy, and confirming the Logs are append-only and consistent from every point of view.
To enable compliance monitoring, Log Operators will be asked to include Google’s Merge Delay Monitor Root certificate in the set of accepted root certificates of their Logs.
In order for their Logs to remain included within Chrome after first becoming Qualified, Log Operators must continue to operate these Logs in accordance with this Policy. Log Operators must:
Google will notify Log Operators of changes to these requirements as well as effective dates for those changes via announcements to the ct-policy@chromium.org. Log Operators that fail to meet these requirements will be in violation of this Policy, which may result in removal of the Log(s) from Chrome.
In order to maintain broad utility to Chrome and its users, CT Logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms, including ChromeOS, Android, Linux, Windows, macOS, iOS. If a Log Operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT Log Operator Application as well as the rationale for this restriction. Note: This restriction may prevent a CT Log from being accepted by Chrome for inclusion.
CT Logs are permitted to reject logging submissions for certificates that meet certain conditions, such as being expired or revoked at the time the submission was made. A logging rejection means that the CT Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. Rejected logging submissions must not be issued an SCT by the CT Log.
If specified within the Application, a Log may reject submission to log certificates that chain up to an Accepted Root Certificate based on one or more of the following conditions:
id-kp-serverAuth Extended Key Usage (EKU).The primary purpose of allowing rejection of certain logging submissions is to provide Log Operators with greater control over the growth and operation of their Logs while still performing their core function. Additionally, these criteria allow Logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging submissions.
In order to provide ecosystem agility and to control the growth of CT Log sizes, new CT Logs must be temporally sharded, defining a certificate expiry range denoted in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject otherwise valid logging submissions for certificates that expire before or after this defined range, thus partitioning the set of publicly-trusted certificates that each Log will accept.
In order to have their Logs accepted for inclusion, Log Operators should deploy and operate their Logs according to the following:
The Chrome team includes CT Logs at their sole discretion, to further public auditability of Certificate Authorities. Upon learning of a Log’s potential violation of this Policy, they will review the information and may take corrective actions to preserve the integrity of its CT Log program. CT Logs may be removed from Chrome at any time, and for any reason.