Root Causes 313: SSL Revocation Reason Codes

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  Today we’re going to talk about revocation.

• 

  Jason Soroko

  Good ol’ revocation.

• 

  Tim Callan

  Good ol’ revocation.

• 

  Jason Soroko

  That’s a tough subject sometimes, but here we go.

• 

  Tim Callan

  We’ve talked about it in the past. I want to focus in on something very specific, which is back in 2022, Mozilla, as part of its root program requirements – this is not a CA/Browser Forum BRs thing - this is a Mozilla thing. So, Mozilla as part of its root program requirements began to require that CAs include a reason code, I believe it’s in the CRL, whenever they revoke a public TLS certificate. I thought we’d explained, the reason codes, what they are, talk about some reason codes that are expressly forbidden, and maybe talk a little bit about the back story behind this.

• 

  Jason Soroko

  The back story is most interesting to me, Tim. Let’s hear it.

• 

  Tim Callan

  One, two, three, four, five specified reason codes, when you revoke a certificate, you should use one of these five reason codes, if they’re applicable. They allow for the possibility there could be a revocation that is none of these reasons, and they tell you what to do there, but let’s start with these.

  First is keyCompromise. That makes good sense, right? “The certificate subscriber must choose the keyCompromise revocation reason code when they have reason to believe that the private key of the certificate has been compromised, i.e. an unauthorized person has had access to the private key and the certificate.” That I think surely is just about the most defensible and important reason to revoke certificates, and definitely we want one for that.

• 

  Jason Soroko

  This is interesting because I don’t think people think of many other reasons other than that. People might ask what other reasons are there? But there are.

• 

  Tim Callan

  Sure, exactly.

  The next one is called affiliationChanged. “The certificate subscriber should choose the affiliationChanged Revocation Reason Code when the organization’s name or other organizational information in the certificate has changed.” The idea here is that in a good world of PKI hygiene, we understand that certs exist for a certain amount of time and that information sometimes changes. Sometimes a company gets acquired or they rebrand themselves or they change their legal name, etc., and this isn’t going to, by amazing coincidence, perfectly line up with the actual information in a cert. The industry recognizes that over time, these things will true up on their own, so there isn’t an obligation necessarily to revoke here. However, people can, and people certainly may want to, especially if they want the information in their certificate to match the information they’re saying they are to the public, and so, under those circumstances, you would use the affiliationChanged Reason Code as a legitimate reason to be revoking your old certificate.

• 

  Jason Soroko

  Right on, Tim. I would think that this doesn’t apply to DV certificates. Is that right?

• 

  Tim Callan

  There’s no guidance here that says these can be used for certain certificates and not for others. That’s not written into the policy, but I agree with you. It seems to be a non-sensical for DV cert. So, presumably that would only occur in the scenario of an OV or an EV certificate.

• 

  Jason Soroko

  I think Mozilla’s wording here, “This option does not need to be made available by CAs who only issue DV certs that do not include any subject identity information.” So, that’s a sometimes choice by the CAs and it kind of is based on my question about DV certificates. It depends on how the CAs set up your DV certificate as to whether or not it applies, would be my guess.

• 

  Tim Callan

  The third one is called superseded. “The certificate subscriber should choose the superseded revocation reason code when they request a new certificate to replace their existing certificate.” So, this is in a “replaced” kind of scenario. For whatever reason you’re supposed to use superseded. Now, if somebody has a keyCompromise and they do a replace, I think it’s preferable to use keyCompromise. But if you're replacing it for some other reason, then you should use superseded instead.

• 

  Jason Soroko

  For this one, I don’t know how often it’s used, but I know that it’s not often used when it could be used, which is – it’s quite common to replace certificates ahead of their actual date. That’s true for one-year certificates. It’s very true for 90-day certificates, and if you’re replacing a certificate at the 60, 70, 80-day mark, before the 90-day expiry, then you could issue this superseded revocation, but it’s very rarely done.

• 

  Tim Callan

  Yeah, I can see that.

  Next is cessationofOperation. “The certificate subscriber should choose the cessationofOperation Revocation Reason Code when they no longer own all the domain names in the certificate or when they will no longer be using the certificate because they’re discontinuing their website.” This makes good sense. This is a cert for a domain. I’m not using that domain anymore. Let’s say I sold the domain or gave up rights to it, and there’s still a cert hanging around. I don’t like that, so, I’m going to go ahead, and revoke that cert. That would be cessationofOperation.

• 

  Jason Soroko

  So, Tim, this is a reminder of course that it’s not the CA that’s going to be issuing this revocation request. If that’s discovered, the onus is on the owner of the domain and in my experience, the owners of the domains typically won’t issue a revocation for this, even if it is true. So, again, I don’t know how often that particular code is issued, but it’s, um …

• 

  Tim Callan

  Yeah. I don’t think this happens much in reality.

• 

  Jason Soroko

  No.

• 

  Tim Callan

  I think people just don’t worry about it. They don’t buy the new cert when the time comes, and the old cert expires on its own, and ultimately, this is why, like, if we could count on 100% revocation of certs once they were no longer used, then certs wouldn’t have to have expirations. I mean, the expiration mechanism fundamentally is built into certs to account for things like people don’t revoke certs when they’re done using them. That’s exactly why it’s there, so that all these things clean themselves up over time. That’s an argument for shorter-lived certs, of course, and I think we should return to that topic. But let’s finish this list.

  The last one is privilegeWithdrawn. “The CA will specify the privilegeWithdrawn Revocation Reason Code when they obtain evidence that the certificate is misused or the certificate subscriber has violated one or more material obligations under the subscriber agreement.” So, this is, the certificate is being used on a phishing site kind of scenario. Things along those lines that cause privilegeWithdrawn.

• 

  Jason Soroko

  Yes. That makes sense. Again, a probably under-utilized reason for revocation for sure.

• 

  Tim Callan

  Yeah. And then, I said there are some that they don’t want to use. So, here are some of the reason codes that actually – these are reason codes that are in RFC 5280 that, and historically CAs might have used because there’s just a big ol’ list of reason codes that someone came up with somewhere along the line, and part of Mozilla’s policy is don’t use these reason codes. So, these are the reason codes that we specifically should not use.

  First one is unspecified, and what Mozilla wants you to do is instead of using the unspecified Reason Code, they say don’t have one at all. Omit that value entirely.

  The next one is cACompromise, and the point here is they say the cACompromise Reason Code is used to revoke a CA certificate like an intermediate. It should not be used on end entity certificates. Using CA Compromise on an end entity certificate is fundamentally wrong. It misunderstands where things fit in the PKI chain, in the PKI ecosystem.

  Then there is certificateHold. They do not want to use certificateHold. Once upon a time, people would do things like use Suspend Mode in OCSP and things along those lines. They don’t want certificateHold to be used.

  removeFromCRL is a reason code, and here, I’ll read this out loud. “The removeFromCRL Reason Code may only appear in delta CRLs and indicates that a certificate is to be removed from a CRL because the certificate was expired or was removed from Hold.” So they want that to be used in a specific way. And again, it shouldn’t be a Revocation Reason Code for a Leaf Cert that’s being traditionally revoked.

  And then, lastly, this one is aACompromised. AA stands for Attribute Authority, and the aACompromised Reason Code is inapplicable in the TLS scenario, and that’s because it’s used for attribute certificates when aspects of the attribute authority have been compromised, and this isn’t an attribute certificate.

  So, there you go. All those are also explicitly forbidden because Mozilla is of the opinion that using them as a Revocation Reason Code for a Leaf Certificate would be inappropriate and non-sensical. And then we’re given that list of five, and there is acknowledgement of the fact that there could be another reason, in which case a reason code is not to be used.

• 

  Jason Soroko

  There you go, Tim. That goes into a long history, too. Some of those codes are quite old. They go right back to the beginning of time. And a lot of even the ones that are still authorized to be used aren’t used much at all. So, it does come down to the keyCompromise, and I don’t see much else out there.

• 

  Tim Callan

  Yeah. So, why is Mozilla doing this?

  First of all, it’s just sort of a general instinct to clean things up, and Mozilla makes the point that there never was any guidance or policy around this, and every CA just kind of made their own decisions about what to do with reason codes, and they would have different policies about why to use a different reason code in different circumstances. Many of them just didn’t use reason codes at all or whether a reason code was used or not used, it might be the exact same circumstance, and it might be used sometimes and not used other times because of the way software was written or systems were implemented or who knows. Different CAs might have different interpretations of the same thing, and then, their policies and interpretations might also change over time. So, something that’s revoked last year for Reason Code A, this year might be attributed to Reason Code B. And so, I think the Mozilla team – I’m channeling them a little here, but I think I’m getting this right – it caused the Mozilla team to feel like this is valueless information. Like, we can’t do anything. We can’t learn from this. We can’t make the web PKI better because when you look at these reason codes, they just don’t tell you anything that’s concrete or actionable or reliable or consistent. And so, what Mozilla is, I think, attempting to do is to put a certain amount of evidentiary rigor in place here in the hopes that reason codes will become a source of actionable information for improving the health of the web PKI ecosystem.

• 

  Jason Soroko

  Like a lot of things that are going on with the CA/Browser Forum, Tim, that you’ve informed us about through time on the podcast, there is a general reckoning going on, on a lot of things, and it’s a slow process but it’s a good process, and this is a part of it. Revocation is important.

• 

  Tim Callan

  Yeah, and you know, I think there’s a lot of things from the history of the WebPKI that were very squishy and were very individual in terms of their interpretations. Like, back in the day before the BRs, CAs actually considered their practices to be very secret and very proprietary. And they didn’t actually tell people what they did. And so, and it was a hard thing emotionally for a lot of CAs, I think, to go through the process of saying, no, we’re going to make this open because they felt like they were protecting it by keeping it secret and this sort of information wasn’t shared and wasn’t worked on. And one of the things that you and I have seen and we reported, we just recently did an episode on some research that was done using the Common Vulnerability Database. Right?

• 

  Jason Soroko

  Yes.

• 

  Tim Callan

  And there’s where you have a consistent – whether there’s reporting or bias or something in there – at least you have consistent set of criteria you can apply. You can put that across a mass of things and try to look for trends and compare and stuff. Prior to this, you can’t do that with Revocation Reason Codes because they’re all over the map. But, now I can imagine some Ph.D. candidate somewhere doing their primary research, looking at Revocation Reason Codes and looking for trends and patterns and things along those lines that talk about how revocation is used in the entire web PKI ecosystem. And research like that, you don’t know exactly how that stuff is going to benefit the world, and Mozilla wants to encourage people thinking in those terms, I think.

• 

  Jason Soroko

  Geez. I’d even like to see Master’s Thesis level work on this. I think somebody in graduate school needs to grab that and start to look because with this kind of uniformity of logic in place, you can now start to do studies, as you say, Tim. Great idea.

• 

  Tim Callan

  Time trending is going to be tough because this isn’t very, very old, but that will become available as time goes on. Right now, you could take a snapshot and start to do analysis around that, and there might useful information there. How does it vary by geography? How does it vary by use-case? How does it vary by certificate type and certificate term and things along those lines? You could see that starting to come into play. That’s part of the ecosystem. Not something that probably your average SSL user is going to bump into, but it is part of what we all as an industry are using to examine and govern and improve our ecosystem.

• 

  Jason Soroko

  That’s great, Tim. Great information. This goes right into the insides of how things work and the machinations of certificates in the SSL industry, so, really cool.