Root Causes 359: 90-day SSL Won't Affect Organization Validation Periods

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

February 2, 2024

With maximum 90-day term coming for public SSL certificates and DCV reuse also moving to 90 days, we explain why we do not expect a similar reduction in the reuse period for organization validation.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe have spoken a number of times on a number of episodes about the announced, and I dare say inevitable, move to a maximum public’s term for SSL certificates of 90 days. And this was announced in March of 2023 and over the course of the 10 months since then, we've explored it and discussed it in a number of aspects. And one of the questions that I get once in a while that seems worth bringing up today is if we go down to 90 day certificates, does that mean that I'm going to be going through a full organizational validation every 90 days or less? And this is an important point and it's worth laying out what I believe is going to happen, what I think the experience is going to be and why.

Jason SorokoIt’s an interesting topic, Tim, because obviously, I think everybody who is a practitioner within this is probably hoping very, very much so that the validity period for those domain scopes and those validation types are not going to go down to 90 day. I think that's the hope.

Tim CallanAnd in the interest of not burying the headline, yes, I believe that that will not go down in scope. So let's start there. If that's all you're looking for, you can turn off the podcast and go back to whatever else you're listening to.

But let's talk about why I believe that. So first, a little bit of background on this, which is, it's not an absurd question, because one of the things that was announced unambiguously by the Chromium Root Store was that they also intend to reduce the maximum domain control validation, aka DCV reuse period, to 90 days.

So they're envisioning a future where a TLS certificate is at most 90 days in length, the public root TLS certificate, and DCV also is at most 90 days old. So that's what they're looking for.

So then at that point, you go, well, the certificate is capped at 90 days, the DCV is capped at 90 days, seems likely that organizational authentication is capped at 90 days. But the purposes for these things are different. And that's the important point. They want certificates to be short, because shorter certificates are safer. You and I like to rattle off the reasons shorter certificates are safer. We can do it on this episode, if we want, but we've discussed this a lot of times. Shorter certificates are just basically safer. And the shorter it is, the safer it is. They also want shorter certificates because of certificate agility. If you have certificates that are sitting out there for a shorter length of time in the world, then if some kind of change needs to occur, it is a shorter timespan before they have all aged out and you have only the new stuff. Without forcing revocation events and other things that are really nasty, that's a great way to make sure that your crypto adjusts in a very frequent, timely and agile basis. And so that's the point of a shortened certificate lifespan.

The point of a shortened DCV is to cause a closer marriage of the server certificate, the SSL certificate, with the domain. And the scenario here goes that I get a certificate for a domain, I give up or lose control of that domain, control of that domain goes to someone else, but I still have an active, valid, correctly issued certificate for a domain I no longer control. And that's disliked, for obvious reasons. If the point of the certificates is to say that this domain really belongs to this person, and it doesn't, and your system allows that that's a weakness in the system. And the shorter the DCV window is, the less opportunity there is for that weakness to occur.

So in terms of both of those things, you've got this really close marriage. Now, when you get to organizational identity, org validation is neither of those things. Org validation is doing something else. Org validation is telling you what this business is. There's not really an equivalent in org validation of giving somebody a new domain. Domain ownership changes. Even if ownership of an organization changes. If I buy your business or new private equity comes in and buys your business. It’s still the same organization. The org validation is still valid, it's just that it's owned by a different entity. It's unlike what goes on with a domain, where you've got to ask who's the owner of the domain, and where's this domain really directing. There's no equivalent of that in a business. Like even if your local bank gets purchased by a large national bank, it's still the same bank. When Flagstar got purchased by Wells Fargo, they didn't stop having Flagstar signs outside and the Flagstar.com website still works, and it just keep doing business with Flagstar. And the fact that they're owned by the larger company just isn't relevant. And so that need for the close synchronization of the cert and the DCV, or the cert or the organization, it's just a whole different animal. And there may be corner case exceptions, but there are extreme corner cases.

Jason SorokoLet me let me put my own language on this is just for the listeners. The durability is what's different, and what these things are most closely tied to. So the org validation, obviously, tied very closely to the organizational validation information, I think is, as you said, it's a highly durable item. And therefore, from a security standpoint, there's not a lot to be gained by validating more than a year and I really, truly believe that and I think you're right on the right path there, Tim.

And I think, though, that the domain control validation is far more associated with the actual certificate that is being issued. And so if that's the case, it is far less durable and why would you then say, alright, well, every 90 days, you have to do a DCV. And if you want certificates to be issued in less time periods than that, let's say you're issuing every 30 days, Tim, just as an example.

According to the to the rules, don't need to do a DCV every 30 days. I think what to do there is to say to yourself, that's not really a renewal. That's a replacement. And there is a difference. And I think that's the best way to think about it is in 90 days, you've got to renew. You have to renew at least every 90 days. If you want certificates less than that, then you're talking about replacement certificates to the actual certificate that was issued. And so, there really are apples and oranges in terms of the durability between the two concepts and I think you're dead right in saying DCV every 90 days, and hey, if it moves to 30 days or 10 days or whatever, you would probably move DCV down to that and yet OV/EV validation will probably stick at that one year because it is a durable concept.

Tim CallanAnd actually, OV validation is two years. Like according to the CA Browser/Forum rules, if you go two years without revalidating an organization. So already you see a disconnect and this is my second point. So the first point is, it wouldn't actually help. And it doesn't align to the very good reasons to make these other changes.

The second reason is, it doesn't align to the behavior we've already seen. We have seen certificates go down to one year in term. There was not a corresponding forced reduction of organization information reuse and so, that's already part of the track record of how we got here is we saw that happening in the real world because they do do different things. They accomplish different things. And there's a recognition of that. So the second way to go at it is to say, how does it correspond to past behavior? And past behavior indicates that there wouldn't be any pressure to move it down.

The third way to go at it is to say, well, what is the real behavior? And the real behavior is though we've seen very clear public statements from Chromium that they want to reduce the term of public TLS certificate and also of DCV, there is no statement from them that says they want to reduce the term of organizational validation. They have a page, they write these things out, it's well organized, it's thorough, it's very easy to read. It's a very well done page. It's not like there's any confusion on this point. It simply is missing from there. It is not a thing they've identified. We've seen public statements from Apple stating that they, too, are very interested in a shorter lifespan for a public TLS/SSL certificate. And again, no corresponding statement about organizational validation.

Jason SorokoI’m going to make a semi - a joke that's not a joke. Google's blog on this, or the Chrome root program is really what it is. I would say it's written kind of like the New Testament, the Bible. And I think that's how they almost see themselves as well. These are the words from God, and therefore you gotta listen. And anytime in the New Testament, something is completely left out, it's left up to interpretation. So Tim and I are here as the priests of PKI.

Tim CallanHere we are. We're interpreting. We're helping you to interpret. So, those are several different ways to go at it.

And then the fourth way to go at it - and this is the last one – I promise you - is to say, if you start thinking in a world of short term certificates, to some degree, you want to stop thinking about them as individual certificates and start thinking of it as a flow or an ongoing process. You get into an automated replacement scenario, as you said, replacement, not renewal. And let's say it's every 30 days, and every 30 days, the new cert is obtained, and it just goes on to the server and all of this happens through ACME or some other agency, and the whole thing is automated. It's done by computers. No human is ever installing anything. And under these circumstances, you start, you should stop thinking about them as individual certificates and individual events and start thinking of it as a continuity of certificate coverage for a certain server. And under those certain circumstances, when you start thinking about it that way, then it becomes clear that these ideas can be completely separated from each other. And if you imagine the logical extreme, again, we've already heard Chromium out there talking about they'd like to see the world move to 10 day certs. So if the whole world moved to 10 day certs, you and I don't think we’d be reauthenticating an organization every 10 days. And so once you imagine where this is going, and you start thinking about this as a process and a flow and a stream, rather than a whole bunch of individual events, then you start to imagine, ok, I have this flow, and I authenticate this flow, and then I'm good for it for a certain amount of time. And then I go back and I reup and I make sure it's all still current. And as you start thinking about it in those terms, once again, where it's going and the ultimate direction of where we intend to end fits much better with the concept of a decoupled disconnected timeline for organization validation than what you have for certificate lifespan or even DCV.

Jason SorokoCorrect. Absolutely correct. DCV is associated with the cert. OV/EV validation is associated with something very different and I think that that's the way to think about it.

I'd like to put one little asterisk on this Tim, which is the renewal replacement idea. I think that you're gonna start to see CAs, just by policy, start to ask certain kinds of customers, especially customers who are being helped by a third party to basically automate that certificate issuance, that deployment. And I think that even if it goes down to alright, well, I want a certificate every 75 days, then, if you're within that period of 90 days, and it's less than 90 days, you might still be expected to do a DCV in the other way of putting it is every replacement, not just renewal at 90 days, but every replacement, some CAs might start to ask for a DCV at those periods of time, because hey, all of our necks are on the line. We want to get things right. We want to make sure that you still have that domain and I think that that might be a prudent move, Tim. Just wanted to add that in.

Tim CallanAnd you can start to imagine things like you can also have automated DCV, let's say, through ACME. At which point, why wouldn't I start doing DCV more frequently? Why would I wait until the last minute? Why would I do DCV on day 89 and maybe something is wrong and I can't give you your cert? Why don't I do DCV every 60 days or every 30 days or every 5 days? I could see that happening as well and I think it makes a lot of sense and I think that's probably a future we have coming too.

So like I said, I get this a lot. It's at trade shows, when I'm talking to customers, when I'm giving a speech. It's a question that keeps coming up. And I believe very firmly that there is no interest, no pressure and no motion to change the organization validation reuse period anytime in the foreseeable future. It doesn't mean, maybe not true forever but for the foreseeable future, think the certificate term and DCV lifespans absolutely will be going down and we can think of those as separate things and kind of put them into separate categories.

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!