Podcast
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.
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?
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?
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?
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.

