[cabfpub] FW: Short lived OCSP signing certificate
rob.stradling at comodo.com
Mon Sep 17 15:07:36 UTC 2012
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
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.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public