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

[Rob Stradling <[e-mail]>]

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.

For at least httpd and nginx, I guess it would be pretty easy (albeit 
crude) to implement this in a simple shell script.  The bigger problem 
would be getting it widely deployed to servers.

>> How about requiring only 1 SCT for certs with durations <= the maximum
>> validity period for an OCSP Response?
>
> I agree that, if we're going to allow one SCT for stapled OCSP
> responses then we might as well allow one for 10 day certs.
>
> However, the only case where ~100 bytes makes any different is if the
> certificate chain is right on the edge of the initcwnd and the server
> cannot (somehow?) set the initcwnd. I.e. it's gone cargo cult.

What % of deployed servers can't (and/or don't?) set the initcwnd?

How small (in bytes) does a certificate chain need to be in order to 
avoid overflowing the initcwnd?

Thanks.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.