12 September 2012. Successor report:
http://cryptome.org/2012/09/cert-transparency-02.htm
7 September 2012
Certificate Transparency IETF Working Group
Topic discussion:
https://www.ietf.org/mailman/listinfo/therightkey
Related: Certificate Transparency certificate-transparency-draft:
http://www.links.org/files/sunlight.html
Date: Fri, 7 Sep 2012 14:20:02 +0100
From: Ben Laurie <benl[at]google.com>
To: sidr[at]ietf.org, therightkey[at]ietf.org
Subject: [therightkey] Certificate Transparency WG
It has been suggested to me that the SIDR WG might be interested in Certificate
Transparency and a possible BoF in Atlanta. Please send followup discussion
to therightkey[at]ietf.org.
Here's an (updated) draft charter.
CT IETF WG Draft Charter
version 2
Objective
Specify mechanisms and techniques that allow Internet applications to monitor
and verify the issuance of public X.509 certificates such that all issued
certificates are available to applications, and each certificate seen by
an application can be efficiently shown to be in the log of issued certificates.
Furthermore, it should be possible to cryptographically verify the correct
operation of the log.
Optionally, do the same for certificate revocations.
Problem Statement
Currently it is possible for any CA to issue a certificate for any purpose
without any oversight. This has led to some high profile
mis-issuance of web certificates, such as by DigiNotar, a subsidiary of VASCO
Data Security International, in July 2011:
http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_
security_incident.aspx
The aim is to make it possible to detect such mis-issuance promptly through
the use of a public log of all public issued certificates. Domain owners
can then monitor this log and, upon detecting mis-issuance, take appropriate
action.
This public log must also be able to efficiently demonstrate its own correct
operation, rather than introducing yet another party that must be trusted
into the equation.
Clients should also be able to efficiently verify that certificates they
receive have indeed been entered into the public log.
For revocations, the aim would be similar: ensure that revocations are as
expected, that clients can efficiently obtain the revocation status of a
certificate and that the log is operating correctly.
Also, in both cases, the solution must be usable by browsers - this means
that it cannot add any round trips to page fetches, and that any data transfers
that are mandatory are of a reasonable size.
Existing Work
Certificate Transparency v2.1a
http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
Spec and working code:
http://code.google.com/p/certificate-transparency/source/browse/
_______________________________________________
therightkey mailing list
therightkey[at]ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
|