[cabfpub] Updated Certificate Transparency + Extended Validation plan

[Rob Stradling]

On 10/02/14 11:35, Ben Laurie wrote:
> On 10 February 2014 10:13, Rob Stradling <rob.stradling at comodo.com> wrote:
>> On 08/02/14 13:32, Ben Laurie wrote:
>>>
>>> On 5 February 2014 18:21, Rob Stradling <rob.stradling at comodo.com> wrote:
>>>>
>>>> On 05/02/14 17:49, Adam Langley wrote:
>>>>>
>>>>>
>>>>> On Wed, Feb 5, 2014 at 12:26 PM, Rob Stradling
>>>>> <rob.stradling at comodo.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Presumably it's somewhere between 10 and 31 days, since 1 SCT is
>>>>>> acceptable
>>>>>> for Stapled OCSP and the BRs permit OCSP Responses to be valid for up
>>>>>> to
>>>>>> 10
>>>>>> days.
>>>>>
>>>>>
>>>>>
>>>>> The speed at which we need to distrust a log depends on the minimum
>>>>> number of SCTs actually, which is why allowing a single SCT in stapled
>>>>> OCSP responses is such a large concession. If the minimum number of
>>>>> SCTs were two then the pressure to distrust a log (and the pressure on
>>>>> the logs) would be dramatically reduced because compromising one log
>>>>> wouldn't be sufficient.
>>>>>
>>>>>> Do you still think [1] is a good plan?
>>>>>
>>>>>
>>>>>
>>>>> Sure, if any CAs are willing to do it now :)
>>>>
>>>>
>>>>
>>>> I think "servers could just download their refreshed certificate over
>>>> HTTP
>>>> periodically and automatically" is the showstopper at the moment. Yes
>>>> they
>>>> could, but I'm not aware of any server that actually implements such a
>>>> feature.
>>>
>>>
>>> Work is under way for Apache: https://github.com/trawick/ct-httpd/.
>>
>>
>> That looks like great work, but AFAICT it's only for fetching SCTs from CT
>> Logs.
>>
>> I was talking about the lack of any mechanism in popular webserver software
>> for automatically fetching and installing certificates from CAs.  In
>> particular: a short-duration certificate that reuses the same public key as
>> the previous certificate.
>
> Ah, I see! But why would you need it if you can refresh the SCTs yourself?

To fix certificate revocation checking, by avoiding the need for it (as 
Adam proposed a couple of years ago - see [1]).

But really, I was just trying to point out that just because CAs aren't 
noticeably issuing short-duration certs today, it doesn't mean that they 
won't do so in the future.  So I think it is worth permitting just 1 
embedded SCT for short-duration certs (for some value of "short").


[1] https://www.imperialviolet.org/2011/03/18/revocation.html
"A much better solution would be for certificates to only be valid for a 
few days and to forget about revocation altogether. This doesn't mean 
that the private key needs to change every few days, just the 
certificate. And the certificate is public data, so servers could just 
download their refreshed certificate over HTTP periodically and 
automatically (like OCSP stapling). Clients wouldn't have to perform 
revocation checks (which are very complex and slow), CAs wouldn't have 
to pay for massive, DDoS proof serving capacity and revocation would 
actually work. If the CA went down for six hours, nobody cares. Only if 
the CA is down for days is there a problem. If you want to “revoke” a 
certificate, just stop renewing it."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online