SecurityEngineering/Certificate Transparency

This page describes the current draft plan for implementing Certificate Transparency in Gecko/Firefox.

The Plan

First we need to implement the ability to verify and interpret certificate transparency data (i.e. Signed Certificate Timestamps, or SCTs). Currently there are three ways to convey an SCT:

• Via an x509 extension in the end-entity certificate
• Via a TLS extension
• Via an extension in a stapled OCSP response

As of this writing, Google, DigiCert, Certly, and Izenpe are running CT logs that may produce these SCTs (see this page for an updated list and more details). We should be able to verify data from any of these logs and be able to distinguish their provenance.

Next we should gather telemetry on:

• How often which SCT delivery vector is used
• Which logs are being used
• Any kind of relationship between certificate validity period and number of SCTs per connection
• If we applied a policy of requiring some number of SCTs to show the EV indicator, how often would we decline to do so for a certificate that otherwise validates as EV

If the data looks good, we can create and enforce a policy. For reference, Chrome's policy documentation can be found here.

Additionally, and ideally before we enforce a policy, some design/UX work should go into displaying to the user information regarding if a site has presented SCTs for their certificate.

Concurrently, we should explore running a CT log at Mozilla.