Skip to content

Latest commit

 

History

History
84 lines (64 loc) · 10.9 KB

log_policy.md

File metadata and controls

84 lines (64 loc) · 10.9 KB
Raw

Certificate Transparency Log Policy

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.

Application Process

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

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:

  • Contact Information for the Log Operator, including:
    • An email or e-mail alias that is continuously monitored by the Log Operator
    • A list of person(s) authorized to represent the Log Operator when communicating with the Chrome team

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 [email protected] as soon as possible.

Existing CT Log Operators

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:

  • Public HTTP endpoints that respond to all Log Client Messages indicated in RFC 6962, Section 4
  • The Logs’ public keys, attached as a binary file containing the DER encoding of the SubjectPublicKeyInfo ASN.1 structure
  • A description of the Logs, including applicable policies or requirements for logging certificates
  • The Maximum Merge Delay (MMD) of the Logs
  • The set of Accepted Root Certificates of the Logs
  • The expiry ranges of each Log in the form [rangeBegin, rangeEnd).
    • Certificate expiry ranges for a set of Logs must be contiguous, with no gaps, and each expiry range should be between 6 and 12 months.
  • Whether the Logs will reject logging submissions for expired or revoked certificates.

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.

Ongoing Requirements of Included 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:

  • Monitor the [email protected] group for relevant updates to policy or requirements for CT Log Operators
  • Have no outage that exceeds an MMD of more than 24 hours. Outages include, but are not limited to: network level outages, expiration of the Log’s SSL certificate, a failure to accept new Certificates to be logged (with the exception of the conditions defined in the Logging Submission Acceptance section below), HTTP response status codes other than 200, or responses that include data that does not conform to RFC 6962.
  • Conform to RFC 6962, including the implementation of all API endpoints defined within Section 4 of RFC 6962
  • Not impose conditions on retrieving or sharing data from the Logs
  • Maintain Log availability of 99% or above, with no outage lasting longer than the MMD (as measured by Google)
  • Not present two or more conflicting views of the Merkle Tree at different times and/or to different parties.
  • Incorporate a certificate for which an SCT has been issued by the Log within the MMD.
    • When Logs receive a logging submission for an already-incorporated certificate, Logs must either return an existing SCT or, if creating a new one, add another certificate entry within the MMD such that the new SCT can be verified using the APIs specified in RFC 6962.
  • Accept certificates issued by Google’s Merge Delay Monitor Root to enable Google to monitor the Log’s compliance to these policies.
  • Operate their Logs in good faith, including, but not limited to each Log Operator:
    • Verifiably incorporating all certificates into the Log for which SCTs have been issued, within the Log’s MMD
    • Maintaining the append-only property of the Log by providing consistent views of the Merkle Tree at all times and to all parties.
  • Notify the Chrome team of any and all changes to information gathered during the Log Inclusion by detailing such changes in an update to the CT Log Operator bug on the Chromium Issue Tracker in which they requested Log Inclusion.

Google will notify Log Operators of changes to these requirements as well as effective dates for those changes via announcements to the [email protected]. 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.

Logging Submission Policy

Accepted Root Certificates

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.

Rejecting Logging Submissions

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:

  • Certificate Revoked: If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging submission. If the Log is unable to determine revocation status, it must accept the logging submission and incorporate the entry into the Merkle Tree within the Log's MMD.
  • Certificate Expired: If a logging submission includes a certificate whose notAfter timestamp represents a point in time before the logging submission was made, the Log may refuse to log the certificate entry. This criteria may be used even by legacy non-sharded CT Logs that do not set certificate expiry ranges.
  • TLS Server Auth EKU: The Log may reject logging submissions for certificates that do not contain the 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.

Temporal Sharding

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 certificate expiry ranges for CT Logs must be no longer than one calendar year and should be no shorter than six months
  • CT Logs must reject logging submissions for certificates whose notAfter timestamp falls outside the certificate expiry range
  • Log Operators should deploy enough sharded CT Logs so that their certificate expiry ranges cover a contiguous period of time, spanning from the current time to 3-4 years in the future
    • Many Log Operators find it convenient to define these ranges on the calendar year, so an application in 2020 would include e.g. Log2020, Log2021, Log2022, Log2023.
  • CT Logs will be removed from Chrome once their certificate expiry range has passed. When Log Operators in good standing have one of their Logs removed in this manner, they should stand up a new CT Log whose expiry range extends the set of contiguous expiry ranges
    • Following the example from above, when Log2020 is removed in early 2021, the Log Operator should stand up Log2024 and apply for its inclusion, following the Application Process defined above.

Policy Violations

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.