Denis, all, Please follow-up on [email protected] which is where this will be discussed.
Thanks, S. On 09/06/2012 03:55 PM, [email protected] wrote: > Part of the stated objective (i.e. verify the issuance of public X.509 > certificates) > is currently addressed, within the context of OCSP, in : > > https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/ > > This draft is being considered within the PKIX WG. > > The second part of the objective (i.e. making all public issued certificates > available to applications) > may be dangerous in many situations. > > Denis > > [email protected] a écrit : ----- > A : "[email protected]" <[email protected]>, "'[email protected]'" <[email protected]>, > pkix <[email protected]> > De : Stephen Farrell > Envoyé par : [email protected] > Date : 06/09/2012 16:42 > Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group? > > Hi all, > > Please see below. Ben Laurie's looking to see if folks are > interested in a BoF on Certificate Transparency for the > IETF meeting in Altanta. > > Sean and I would be fine with that, if there's sufficient > interest etc. > > Please follow up on [email protected] if this is a > topic that's of interest to you. > > Thanks, > Stephen. > > > -------- Original Message -------- > Subject: [therightkey] Certificate Transparency Working Group? > Date: Thu, 6 Sep 2012 15:32:05 +0100 > From: Ben Laurie <[email protected]> > To: [email protected] > > 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 > > > > > _______________________________________________ > pkix mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > wpkops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
