[cabfpub] Short-Lived Certs - the return

Ryan Sleevi sleevi at google.com
Thu Mar 19 15:54:15 UTC 2015

On Mar 19, 2015 6:19 AM, "Gervase Markham" <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.
> Gerv

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...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150319/7a8de939/attachment-0003.html>

More information about the Public mailing list