Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) are important technologies that—with ongoing work to improve their operations—can continue to provide a foundation for online trust. However, recent efforts within the CA/Browser Forum and Mozilla’s decision to support “short-lived” certificates in future versions of Firefox have shined the spotlight on an innovation that can help expand the use of HTTPS and provide an alternative method to balance performance with security.

Performance vs. Security

Traditional online certificate checking involves CRLs and OCSP. Both processes work well but have limitations that can be offset with certain enhancements such as standardizing smaller-sized CRLs that Certificate Authorities (CAs) distribute, standardizing OCSP response time requirements, and encouraging server administrators to implement OCSP stapling.

There is not a standard size for a CRL file but best practices recommend CAs distribute several CRLs instead of just one to help reduce the size of each revocation list. Downloading a large CRL file or checking a CA database for the status of a certificate can take time, and in an online world where even milliseconds matter, site vendors don’t want to worry about users jumping ship because a large CRL increases page load time.

Leading CAs generally serve OCSP over the edge through globally distributed content distribution networks (CDNs), leading to faster speeds that fit with user expectations of nearly instant site load times. Leading CAs, such as DigiCert, focus on delivering the fastest OCSP responses so that sites using their certificates do not waste precious milliseconds when trying to make a secure connection. For example, on average, DigiCert OCSP response times (19 milliseconds) are nearly eight times faster than competitors (average of 144 milliseconds per chart below).

Additionally, OCSP stapling overcomes latency concerns by caching responses on the server for up to seven days and eliminating constant online status checks with CAs. All browsers support OCSP stapling. All major servers support OCSP stapling, although not all of them have OCSP stapling enabled by default.

Short-Lived Certificates

Short-lived certificates are an alternative to traditional certificate checking methods by shortening certificate lifetimes ranging anywhere from 24 to 72 hours. This shortened certificate validity period would make inclusion of CRL or OCSP information unnecessary, since any stolen or misissued certificates are set to expire before browsers would check for CRL or OCSP status and before a major attack could be completed. Because browsers do not have to check for certificate status, short-lived certificates enable faster web load times. Similarly, by not relying on receiving an OCSP response, short-lived certificates are not vulnerable to a sophisticated man-in-the-middle attack that would block responses. On the performance side, for many large consumer-facing sites, every millisecond matters, and the balance with security is difficult to reach with current methods. Short-lived certificates help eliminate this concern.

Recently, DigiCert introduced Ballot 153 – Short-Lived Certificates in the CAB Forum to officially endorse short-lived certificates; the motion was endorsed by Google and Mozilla. The ballot failed (CA votes: 4 for, 17 against, 5 abstained; Browser votes: 4 for, 1 against) with most of the opposition coming from a coalition of small regional CAs.

But the push for short-lived certificates has just begun. Mozilla has already implemented code in its latest Firefox release that supports short-lived certificates.

Short-lived certificates are not likely to be used on a widespread basis because they require sophisticated automation and frequent reissuance, along with a partnership between the company and a capable issuing CA, such as DigiCert. Large sites are more likely to use these types of certificates—sites where high performance is required and the balance with security and privacy controls are needed to help protect users. This is especially true in countries where governments may limit internet availability to block OCSP or CRL checks.

In brief, some of the reasons to use short-lived certificates might include:

• Smaller handshakes, with no call backs to CAs
• No online certificate status checks
• Certificate expiration within a few days, limiting the use of a compromised certificate in an attack

The CA community should remain flexible so that when new innovations are presented that can extend TLS protections to a greater number of users, such as in the case of short-lived certificates, they are ready to give them a try. Those reluctant to innovate should not be allowed to hinder the advancement of extending HTTPS protections to a larger user base.