!!! Overview
[{$pagename}] is described in [RFC 6962] as an experimental protocol for publicly logging the existence of [Transport Layer Security] ([TLS]) [certificates] as they are issued or observed, in a manner that allows anyone to [audit|Auditing] [Certificate Authority] (CA) activity and notice the issuance of suspect certificates as well as to [audit|Auditing] 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.
[{$pagename}] is one attempt reduce the [Public Key Infrastructure Weaknesses] [Attack Surface]
Logs are network [services] that implement the [protocol] operations for submissions and queries that are defined in [RFC 6962].
[{$pagename}] aims to remedy these certificate-based threats by making the issuance and existence of SSL [certificates] open to scrutiny by domain owners, CAs, and domain users. Specifically, [{$pagename}] has three main goals:
* Make it impossible (or at least very difficult) for a [CA|Certificate Authority] or [Registration Authority] to issue a SSL [certificate] for a [domain|DNS Domain] without the certificate being visible to the owner of that domain.
* Provide an open auditing and monitoring system that lets any domain owner or [CA|Certificate Authority] or [Registration Authority] determine whether certificates have been mistakenly or maliciously issued.
* Protect users (as much as possible) from being duped by [Compromised Certificate] that were mistakenly or maliciously issued.
[{$pagename}] satisfies these goals by creating an open framework for [monitoring] the [TLS]/[SSL] [certificate] system and [auditing] specific [TLS]/[SSL] [certificates].
[{$pagename}] aims to mitigate the problem of improperly issued [certificates] by providing publicly [auditable|Auditing], append-only, untrusted logs of all issued [certificates]. The logs are publicly auditable so that it is possible for anyone to verify the correctness of each log and to monitor when new [certificates] are added to it. The logs do not themselves prevent improperly issued certificates, but they ensure that interested parties (particularly those named in [certificates]) can detect such improperly issued certificates. Note that this is a general mechanism, but in [RFC 6962], we only describe its use for public [TLS] server [certificates] issued by public [Certificate Authorities|Certificate Authority] ([CAs]).
Each log consists of certificate chains, which can be submitted by anyone. It is expected that public [CAs] will contribute all their newly issued certificates to one or more logs; it is also expected that certificate holders will contribute their own certificate chains. In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known [CA] [certificate]. When a chain is submitted to a log, a signed timestamp is returned, which can later be used to provide evidence to clients that the chain has been submitted. TLS clients can thus require that all certificates they see have been logged.
Those who are concerned about improperly issued certificates can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect. What they do with this information, particularly when they find that a improperly issued certificates has happened, is beyond the scope of [RFC 6962], but broadly speaking, they can invoke existing business mechanisms for dealing with improperly issued [certificates]. Of course, anyone who wants can monitor the logs and, if they believe a certificate is incorrectly issued, take action as they see fit.
Similarly, those who have seen signed timestamps from a particular log can later demand a proof of inclusion from that log. If the log is unable to provide this (or, indeed, if the corresponding certificate is absent from monitors' copies of that log), that is evidence of the incorrect operation of the log. The checking operation is asynchronous to allow [TLS] connections to proceed without delay, despite network connectivity issues and the vagaries of firewalls.
The append-only property of each log is technically achieved using [Merkle Trees], which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, [Merkle Trees] avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for [certificates] they then don't log) can be efficiently detected and proved to the world at large.
!! [{$pagename}] and [Public Key Pinning Extension for HTTP]
[{$pagename}] solves one part of the problem that [Public Key Pinning Extension for HTTP]: That is no [Certificate Authority] will be able to issue a [certificate] in secret without the owner of the [DNS Domain] knowing about it because it will be present in publicly visible CT logs.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Certificate Transparency|https://www.certificate-transparency.org/what-is-ct|target='_blank'] - based on information obtained 2013-04-10