[cabfpub] FW: Short lived OCSP signing certificate

[Rob Stradling]

On 17/09/12 15:43, Gervase Markham wrote:
> Hi Mads,
>
> On 17/09/12 14:40, Mads Egil Henriksveen wrote:
>> *C: Short lived certificates*
>
> ...
>
>> The application could deal with short lived SSL-certificates in a
>> standard way, i.e. discard expired certificates. However, I assume that
>> browsers to not support short lived Subscriber certificates properly at
>> the moment (?).
>
> Why assume that? Short-lived certificates are just the same,
> technically, as normal certificates which have nearly reached their
> expiry date. Why would browsers not support them properly?
>
> One advantage of C over B is that it requires no infrastructure changes.

Gerv, which infrastructure(s) are you referring to?

I think most CAs would need to change their infrastructures to some 
degree in order to support short-lived certs.  Expecting the domain 
holder to initiate a fresh certificate order every few days would be 
impractical.

I think most webservers would need some changes too.  Expecting the 
domain holder to manually in install a new short-lived cert every few 
days would be impractical.

I think most browsers would need some changes too.  I'm not aware of any 
browser that avoids doing online revocation checks just because the cert 
is short-lived (or is sufficiently fresh).  (And if online revocation 
checks are not being avoided, what's the point of short-lived certs?)

I think the BRs and EVGs may need some changes too, if the consensus is 
that short-lived certs are permitted to contain zero CRL/OCSP URLs. 
(IIRC, opinions are divided on this point).

I think I'd argue that less changes are actually required for "B: 
OCSP-stapling", since all of the major browsers (except for Firefox!) 
and IIS, Apache httpd and (imminently) nginx already support OCSP Stapling.

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