Root Causes 281: Google Proposes Optional OCSP

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

February 27, 2023

In response to concerns about OCSP and privacy, Google has proposed removing the requirement for OCSP revocation checking for public SSL certificates meeting certain specific conditions. In this episode we go into the details of this proposal.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanIn our recent episode 272, we discussed the concerns that some people, including some members of the browser community are having about OCSP and privacy concerns associated therewith. And I posted that episode on LinkedIn and in a response to my episode, Ryan Dixon, who is in charge of the Google root program, actually posted a link to Google’s proposal to the CA/Browser Forum about making OCSP not be mandatory.

And so, first of all, thank you, Ryan, for making that available to the listeners so readily and easily. But, secondly, we thought, wow, this is great. Let’s follow up and let’s discuss this proposal in detail. So, I think that’s what we are going to do today.

Jason SorokoPerfect, Tim. We’ve been talking about all forms of revocation and how you do revocation checking. This goes right to the heart of the most recent talks around it and I think it would be good to get into the reasons why Google might be doing this.

Tim CallanAbsolutely. So, we focused in particular on the aspect of privacy which is a very big concern and it’s a major thing that lots of people are thinking about. There is just a little aside here that will mention, which is the Google paper does point out that there are some other benefits as well including the fact that it is very expensive to operate an OCSP infrastructure and therefore, it makes it harder for CAs to operate in general and that there have been some bugs associated with OCSP as well that could be eliminated in the event that the scope and impact of OCSP was limited or less focused. So, let’s kind of walk through this proposal and I’m gonna try to break this down in a way that makes sense.

So, the first thing probably to emphasize is it is not a proposal that we make OCSP illegal or eliminate OCSP or force CAs not to use OCSP. It is merely a proposal that says for certain certificates that meet the specific conditions that will be specified, which is they’re short-lived – and we will get into what that means – then OCSP responders are no longer required. So, one consequence of that would be if a CA wanted to have short-lived and long-lived certs both, then that CA would never really be truly free of OCSP. They would just be able to reduce the scope of what they need to provide OCSP for, which might still have benefits and it might be great. But that’s the first thing to bear in mind. It’s not a requirement that people move off of OCSP entirely. Rather, it’s an option that’s available to the CA and available to the subscriber. The certificate consumer who is going to use that certificate. So, that’s a very important point.

And the conditions under which the CA is allowed to issue certificates that no longer require OCSP responses, the main one is, as I said, short-lived. And the definition of short-lived here is not longer than ten days. So, if I want to issue you a one-day cert or a one-hour cert or a five-day cert or a nine-day cert, or a ten-day cert, that’s fine according to this proposal. As soon as I issue you an 11-day cert, however, that is not ok and that will require revocation checking. And, of course, the maximum duration would not change. At present it is 398 days according to CA/Browser Forum rules and, perhaps in the future that will go down. You and I have discussed and speculated that in the past and under those circumstances, that maximum day would be shortened but either way, that is a separate consideration separate and apart from this ten-day maximum for which a non-OCSP certificate is allowed.

Jason SorokoRight on. So, it’s all very logical I think in the way it’s laid out. I also think that it’s not putting an enormous amount of onus on the CAs to do something unnatural at this point. But I can also see though that this is a movement forward to short-lived certificates and getting away from revocation perhaps almost entirely at some point down the road, Tim.

Tim CallanAnd absolutely. And part of the trend of shorter-lived certificates for sure, first of all, because there is at least some kind of an incentive beyond what exists today for shorter-lived certificates to occur. If you are a CA and you would like not to operate OCSP for some subset of your certificates or conceivably all of your certificates, then you have a path to doing that. Which involves shorter-lived certificates, which is good.

And then the second thing that’s connected to that is if you are subscriber and you would like to preserve the privacy of anyone who is connecting to your server then you can do that. You have an option. You go to a short-lived certificate automated scenario where you are updating your certificate every week or ten days or whatever it is and as a consequence, no more OCSP will be served on that and therefore, you have the benefit of preserving that privacy for the subscriber. So that becomes a motivator on that side as well.

So, if you look at these two things in conjunction, you see it is raising the motivation at least to some degree across the ecosystem for more adoption of short-lived certs than there would have been otherwise.

Jason SorokoI’m just thinking about this, Tim, and in fact, Google does call this out in their proposal in the background and justification section for those of you who want to read it and I suggest that you do because it’s interesting. It’s well-written, too.

Tim CallanJay, I just had this thought. I will post this as a reply to my LinkedIn post when I put this up. So, if you are listening to this and you want to find that link, go to the LinkedIn post. My LinkedIn post for this episode and the link will just be right there. But go on, Jay.

Jason SorokoAbsolutely. I’m thinking background and justification I would almost want to use motivation here as well for everyone. Motivation for the CAs. Motivation for people who are hosting websites. Motivation even for people who are consuming the websites. Everybody has got a motivation here and I think that the motivation is there’s no contrary motivations. And let me explain.

If you think about just the OCSP in general. You’ve got the individual’s browsing history and the concerns about privacy regarding that are due to perhaps two things. One being the fact that logs can be breached which would then give you an idea of what the user was actually looking at. And then, of course, there is the other concern which is interesting in the industry. A lot of us don’t think about it for ourselves but it does have to do with things like subpoena. In other words, the logs exist therefore they can be subpoenaed out by law and your records are out there somewhere.

And then, of course, the other motivation for the CAs, very specifically, is there is a lot of cost associated with doing OCSP responses. So if you think about it all around and if you include just what you just said about the fact that the website servers, the people who are actually handing out the websites also can then say, hey, I am protecting your privacy by using short-lived certificates. That’s pretty in the weeds. I don’t know if anybody would ever advertise that but it may just be. You never know. I think if you look all the way around to all those three main players in the simple web browser to web server relationship that also includes the CAs themselves, everybody wins by going to the short-lived certificates and getting away from revocation in total.

So, there’s a lot of motivation and that’s why I think it’s a good proposal. It’s a good bridge proposal into the future is force anybody to anything. But I can see the writing on the wall and because the motivations are positive on all sides, I can see this eventually happening.

Tim CallanAlright. So, now I said that short-lived certs was a requirement but it’s not the only requirement.

The other main requirement here is that the CA must have very, very current CRLs, which is to say they must be issued daily or more frequently. So, there’s always a current CRL available since that basically is going to become our surrogate for OCSP. So, you need to have that available daily or more frequently. And daily, of course, is an interesting timing because for different kinds of events with certificates, there are different periods of mandatory maximum revocation time. So, depending on the nature of the problem with the certificate you can have revocation times of different time periods. The most common one is a five-day revocation period. So, once the CA become aware of a certain kind of problem with a certificate, typically there are up to five days. 96 hours to revoke the certificate. However, sometimes you run into a different kind of requirement and you get a one-day, a 24-hour, revocation period.

So, that one day is significant. One day, 24 hours. So, if the CRL is being issued daily then there is daily revocation information available. So in the event I do have to revoke one of these ten-day certificates, every day the revocation information becomes available. At least in principle. And so, that would be point number one.

And then the other point that’s very important is Google does point out in their, their paper here, that it is not necessary that the complete CRL is published daily concluding all certificates, rather you can what they call shard your CRL. You can break it up in various ways into smaller pieces and there are no real dictates around how you would shard it. So, you could in principle, shard it quite a bit. And I could imagine having a very sharded CRL strategy so that the CRLs are not themselves prohibitively large and the cost of serving those CRLs does not itself wind up being equally expensive as performing OCSP. Which would eliminate one of those benefits. So, to the degree that CAs can be smart about how they shard their CRLs and automate that whole process and issue those every day, then that is an essential part of making this whole thing work. So, that’s the other main thing.

And then probably the last thing to be aware of is, according to this proposal, which is not gone about or anything, so this isn’t coming as a sure thing, but it is an important player, who made this proposal. According to this proposal, the effective date would be January 15, 2024. So, a little over a year from now. And I think what that would do is that would give everybody else in the industry time to catch up because this is a pretty big deal. If you are gonna stop offering OCSP for your ten-day certs but you are gonna offer them for your longer certs and you are gonna do something with your CRLs about it and blah, blah, blah. Like there’s some non-trivial process and engineering work that is required here for a CA to be able to honor this. So, they’ve put some time in while everybody works on that. And that’s a common practice with major significant important proposals in the CA/Browser Forum is there’s usually some time of time gap to give the CAs an opportunity to catch up.

Jason SorokoFair enough. It’s very fair in that way and I like that a lot, especially with something that really fundamentally changes the way people are operating and has a lot of impact on cost and setup. These things, even if Google or anybody else were to write this proposal, there’s a lot in here that you couldn’t snap your finger and make a change anyway. So, it makes a lot of sense for how that process works and it’s good.

Tim CallanSo, again, let me emphasize that this would only apply to short-lived certificates. CAs to the degree that they issue certificates that are longer than that up to and including the maximum length, 398 days, would be expected to continue to offer OCSP under those circumstances. And likewise, for certificates that you presently have in the active certificate base, certificates that were issued prior to such a ballot passing that were lingering because they were running through their natural lifespan would also be expected to have OCSP coverage. And there’s no getting around that. You can’t shorten that by let’s say revoking the certificates because after all, that’s the point. So, there would be nothing for it but just to wait for them to expire out.

So hypothetically, if you are a CA and you wanted to completely and utterly shut down OCSP, you wanted to go dump a bucket of water on that server, what you would have to do is you would have to wait until the last of your certificates that was more than ten days in term had expired and at that point and only at that point would you be able to go and pull the plug on that thing and shut off the red light. And I imagine what would be a more likely scenario would be that CAs would continue to offer OCSP because it would be a hard thing to turn around and declare that 100% of your subscribers had to suddenly go to short-lived certificates. Because some may not want to. And so probably in the real world in terms of a commercial CA probably what you would see is you would see a reduction in time or a reduction in the size of the footprint of what needed to be done with OCSP as some portion of your certificates moved to these short-lived sub ten-day certificate lifespans.

Jason SorokoAbsolutely. There’s even, Tim, the piece on the CT logs in here as well in terms of having to shard off the CT logs because of the fact that a CA with ten-day certs, of course, are gonna have a lot more records.

Tim CallanAnd just to clarify, so Google has a section at the end where they talk about the fact that, they recognize the fact that there might be things in the ecosystem that aren’t ready for this and are gonna break if we do this and basically saying we have between now and whenever such a ballot has passed and an active date comes into effect to make sure that that stuff isn’t breaking anymore. Go on, Jason.

Jason SorokoThis is just in reflection, Tim. You can definitely see how they are trying to do it carefully. They are trying to do it thoughtfully. They are not trying to break anybody here but this is where they might want to go and I’m having a hard time coming up with a reason why not.

The only reason I can come up with is what you just said – people who may not want to go to ten-day certs. Well, who are those people? And I bet you those are the folks who are on spreadsheets managing their certs.

Tim CallanAnd let’s break that down a little. First of all, you’ve got people who are fully automated. They are using ACME or some kind of automated solution. Those people you’d think you ought to be able to handle a ten-day cert if you are fully automated. And that seems like that would be good and motivational and that those users, those subscribers would want to move to that model and also those CAs would want to move to them. You could imagine, for example, Lets Encrypt saying, ok, we are gonna go entirely to ten-day maximum certificate duration and we are gonna stop serving any OCSP at all and, yes, we are gonna go in fact pour a bucket of water on the server. And the good news for them is that in their case they would only have to wait 90 days for all those certs to term out because they’re already running shorter-lived certificates. So, you could see that. You could see lots of sub services where the same kind of thing happen. So, for instance, another company that is mentioned in the same breath as Lets Encrypt a lot is ZeroSSL. ZeroSSL, again, it’s all ACME. It’s all automated. I could imagine ZeroSSL going down doing the same thing. Saying we are only going to be ten days or less and basically for the exact same reasons.

Then you get basically owned CAs. CAs that are owned only for the use of the company that is actually the CA and, in particular, I’m thinking of AWS and Amazon Trust Services, Google Cloud Platform and Google Trust Services. And in both of these cases these are public CAs that do not give any certificates to anyone but themselves and they run them entirely in an automated fashion inside of their large robust public cloud agile platforms and you could easily imagine those services saying I’m gonna go to ten-days or less and once again, I’m just gonna shut down the OCSP service in its entirety.

So, there are lots of places in the ecosystem where this is very viable. There are entire Certificate Authorities who can probably walk away from OCSP entirely in not a hugely long time period. A little over a year. Then there are people like Sectigo that serve a very broad set of users and use cases and under those circumstances, as long as some of those users for whatever reason do not want to go ten-days certs – which is probably to your point, Jay – because they are not automated, then they are gonna be stuck with OCSP and that means that the CAs who want to serve them will also be stuck with OCSP for at least a subset of their active certificates. And that will probably linger.

No matter how much you and I tell the automation story, there are plenty of people who don’t hear that story or don’t absorb it or don’t prioritize it. And we bump into these people over and over and over again in our jobs. So, we know that that’s gonna be a long path. However, whatever it is, a 1,000-mile journey starts with a single step. So, this is great. This is a step and we get going and the more steps like this occur the more it will help the whole world move in this direction.

Jason SorokoIt’s a positive step all around. There’s multiple reasons for it to be considered positive. It’s just those folks who are not automating that I can see being that long-tail that as you say will be with us for a while. But this is interesting, Tim, and, like I said, if you are in the industry at all, read the proposal. It’s almost like looking into the future. Thanks, Tim, for putting that up.

Tim CallanI will put it on my LinkedIn. There will be I’m sure much discussion about this. Both in the meetings and CA/Browser Forum meetings which aren’t open to the public but also on publicly available bulletin boards. I believe that there will be a lot of discussion here and that the main thread of the dialogue will basically be present for anybody who is interested enough to monitor and watch and, if this is an interesting topic I would recommend you do that. And to the event that this gets traction and becomes some kind of ballot, obviously, we will come back and let you know.

Jason SorokoThat’s great. Well, thank you, Tim, for explaining it really well in terms of the machinations of it. I still can’t do anything but reflect on this and because of the fact of where it shows us going and how positive it actually is. So, thanks for that.

Tim CallanI think some form of this proposal I predict will pass a ballot. Because, as you said, there’s no real down side. The closest thing you come to a downside I would think is revocation information still equally available. So, in the event that I revoke a certificate – let’s think of a one-day revocation event. Let’s say that my private key gets stolen and I say, oh shoot, private key was stolen. Big problem! Revoke! Revoke! Revoke! Now in an OCSP scenario, then instantly everybody knows.

In a CRL scenario, then everybody knows in upwards of 24 hours depending on when that CRL was published and in the event that software support for CRL is imperfect, which is a question that Google raises, possibly longer including for the full duration of the cert. Now granted, the attack surface for that or the risk aperture for that goes down to ten days, which is much less than 398 days. Nonetheless, it is still much more than one day. And so, that would be as far as there is a down side, I think that would be the single sole downside. However, it’s easy to imagine you say, well, loss of key or DCV failure or the other things that require a one-day revocation are exceedingly rare and in the event that they happen, the risk aperture is still at only ten days and we believe that it is a net positive for the overall health and security of the ecosystem by protecting privacy and getting these other benefits. And that would be the argument. I think that would be a credible argument. I think that that’s something we could debate but you can’t at least dismiss that argument off-hand – out of hand. And so, that will probably be discussed. I’m certain that will be discussed in a number of places by a number of people and for a ballot like that to pass, the community as a whole is gonna have to get comfortable with that argument. But I think they will and I’m predicting that at the end of the day this is something that everybody will feel good about and will actually pass a ballot and then CAs and supporting ecosystem will all start driving toward being able to work in this new world order.

Jason SorokoTim, in the private trust world, the idea of giving up revocation for the greater good and just having the short-lived certificates, that debate has kind of come and gone.

And so, I don’t think anybody is denying the fact that a perfect world would include a revocation check. But in some ways, sometimes it’s just too expensive or it’s not possible at all and it’s better to just have the certificate environment in general just functioning as is without it.

Tim CallanAnd the other point on that is revocation itself is imperfect. OCSP is imperfect. There are scenarios where the fact that a cert has been missed or has been revoked can be missed by the client. If the OCSP response just doesn’t come back, the client won’t know that it’s been revoked. And that can happen. It’s the internet packets fault. And so under these circumstances, a revoked certificate could still be honored. However, an expired certificate is expired under all circumstances. So, when you look at it that way, that becomes another argument to say that in a way this is stronger and more secure than a revocation checking scenario.

Jason SorokoJust the idea of short-lived certificates, Tim, and I’m trying to recall whether we did a podcast on this but we could probably spend an entire podcast just laying out the positive attributes to a shorter-lived certificate.

In both public and private trust scenarios.

It’s just – it’s good. It’s good all the way around. And I’ll tell ya, in a world where we very well may need crypto agility in other words, to be able to reissue certificates very quickly especially with the quantum apocalypse coming, who knows what may happen with RSA one day even before quantum. Who knows? I just think shorter-lived certificates just make a lot of sense in a lot of ways.

Tim CallanAnd, Jason, that’s awesome. You just hit all the buzz words right there. Like in one sentence.

Jason SorokoThat’s my job.

Great. That’s my job. Alright. Well, I think that’s probably it for this topic. We will continue to track this. There will be more coming on this topic I’m quite confident, and we will come back and we will tell you as it happens.

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!