[cabfpub] Short-Lived Certs - the return
brian at briansmith.org
Fri Jun 5 17:46:48 MST 2015
On Wed, Mar 18, 2015 at 6:56 PM, Ryan Sleevi <sleevi at google.com> wrote:
> Why 72 hours? Why not the OCSP max age?
> The downside of setting such a low number is that you make it
> significantly more risky for issues to arise that prevent issuance, making
> it much less appealing to use short-lived certs.
> I'm aware that some have suggested lowering the OCSP time, but it seems
> more useful and just as secure to be permissive, gain experience, and then
> consider reducing if and when necessary.
I think it would be better to gain experience with the 72 hour maximum with
short-lived certificates so that we can change the OCSP maximum to 72 hours
too. If the short-lived certificate maximum validity period is made to be
as long as the OCSP maximum validity period then we'd end up increasing the
resistance to shortening OCSP validity periods.
At least in the beginning, websites that use short-lived certificates
should have long-lived (with OCSP-based revocation) backup certificates
and/or an alternative short-lived-certificate-vending CA on standby. (The
same goes for Must-Staple.) That would be a much more effective risk
mitigation strategy than waiting until there is an issuance problem and
then spending the next 3-7 days trying to fix it or hoping somebody else
72 hours is an extremely long time to wait for a browser to start
recognizing that a compromised certificate (key) should no longer be
distrusted. Eventually we'll need to find some way to get a faster reaction
time with the same level of automation that OCSP provides (in theory).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public