Short-Lived Certificates

Bruce Morton

Certificate revocation is a current SSL industry issue. There are many causes to the problem. Some end-users do not have certificate-revocation checking turned on. Browsers support CRL or OCSP, but in some cases not both. The certification authorities (CA) may not provide reliable revocation responses. And what if there are no revocation responses from a CA; should there be a hard or soft fail?

One result is the CA/Browser Forum is looking into revocation to see what can be done to improve the situation. Another result is that the short-lived certificates are now being discussed.

A short-lived certificate is issued for a limited validity period, say seven days instead of one year. The certificate is re-issued every few days, so that the subscriber can update the certificate on their server on a continuous basis. The technical difference is that the short-lived certificate would not have any information about where revocation data can be found. If there is a breach that requires certificate revocation, then the CA would just stop re-issuing the certificate.

Revocation would be complete within the validity period of the last certificate issued. In this case, the period would be seven days, which is also the same validity period of a typical CRL or OCSP response. The result is 100 per cent revocation, as all browsers provide a trust dialogue on expired certificates.

A study has been prepared by a group of Stanford and Carnegie Mellon University researchers. Their conclusion was short-lived certificate complement the CRL by adding security when software updates do not make sense (e.g. mobile platforms), rebalances power between browsers and CAs and removes Google as a single point of failure. In the case where a CRL is not supported, short-lived certificates provides the security guarantees equivalent or better than OCSP. Short-lived certificates are fully backwards compatible, incrementally deployable, impose no performance penalty, and add another layer of protection to Web users.

The study authors reference Google and Chrome, as Google has declared that Chrome will not use CA provided revocation information.

Is this the answer for everyone? No, primarily it’s a solution for highly technical certificate subscribers with a high-value Web domain that can update their certificates on a continuous basis. It is unlikely that this solution will be implemented by smaller users until Web servers support methods to continuously update the SSL certificates or until Web-hosting providers support the solution.

You don’t have to worry about short-lived certificates yet. The CA/Browser Forum Baseline Requirements specifies that SSL certificates support CRL and OCSP. If the concept is accepted, I’m sure there will be a proposal to update the requirements to allow short-lived certificates.

Bruce Morton
Bruce Morton
Director, Certificate Technology & Standards

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

2 Comments

  1. Dave W August 24, 2012 Reply

    Can you explain more what the Stanford/CMU study means by re-balancing poser between the CAs and Browsers?

    • Author
      Bruce Morton August 27, 2012 Reply

      The power of revocation is with the CA. They perform the revocation and they provide the revocation status. If the CA’s revocation system is down then revocation doesn’t work. Short-lived certificates means that certificates are revoked when they expire. The CA just has to stop issuing certificates and they will be revoked within X days. The CA does not have to provide revocation information for the validity period of the certificate.

Add to the Conversation