On 6 September 2012 18:33, Thomas Hardjono <[email protected]> wrote: > Hi Ben, > > A couple of questions: > >> 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. > > (a) Is this a log (repository) of just CA certs only, or does it > include every cert on the planet?
Every public cert on the planet. > (b) Does it apply to public CAs only (or can private CA also > contribute to this log). Private CAs can contribute. >> Clients should also be able to efficiently verify that certificates >> they receive have indeed been entered into the public log. > > (c) Will there be legal trust-frameworks to oversee the operations of > the contributing CAs as well as the log-operators? Our proposal does not require trust, so I certainly don't intend to propose legal frameworks. Others may have other ideas, which I look forward to hearing about. > (d) Will the end-user (client side) have to pay to access the log? Not our log. > (e) Who are the potential operators of the log(s) & how do they make > money? It is surprisingly cheap to run a Certificate Transparency log, we believe. So, we hope that there will be sufficient interest in the stability of the 'net to not require a way to make profit from a log. Google intends to run one, in any case. > (f) History has shown that server-side certs are rarely ever validated > by the client. What's different this time that would make the clients > willing to look-up the log. Certificate Transparency does not require lookup. I'd also note that browsers _do_ validate certs. Other clients are less diligent, agreed - this is a different problem which is also worth solving. > (g) Will the CT-WG define Web APIs for accessing the log? (or will the > APIs be non-standard defined by log-operators). I believe that such APIs (I would call them protocols :-) are in scope for the WG. > > > ps. anyone remember UDDI? > > > Thanks. > > /thomas/ > > >> -----Original Message----- >> From: [email protected] [mailto:therightkey- >> [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
