Root Causes 187: Apple Limits Term for S/MIME Certificates

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

November 8, 2021

Apple recently announced that it would limit the allowable term for public S/MIME certificates to 825 days. Our hosts explain this declaration's implications.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanToday, we want to talk about a recent development. The CA/browser Forum has three face-to-face meetings per year - although, right now, they're virtual because of COVID, but they used to be in person, and they'll probably go back to it again. At the last face-to-face meeting in the CA/Browser Forum, Apple made an announcement that's going to be important for the world of S/MIME certificates. Apple announced that they were going to limit the accepted term of an S/MIME certificate to 825 days, which is the classic 27 months, right? Two years plus three months that, you know, used to be the limit for two-year SSL certificates before we went to the current 398 days, and more importantly, not just they were going to limit it, but that was going to be a root store requirement.

Now, what that means when I say that is there's two ways that a major operating system vendor can enforce a term limit on certificates and one of that is just an application limit. They say, our software is going to distrust certs that are longer than this many days old, or our software is going to distrust certs issued after a certain date that are issued for more than this many days, and you do that on an OS basis. So, Apple could have done that, at which point I wouldn't be able to send these S/MIME certs to Apple Mail users because their phone wouldn't honor it, wouldn't see it. Instead, they decided to make it a root store requirement, and what this means is that Apple is declaring any public CA who is issuing public certs beyond these 825 days is going to be in violation of our root program and, in principle, could be distrusted over it. This was a pretty strong move on Apple's part in terms of limiting the term of S/MIME certificates.

Jason SorokoI'm thinking, Tim, as you're talking, what kinds of software I even would use on my Mac Pro, just as an example. What would be a client consuming that S/MIME cert, and I'm not coming up with one. I apologize for any software developer who has an app probably raising their hands right now saying, me, me, I have that. But the reason I even mentioned that is because probably every time I use an S/MIME cert on my Mac, it's using an Apple product. It's very, very Apple-centric. I'm using the Mail app, for example. And so therefore, this is not onerous for me, because I'm not worried about some sort of incompatibility with some third-party software. To me it just makes sense. It's not as onerous as it sounds overall, simply because of the Apple ecosystem. Perhaps, different in Windows, but in Apple, not so much.

Tim CallanYeah, but let me modify that. So, in the case of a software-based program, I think you could make that case. Although still, the worry there would be someone else outside in the world sends you an email with a three-year cert because they're not on Apple and you receive it on the Apple mail client, what happens? That still is a valid question in the event that somebody has one of those certs, but what's interesting about Apple making this a root store requirement is now let's look at a major public CA. Let's look at us, for example. Sectigo. We issue S/MIME certs. We also have a requirement that we need to be compatible with Apple's root store program, because without that, all of our certificates including our SSL certificates have a major, major problem. So, we've got to live with the rules that Apple sets out, and Apple has stated if you issue three-year S/MIME certificates, which at present are available from Sectigo - you can go get one from our website - you will be incompatible with our root store. So, suddenly, if I'm the product decision maker at a major public CA, I have a choice. I either limit all of my S/MIME certificates for everybody down to not more than 825 days or I face the problem that I am willfully doing something that is incompatible with Apple's root store program, with possible penalties resulting up to and including exclusion from the program

Jason SorokoAs a CA that's your worst-case scenario.

Tim CallanSo, it's interesting. What's happening is Apple effectively is eliminating three-year S/MIME certificates for all OSs, in all use cases, globally.

Jason SorokoRight. I was already the step ahead, which is, how would that affect me in my Apple ecosystem? Probably not that much. But because of the fact that you might have those three-year certs also floating around in a Windows world. So, if I'm strictly living in an Apple world, I already know all the rational CAs are gonna basically, conform to that.

Tim CallanThey have to.

Jason SorokoAnd I think, Tim, the other thing that we're not saying here, and I don't want to gloss it over is the shortening of lifespans for all certs is coming down. And SSL. We've had several podcasts now on the shortening of lifespans for publicly-trusted SSL certificates. We've also had podcasts on the dramatic shortening of lifespans for very good reasons for private trust certificates such as DevOps as an extreme example, and IoT as another example. I'm really not shocked to hear about the same trend now for S/MIME.

Tim CallanIt is definitely on trend and in a way, it's not surprising that Apple is the one who did it because, number one, Apple is part of a smaller universe of consumers of both types of certificates. If you got a browser, let's say like Chrome, they don't use S/MIME, right? Or if you've got something else that uses S/MIME, like, let's say, Gmail, they don't use SSL, right? But Apple uses both. So, in that sense, they become a part of a small universe of consumers of both. Apple also was the first CA to make a move unilaterally to limit the term for SSL certificates back in 2020. We saw them do it. Now they've done it again. Apple was prepared, surely understood the implications of this, that this was going to affect people outside of their sphere in their world, and decided to do it anyway.

Jason SorokoLike I say, because of their unique ecosystem, it makes sense. And the fact that you're going to force the CAs to go down to two years regardless of the ecosystem, I think everybody else is probably going to say, well, not a bad idea. Not surprised Apple went first. I guess that's just the nature of the beast, Tim, of the combination of the CAs have to conform to the lowest common denominator and Apple has their reasons, because of the uniqueness of their ecosystem to do it. It all makes sense.

Tim CallanYeah. Now the other connection to the bigger trends that are going on. S/MIME is wild and wooly, right? Now we've had baseline requirements for nearly 10 years for SSL and EV guidelines for well beyond that. S/MIME has never really been regulated at all. There aren't really any standards at the CA/Browser Forum level. There aren't equivalents of that. The x.509 standards are extraordinarily vague and as a result, CAs have a lot of decisions they just have to make about how to do this, and they're not necessarily making the same decision. A good example is term. We're capped at three years. But there is no cap. Just like the old days of SSL. If I wanted to, I could give you a 20-year S/MIME certificate.

Jason SorokoSure.

Tim CallanAnd so, all of that stuff is going to get solidified. The CA/Browser Forum has a working group that ultimately, the goal is, and I think it will happen, the goal is to produce and ratify a set of S/MIME guidelines. Basically, BRs for S/MIME. But that's a slow process because they have to understand the use cases and what's going on and why are things the way they are? And what am I going to break when I go and I make these rules, and am I willing to break those things in order to enforce this particular rule or not? And that's gonna take a while, but Apple decided that this term limit they were just going to put into place.

When they gave their reasons why, it wa not really surprising. It was more or less the same reasons that we heard and hear on the SSL side, which is two main things.

First of all, shorter lived certificates are more secure. You and I have gone into a lot of detail in previous podcasts about the various reasons that that's the case. The other one is and, again, this is not really a surprise, is that it allows greater crypto agility. So, there is the sense whatever changes that we make for our certificates, we say, okay, from now on, we're going to require this hashing algorithm or this minimum key length or this amount of entropy and a serial number or whatever it is, you then have until all the existing issued certs age out before that is something you can rely on. Not that long ago, that was three years. So, you'd say we're going to force this cryptographic change, and three years later there could still be active certs that were compliant, that didn't have that cryptographic change. Then they took that down to two years a few years ago. Now, in the SSL world, they took it down to one year. So, in the S/MIME world, it's still sitting at years, or whatever. Could be more. And Apple said, we're going to put a cap on it. We're going to take that down to two years. This is in advance of the BR guidelines, the S/MIME, CA/Browser Forum guidelines and in advance of the completion of that process. That's where it's a little surprising, Jay, is there was a process. It was a slow process, but these processes are slow. But Apple just decided to accelerate the whole thing and let everybody else deal with it.

Jason SorokoOh, that's interesting, Tim. Perhaps that's just the way things work now is unilateral decision making to force things ahead. Like I say, I'm not surprised by any of it. I'm not surprised by who did it. I will be the last one surprised with the CAs conforming to it. I don't think it's a bad idea. Tim, thank you for making those points and thank you for bringing this up. I think that was important in this podcast, because there are a lot of people who think about S/MIME certificates. It’s important. As you were talking, I was trying to add what kind of bonus comment I could make about this in terms of crypto agility, which is a favorite topic of mine. Let's just take a moment to think about crypto agility for S/MIME, because a lot of people might not think of that's important, but let me put it to the front of your mind as to why it might be.

Tim CallanPlease.

Jason SorokoWhat are the three things that you can do with an S/MIME certificate, Tim?

Tim CallanYou mean like put it on my email?

Jason SorokoWell, yeah. You certainly can put it on your email. There's two things you can do with your email, specifically, with an S/MIME certificate. I'll give you one of them. You can sign.

Tim CallanI can sign in and I can encrypt.

Jason SorokoThat's it. And the third thing is, a lot of people don't realize, you can also authenticate with an S/MIME certificate. A lot of people don't do it, but you can use an S/MIME certificate to authenticate into your email system. So, an S/MIME certificate can do those three things. That's the classic PKI trinity. Signing, authenticating, and encrypting. Think about this for a moment, Tim. Isn't it interesting that if you look at the cryptographic primitives used by an S/MIME certificate, two out of those three are at higher risk, than the third when it comes to the quantum apocalypse? And so, therefore, authentication and signing are potentially at risk to quantum computing. I would say encrypting the AES-type encrypting with that primitive is theoretically at less risk.

I think a lot people think about signed documents. I have a document that's signed, and I want that signing to remain secure for a week, two weeks, a month. You don't think about the quantum apocalypse within that kind of time period. But for documents and contracts that are going to last longer, it becomes a big question mark. And so, therefore, if you have sensitive emails, for example, encrypting those emails is something you don't have to worry about for a little while, but I definitely think that authentication into email systems is something you do have to worry about. But the one you really have to worry about is signing. That's the one where bringing down, Tim, the S/MIME, you know, the length of time to live for an S/MIME certificate, down to two years down to one year, perhaps down in the nearer future, is not an irrational thing to do as we face the quantum apocalypse.

Tim CallanI agree. I don't think it's irrational at all. I think, again, it was a little outside the normal process and as opposed to the SSL case where the process was clearly and obviously stalled. In this case, there was a working group that was working on it. And maybe just that working group was a little too slow. Or maybe Apple was imagining that the exact same outcome was going to occur, or maybe they were worried about the clock with quantum computing. It could have been any of those things, or a combination of all of them. But whatever, that was the thing that was a little surprising is that we all felt like we're gonna wind up with some kind of time limit, like two years on S/MIME certificates and we're all waiting for that. We just didn't think it would go quite this way.

Jason SorokoYeah, I hear you, Tim. There was something in place to make that decision, and the decision was made unilaterally in a different way. So, there you go.

Tim CallanLet's share a couple dates. So, Apple is looking to solidify this policy by the end of this year. The date that has been thrown out is April 1, 2022 for the effective date of a variety of policy requirements on S/MIME, most important of which is the 825-day limit. So that's not set in stone yet, but that is a good target date and a good expectation. Expect that starting on April 1 will be the date when that limit will come into effect and, again, my expectation is that every public CA of any consequence will be limiting itself at that time to that term for their S/MIME certs.

Jason SorokoThere you go. If you're running S/MIME, folks, that's one to keep your eye on.

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!