Hi Ben. Yes. That's right. But, maybe that's unnecessarily restrictive. I was trying to come up with a response to Denis' objection. As only a subset of all certificates will appear in the log (at the very least during a transitional phase) and a subset of certificate-using software will only accept certificates that do appear in the log, we need a graceful way of lining the two subsets up.
All the best. Tim. On 2012-09-06, at 2:30 PM, "Ben Laurie" <[email protected]> wrote: > 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
