Root Causes 283: Google Optional OCSP Proposal Clarified

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

March 6, 2023

In our episode 281 we reported on Google's proposal for optional OCSP. In this episode we correct some of our earlier reporting in that episode, including the use of CRL and the removal of any revocation requirement for SSL certificates of not more than ten days in term.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanThis is a correction episode. So, we put out our Episode 281 fairly recently, which describes Google’s proposal for eliminating OCSP from, as a requirement for public TLS/SSL certificates. There were a few details there that I actually spoke incorrectly about. They were in the proposal. I just misinterpreted what I was reading. Ryan Dixon of Google’s root store program was kind enough to point that out to me and thank you very much, Ryan. I appreciate that shout out to you and we just want to put up a quick episode and make sure that listeners understand the details of this correctly.

First of all, if we go back to Episode 281 real quick - at a high level, the proposal that OCSP can be eliminated as a requirement for public SSL certificates and the reason for that is because CRL certificate revocation lists can be used instead as a method of checking revocation. And the real quick story on the reasons for that is that there is a concern about privacy for OCSP certificates and that’s because if you are checking every domain that you are going to you can theoretically somebody sitting in the middle could understand where you are visiting and depending on where that is that might not be ok. That might be a privacy problem. So, browsers are interested in solving that problem and the proposal that Google is driving would be that OCSP would not be illegal but would be not required. Optional. For potentially all public TLS certificates.

Now the way this would – so, all that is well and good. Here is what was incorrect in the last one and I’m just gonna get it right. There is an element of this proposal that has to do with the duration of the certificate and the use of CRL and we will just say what the real proposal is here is that for certificates between the duration, the term, of 10 days and the maximum term 398 days, then there must be a revocation mechanism in place. And while CAs are free to continue supporting OCSP if they would like, they will have to support CRL for those certificates and what that does is that supplies the revocation mechanism that according to this proposal is considered to be sufficient – meaning that we could not support OCSP and it would still be ok.

Now, for certificates under or let’s say not more than 10 days in duration, no revocation mechanism need be in place at all. So, there does not need to be CRL. There does not need to be OCSP. And as we talked about, the rational behind that is that they are very short-lived and therefore, the risk surface if you will – the risk window – is short enough that in Google’s considered opinion, this would be an acceptable tradeoff and that the natural expiration of the certificate would take the place of revocation. Presumingly, you wouldn’t continue to renew the bad certificate would take the place of revocation in order to prevent the problem from continuing. And that is not exactly the same as what we described in our Episode 281. So, just want to make sure that is crystal clear.

So, does that make sense, Jay?

Jason SorokoIt makes sense, Tim. I think at the heart of it, the reasons why, I think we captured pretty well in our episode in terms of the – especially with respect to privacy and some of the other issues that you brought up again today. So, I think that the previous podcast still has some value, but we absolutely wanted to perform the errata especially because the people very deep into it very thankfully reached out to us to correct us. So, we really do appreciate that.

Tim CallanAbsolutely. And just as a little bit of background, again, the idea is that this would actually be brought forth to the CA/Browser Forum as a ballot that would modify the existing baseline requirements because and this is a good reminder – the BRs are requirements of the various major root programs. So, in their program requirements, they state you must follow the CA/Browser Forum baseline requirements, which means that any requirement in the baseline requirements becomes inherited into the root programs.

So, in this case, if we are trying to relax a requirement, we must change the BRs because if we don’t change the BRs then even if a root program says we don’t care, somewhere else in their program they have said – - in their rules they have said that you must follow the BRs and therefore, you do care. So, the proper process to do this with Google’s following is we remove that as a requirement or lax that as a requirement from the baseline requirements and what that does is that then frees the CA from that obligation to each of the major root programs. So this is the process.

We’ve seen in the past root programs have created requirements at the root program level. Probably the best example would be Apple taking everybody down to a maximum of 398 days for a public TLS certificate. But there have been other ones. And if a major root program makes that requirement, it becomes a defacto requirement for everybody. So, that’s a perfectly workable method for the browsers to increase the strictness of requirements, but if it’s the opposite, if they’re trying to loosen the strictness of requirements, then we’ve really gotta go in and change the BRs because otherwise the stricter of the two is always the one that the CA must follow. Does that make sense?

Jason SorokoIt does.

Tim, you’ve been in the BR Forum long enough, you work with these folks. I mean what’s the kind of timing of a proposal of this nature that it might go through?

Tim CallanWell, so there would be a ballot process. A ballot has not been proposed yet. Presumably, folks over at the Google root program are writing a ballot or at least have a good idea for what they want the ballot to say. That would be written. That would be proposed. Somebody would support that ballot. You need to have two members to put a ballot forth. Then there’s a discussion period and a voting period and that whole process takes less than a month. And then at the end of that, the ballot will have some kind of active date.

Now, where the ballot is a stricter requirement, normally the ballot is written with some time so that CAs can adjust. And if it’s a big deal, it might be a long time. If you look at the S/MIME rules, it’s nearly a year because there’s a lot of stuff you have to do to get in line. If you look at there were changes to code signing. It was a long time. It was nearly a year.

This is interesting though because this is a relaxation of requirements, which means that if you keep doing things the old way you are not non-compliant. You could keep right on doing things the old way if you want to and what that means is it gives every CA the opportunity to just change their own systems and processes to relax as it makes sense. And as such, I could see this going into effect much sooner – up to and including immediately. Because it doesn’t matter. If you are not non-compliant if you are not doing it, it just gives you an opportunity to modify your systems and push them live when they go live. That’ll really be a function of the ballot. As I’m not writing the ballot, I would just be speculating but, I think that kind of thing could be fast. And I would be surprised if they didn’t come forward with this ballot pretty quickly because I think this is something Google cares about. I think they’ve given it a lot of thought. I think they know what they want to do. They have a lot of clarity on that and, that root program acts decisively when they know what they want. So, I am expecting that to happen in this case. We will keep our eyes peeled. It hasn’t happened yet, but it will probably come fairly soon.

Jason SorokoFolks, certificate lifecycle management due to shortening lifespans due to things like this where, you are really inside the industry – even those of us who are pretty much inside of it – look how hard it is to even understand it perfectly clearly but I would argue that in this case for those of you wondering whether or not it’s still ok to ignore management on top of certificates, I think it’s coming time, Tim, when running SSL certificates at all unless it’s – even if it’s one – is going to require some kind of automation and certificate management.

Tim CallanAnd that’s a valid point, Jay. If we go back a little bit to what we talked about in 281, part of the motivation here – not the only motivation, the privacy motivation is very real but there’s also a widespread relief among the ballots which I think you and both agree with that shorter certs are just better. They’re just safer and as a consequence, they are more agile. There’s a lot of reasons why they are better and so the browsers look for every opportunity to encourage automation because short-lived certs, 10-day certs – can’t manage 10-day certs manually. You just can’t. People go on vacation; people get the flu; people get distracted. It just doesn’t work. So, if you are going to be running certs in anything remotely in that kind of timeframe, you have to be automated. And so, if we look at this, what happens – there is an incentive built in for the CA to encourage or operate in an automated system and that’s another piece of this. They want to systematically incentivize that the automated behavior inside of the system and when they see an opportunity to do that, browsers tend to take it. So, that is not the primary motivator here in my opinion but certainly a benefit that Google is aware of and wants to reap.

Jason SorokoPerfect. Hey, this is a great example, Tim, of the community working really well even to the point of making sure that we are putting out accurate information on the podcast. Thank you so much for delivering the errata and I got to learn something here today as well.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!