[cabfpub] Short-Lived Certs - the return
sleevi at google.com
Wed Mar 18 21:56:55 MST 2015
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'd rather see us match the OCSP time, allow sites and CAs to experiment
(CAs can certainly use less; this is JUST the upper bound, and there's no
security *loss* by matching the OCSP upper bound). 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
On Fri, Mar 13, 2015 at 4:40 PM, Gervase Markham <gerv at mozilla.org> wrote:
> On 10/03/15 11:14, Jeremy Rowley wrote:
> > *_Short-Lived Certificate_*_: An end-entity Certificate containing a
> > validity period of 72 hours or less and where the Certificate is issued
> > by the CA within 24-hours after the nonBefore Date listed in the
> > Certificate._
> In my proposal, at least, it was 73 hours, and the CA was supposed to
> issue around 24.5 hours after the notBefore date they were using (or, to
> put it another way, set notBefore to 24.5 hours before the issue time).
> This would make the lifetime of the cert for clients with accurate
> clocks just over 2 days, with an expectation that it would be replaced
> after 1 day.
> If you say "within 24 hours", a) that means they can't do 24.5, and b)
> it means they can do 0, which gives a 3-day lifetime, 50% longer than my
> So I'd write:
> "An end-entity Certificate containing a validity period of 73 hours or
> less and where the notBefore date listed in the Certificate is set to
> between 24 and 25 hours before the time of issuance."
> Public mailing list
> Public at cabforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public