[cabfpub] Short-Lived Certs - the return

Doug Beattie doug.beattie at globalsign.com
Thu Jun 11 11:54:37 UTC 2015

Hi Eddy,

While Revocation can take place immediately, the BRs only say that you must update your cert status every 10 days.  CAs can opt to do this much more frequently, and most/all do.  The same is true with short validity period certificates; CAs can opt to issue them with or without CDP/AIA, or set the validity period shorter than the upper bound being proposed for this ballot.  We're setting the upper bound, not mandating the validity period.

The ability to use short-lived certificates without CDP/AIA is going to be up the eco-system you're using them in.  If the relying party needs to check the revocation and it can't, then the certificate will not be of much use anyway.  This ballot will enable browsers and other applications that process SSL certificates to start considering if/how they want to handle them.  I don't expect all the CAs to immediately start issuing short-lived certificates immediately.


From: Eddy Nigg [mailto:eddy_nigg at startcom.org]
Sent: Tuesday, June 9, 2015 3:37 PM
To: Doug Beattie; CABFPub
Subject: Re: [cabfpub] Short-Lived Certs - the return

On 06/09/2015 10:26 PM, Doug Beattie wrote:
Browsers can check, or not, the status of SSL certificates today and they can also change the rules for shorter validity period certificates as they see fit, that is outside the scope of the BRs.

Right! I'd prefer to keep it this way, the same way we can't mandate browsers to perform any sort of

  The purpose of this discussion/ballot is to enable the issuance of SSL certificates and not require the CA to set up revocation services.

Well, that's the problem I basically personally have with it.

By selecting a sufficiently short validity period we can "revoke" certificates more quickly than is currently mandated.

I don't think so, rather the opposite. Revocation can take effect immediately for anybody that doesn't have a cached result already in the software which means that the minute a revocation response is set to revoked, a compromised certificate becomes (commercially) less interesting.

Of course for specifically targeted attacks this is no true, which however requires quite some controls over the victims network. It's still a lot more difficult than with a certificate without any revocation pointers.

Browsers might also change their expired certificate warning to that of a revoked certificate.

I believe that's a different discussion altogether.


Eddy Nigg, COO/CTO

StartCom Ltd.<http://www.startcom.org>


startcom at startcom.org<xmpp:startcom at startcom.org>


Join the Revolution!<http://blog.startcom.org>


Follow Me<http://twitter.com/eddy_nigg>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150611/b72b8dc0/attachment-0003.html>

More information about the Public mailing list