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.