RFC 6962

RFC 6962
Title	Certificate Transparency
Number	6962
Status	Informational
Published	2013-06
Authors	Ben Laurie, Adam Langley, Emilia Kasper
Organization	Google

RFC 6962

Introduction

RFC 6962 defines a framework titled Certificate Transparency, a system intended to detect misissuance of X.509 certificates by creating public, append-only logs. The document describes interactions among submitters, log operators, monitors, and auditors to improve the trustworthiness of public key infrastructure-related artifacts such as Transport Layer Security certificates and to complement mechanisms like Web PKI. RFC 6962 influenced later standards and deployments across ecosystems involving entities such as Google, Mozilla, Microsoft, Apple Inc., and certificate authorities like DigiCert and Let's Encrypt.

Background and Purpose

The purpose of RFC 6962 is to address failures in certificate issuance highlighted by incidents involving misissued or compromised certificates that affected services run by organizations including RSA Security, Comodo, and DigiNotar. The memo situates Certificate Transparency within historical attempts to secure name-to-key bindings exemplified by projects like DNSSEC and proposals such as Perspectives (network security), and by protocols developed at institutions including Internet Engineering Task Force working groups and research labs at Carnegie Mellon University and Stanford University. By providing verifiable logs, the specification aims to deter or detect fraudulent issuance affecting high-profile domains owned by companies like Facebook and Yahoo!, and to support policy commitments from browsers maintained by vendors such as Google Chrome and Mozilla Firefox.

Architecture and Components

RFC 6962 outlines an architecture comprising several actors: submitters (typically Certificate Authority entities such as Symantec or Entrust), log operators (run by organizations like Google), monitors (third parties including security firms and academic groups at University of Michigan), and auditors (which can be integrated into clients such as web browsers or standalone services run by groups at Electronic Frontier Foundation). Key components include Merkle trees derived from constructions studied by researchers at MIT and ETH Zurich, Signed Certificate Timestamps (SCTs) analogous to digital signatures in standards like RFC 5280, and Signed Tree Heads (STHs) enabling consistency proofs similar to techniques from Ralph Merkle's work. The design references cryptographic primitives standardized by bodies such as the National Institute of Standards and Technology and draws on operational practices from registries like IANA.

Protocol Operation

The protocol specifies that when a Certificate Authority issues an X.509 certificate or a pre-certificate, it submits the data to a public log which returns an SCT. Clients such as Google Chrome and Mozilla Firefox can require SCTs before accepting certificates, while monitors operated by organizations like Censys and Shodan scan logs to detect anomalous entries. Logs provide append-only guarantees through Merkle tree roots and support inclusion and consistency proofs verifiable using algorithms studied at Stanford University and described in literature from conferences such as USENIX and IEEE Symposium on Security and Privacy. Interactions incorporate transport and encoding conventions influenced by HTTP/1.1, TLS 1.2, and later adaptations for HTTP/2 and TLS 1.3 deployments in infrastructures run by companies like Cloudflare.

Security Considerations

RFC 6962 analyzes threats including log equivocation, log operator compromise, and collusion between Certificate Authorities and logs—risks previously exemplified by incidents tied to entities such as DigiNotar. Mitigations include distributed auditability through multiple independent logs, gossip mechanisms for STHs inspired by proposals from researchers at Google Research and ETH Zurich, and legal or economic incentives drawn from industry practices at firms like VeriSign. The specification discusses reliance on cryptographic assumptions validated by standards bodies such as IETF and NIST, and operational security measures comparable to hardening guidance from agencies like US-CERT.

Implementations and Adoption

Following publication, implementations emerged from major browser vendors and infrastructure providers: Google operated a public log; Mozilla integrated CT policies; Apple Inc. and Microsoft adjusted trust policies; certificate issuers including Let's Encrypt and DigiCert incorporated CT submission workflows; and open-source projects such as OpenSSL and BoringSSL provided client-side support. Academic groups at University College London and industry teams at Akamai developed monitoring tools; services like crt.sh by Cloudflare and projects by EFF facilitated public auditing. Adoption timelines were influenced by policy pronouncements at events such as IETF meetings and the inclusion of CT requirements in Chrome's enforcement milestones.

Impact and Legacy

Certificate Transparency catalyzed shifts in how the Internet ecosystem handles certificate issuance, inspiring successor standards and work in forums like IETF and prompting research at institutions such as ETH Zurich and Princeton University. The model influenced transparency initiatives beyond PKI, echoing in proposals relating to blockchain research at MIT and transparency registries advocated by civil society organizations including Access Now and Electronic Frontier Foundation. The operationalization of CT affected market practices at certificate vendors like Symantec and Entrust, and its audit-centric approach remains a reference point for contemporary debates involving organizations such as ICANN and regulatory dialogues involving European Commission privacy initiatives.

Category:Internet standards