Root Causes 212: S/MIME Limited to Three Years

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

March 28, 2022

On April 1 new root program requirements from Apple for S/MIME certificates go into effect, including a limitation of the allowable term to three years. This is contrary to Apple's stated intentions last year. In this episode the explain this change in policy and what certificate users can expect for the future.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe want to give an update. We actually covered this topic in our Episode 187 back in November, which was about new rules that are coming down and, in particular, we talked about term limits that were coming down for S/MIME certificates. At the time, what we said was entirely accurate in terms of what the forward-looking plans were. However, the thing about plans is sometimes they change. And so, the rules around S/MIME certificates and term are slightly different - or not that slightly - are different from what we talked about at the time and we just wanted to give everybody an update, so you know what the new going forward rules are going to turn out to be, and where we think all of this ultimately is gonna wind up.

Jason SorokoThanks, Tim. Even I need to an update on this. So let's get the refresher. Thank you.

Tim CallanBack in November, what the plan of record was, and I'll do a little bit of background, this is obviously, this is driven by Apple and by Apple's root program. Apple has one of the most important root programs on the globe because their entire technology stack depends on their root store. So, it's their mobile devices, their Mac, their Mac machines. And all of that is using the Apple root store. So, if Apple says you must, public CAs comply, because nobody is going to have their roots not work with all of those machines. And last year, Apple announced that as a root store requirement, they were going to limit the term of S/MIME certificates to two years. So, it wasn’t quite two years, it was 27 months. The normal kind of two-year limit. And that, not just that they were going to limit this on their own machines, but they were going to make this a matter of their root store compliance, which meant that if you issued public S/MIME certificates that were of longer duration than that, then you would be non-compliant with the root store. So that's a pretty serious thing to say. It's something for a major root program to when they do that, CAs sit up and take notice. We take that very, very seriously. And so, it looked like the entire industry was going to be knocked down to two years in duration for S/MIME certificates. What happened was there was a great deal of public dialogue subsequent to that that Apple was very involved in where people talked about the consequences of limiting S/MIME certificates to two years. And in particular, there was a lot of focus, not on an S/MIME certificate that's sitting on an email necessarily, but certificates that are embedded in tokens. In hard devices. Imagine a badge. You might have a badge that you carry, it's got your picture and your name on it, and you use it to badge into things and that has a certificate on it. And a lot of those were being issued for more than two years, three years plus, and there was a general sense that having to swap out these badges a year earlier than we would have had to otherwise would have been prohibitively expensive and difficult for a lot of the people who are relying on them today. And so, it was less an argument about me having a cert sit not my phone, or my MacBook, and it was more about - or I guess anything, it wouldn't have to be Mac – me having a cert sitting, I was searching on my phone or my laptop and it was more about these other use cases for which people are still using S/MIME certificates. And at the end of the day, Apple announced that they were going to limit the term to not two years, but three years or three years plus two months, certain amount of days, and that was going to be the new requirement that was coming down from Apple in 2022.

Jason SorokoThat's interesting enough. I certainly remember the conversation you and I had with respect to the shortening of the lifespans, which was pretty consistent with the rest of what was going on in certificates in general. But it's also understandable that there are specific use cases and people with some concerns. So it makes sense.

Tim CallanSome of the - not to belabor the obvious. Obviously, this only applies to public certificates so if you have a private root, you're allowed to make it any term you want. This is about S/MIME specifically. So other requirements, other certificate types are separate and are what they are. For instance, public TLS certs are 13 months. We all know that. Or 398 days. And then the last thing just to know is that this new rule comes into effect on April 1, which is coming up pretty soon.

Now, the difference from three years to two years in that regard is rather dramatic. For example, all of our what we'll call retail certificates, if you come to one of our websites and get a certificate, you're capped at three years anyway. So, none of that for Sectigo had to change. I think some of that did change for some CAs but it didn't affect us in particular. And in general, your email cert implementation of S/MIME is seldom running more than three years in term anyway. So, in that regard, it's not going to be hugely impactful. Where it is going to be impactful is if a custom certificate for a custom use case was being built with more duration than that, that practice has to stop. And one thing about S/MIME is S/MIME traditionally has been rather unregulated. There aren't a set of BRs for S/MIME today. And so, CAs had a whole lot of latitude on what they do and if a CA wanted to handcraft a deal with some customer to give them four-year certs or five-year certs that was up to the CA and that will not be up to the CA moving forward. That three-year cap is going to be quite real for everybody for public certs.

Jason SorokoWell, that’s good. I actually think that that's probably not the worst thing in the world. It makes sense to wring out some of the last Wild West sections of the certificate world that still exists. That's how I see it, Tim.

Tim CallanS/MIME has been very Wild West. And just, so segueing into a very related topic, the CA/Browser Forum is working on a set of baseline requirements for S/MIME. And so that will be another big piece of wring out Wild West and that will include the kinds of things that we're talking about here. But I think, we've seen Apple in the last few years become a much more proactive, or I almost want to say muscular root store program than they have been in the past. And, historically, they were more comfortable with letting people like Mozilla and Google set policy and we've seen Apple move into more of a policy setting role. And so, in that sense, this is consistent with their behavior of the last maybe three years. And, they are deciding that there's some things they want about this, this kind of certificate, and they're putting that in place, and the industry is going to fall in line.

So, this deadline comes, it's as of April 1. So that deadline is in place in April 1. Sectigo is compliant with that today. So, you can't get more than three-year cert from us now anyway. And I'm sure all other CAs if they're not compliant will come compliant between now and the end of the month.

Then the last thing though is we should look at that initial announcement I would say as an indicator of where Apple wants to and I would speculate, plans to, take the industry. So, the fact that we're all at three-year certs now should not be construed to mean that root store programs are going to let that duration sit forever. Just as we've seen with other kinds of certificates like SSL, that those spans have been going down, I would expect the same to occur here. I think that, Apple has clearly telegraphed what they would desire or maybe even what they would desire as a first step. Just like with SSL, we saw them go to three years, then we saw them go to two years, then we saw them go to one year. I think we're gonna see them go to six months. Along the same lines, so we've seen S/MIME go to three years. What's the line in Vegas on whether it stops there?

Jason SorokoI wouldn't be betting long term money on it staying static that's for sure.

Tim CallanThat's where it is. Keep an eye on that. But certainly, we won't see another reduction anytime in 2022. It would be probably 2023 at the earliest that we'd seen this go down to a shorter lifespan. We should expect that to go on. Those term limits are going to continue and they're going to continue to shrink but it's going to be the same kind of pace, I think, that it's been in other parts of the industry, which is it's going to take years to get it all the way down to kind of one-year certs.

Jason SorokoMy take on this overall, just thinking about all of a sudden these activities, especially with what you just said about the baseline requirements, and also the term limits - I think, I think what we're seeing here, Tim, is S/MIME is just becoming even that much more important.

Tim CallanThat's the other thing we've seen, is S/MIME has been around forever and for the longest time it was kind of used by hobbyists and computer scientists. We are seeing S/MIME, there are some regulations that require S/MIME for certain specific circumstances. If you want to do business with the Department of Defense, for instance, you need to have S/MIME in place. It's a requirement. So, these sorts of things are definitely picking up more and more. We're seeing it get more attention at the enterprise level. There's good reasons for that. Spear phishing is a big reason for that. We're seeing that and I think we're going to continue to see that trend and associated with that, not surprisingly, you're seeing more attention from the root store programs and that's as it should be.

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!