Podcast Feb 10, 2025

Root Causes 466: Apple Moves 47-day Ballot to CABF Vote

Apple is proceeding with a ballot that eventually will shorten SSL certificate maximum term to 47 days. Accompanying the ballot, Apple released a statement explaining its intent with the ballot. In this episode we unpack its statements.

Original Broadcast Date: February 10, 2025

Tim Callan · Root Causes 466: Apple Moves 47-day Ballot to CABF Vote

Episode Transcript

Lightly edited for flow and brevity.

Tim Callan

We're here at Toronto Session, Season 3. So Jason, we've talked a lot on the podcast about shortening certificate lifespans and about the Apple proposal that has been a proposed ballot, and it's now gone into discussion period. As of taping, we’re in discussion period. By the time we air, it will probably be in voting period. But when Apple pushed this out, this ballot - and this is the ballot that steps down to 47 days, which I think we've discussed - when Apple pushed it out, they also pushed out a rather detailed explanation of their motives and reasoning, and we thought that it might be really useful for listeners and watchers of the show, who don't necessarily read the kinds of things that I read at my job, to just hear what Apple had to say.
Jason Soroko

I think a lot of people are curious about it. When people from slightly outside of WebPKI talk to me about this, this is the kind of stuff that they want to have interpreted for them.
Tim Callan

Here's what I'm going to suggest. It is two pages of text. What I'm going to suggest is, why don't we read a little, unpack it, read a little, unpack it, read a little, unpack it.

It's broken into three sections. It says purpose of ballot. SC-081 introduced schedule of reducing validity and data reuse periods. Then it's broken into three sections - background, approach and benefits. So I'll start with background and we'll make it as far as we make before we have to talk about it.

Background. This is all I'm just quoting from Apple. The WebPKI is a complex, integral and dynamic ecosystem underpinning the foundational security properties of the internet. Since the TLS baseline requirements per NTBRS were first adopted in the CA/Browser Forum and subsequently incorporated into various root programs as an interoperable basic threshold for participation, the topics of certificate validity and data reuse periods have been a near constant point of discussion, in large part because of the cascading impact changes to these aspects of the TBRs has on the overall health and stability of the WebPKI. The focus of this ballot is a set of changes to the TBRs. The TBRs address requirements only for certificates which are “intended to be used for authenticating servers accessible through the internet”. Certificates which match or are compatible with the profiles described in the TBRs can be and are used for a variety of purposes not addressed by the TBRs but these use cases, such as private PKIs are not directly in scope of the TBRs, nor the changes proposed in this ballot.

Basically, they're just trying to define the scope and the scope is what we normally would call public SSL certificates, or WebPKI SSL certificates. They're trying to clarify. We're not trying to change private root. Do whatever you want on private roots. It's your PKI architecture. We're also not trying to change any use case that is not the WebPKI.
Jason Soroko

I find it a little bit surprising that people who are outside of our industry but are very interested in cybersecurity in general, when they hear about the shortened certificate lifespan proposal, whether it was Google's original or Apple's or anyone perhaps in the future, I sense confusion that they think it means all digital certificates.
Tim Callan

I actually think that's understandable, because one of the things that's gone on is all certificate lifespans have been shrinking. Because the reasons for shorter certificates, which you and I have discussed, we laid out our seven reasons in an earlier episode, are pretty universal, and they really apply to any kind of certificate, public or private, whatever the root case, whatever the form factor. We've seen certificates getting shorter across the board. Not just SSL. S/MIME has gotten shorter. Is getting shorter again. Code signing is likely to get shorter. When you see this trend across multiple kinds of certificates, I think you can start to lump them all together. This is Apple trying to be really clear about what we're talking about and what we're not.

Continuing. The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such a way as to allow for certificate replacement within any given 24 hour period. While this requirement has been part of the TBRs since its first adopted version, the reality of certificate management practices, whether policy, practice or terminology, has not necessarily reflected such an expectation. Nonetheless, this is, and has been, the requirement presented by the TBRs.

What's Apple telling us there? Apple is saying, one of the motivators behind shortening certificate lifespans is this abject lack of agility is what you and I usually call it. Certificate agility. This abject lack of certificate agility causes many problems - one of which is you can't respond to a revocation incident. The way the lack of agility manifests itself in the real world is all of these del rev bugs that we had in 2024, where you get these organizations and institutions saying you can't revoke my certs because if you revoke my certs everything's going to go dark, and people aren't going to be able to bank online, and airplanes are going to fall out of the sky. You got CAs going, well, I don't want to make airplanes fall out of sky, so I guess I'm not going to revoke your certs. This is Apple coming back to say, listen, there is an expectation that this stuff needs to be done. We’re not going to accept, and I can't do it on a 200-day cert, or a 47-day cert, when, in reality, you need to be able to do it in 24 hours.
Jason Soroko

I think we were sitting right here in December recording another set of podcasts where we were talking about, isn't it wild that we live in an age of hyper automation, agentic AI, and what is it about certificates and the lack of desire to automate? I just don't get it.
Tim Callan

Exactly. This has been true in a lot of both Apple's and Google's rhetoric, which is, number one, we're not going to accept that excuse, number two, to turn around and say, well, it's kind of a chicken/egg problem. The reason you guys won't automate is because we accept that excuse, and if we stop accepting that excuse, you're going to go automate.
Jason Soroko

I do want to say I've seen comments and I've heard people say, Tim and Jay, and people like them, they're just shills for people who sell the automation software, and they just are relishing in the fact that shortening certificate lifespans is good for their business. It's like, guys, did you hear what Tim just said? He was reading a statement that wasn't written by Sectigo. It was written by Apple who is running a root program. These changes that are trying to motivate people towards automation are coming from the root store programs. We are responding as an industry to it.
Tim Callan

The root store programs are huge on this. Automation is the thing that root store programs want the most. Like, if Genie came out of a bottle and went to someone who owns a major root store program and said, I'll do one thing to your industry. What do you want me to do? That's what they're gonna say. It's universal certificate automation.
Jason Soroko

We don't typically talk about selling software on this podcast, because we want to stay away from that. But the reason why we do sell that software, Certificate Lifecycle Management, is because of this. If we didn't do it, Tim, the root store programs would not be very pleased with us.
Tim Callan

No. Yes. Well, in fact, it's a requirement. There are requirements coming in that CAs, and right now it's a requirement on new CAs, but eventually it's going to be requirement on all CAs that you have to have automation support, or they won't add your root.
Jason Soroko

That's how fundamentally important it is.
Tim Callan

I mean, that's how the root programs think about it. You see that here. There's a whole paragraph dedicated to that here.

Next section, called Approach. It’s one paragraph long so we'll do the whole thing. The other thing I'll say is, there's end notes. There are 10 end notes on this. I'm not going to read the end notes because it's going to be too hard. You can go read them yourself if you want.

So Approach. “Reducing certificate validity and data reuse periods involves changes that extend beyond the CA/Browser Forum, and it is challenging to predict all potential impacts. Because we need to address known unknowns as well as unknown unknowns, it's important to provide mechanisms for one, substantiating previously unassessed risks, and two, altering course when necessary. Similarly, in order to shift more unknown unknowns toward known unknowns and known knowns over time is useful to ensure broad awareness prior to changes taking effect. In an effort to meet these goals, this ballot proposes multiple changes over an extended period of time with the intent of setting reasonable and attainable timelines upfront, while still allowing for future alterations if determined to be necessary.“

So probably the first thing is, let's clarify these three terms Apple uses:
- An unknown unknown, a known unknown and a known known. An unknown is something where it's something that matters, that's salient and important, and you don't have full understanding of it. You can categorize that into two things, and this isn't a new concept to Apple, which is known unknowns and unknown unknowns.
- A known unknown is there's creatures in the sea we haven't discovered yet, and we're aware of that, because the ocean is big. In some places, it's really deep, and we're aware of the fact that there are creatures in the sea that we haven't discovered. That is a known unknown.
- An unknown unknown is something that completely surprises you. You say, holy smokes. We didn't even imagine that. That's an unknown unknown.
Then a known known, of course, is there's millions of creatures in the sea that have already been codified, and they have Linnaean names, and we know perfectly what they are and where they fit in the family tree. That's a known known.

What Apple is saying, and I think they're correct, is we need a process of discovery, where these unknown unknowns get discovered, and they turn into known unknowns, and then they get looked at, and eventually they turn into known knowns. That this is a healthy, normal process in any technology ecosystem, and that we're going to have to do that here.

The first sentence says, reducing certificate of validity and data reuse periods involves changes that extend beyond the CA/Browser Forum. They're saying other stuff is going to be affected. We're aware of that. What we've done is we've built a gradual progression in so that the entire affected ecosystem, or every affected ecosystem, has an opportunity to uncover and solve these things before we stampede directly to 47-day certificates.
Jason Soroko

A known known, even though it's not dealt with yet, we talked about that last two months ago, when we referred to publicly trusted certificates used for purposes of client authentication. We know that that's a case. What you're saying is, there are many of these cases. Not all of them are known yet.
Tim Callan

There will be. And as there are, they'll come up. For viewers who don't remember, the actual step down process is that first they go to maximum term of six months. They sit there for a year, then they go to a maximum term of three months. They sit there for a year, and then they go down to 47 days, which is supposed to be the one month cadence. So, the idea is that something will come up and it will start causing us heartburn when we have to do it every six months, but it won't break us. Then we'll say, whoa, problem. It's an unknown, unknown. Then we got a year to get that rectified before we go down to three months. If it's something that doesn't come up on the six month cadence because that's still acceptable, then you repeat that same thing again. But when it drops from six months to three months, you go, whoa, problem. It's causing me heartburn. Now you have another year to fix it. That's the idea. By stepping down over the course of three years, it's a pretty significant project. What it does is they want these problems to be uncovered and dealt with at a pace that doesn't cause stuff to stop working.
Jason Soroko

Notice what it doesn't say, Tim. I think that's what's most interesting to me, is it doesn't say, oh, well, when we find an unknown, we're just going to reverse and stop the process.
Tim Callan

Absolutely. I think that's a huge one. Say, listen, folks, this train's got to leave the station. It's leaving. If we all work together and get on board here, it can be a great, smooth, flawless, error-free train ride, or if you're not ready to get on the station and you have a bad day as a result, like it's not in our control but wouldn't it be better if we all had a good day?
Jason Soroko

For those of you who are using publicly trusted certificates for inappropriate reasons - client authentication - places where a private CA would be better, and all the other cases that we're going to be discovering through time, you're going to have to deal with that. Three years sounds like a lot, but it's not. I think when you come up with the entire list that we're going to come up with.
Tim Callan

Three years is enough time, but I wouldn't just kind of while away.
Jason Soroko

That's the point. There's no room for laziness in this process.
Tim Callan

It's time to get going. Three years is enough time if we get going. Three years is not enough time if we sit and stare at our fingernails for a year. Then we'll be in trouble.

All right. Benefits. “The value of continuing to reduce maximum certificate validity and data reuse periods remains evident today, as described in prior ballots which proposed similar changes. In particular, the following are perceived benefits to the WebPKI. First bullets. There's six bullets.

First bullet - certificates are representations of a point in time state of reality. That is, at the point of certificate issuance, all data certified therein is correct and the process followed for that certification is accurately documented for that point in time (with some exceptions). The more time passes from that moment of issuance, the more likely it becomes the data represented in the certificates diverge from reality. Thus a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates.“
Jason Soroko

Domains change hands.
Tim Callan

Organizational information changes. Your company gets renamed. Your company moves its headquarters to another state. You give up control of this domain and someone else gets it. And this is Apple openly acknowledging that a certificate that is correct the day that it's issued could start being correct the day after, through no fault of the cryptography or the PKI infrastructure or the CA itself.
Jason Soroko

I find that as we do these podcasts, we are tending to bleed into podcasts we've done in the past. The reasons for shortening certificate lifespans is what we're talking about here. On that podcast, you and I talked about how when it was five year certs, three year certs, two year certs, when you really think about it, that's an incredibly long period of time.
Tim Callan

Pretty insane. Absolutely. Even today, even with today's rules, I've walked through the math on previous episodes and shown that you can have a 100% valid certificate where everything was done right, there's no misissuance, no problem, everything was correct for a domain that you have not owned in more than two years. How is that okay?

Next bullet. The existence of certificates with formally correct contents poses real risk to websites, domain owners and relying parties. Both past and recent research reinforces this risk, whether with domain expiration, key access/control by third parties or other “security relevant events that enable a third party to impersonate a domain outside their control.” I'll keep going to the next bullet.

As alluded to above, at times CAs do not issue certificates in accordance with the policies, requirements or specifications which govern such issuance, requiring more frequent validation of information used in the issuance of certificates, and lowering the maximum validity period of certificates reduce both the risk of improper validation and misissued certificates negatively impacting the ecosystem and its relying parties.

So what are they saying here? They're saying that, first of all, the part we talked about. Things get out of sync. That poses a real risk. But then, “at times, CAs do not issue certificates in accordance with the policies, requirements or specifications which govern such issuance.“ So now we're back to misissuance. And this goes directly back to a huge topic that you and I have had over the last year, which is revocation.
Jason Soroko

Misissuance is inevitable. Revocation is necessary. It's maybe one of the biggest reasons for certificate lifecycle management and automation and shortened certificate lifespans.
Tim Callan

One of the seven reasons we had to shorten certificate lifespans is that, unfortunately, CA-based revocation, partly through the decisions of CAs, partly through limitations of the structure of revocation is imperfect. If revocation were perfect, there would be less heat on the idea of shortening certificate lifespans. Some of that's unavoidable, just because of the way it works. Some of that is avoidable. It's because of decisions that CAs made. So any CA who you don't want certificates to get shorter, you kind of brought this on yourselves guys.

This is just what we're talking about. Certificate status services such as CRLs and OCSP are technologies which do not adequately protect relying parties at this current scale of the Internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses and the accuracy and usability of data or other inadequacies. A reduction to certificate lifetimes provides firm protection to users independent of certificate status services, further reducing the associated costs to internet users.

This is one of the things we've talked about a lot - the trouble with OCSP. We had an episode called The Trouble with OCSP. There's OCSP privacy concerns. There's OCSP reliability, where it doesn't necessarily do what it's supposed to do when it's supposed to do it. CRL is better in terms of the reliability, but there's a real performance hit. When you put these things together, revocation is imperfect.
Jason Soroko

Yes. My goodness - even if you're doing revocation, even if we didn't have problems with CAs not wanting to revoke because they have customers who don't want to automate, we have enough problems with the revocation process as it is.
Tim Callan

Correct. Just these mechanisms have hair on them. A shorter certificate mitigates those problems.

Second to last bullet. Deprecating cryptographic algorithms used in the generation or certification of keys is typically a complex process affecting security critical properties of certificate use. When factoring in the ever present risk that a weakness may be identified with an algorithm library or similar component of the ecosystem at any time, with or without forewarning, it is vital that the WebPKI structure itself such that a response can be made rapidly and effectively. A reduced maximum validity period for TLS certificates provide substantial support for smoothly, and when necessary, swiftly transitioning between deployed and supported cryptography.

This is a favorite topic of yours, Jay.
Jason Soroko

I almost wanted to jump right on it as you were saying it because it's not just certificate agility, it's cryptographic agility. And this is what Apple is telling you. Tim, I'm starting to think Apple heard our podcast and repeated what we were saying.
Tim Callan

I'm firmly convinced that everybody at Apple is just hanging on my every word. That's what I believe. As I think most of the people in this technology sphere are. No, but seriously, they've been like, like, this is unambiguous and, Chrome and Moving Forward Together has been clear on the fact that crypto agility is one of their motivators. And this is Apple telling us the same thing. That crypto agility is one of their motivators. Of course, with PQC coming we've seen the level of commitment that the browsers have to PQC. Heck, Chrome already supports it. I think Safari does, too. We need to look into that. That is huge. Like that shows that level of commitment.
Jason Soroko

It's not just about post-quantum. I've said this before. You said it before. What happens if we woke up tomorrow morning and we had to deprecate RSA? Cryptographic agility is necessary even before post-quantum.
Tim Callan

I mean, we talked to Michele Mosca recently, and he was giving the chance of breaking RSA using a traditional computing architecture - he was putting it 5%. That's enormous. That's huge. Like, if there's a 5% chance that all of our digital systems have to stop and we have to go back to pen and paper, that's incredibly large. So, as you and I have said a bunch of times, we've been spoiled in the IT sphere by the fact that we can put crypto in place and literally leave it there for decades, and that will never occur ever again, and we all have to get used to that. Most of us are not used to that.

The very fact that you could have an IT professional who spends their entire career from day one of their job, from graduating from university, from college to retiring and use the same, same algorithm - that will never occur ever again.
Jason Soroko

Never ever again. We've had multiple guests say that on our podcast.
Tim Callan

This is Apple saying that, too. Crypto agility. I've brought this up in the past, but I think the real light bulb moment from this was the deprecation of SHA-1.

Because everybody decided we got to get off SHA-1. We need a little bit of time to get ready for that. Y’all take a year and a year from now, everybody's got to get off SHA-1. A year from now is the last day you're allowed to issue a SHA-1 certificate. We’ll get right on it browsers. And then that day rolls around and it's the last day to issue a SHA-1 certificate and in that time frame, public TLS certificates could have been three years in length, and there were certs sitting out there more than four years after the realization had occurred that we couldn't use SHA-1 anymore, like starting now can't use it, that were valid, that were not misissued, that were not due to be revoked. And that was a huge light bulb moment where people, especially in the browser community, said, we are doing this wrong.
Jason Soroko

We have clear precedence for how we've done crypto agility in the past. And post-mortem says failure.
Tim Callan

That was a huge one. Like that was just this giant wake up for a lot of people.

Last bullet - while not intended to be a primary benefit of this ballot, it is also worth noting that an ancillary benefit to these changes is expected in increased consistency of quality, stability and availability of certificate lifecycle management components which enable automated issuance, replacement and rotation of certificates. Increased deployment of robust bidirectional automation is not a panacea for challenges in the WebPKI, but it certainly helps.
Jason Soroko

I feel like I'm repeating myself now. Basically it's Apple and it's Google and other root store program operators who are saying you need to be running Certificate Lifecycle Management.
Tim Callan

Again in Moving Forward Together, Chrome is unambiguous in saying one of the benefits of shortening certificate lifespans is that it will encourage automation. This is Apple saying the same thing. I've been pretty public in my viewpoint that it's a chicken/egg problem. We don't automate because automation isn't required, and we don't require automation because we haven't automated. Yu can go in this circle for as long as you want, and you'll stay in that circle until something changes it. The only something in that loop that can get us out of the loop is for some kind of automation requirement to go into place. And again, we're seeing this now with Apple in the step down approach. So that's Apple openly acknowledging that while it's not the primary motivator, they don't mind that it's an outcome.
Jason Soroko

We've come a long way, haven't we, Tim, from the days of keeping track of your certificates in a spreadsheet? We've come a long way over a lot of years. It has taken a long time to get to this point. But thanks for that.
Tim Callan

There you go. I'm sure we'll be returning to this topic whether the ballot succeeds or fails, but I thought that background was just helpful.