Root Causes 459: 2024 Lookback - Shortening Certificate Lifespans & DCV

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

January 24, 2025

2024 set in motion major changes for certificate lifespans and DCV. In this episode we discuss the Apple 47-day proposal, stepping down certificate term, public versus private CA use cases, DCV reuse periods, MPIC, WHOIS, and other topics.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe've been doing a series of 2024 look backs, and I don't know how we don't talk about shortening certificate lifespans and DCV.

Jason SorokoWell, we got the Apple proposal in 2024.

Tim CallanWe sure did. Very concrete, very detailed, real dates. Different, I would say, from the directional guidance that we had gotten from Chrome previously. I look at the Chrome Moving Forward Together pronouncement as a statement of intent, a statement of philosophy, and if you will, a North Star. Look, everybody says Chrome. This is where we got to go as an industry. I look at the Apple pair of GitHub repos, the first one and then the amended one based on feedback, as saying, okay, knuckles are cracked. Here's how we're going to get there.

Jason SorokoI think we've talked about this before, but if you're listening to this episode and I really hope those of you who are watching our look backs are looking for some real substance here. Let me give it to you, if you haven't heard it yet from us, this right now.

If you heard about Google's 90-day, which is what Tim just was just talking about, and then you hear about Apple's proposal of 200 and all the way down to 45 you think, what's with all these numbers? It's all around that the value of 90-day anyway. It’s just slicing and dicing based off of that. So if you think about it, like Tim will tell you, a one year certificate, it's not one year. It's 398 days, because there's some forgiveness for pragmatic reasons to make sure that you get the full value of one year, plus an ability to renew and deal with problems and it's a very pragmatic way that the industry works. So when Google said 90 days, they were just saying something that was already a lot of CAs already issued 90-day certificates. The problem with a 90-day certificate, Tim, is that you don't get the full value of a 90-day. Therefore Apple saying 100 days. You get 10 extra days of grace.

Tim CallanIt's not really 90 days. It’s once a quarter. This is one of the things, if you think back to old episodes where we talked about 90 days, one of the things I pointed out is, well, you can't use four 90-day certs to cover the year, because 90 times four is 360 and there's more days than that in a year. So 90-day was always kind of a little bit of shorthand, and without criticizing a little bit of sloppy talk. We probably all always should have been saying quarterly or every three months, because that captures the real intention. So you're touching on, I'd say two other important things about the Apple proposal.

Number one is, again, very pragmatic and considered. Why was the first stepdown 200 days because that's a six months cadence, plus some some wiggle room.

Jason SorokoThat's for those of you who can't deal with 100-day certs immediately.

Tim CallanLet's break it into two things. One is the precision of it. To say, instead of just calling it 180-day cert and being back in the same boat, Apple, called it a 200-day cert.

Jason SorokoIt’s a six-month cert.

Tim CallanSo it can be a six-month cert. They made it 100-day cert, so it can be a three- month cert. They made it a 47-day cert, so it can be a one-month cert. So someone had thought through what is going to have to happen to really do this in the real world. It was pragmatic, and it was considered at that level, and it was a proposal that was designed to be implementable. That was the first thing we noticed about the Apple proposal.

The second thing we noticed about Apple proposals, which is what you're getting to, Jason, which I think is incredibly important, is the step down. That's the major initiative here is to say we're not going to leap directly from 398 days to quarterly. We will have a step down process that will get us to where we need to be over the course of several years and what that does is that makes the whole thing much more implementation friendly.

Jason SorokoFor those of you who are in environments where a quarterly certificate works just fine, I think during the 200-day certificate period, it would be prudent to take the option of a 100-day certificate and start cycling it every 90 days. For those of you who, oh my goodness, I still have to do it manually because of some thing, well, you've got your half a year certificate.

Tim CallanYou’ve got your half a year certificate for a year. Again, I think that that was deliberate and considerate, which is, okay, we're gonna put them on a six-month cadence. It's gonna be a shocking wake up call for some people. Then they will be motivated to do the work they should have done anyway. But, in the meantime, we're not going to break them. So when you look at the step down, that says to me that that's what the step down is about, is to light a fire under the Luddites without breaking them.

Jason SorokoThat is exactly what it's for. It's motivating without breaking everything. That was the big fear. If we were gonna go straight to 90-day, oh my god, everything was gonna break.

Tim CallanPeople are imagining waking up one morning and I can't bank online, and I can't pay my taxes, and I can't et cetera, et cetera, et cetera. The step down goes a long way, miles, in terms of mitigating that risk. There may still be some, but I think we vastly reduce that negative consequence and vastly reduce that risk.

Jason SorokoI think the Apple proposal is so well considered. We should all be very pleased that we're working with people who are thinking through it so well.

Tim CallanI do expect that proposal or something that's materially similar to go to CA/Browser Forum ballot.

Jason SorokoTim, I cannot exit this episode on shortening of certificate lifespans without talking about some of the objections and just addressing them. One of the objections is, hey, there's places where certificates go where I can't automate. And I've heard some of those places being like load balancers. And my argument is, well, then you're just not aware of the some of the automation technologies that are available.

Tim CallanSo a big thing that happens with a lot of the objections, because we saw firestorms on places like Reddit when this first came out, and you would see people coming up and saying, I can't automate this platform. I can't automate that platform. I gotta do this and that. Then other people would jump in and say, well, here's how you automate this platform. Here's how you automate that. I think you've seen that there's this assumption built into a lot of working on the ground IT sysadmins that they can't do this kind of automation when really they can. Maybe it's because the last time they looked into it they couldn’t do it, or because they're assuming, maybe they never really looked into it. But I think we see a lot of that going on.

Jason SorokoTim, I think there's a second category of objections that I want to address. And that is, people who are using publicly trusted certificates for purposes of things such as client authentication - -

Tim CallanWhere they really shouldn't be.

Jason SorokoWe've got a whole episode coming up where we're going to talk about Google's Moving Forward Together blog that came out in October that actually addresses this, and you guys need to prepare.

Tim CallanFor sure. That is another one where I think that objection has occurred frequently and that response is exactly right.

Now the last objection is stuff that legitimately you can't automate, most of which is either homegrown or unsupported platforms technology. And the response to that is, if you're using platforms and technology that are not automatable, then ultimately you have a business continuity, a robustness and a security problem that badly needs addressing, and it needs addressing anyway, let's kill two birds with one stone.

Jason SorokoEvery certificate has to be a managed certificate. That's not just the CA saying it. That is the root stores absolutely saying it, because if there's a certificate that's been misissued by any of the CAs for any reason, that certificate needs to be revoked. If there's a key compromise - -

Tim CallanLet’s talk about key compromise. Does anyone get into debates about misissuance. Key compromise. If bad guys have your private keys, they have your private keys. The math is the math. The bad guys are going to do the bad things, and they're not going to hold back because they feel sorry for you. If you cannot cycle those certificates out, you're just a sitting duck. You have to be able to. It is a must.

Jason SorokoEvery certificate needs to be a managed certificate. If I could just put that on a loop and repeat it 100 times in one podcast, I would Tim. I think that's the message all of you, all of you, need to be listening to.

Tim CallanSo connected to the shortening certificate lifespans also there was a DCV step down. This is very important, because one of the other things we've talked about a lot is the browser's desire, in the world of TLS, I think correctly, to marry certificate ownership to domain control in a very tight way. I'm not going to go through the math. I've done it in other episodes. But you could get a legitimately issued - you could be owning a legitimately issued public certificate today for a domain that you had not controlled anytime in the last two years. And that's just not all right. And so, we see accompanying the cert lifespan step down, we see a DCV reuse period step down, going down, ultimately to 10 days by 2018. That is also a major change in a year of major changes to DCV, a year where MPIC was passed as a requirement, and work started to happen, and it's going to flow into hard requirements next year, where CAs are going to be expected to do it and act on the results. Then it's going to phase up in its impact over the next several years. So a year of MPIC, a year of deprecation of who is as a source for email DCV. So we're removing who is as a source for email DCV. That's been around since the very beginning. That's one of the oldest things we've got in the WebPKI, and a strong move toward complete deprecation of email-based DCV at all. So all of this stuff has been going on in 2024. Big year for DCV reform.

Jason SorokoSo Tim, let's back up and talk about one of the reasons why we trust this whole ecosystem. It comes down to me to three things. CA/Browser Forum BR rules, of which you're a big piece of. CA/Browser Forum BR rules, number one. CT logs, number two. I would say the one thing that needed to be shored up, just because there's threats and there's better thinking, was DCV, and I think that those are the three legs of the stool that the reason why this ecosystem is trustable and why it works. And I think that this latest set of 2024 shoring up of DCV, of all the things you just said, I think we're exiting 2024 in a good place.

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!