Root Causes 432: Apple Floats New Short-lived Certificate Proposal

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

October 14, 2024

Apple recently floated a draft CABF ballot for commentary that steps down maximum term for SSL certificates starting next year and eventually landing at 45 days in 2027. We share the details.

Podcast Transcript

Tim CallanSo at last week’s CA/Browser Forum face-to-face, there was a pretty major development in the world of reduction in certificate lifespans, and we want to talk about that today.

Jason SorokoThat's one of the top topics, Tim, that's on the top of my mind, and has been for quite a while. So let's hear it.

Tim CallanSo the CA/Browser Forum face-to-face took place in the beginning of October. Specifically, the dates were - I can tell you in a moment. This face-to-face was October 8 through 10. October 8, 9, and 10, 2024. and on the 9th, Wednesday of last week, there was a discussion about the Mozilla proposal to ultimately solve the delayed revocation problem. And we talked about that in a very recent episode. So go back to that if you want to hear about that, because that itself is super interesting and important. And in the midst of that discussion, there was clear, I want to say, a clear opinion voiced by a couple of the browsers, to say, wouldn't all of this work better if certificate lifespans were just shorter to begin with? And while that was going on, we became aware of the fact that Apple had very recently posted a proposal on GitHub. And GitHub is where the CA/Browser Forum houses its proposed ballots these days. And there was a proposal on GitHub, and we went and looked at it. So we became aware of this on Wednesday the 9th, and then there was a discussion of this was added to the agenda that occurred on Thursday the 10th in the CA/Browser Forum meeting. And I want to go over what this proposal states. But before we do that, Jason, let me emphasize this is a proposal for discussion. It's a proposed ballot, but it's not a ballot that is officially moving through the voting period at this time. So this is just out there for Apple to gather feedback. I expect, based on this, there absolutely will be a ballot. I expect that ballot will be materially the same as what we're looking at here, but it might not be identical, because that's kind of what the feedback process is for, and exactly when this goes into ballot and all of that remains to be seen. So is all that clear?

Jason SorokoWell, Tim, sure. It is clear, but maybe I'll reserve the question for when do you think, if it goes to ballot - -

Tim CallanIt’s a great question. Let's go through the ballot and then remind me of that question. I think it's worthy. That's worthy of discussion, for sure.

Jason SorokoLet's do it.

Tim CallanBut the listeners are probably eager to hear. So this is a ballot that would step down, over time, the maximum allowable term for a public SSL certificate from what it is today, which is 398 days, down eventually in 2027 to 45 days. So that's considerably less than the 90 days we've been talking about. So that's point number one.
And then with it, the DCV reuse period would also step down until eventually, in 2027, according to this ballot, it would get down to 10 days. Now, as we've mentioned in the past, DCV reuse is another thing in the moving forward together program that Chrome states that it wants to reduce. So these two things really flock together. And so, why don't we go through the specific dates in the proposal as they exist today?
So the first date is September 15, 2025. So September of next year, the maximum certificate term and maximum DCV reuse period would drop to 200 days. Exactly one year later, 9/15/2026, the maximum certificate term and the maximum DCV reuse period would drop to 100 days. And then on April 15 of 2027 - so considerably less than one year later - the maximum certificate term and DCV reuse period would drop to 45 days. And then the final date is that on September 15, 2027, the DCV reuse period would drop to 10 days. Even though the certificate period would remain the same. So up through April 15, 2027, they're synced up. And then there's one more reduction that comes for DCV reuse.
So let me pause there. There's a little more nuance on this, but let me pause there. That's the gist of the important parts of the ballot, and let you internalize that and ask questions or say what you're going to say.

Jason SorokoSure, Tim. So, I understand going to down to 200 days within a year. I am curious about what was discussed, or, you know what the word on the street was regarding the shortening of the DCV period down to 10 days at some point after the 45 days started. So instead of going down to DCV per issuance in real time, they're giving people a 10-day grace. Is that the idea?

Tim CallanSo the idea would be - exactly right. Like, let's say that you come in and you order 100 certificates from me, and I'm gonna pour them out over the course of five minutes. It would be pretty silly for me to make you do DCV 100 times. So there needs to be some kind of reuse period there, because, otherwise, you would literally have to do it every single time. Even if it's one second, that's still a reuse period. And, is 10 days the magic number? I don't know.
What the browsers are after in general, is they want a tight marriage of domain ownership to certificate ownership. They really don't like a situation where somebody owns a valid certificate for a domain that they no longer control. That is fundamentally in the browser's mind, just a thing to be avoided as much as we conceivably can. And they talk about scenarios like people don't renew a domain and someone picks it up, or people sell a domain or, and they talk about attacks. Somebody exploits a domain, or exploits a private key. All of these things kind of fit into it. But at the end of the day, there is this desire to have as close as we can, a perfect overlap between who owns a certificate and who controls that domain. And so reducing DCV, the DCV reuse period, gets you closer to that. Ten, five, two, one. I don't know what the right number is in there, but I think it's something in that ballpark. And I think 10 is probably the biggest you might go for. And that might have to do with why Apple went with 10 is just to be as light handed as they can within what they're trying to do. And they could always go back and tighten it up later if it's decided that it needs to be tighter than that.
This 10 day thing has come up in the past. That is the period that according to CA/Browser Forum ballot right now, if assert is not more than 10 days in term, then it doesn't need revocation checking. So that's in the CA/Browser Forum rules. That's in the BRS. So by that line of reasoning, syncing up with 10, maybe it's smart. The fewer arbitrary numbers you have floating around, the less opportunity there is for someone to get confused and use the wrong number. So, if nothing else, there's some virtue just in that. So that may be it. And again, I think if the community determines that somewhere down the road that they'd rather it were three days, it can be updated and it can be reduced to three days. And so I just think that's probably Apple being as light handed as it can in what already is a pretty assertive ballot.

Jason SorokoTim, this first reduction in certificate lifespan down to 200, there's a date that I think you said was next year.

Tim CallanYes. September 15.

Jason SorokoSo any one year certificates, 398 day certificates, that are purchased before that date, are they still valid past that date?

Tim CallanLet me clarify. That would be the date at which a cert that is issued on or after that day would be maximum. So yes. On September 14, you would be able to buy a 398 day cert, and it would be good for its full term. To be clear. And that would be true of every one of these things. So on September 14, 2026, you would be able to get a 200 day cert, and it would be good for its full term. On April 14 of 2027 you would be able to get a 100 day cert, and it would be good for its full term. So once they're issued, they're good for their full term. What this is, this is a prohibition on issuance of that length or longer.
Now these dates - 200 days. 100 days. You might think those are funny days. Funny time periods. Like why isn't it 90 days? And the rationale for that, which Apple explained, was, and I think it's actually absolutely right on. Apple says 200 days is 180 days plus a little bit. 100 Days is 90 days plus a little bit. 45 days is six weeks plus a little bit.
So what they're doing is they're building in the idea of having a little bit of a renewal grace period. This is something that certificates have had for decades, which is, if your certificate is expiring on October 1, what you really want to do is you want to get a certificate from me in September so you can deploy it and if there's a problem, you've still got the old cert. And this is done all the time. It's considered to be a best practice. And by giving us 100 days, you can have 90 day certs that still co-term on your schedule. By giving us 200 days, you could have 180 day certs that still co- term on your schedule, or six months certs, if you'd rather, which isn't exactly 180 days, that still co-term on your schedule. So all of that becomes possible. It gives you a chance to maintain a regular calendar cadence. I'm doing this twice a year on a certain date. I'm doing this four times a year on a certain date without having to worry about you've got a little bit of overlap. You got a little bit of fudge time in there. And this is one of the things that you and I have discussed in a great deal when we talked about the 90 day proposal from Chrome, is that that isn't four renewals a year. It's five or six renewals a year. And so this is Apple accounting for that, and saying, okay, we can build this proposal in a way where the actual cadence you're able to maintain is for a year. And I think that's, what you see going on with those dates. So I've had people ask, what’s up with those time periods? I think that's what's up with it.

Jason SorokoThere are a lot of 90 day certs out there right now, and I happen to know that a lot of people renew them before 90 days don't get the full 90 day value most of the time.
So that's an example. And the most clear example we have is current one year certificates are not 365 day certs. They're 398.

Tim CallanThat’s exactly right. It lets you co-term where it originally was for purposes of scheduling and everything else. We always know. I know this cert is expiring on the last day in September, and I know that, and it's okay I know that, but I just turn around and I renew it earlier in September, because that way I'm not gambling. And it's the best practice. And again, it shows this is a well thought through proposal. Apple doesn't want to arbitrarily create a situation that interferes with people employing best practices, so they built that into the proposal so that we can still employ best practices and also meet the desire for the certificate term that Apple is trying to achieve.

Jason SorokoTim, talk to me about ballots, ballots proposals, voting times, etc.

Tim CallanSo let me tell you one more subtlety before we get into that. There's another thing in this ballot that people are less interested in, but it's worth knowing, which is today, the maximum reuse period for organization validation OV is two years, and that is being reduced to one year as part of this ballot.
So this ballot will bring the OV reuse period from two years down to one year. Now at Sectigo we have a one year limit anyway. We reorg value every year, no matter who you are. So if you're a Sectigo customer, you're used to that, and you've been living it anyway. But not every CA does that, and not every CA has to. So this will reduce that time period.
So that's one thing to know, but the other thing to notice is that there's a DCV step down, but there's no corresponding OV organization validation step down in the program, because one of the questions that I've been asked in the past is, oh, wait a minute, does this mean I'm going to be reorg validating every 90 days? And I've always said there's nothing to indicate that that's anybody's desire. I would say this goes a step forward by showing us the proposal they showed us, and having the DCV, OV and cert term all individually spelled out, Apple is making it pretty clear that they're happy with one year org val, and have no immediate desire to push that further down. And so that's another good thing, just to be aware of that's in this ballot. And I just wanted to get that out there.
Okay, ballots themselves. So this is a, again, this is a proposal for discussion. In principle, a proposal for discussion could sit there forever. In principle, a proposal for discussion could not move forward. Let's say the discussion shows that it's not a good proposal, then you just stop. You don't do anything. There's nothing in the rules that states that a proposal for discussion must turn into a ballot. That said, I expect that this proposal will turn into a ballot, and I don't think it'll sit around for months. I don't think there's going to be like three months of discussion. For a couple reasons. One of which is, it's actually a fairly simple proposal, and I'm not sure how much people are going to say that's really going to be constructive or contributory.
So when we were looking at something like MPIC, it was very complicated. There was a lot going on. It's very complex. It took a long time to work it through. Sometimes these things are very complicated, and they took a long time to work through. This is just maximum term and a schedule. So there's not a lot you're going to comment to. You're going to say, well, instead of 200 days, I think it should be 205 days. Or you're going to say, well, instead of September 15, I think it should be August 15. That's the kind of thing that people are going to discuss. How much discussion is there really to have there? I don't think there's a lot.
Also, this went up last week in a very public way in front of the entire CA/Browser Forum, and there has been very little commentary so far. So I don't think that there's going to be a great deal of commentary on this. I don't think there's a lot to say. And the biggest thing that we're probably going to hear from some people is, I don't like this, and they're going to be people who don't want to automate. I don't like this. And I don't like this - like, there's not a lot of dialog to be had around that. There's not a lot to investigate. So I don't think this is going to be a super long commentary period. I don't expect it to last for months. I expect it to last for weeks, and then at the end of that commentary period, with maybe some minor adjustments, I expect there to be a ballot. Now to be clear, full disclosure, Sectigo has already endorsed the proposal that Apple put out there. So you think you know what my opinion is, but, we'll see what the proposal of this is, and then I think that it goes into a ballot within the next month.

Jason SorokoSo, Tim, the CA/Browser Forum votes outside of its face-to-face meetings?

Tim CallanBallots just happen whenever they happen. They happen all the time. Sometimes there's more than one ballot running at once. They're very frequent. We have multiple ballots per month. So you and I don't talk about most of them here, because most of them are kind of down in the weeds and are a little clerical and are esoteric, and they just don't deserve to be in this form forum. But ballots go on all the time. Ballots can happen entirely separate from those. We do not have to wait for the next face-to-face. This is something that will move forward when it's ready.

Jason SorokoTim, I find it interesting that the initial blogs on this, the initial presentations at the CA/Browser Forum, were done by Google, and now we have a ballot for proposal by Apple. So I'm sensing there's a lot of browser trust store support for shortening certificate life.

Tim CallanI think that's a very astute observation, Jason, and you're absolutely right. You and I have talked a lot about Chrome. Chrome wants this. Chrome says it will do this. Chrome has the power. Chrome has the ability. Then just a few weeks ago, we saw something coming from Mozilla that was also pointing towards shortening certificate lifespans as the remedy for a lot of what ails us. Now, you see Apple coming out with the most concrete, the most ready to go, the most advanced and in the long term, the most proactive proposal to do exactly that. And so when I look at that together, what I see is broad support inside of the browser community for this kind of thing. And I think that's very important, because we've got to remember a ballot like this is very difficult to pass in the CA/Browser Forum.
It's kind of like a lot of parliaments. There's two bodies. One body is what we call certificates consumers, which you and I usually use the word browsers. But it's not just browsers, like Cisco's in there, for instance. It's anybody who has a root store that uses certificates. The other body is the CAs - the people can issue certificates, and both bodies have to pass a ballot, just like in a lot of parliamentary systems, and if one of them doesn't, the ballot doesn't pass. So in the earlier certificate shortening ballots that we looked at when we're trying to go down from two years to one year, about four years ago, the browsers kept passing them and the CAs kept rejecting them, and at the end of the day, Apple made it a root store requirement, after which Chrome and Mozilla followed suit, and then at that point, we passed the CA/Browser Forum ballot.
So it is very possible that this ballot fails because we cannot drum up a majority of support among CAs, and if that occurs, it is also very possible that one or more of the root stores does something the same as what Apple did four years ago. Now we are in support of this, as I said, because we just think it's healthier for the WebPKI. We think these long lived certs cause a lot of problems, and there are solutions for that.

Jason SorokoThank you, thank you, thank you for that. I think that what I'm reading into it, Tim, is shortening certificate lifespans, I think the writing's on the wall that we're going to be getting a shorter certificate lifespan than one year. And I don't want to leave this podcast without stating what is always the obvious in my mind, which is, I think the only rational way of dealing with that is not to do manual renewals every 200 days, every 45 days, etc. It really comes down to certificate lifecycle management is now - it's just something that every certificate really should be a managed certificate, and that's the other way of not only dealing with shortened and certificate lifespans, the reasoning for all of this is because certificate agility is something that we all need. It's the right thing to do.

Tim CallanAnd this step down is interesting. In that regard. Because what Apple is doing is they are increasing the stakes over time. So first step down will be from one year to six months. So I predict that there will be some enterprises who say, no, that's unacceptable to me. I can't deal with the extra work, or I can't deal with the extra risk. There will be some folks who decide to deal with the extra work and the extra risk. Then a year later, it goes down 90 days or 100 days. At that point, the pressure is doubled again. And there will be more people who say, I can't deal with the extra work, or I can't deal with the extra risk. Like, I think at that point it's like pretty much everybody. And then once we're all good at that, once we're all automated, anyway, why not go down to six weeks. Then eventually, why not even lower and so that appears to me what Apple is up to here. They're giving people an opportunity to understand that they really should get automated by getting thrown into the fire a little, and people who don't get the job done and suddenly go down to six months, start to realize, gee, this really sucks I need to do this because it becomes very painfully obvious to them, it sucks, but they do it in a way where they don't just break everybody. And again, I mean, I wasn't there. This is just me reading the tea leaves based on what I see, but when I look at that, I think that was the rationale behind the step down. And again, I think it's smart, and it shows that this is a well-considered smart ballot that can be very effective in migrating the WebPKI down to shorter lived certs.

Jason SorokoTim, a lot of times we offer personal opinions on this podcast and mine is it this is good because a binary switch down to 90 days, which is something we had been talking about for such a long time, probably would have sent a lot of websites out because a lot of people just would not be prepared for that level of shortening of certificate lifespan. So this helps.
It just makes me feel more confident that we will have a successful program of shortening lifespans. That's it.

Tim CallanAnd I would say this, again, for that point, similar to the point about 100 days versus 90 or 200 days versus 180, I think this shows that this proposal comes from a period of listening. I think Chrome threw an idea out there, and the market reacted and a lot of people said a lot of things, us included, and it sounds to me like Apple was listening to what people said, and then constructed a proposal that accounted for that. The step down accounts for that. The 100, 200 versus 90 and 180 accounts for that. And so it shows that the things that the public had to say about this idea of going to 90 day certs were heard and are part of this new proposal, which is why I consider it to be more advanced than what anyone has done before, and ultimately more likely to succeed, and also just a better way to do it. So and all of that comes from listening to the market and listening to the public's voices, and I think we see that reflected in this ballot, which is another reason I don't expect an extended discussion period. Because, kind of, in a way, we've already been discussing this for a year and a half. And so I don't know what else is going to come up that didn't come up already.

Jason SorokoExactly. This is a refinement to what was a de facto proposal in the past. So thanks for that, Tim. This is really good. A lot of information there to take in.

Tim CallanThere's a lot there. I think we'll probably follow up with this. There's some more nuance that you and I felt was out of scope for this first introduction, but probably in the next few weeks, we'll do a follow up on this, because there's one or two other things that are worth discussing, and then there's going to be developments. So I'm sure we're going to follow up based on if this goes to a ballot, if it becomes an actual proposal, if it gets modified in some significant ways. All of that will need follow up as well. So stay tuned on this one for sure.

Jason SorokoWhat a busy time in our industry. Stay tuned.

Tim CallanWhat a busy time in our industry. Thank you, Jay. This has been Root Causes.

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!