Root Causes 377: Is CPS/Issuance Misalignment a Revocation Event?

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  How you doing today, Jason?

• 

  Jason Soroko

  Doing great, Tim. Glad to be here with you and we're both fired up today.

• 

  Tim Callan

  We are fired up because things continue. So there's a couple episodes that we talked about in the past. If you haven't listened to them, after you're done with this episode, go back and listen to them, but one was called Drama on Bugzilla. Another one was called the Bugzilla Bloodbath, and they've both been up just in the last few weeks and this craziness on Bugzilla continues.

• 

  Jason Soroko

  Let's hear about it, Tim.

• 

  Tim Callan

  So, what I want to focus in on today - - there's multiple things going on. It's nuts. I've never seen this much activity on Bugzilla. But what I want to focus on today in particular, is the question of whether or not CPS misalignment between your certificate issuance practices and what your CPS states you do, number one constitutes an incident and number two, or number two, constitutes certificate misissuance, and number three, requires a revocation event. So that's what I want to get into today.

  So, a little bit of background, your CPS, your Certificate Practices Statement is a statement that every public CA must have that is publicly available that explains what you do as a public CA and there are a variety of aspects that you cover, and you talk about how you do validation and how you do DCV and how you run your infrastructure and how you, etc. and you've got all of these things in there. And that's your Certificate Practices Statement. That's you saying what your practices are around certificates and it's a public facing document so that any member of the public, such as an academic or a watchdog or a journalist or a concerned citizen, can go look at what you're doing and scrutinize the public CA’s behavior and the reason this is important is because the CA's of course, are stewards of the public trust, and as such, they are expected to meet certain standards and requirements. Now, your behavior against the CPS is audited in your Webtrust audit. So an accredited Webtrust auditing firm looks at your practices and determines whether or not they match your CPS and a mismatch between your CPS and your actual practices is a problem, does show up as a problem in your Webtrust audit, and could conceivably get you a qualified opinion on your audit. So, you know, that's there and that's a mechanism and then the last part to probably clarify about the CPS mechanism is public CAs also maintain a historical record of their CPSs.

  So I can go back to any point in time. If I want to go back to 2017, you know, April 12, 2017, I can see what the CPS was on April 12, 2017. So I can match practices back to the time period in which a certificate was issued. And this is very important because practices evolve over time. They change either because the rules change, or they change because CAs figure out they're doing something wrong and make it right. Or they change just because CAs find ways to get better or just find ways to change their practices that are still in alignment with requirements but are working better for them or their subscribers or their relying parties. And so all of that is the reason we have a CPS infrastructure, and it goes all the way back to the 1990s and as part of the core of the concept of the web PKI and public trust. Does that make sense?

• 

  Jason Soroko

  It sure does, Tim. I've been around an awfully long time. I do know that choosing what is in your CPS is as important as anything else you do.

• 

  Tim Callan

  Heck yeah. Yeah.

• 

  Jason Soroko

  It is. And as a public CA - times infinity, essentially, because it's what you agreed to do.

• 

  Tim Callan

  Right. And it's what you're telling the public you're doing. And so it would be just like any other promise I made. If I were making a promise publicly about my behavior, and I was in a contract as a result of that promise, the fact that I made that promise, and I actually follow through on the promise I made is part of the contract being good and valid. So the same thing happens here, right? There's a contract between the public CA and the subscribers and the relying parties and the subscribers and the relying parties need to know - need to be able to know. They don't all individually know, but they need to be able to know what the CA does, or someone acting on their behalf needs to be able to know so that we can ensure that our CAs are following practices that were prepared to trust. And that's what a CPS does. Part of what's going on in the Bugzilla bloodbath right now is that there is at least one bug - I think it's one bug at the moment - that is misissuance due to CPS and practices misalignment. And it's a non-trivial number of certificates. It's almost 10,000 certificates. And in particular, this is a case where there was a misalignment between a published CPS and the actual practices and that has caused a large number of certificates to have been issued according to rules that did not match what was in the CPS. Now, in the case of this particular bug, the issuance practices themselves absent the CPS mismatch would not have constituted misissuance. However, they didn't correspond to what was in the CPS, and that, according to the rules in black and white, constitutes misissuance. Does that make sense?

• 

  Jason Soroko

  It's misissuance.

• 

  Tim Callan

  Right.

• 

  Jason Soroko

  Period. Yeah. It is. And that needs to be taken really seriously, Tim.

• 

  Tim Callan

  Yeah. And this comes up. Like this comes up. We ourselves have had to do this in the past, where we've discovered that exact scenario, where Sectigo has discovered that we had certificates that were issued according to the rules of the CA Browser/Forum and were completely compliant and completely safe in every other way, but they didn't correspond to the CPS, and we had to go revoke those certs. And we had to put up a Bugzilla bug and do all of that stuff, which we did under those circumstances. And, this goes on. Like it's not the most common Bugzilla bug, but it's not so rare that it's a weird head turner when it occurs. This is the kind of thing you just see once in a while. And as of such, it could have just been a non-event. But here's the wrinkle. The CA in question is contending that because they have updated their CPS and therefore if they revoke and reissue these certificates, that the new certificates will be exactly the same as the old certificates and therefore, that revocation is not required.

• 

  Jason Soroko

  That kind of goes against the whole purpose of the CPS at a given point in time.

• 

  Tim Callan

  So you see their argument, right? Their argument is, I'm going to blow up your cert. I'm going to give you another cert. The cert I'm going to give you is going to be the same in every way as the cert I blew up, therefore, no good is done and subscribers and potentially relying parties if there's an outage suffer. Therefore they're suffering without benefit. Therefore, it's a bad rule, and we shouldn't do it. Right?

• 

  Jason Soroko

  Wow.

• 

  Tim Callan

  Now, I think there's two things to unpack here. And the first one is, is it a bad rule? And then the second one is, regardless of whether or not it's a bad rule, should we do it? So which one do you want to start with, Jay?

• 

  Jason Soroko

  The first one first.

• 

  Tim Callan

  Okay. Is it a bad rule?

  So I think that that is fundamentally a very a poor argument. I think it's an unsustainable argument, that if you're being intellectually honest, you can't look at and contend. And the reason for that real simply is because if you have a certificate, and it is issued outside my CPS, and I update my CPS, and I revoke your old certificate and I give you a new certificate, those two certificates are not identical. They absolutely are not. They are unidentical in several ways. They have different serial numbers, for example, but the way that is probably most important that they're not identical, is they have different not before dates. The not before date is when the certificate is first considered valid by a piece of software that's looking at it. If I take my operating system, and I move it back in time to before a certificate was issued, and I go to a website and I try to attack that certificate, I'm gonna get an error, right? Because it's not before. And that is important, because as I said in the beginning, the not before date, tells me which CPS was in effect when the certificate was issued.

• 

  Jason Soroko

  That’s a really good point, Tim.

• 

  Tim Callan

  Right?

• 

  Jason Soroko

  We spend so much time in this podcast talking about the not after date, like - - a huge amount of time. We very rarely talk about the not before but here's the exact example of where it's important.

• 

  Tim Callan

  Absolutely. And so the whole point of CPSs, the whole point is transparency. And if we didn't have a need for transparency, we wouldn't need it at all. All these mechanisms would be different. And the reason for that is so that a watcher can go review a CPS and people do. It's rare. It's not every consumer, but it shouldn't have to be every consumer. And there are people who do and when there are problems like this, they will come to light as happened in this case. And so the fact that I'm going to update my CPS to something that's compliant with current rules, and then contend that old CPSs, that old certificates that were issued prior to that update, that somehow someone is supposed to figure out that that old certificate issued prior to that update matches the practices that are in the post updated CPS, not the pre-updated CPS is just patently absurd. Of course not. Absolutely not. And I don't think any serious intellectual in this business could look me in the eye and contend that somebody should be able to do that. But that's essentially the contention that's being made.

• 

  Jason Soroko

  It is, Tim. Look, I'm going to mention this once and I think we can move this what I'm about to say to another podcast but there's a lot of elephants in the room with us here, Tim.

• 

  Tim Callan

  Oh, yeah.

• 

  Jason Soroko

  There's our herd of elephants in this room. And I just want to point out one of them.

• 

  Tim Callan

  Okay.

• 

  Jason Soroko

  And that one elephant is why? Why? What the heck is going on? And I think I know what it is. I have identified the elephant and it's this. We live in 2024. This is when we are doing this podcast right now. And misissuance for various reasons is inevitable. We're not calling out anybody for oh naughty you for doing misissuance. That's not even the issue. The real issue here is, why is it so painful in 2024 to deal with mass revocation. And that's another podcast for another for another day.

• 

  Tim Callan

  I want to record that podcast. I think that's an important one for us to talk about. So let's just give our listeners a teaser. Guys, expect that one to come, too. And we will do that for sure. And we will give you that.

  So the second point - - the first point was, you know, should these certificates - - is this a good rule that says that you can't just update your CPS? And the answer - - I'm 100% confident is yes, that is a good rule. Right? The good rule is that if you're misaligned with your CPS, those certificates are bad. They're misissued, and they should be revoked. But even if you felt that it was a bad rule to say that they were misissued, even then, they still need to be revoked for the simple reason that we need black and white rules. We need rules that anybody can look at and objectively agree on and the basic contention that's going on here is that someone as a public CA is going to say, oh well, these certificates are harmless. These are okay. This is a problem that doesn't really matter so I'm going to unilaterally judge that I don't have to follow that rule. And this is another point we'll return to in that episode that you and I are going to make because I think it directly leads into that conversation and my response to that is no. We have rules. And I've said this a lot in the CA/Browser Forum meetings, and I'm kind of a little bit famous for saying this, which is we have to follow the rules we set for ourselves. And if the rules we set for ourselves are bad, then shame on us. We have the power to change them. But if we just start ignoring the rules that we set for ourselves when we personally don't like them, then why do we have rules at all? And that's the other problem.

  The rules are black and white, They're clear. It is misissuance. Misissued certs need to be revoked. Depending on the nature of the misissuance, leave certs need to be revoked either within 24 hours or within 120 hours. That's all clear. None of that is subject to debate. It's all written in the rules. And if individual CAs just start declaring, well you know what, I'm not going to revoke these certs because I don't think it's a big deal. Or I'm not going to revoke these certs because I can't get around to it. That's a problem. And so, first of all, let's lock down the list, right? Is CPS an actual practices alignment an example of misissuance? Yes. Is it an example of an incident that needs to be codified in Bugzilla? Yes. Is it an example of certificates that need to be revoked? Yes. If you fail to revoke them within the timeframe is that a separate incident? Yes. And it's yes all the way down, and CAs who are contending otherwise, are just wrong. Just plain wrong.

• 

  Jason Soroko

  There you go. That's an unequivocal opinion. And, Tim, I'm glad you made it on this podcast. Look, I think you're right. I think you're right. And I think the only reason why this is painful, and I could be wrong, maybe there's other reasons, but I think in this next podcast we're gonna record, we're gonna get into the heart of why the heck we're having this problem and why we can't seemingly follow our own rules in the industry. What the heck is going on here?

• 

  Tim Callan

  All right. So, ooh, boy, that was fun. I got charged up for that one.

• 

  Jason Soroko

  I knew we were charged up, Tim. That was a great performance. Thank you so much.

• 

  Tim Callan

  Thank you, Jason. And this has been Root Causes.