He said ... The second part of the objective (i.e. making all public issued certificates available to applications) may be dangerous in many situations.
On Sep 6, 2012, at 2:45 PM, "Ben Laurie" <[email protected]> wrote: > On 6 September 2012 19:41, Tim Moses <[email protected]> wrote: >> Hi Ben. Yes. That's right. But, maybe that's unnecessarily restrictive. I >> was trying to come up with a response to Denis' objection. > > Perhaps I missed something - I am not sure what Denis' objection was? > >> 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
