Root Causes 292: Validation Data Reuse for 90-day Certificates

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  In our Episode 284 we talked about the coming requirement for maximum term of 90 days for TLS certificates. This has been an oft discussed topic in the last few weeks as it’s a big deal for a lot of people. As I’ve had a chance to talk to others about this, one of the questions that’s come up repeatedly, that my recollection is we didn’t cover in Episode 284, was what happens to data reuse? Validation data reuse. So, we thought we’d hit that topic specifically today.

• 

  Jason Soroko

  So, Tim, the hot burning question that I’ve heard myself a few times is, ok, I have completed validation for an EV certificate. I have completed validation for an OV certificate. If the maximum certificate lifecycle goes down to 90 days, which we know it will at some point, then do I have to revalidate every 90 days?

• 

  Tim Callan

  Do I get revalidated every 90 days? Yes, it’s absolutely the right question to ask.

  So, to do this, first of all, let’s start with a little bit of background. Let’s talk about what the rules are right now, and in order to do that I want to break this into two sets of validation information – what I’ll call DCV or domain control validation, which is authentication of the fact that the person who receives the cert is in control of the domain for which they received the certificate. So, that’s DCV or domain control validation. And then everything else I’m just gonna refer to as OV/EV validation. OV/EV validation. And what that means is that is all of the stuff that we do apart from DCV to validate the organization, its nature and the person who is receiving the cert on behalf of the organization. So, we are gonna put all of that together, lump it all into a single bucket that I’m gonna refer to OV/EV validation. Ok? And that’s gonna make it easier to discuss.

  So, today, the rules are that DCV and OV/EV validation both are reusable for 398 days, which is the maximum term that is allowable for a public TLS certificate today. And what this means pragmatically is that I can buy certs and renew them. Right? So, if I get a cert on Day 0 and the maximum term that cert may have is 398 days then that means as I’m coming up on the end of that duration, that term, and I want to do a renewal, data reuse is allowed, which means I get one renewal without having to redo validation. So, I get a cert for 12 months, 365 days, and then when I’m getting close to the end of it, I’ve got 20 days to go or a month to go on my cert, I buy the renewal. We tack that extra time on. So, now instead of 365 days, if there’s 20 days to go, let’s say it’s 385 days. I get another 385-day cert and I get that within the validation period and then a renewal of that cert would require revalidation. Does that make sense?

• 

  Jason Soroko

  Yes, it does.

• 

  Tim Callan

  Ok. So what happens in the 90 day certificate perspective? And now, again, like we talked about in Episode 284, a lot of this is interpretation. It’s looking at the things that Chromium has written in the Moving Forward Together page looking at the history inside of the CA/Browser Forum and interpreting what we expect based on that. So, I want to just give you that caveat.

  But if we look at the Moving Forward Together page, I want to read you a specific passage from this page. And this is down in the bottom. It’s the section that’s called Streamlining and Improving Domain Validation Practices. And again, if you want to look for this page yourself just do a search on the following phrase: “Chromium moving forward together.” If you search for those four words, it will be the first thing you see. So you can click on that and you will be right where I am.

  So down at the bottom it says Streamlining and Improving Domain Validation Practices. I’m gonna read from this:

  “The Baseline Requirements allow for the reuse of data or documents related to previously completed domain validations for up to 398 days. However, with the existing policy requirements in place, it’s possible for a CA to rely upon ‘stale’ information for much longer than this (i.e., a new 398-day validity certificate can be issued that relies on information that’s 397 days old).”

  So, if we unpack that first statement a little, what they are pointing out is, in principle, I could do DCV on Day 0 and that could be the last day that I own that domain. I could then turn around and sell that domain and there could be valid active certificates out in the world for that domain for a total of nearly 800 days. Right? 795 days later there could be still be an active cert that was considered legitimate even though 794 of those days ago, that certificate changed ownership. And their basic point they are saying is look, that’s just too long. We understand there will be some period of time where there might be a mismatch between active certs and domains but that’s just too long. It’s gotta be shorter. That’s the basic point that they are making there.

  So, if I move back to what they say as a result. “In a future policy update or CA/Browser Forum Ballot Proposal, we intend to introduce reduced domain validation reuse periods, along with a reduction of the maximum allowed TLS server authentication certificate validity to 90 days.” So, in other words, they make it explicit here that they’re going to offer, that they are going to use the same methods that we discussed in our Episode 284 about reducing the term of an SSL cert to 90 days. In that same action, whether that’s a CA/Browser Forum ballot or a root program requirement, they’re also going to bring DCV time down to that same 90 days.

• 

  Jason Soroko

  Alright. So, the certificate maximum lifespan is 90 days and the DCV goes to 90 days. Got it.

• 

  Tim Callan

  Correct. And we should expect that to happen simultaneously. So, whatever day the certificate maximum changes we should expect DCV to change the same day. That’s point number 1. And by the way, it is also referenced further up. That there’s a reference to DCV further up in this as well. So, it’s pretty darn clear that this is something that they are quite, quite, quite committed to. To doing as part of the 90-day certificate program.

  Now, however, you can read this entire page and you are not gonna see any explicit mention of what I’m calling OV/EV validation. Or OV/EV data reuse. It is simply absent from this page. Now I put it to you that if there were an intention on the part of the Chrome Root Store to similarly limit OV/EV reuse that we would expect a reference to that here. The DCV reuse is very explicit. It’s unambiguous. They’re very clear in spelling out what they intend. They’re very clear in spelling out why. They’re just very clear on the whole thing. And to completely omit another important set of validation rules that they do intend to modify and just to not mention them would be extraordinarily sloppy, not at all in keeping with what they are doing and not at all in keeping with why they created the Moving Forward, Together page in the first place. So, that strongly suggests to me that there is no intention on the part of Chrome to make a similar change for OV/EV validation.

• 

  Jason Soroko

  Right, Tim. So just a reminder to everybody, the current one year, or as you said, 398-day certificate lifespan, that would carry forward for OV and EV validation information.

• 

  Tim Callan

  Correct. That would be my expectation. Now there’s another point and another reason that I believe this is that we - - in general we have seen DCV treated differently from OV/EV validation in other ways. The most obvious of those is the required revocation period. In the event that there is a DCV error, revocation of the cert is required within 24 hours. In the event that there is an OV/EV error, revocation of the cert is required within five days. Those are different rules, and that is already establishing a precedent that inside of the BRs we can have different rules for different kinds of validation. And so I believe when I look at what I see here, I’m expecting that when we do see a ballot from Chrome, which we haven’t seen yet, but I’m expecting that the language of the ballot from Chrome will clarify that they are moving DCV to 90 days and will not do anything to EV/OV data reuse and that’ll be fine because we already have that precedent inside of the BRs today.

• 

  Jason Soroko

  Ok, Tim. That’s important information and I know a lot of you have been wondering about it because those of you are in this CA industry and interested in Certificate Lifecycle Management or are obviously consumers of SSL publicly trusted certificates, this is important news for you guys. So, there you go.

• 

  Tim Callan

  Yeah. This is very important. So, we go back to your original question and we say, ok, how does this all work in a world of 90 days? What happens?

  Well, first of all, let’s hope that you are automated. Let’s say that you are automated somehow. You are using ACME or you are using a CLM and your certs can be deployed in an automatic fashion. So you don’t have to go and deploy them every 90 days or maybe if you do, what do I do? So, I go ahead and I order an OV or EV cert the way I would today and I get a certificate, and then I can replenish those certificates in whatever timeframe or renew and replace them in whatever timeframe I think is appropriate. I think we talked about in our earlier episode that you are not gonna do it every 90 days because you don’t want to have a potential outage. So, let’s say you are doing them every 60 days or every 70 days or whatever cadence you are on. You can order the new certs. You perform DCV every time, which hopefully is easy. The new cert comes, you deploy the new cert and you don’t worry about your org validation for, probably if nobody changes it, it will be 398 days. That means if I can get through an original order and four replacements if I’m going up to 90 days or six replacements if I’m going every 60 days – every two months – before suddenly I have to go through another validation again. And I think that’s important because it removes a great deal of the potential pain from these shortened certificate durations. The Chrome Root Store isn’t doing this because they want us to suffer. The Chrome Root Store is doing this because they believe shorter lived certs are safer. And to the degree that they can bring about shorter-lived certs, which they believe are safer, without causing suffering, that is a smart thing to do. So, that’s what they are doing in this particular case. By allowing reuse of OV/EV data for the original time period, the degree of suffering goes down considerably while the degree of security risk goes down minimally. And so that’s good bang-for-your-buck math. And I think that’s another reason why I believe that’ll be the case because I think they’re going to look at it and they’re going to come to the same conclusion that I have, if they haven’t already.

  Based on that supporting information behind the idea of what I believe which is that you are gonna get your cert, you are gonna be able to run through however many updates you do in the next 398 days. So, in 13 months, you’ll be able to run through whatever you update cadence is and then at the end of 13 months, whether it’s 60 days or 70 days or 50 days or whatever, 2 months, and then at the end of that you’ll turn around and you’ll get another one. You’ll go through another validation and that will last you another 13 months and that’ll be the new going forward cadence for everybody.

• 

  Jason Soroko

  So, Tim, just like on the previous podcast where we talked about this 90 day announcement from Google, I think the conclusion then is the same, which is automation now becomes mandatory. I’ll flat out say that. Automation is mandatory as part of certificate lifecycle management. Remember that you won’t be able to automate what you don’t know what you have. So, therefore, other pillars of certificate lifecycle management become important. Visibility, discovery, and all these things that are not necessarily direct automation also then become important.

• 

  Tim Callan

  I agree with all of the above, Jason, and let me just put a little bit of emphasis on automation. You and I have talked about automation a lot and we often talk about automation of renewal, automation of deployment, but let’s put a particular bow on automation of DCV.

• 

  Jason Soroko

  Automation of DCV.

• 

  Tim Callan

  Right? Because you are gonna be doing that every 90 days so let’s make sure that’s automated.

• 

  Jason Soroko

  Yes. Automation of DCV. Automation of your renewal means also automation of your domain control validation. So, therefore, open protocols such as ACME, which Google does call out as being one of the many solutions that are out there but they do call it out. That automates your DCV or at least gets it to the point where it’s, you know, part of your process and therefore, it’s not forgotten about. That really becomes important. And I would say mandatory.

• 

  Tim Callan

  Yeah. And ACME does allow DCV. You can do DCV through ACME. So if you are doing ACME that seems like a very clear thing to explore as a potential path forward.

• 

  Jason Soroko

  You got it, Tim. Great information. I hope this answers the big questions.