Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan

[Ben Laurie <[e-mail]>]

On 10 February 2014 10:13, Rob Stradling <[e-mail]> wrote:
> On 08/02/14 13:32, Ben Laurie wrote:
>>
>> On 5 February 2014 18:21, Rob Stradling <[e-mail]> wrote:
>>>
>>> On 05/02/14 17:49, Adam Langley wrote:
>>>>
>>>>
>>>> On Wed, Feb 5, 2014 at 12:26 PM, Rob Stradling
>>>> <[e-mail]>
>>>> 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?