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


Hosted by
Tim Callan
Chief Compliance Officer
Jason Soroko
Fellow
Original broadcast date
February 10, 2025
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.
Podcast Transcript
Lightly edited for flow and brevity.
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.
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.
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.
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.
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.“
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.
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.
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.
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.
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.
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.

