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

Reply via email to