On 6 September 2012 16:16, Tim Moses <[email protected]> wrote: > Hi Ben. I am supportive of this initiative, and intend to participate. > > Perhaps a small clarification is warranted. Consider limiting the proposed > solution to "Publicly-Trusted Certificates", which are defined as follows by > CABForum: "A Certificate that is trusted by virtue of the fact that its > corresponding Root Certificate is distributed as a trust anchor in > widely-available application software".
I don't think we should place a bar to other certificates being logged, but certainly this is the set of certs that should be mandatory. I already said "public" in various places, so I presume you are suggesting I switch that to "publicy-trusted"? > > All the best. Tim. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Ben Laurie > Sent: Thursday, September 06, 2012 10:32 AM > To: [email protected] > Subject: [therightkey] Certificate Transparency Working Group? > > Would people be interested in starting a WG on Certificate Transparency? If > so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to monitor > and verify the issuance of public X.509 certificates such that all public > 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 site > without any oversight. This has led to some high profile mis-issuance of > 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. > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
