Technical Summary
This document describes version 2.0 of the Certificate Transparency
(CT) protocol for publicly logging the existence of Transport Layer
Security (TLS) server certificates as they are issued or observed, in
a manner that allows anyone to audit certification 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.
This document obsoletes RFC 6962. It also specifies a new TLS
extension that is used to send various CT log artifacts.
Logs are network services that implement the protocol operations for
submissions and queries that are defined in this document.
This document is a bis document for the Experimental RFC 6962.
Working Group Summary
(2019 Summary)
During the document development, some content was split of
into other documents for clarity. Topics split of covers a threat
model document, a log monitoring API, and a client/gossip API.
Name redaction has been considered and was split of in another
document as well. The WG is still discussing whether or not to
allow name redaction as well as the redaction method that would
be used.
(2021 Additions)
Per WG discussions around version -29, this document was made Experimental (not PS) because of the lack of deployed implementations and a sense that there was insufficient operational experience.
The 2019-03 IESG review on -31 produced a few DISCUSSes which took some time to resolve. This delay included returning the document back to the WG and finding additional document production help.
Document Quality
(2019 Summary)
There are various implementations in different state of completion
which have lead to updates to the document.
Various well-known crypto libraries have started implementation.
A few new independent parties have also implemented or mostly
implemented this document's specification - both proprietary as well
as opensource implementations.
Stephen Kent gave many in-depth reviews of many versions of the
document, all of which were dealt with by the Working Group. Daniel
Kahn Gillmor came up with a new attack, which is now described in one
of the documents that was split off from this one. During WGLC several
implementers came forward explaining that one MUST keyword (in Section
5.1) had to change to SHOULD to allow for log behaviour that was deemed
necessary for actual deployments, which was agreed on by the Working
Group.
Personnel
Who is the Document Shepherd?
Paul Wouters
Who is the Responsible Area Director?
Roman Danyliw