[cabfpub] Short-Lived Certs - the return
doug.beattie at globalsign.com
Fri Jun 5 13:06:58 MST 2015
This topic has been on the back burner for a while and I think we should move it to pre-pre-ballot discussions.
Given both OCSP and CRL max validity are set at 10 days, I’d recommend we allow SSL certificates to omit OCSP and/or CRL information if they are 10 days or less in duration, that is currently the max lag time a relying party can go without an update (most CAs actual controls are much shorter than this, and they can also have shorter limits on their “short validity SSL certificates”)
I also recommend that we clearly specify that you cannot pre-date a certificate by more than 24 hours, and you cannot postdate the certificate at all as part of this ballot (to make it clear you cannot pre-generate a years’ worth of certs ahead of time).
I would propose that we allow DV/OV and EV certificates to implement this; however, if EV should be exempt of have a shorter limit, I’m fine with that.
1. DV/OV/EV certificates with validity periods of 10 days (240 hours) or less may omit CDP and OCSP URLs
2. Certificates may be dated in the past by up to 24 hours
3. Certificates must not be dated in the future
Conceptually, is this something the members feel they can support? If so, I can start on a pre-ballot and we can discuss at the F2F.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Thursday, March 19, 2015 11:54 AM
To: Gervase Markham
Subject: Re: [cabfpub] Short-Lived Certs - the return
On Mar 19, 2015 6:19 AM, "Gervase Markham" <gerv at mozilla.org<mailto:gerv at mozilla.org>> wrote:
> On 19/03/15 04:56, Ryan Sleevi wrote:
> > Why 72 hours? Why not the OCSP max age?
> My view is that the risk analysis is not equivalent. Sane people may
> disagree :-)
Exceptional claims deserve justification.
> Also, the documented OCSP max age is not the same thing as
> what people use in practice. Several CAs have mentioned that they use
> lower numbers. Therefore one could see the higher number as "looser
> security than we currently have /de facto/".
This doesn't change the ability of those same CAs from being able to issue certs at a shorter period. For example, if they refresh their OCSP responses every 24 hours, they could issue short lived certs every 24 hours.
It doesn't make any sense to argue that requiring the upper bound must not exceed the upper bound of OCSP is somehow different security posture.
> > 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 see that as a risk. My view was that if CAs have servers which go down
> for > 24 hours, I'd worry about their OCSP servers, never mind
> short-lived cert servers. Also, this seems like something the market
> could fix.
Who said anything about a CA going down?
This is simply about their ability to respond to these cert issuances. They could be fully operational in every other aspect, while still being unable to issue in the time you desire.
For example, consider the hypothetical best case, where they simply have so many certs to sign they can't sign then all in the same time. Or perhaps the CAs automated signing infrastructure has hiccups, while all the other operational capabilities remain unimpeded.
I cannot see any benefit to requiring the shorter time and leaving it inconsistent with OCSP. If it's because you believe OCSP times are too long, then let's call a spade a spade and have that discussion, but it doesn't seem anyone wins today by having them be inconsistent.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public