(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 31, 2016 Comments closed

What is Mozilla’s OneCRL?

in Industry Lowdown

OneCRL is part of Mozilla’s solution to certificate revocation.

Certificate revocation is one of the most challenging problems in internet PKI. Whatever system handles revocation has to be fast, reliable, accurate, and privacy-preserving; and it has to be able to respond to hundreds of thousands of requests in a cost-effective way.

So you may not be surprised to know that most of the current revocation methods we use are essentially broken. Progress is being made – there are some great technologies being developed that should work for the majority of situations. But getting the technical standard ironed out and then deployed on both client and server software is still quite a ways out (likely years before wide deployment).

But the industry can’t just sit on its hands while that happens. That’s why last year Mozilla introduced a revocation measure known as OneCRL.

OneCRL is based on Certificate Revocation Lists (CRL), a system designed in 2008 which failed as a broad solution to revocation. The main problem with CRLs was the scale of revocation – when CRLs were used to list every revoked certificate the files became too big and unwieldy – they couldn’t be efficiently downloaded or processed.

OneCRL fixes that problem by only attempting to handle intermediate certificates. These are certificates operated by CAs (Certificate Authorities) that issue the end-entity certificates used by individual websites (like the certificate we are using on this blog). Intermediate certificates can issue trusted certificates for any website, so dis-trusting them through revocation is extremely important.

The most troubling reason for revoking an Intermediate certificate is compromise of the CA or key, allowing it to be mis-used. These are the cases that get reported on in tech-blogs and have security professionals riled up. But revocation of intermediate certificates can also be a normal part of operation. CAs may “retire” specific intermediates because they no longer plan to use them, or have replacements for them (replacements which may be using stronger hashing algorithms or private keys). Or the CA may go out of business altogether. No matter the situation, it’s important that browsers stay current with their trust to reduce the attack surface.

Mozilla’s Firefox browser has used OneCRL since version 37, released in March 2015. Firefox regularly updates OneCRL in the background, on an almost daily basis, without the user needing to restart or update their browser.[1]

Shortly after OneCRL was implemented, it was used to revoke an intermediate certificate from Chinese CA CNNIC that was being mis-used. Mozilla is also considering using OneCRL for the revocation of high-profile end-entity certificates, in situations where the danger to the Firefox user-base is so great that they would need to be protected immediately.

Because of its performance and security benefits, Mozilla views OneCRL as a long-term solution for checking CA certificates. Google’s Chrome browser uses a similar mechanism known as CRLsets.

Improving Revocation

Mozilla has a “long-range vision” for revocation that outlines their ideal methods for revoking certificates. Like others in the industry (including the CA Security Council), their vision includes a very promising combination of technologies: OCSP Stapling with Must Staple, which will allow for both low-impact and reliable revocation.

OCSP Stapling is a method of distributing revocation information which can happen during the initial connection between the client and server. Must Staple is an addition to OCSP Stapling which makes it difficult for attackers to circumvent. We think OCSP Stapling is a great solution for revocation and I recently wrote a long-form post explaining why.

But even the “best” solution for certificate revocation will likely never be a single mechanism or technology, because one of the challenges of revocation is the huge range of reasons that warrant revocation.

An improperly issued end-entity certificate for a small website is not anywhere as dangerous as a compromised intermediate certificate. Given the real-world performance and bandwidth costs of distributing revocation information to the world’s computers, those two situations just can’t have the same response.

The future of revocation involves a combination of mechanisms and policies, each tailored to different situations. OneCRL will likely always be used because it is a great solution for revoking intermediate certificates.

[1] https://wiki.mozilla.org/CA:RevocationPlan#OneCRL

• #Certificate Revocation
• #Intermediate Certificates
• #OCSP Stapling
• #OneCRL