Root Causes 451: A Year in CABF Ballots

Hosted by

Fellow

Original broadcast date

December 26, 2024

It was a crazy year for CA/Browser Forum activity, with nearly three times the normal number of ballots. Guest Martijn Katerbarg goes over the 32 CABF ballots from 2024.

Podcast transcript

Lightly edited for flow and brevity.

TCTim CallanVery excited to have a guest today. Our guest today, this is your first time on the Root Causes podcast is Martijn Katerbarg. Martijn is a Senior Compliance Engineer here at Sectigo. Welcome Martijn.

Martijn KaterbargThank you, Tim. Thank you, Jason, for having me.

TCTim CallanSo the reason you're on here today, Martijn, is you actually, in the closing days of 2024, you engaged in what I thought was a very interesting exercise on LinkedIn, which is that you posted individual posts discussing all of the different ballots that had occurred in CA/Browser Forum in the year of 2024, and it was quite a lot, wasn't it?

TCTim CallanYes. We had quite a lot, especially if we compared it to previous years.

TCTim CallanHow many did we have altogether? Like 30?

Martijn Katerbarg32. One additional has been launched, but not yet completed, so I'm not counting that yet.

TCTim CallanSo 32 not counting one that ended the year in flight, and that's compared to, I'd say that's like three times what we normally get. Ten or 12?

Martijn KaterbargIt is indeed. I looked it up. We had 11 in 2022, and 12 in 2023.

TCTim CallanSo that's crazy. Any thoughts on why so many ballots?

Martijn KaterbargThat is a very good question. It's been a more active year. I think on the server certificate side, there has definitely been a lot of smaller ballots. There's a small change that needs some realignment, some clarification that needs to be done and the process is fairly effective, so it gets done. The second item is that we have a new working group. The S/MIME working group, which did its first ballots in 2023 but has definitely come onto its strides in 2024. And NetSec, the network security working group, has, I always want to say, restarted, at least on the ballot front. They hadn't done any ballots for three years, and now they've done four this year, so that's definitely contributing to that.

TCTim CallanI think we're seeing a very active, very dynamic time in CA/Browser Forum. Some of the reasons for that is that there's just a lot that needs to be done, to be frank.

All right, so tell us about your LinkedIn exercise. What did you do?

Martijn KaterbargEssentially, I mean, everybody knows these end of day, end of year reviews that are done by a lot of companies. Like what's been going on throughout the last year, and that's essentially it. But with 32 ballots, and I'm skipping the weekends. I had to start quite early, compared to I think most other organizations.

TCTim CallanThat’s six weeks’ worth of posts there. Let's get into it. You're going to walk us through all the ballots that happened this year.

Martijn KaterbargI will indeed. It’s going to be a very short overview of each one, I think. So let's get started.

We'll start with the forum itself. And Tim, this is one you've been involved in, actually. The forum itself can do ballots, and they had one this year, which was the establishment of a new working group.

TCTim CallanThat's true. The DVWG, the definitions and glossary working group. Of course, I was established as the vice chair of that.

Martijn KaterbargIndeed. So we're expecting big things from that working group, obviously. So onto NetSec. Like I said, no ballots for a couple of years there, and then suddenly this year, we had four ballots.

Also in the second half of this year, pretty much, one is an exception to that, but we've had NS003, which had fixes done for the realignment for Section 1, 2 and 3 of the NetSec requirements. The NSRs as we call them. That's essentially a big restructure with no new requirements, but a restructure for future changes that will be coming essentially.

Subsequently to that, some issues were discovered, so fixes were done through the ballots that are called NS005, and 6 and I think for the keen listeners can already hear, any ballot that starts with NS will be for NetSec. Same for Code signing. Those all start with CSC. Server starts with starts with SC. So they all have their working group prepended to a ballot number.

TCTim CallanFor the keen listeners, that implies that NS003 is the third ever ballot from the Network Security working group. Because it's a fairly new group in the grand scheme of things.

Martijn KaterbargIndeed. It's been around for a few years, but there's been a lot of discussions ongoing, and the previous ballots were essentially the adoption for the old requirements that already existed. Then an election ballot for a new chair.

Then the final ballot, obviously we have 05 and 06, 004 has to do with vulnerability management, and that's the real only new hard requirement for CAs, and one where CAs have to make sure they have a proper asset inventory for all of their CA systems and infrastructure, and CAs have to disclose what their vulnerability management practices are, which I personally find quite interesting.

TCTim CallanAll these ballots passed?

Martijn KaterbargThey did indeed. Correct.

TCTim CallanThat's the network security working group. What do we got next?

Martijn KaterbargWell, let's take code signing next. So code signing, six ballots this year.

We'll start with the CSC21. The signing service update, which didn't affect too many CAs. I'll be honest. It's essentially some requirements around signing services which can either be operated by a CA or by an external party. Obviously, one would say that CAs are signing services themselves as well, but we sign certificates, and these requirements were more around private key protection for code signing, signing services.

Then we had two follow up cleanup ballots, essentially. So no new requirements onto that. One was marking an old document as superseded. It's just a cleanup making sure people know that that document is no longer relevant, and a high risk requirement update which removes some language which was essentially no longer of practical use.

TCTim CallanThere's no hard definition of what a cleanup ballot is. But basically the idea is that we're not changing the requirements. What we're doing is we're changing the way that they are communicated, in particular to keep clarity around what's required from a CA, is that correct?

Martijn KaterbargYes, that's correct. There's nothing officially preventing a requirement change. But we tend not to do that in a cleanup ballot.

TCTim CallanIt’s a good practice to lump cleanups into cleanup ballots and keep requirement changes segmented out for their own ballots.

Martijn KaterbargAbsolutely. We also have the thing called clarification ballots, which I think those are more some CAs have interpreted it one way. Other CAs a different way. In that case, those would be ones that, for some CAs, might be a requirement change.

Jason SorokoMartijn, I think that compared to 2023 I think 2024 was relatively quiet with respect to ballots and work that was going on. I remember 2023 for code signing would be quite busy. Would you agree with that?

Martijn KaterbargYes, absolutely, I would agree with that. Code signing is heading in some new directions, and I think we've done some preparative work for that throughout this year and more to come next year. I think on that preparative note, we had CSC25. Which was the import of the EV guidelines into the code signing BRs. So we have two types of code signing certificates at the moment, as the two of you well know. EV code signing, and well, we call it non-EV code signing, or regular code signing.

The EV code signings, they still reference the EVGs, the EV guidelines, which mainly are used for TLS. Code signing is looking towards moving towards a one type certificate, which would mean we need to remove some of the EV references, while also keeping others and importing the EV guidelines into the document itself is a good first step to making sure all the language is there, and then we can more easily start to dissect it.

TCTim CallanThen you go through, and where there are differences in the two requirements, basically we settle on one.

Martijn KaterbargCorrect. So the last two ballots actually are the same ballot. We have CSC24 and 26. They are the updated requirements for timestamp certificates and CA private key protection and code signing has a lot to do with private key protections and time stamping is a scope of that as well.

Unfortunately, CSC24 initially failed. The code signing working group is a bit fragile, as there is only one certificate consumer, and we didn't get a vote in time. So after a short internal discussion, we relaunched that as CSC26 and that one did pass.

TCTim CallanAnd so apart from the number, it was identical. Is that correct?

Martijn KaterbargYes, correct.

TCTim CallanThat is very unusual.

Martijn KaterbargIt is. We do hope to avoid it in the future, but things happen. We all know that. And we've got numbers enough so there's no worries on that.

TCTim CallanAll right. That's it for code signing. So what do you want to tackle next?

Martijn KaterbargWell, let's take the server cert, which definitely is the biggest one, and S/MIME after that. And the reason for that is that S/MIME tags along nicely with the server cert working group.

So server cert, 15 ballots in total. The chair, our very good colleague Inigo, has done a lot of work for that, not by writing the ballots, but definitely by managing all of those and getting new documents out. So kudos to him.

So we start with SC65 which was a ballot with a fairly long run time converting the EV guidelines into the RFC3647 format. This might need a little bit of explanation, I guess. RFC3647 essentially defines a format and all of the headings that a CP or CPS should have. So we as a CA, we have our CP. We have our CPS and the baseline requirements, all of them, are also in that format, which makes it very easy to look up requirements because they'll all be in the same, in general, be in the same section.

TCTim CallanThey’ll all have the same number. 3.2.7 is 3.2.7.

Martijn KaterbargThere are certain exceptions, but not a lot of them. That essentially has been done with the EVGs as well now but obviously converting a large document without introducing any requirements, that definitely took some time. Then we might as well go right onto the next ballot, which is, I would say, actually the largest one of the year, the MPIC ballot – multi-perspective issuance corroboration.

TCTim CallanWe’ve discussed this in some previous episodes. We've talked about Border Gateway Protocol and what that is. What a BGP attack is. We've also talked about MPIC in at least one prior episode. I think more than one. We may have discussed it under its earlier name, MPDV and, that was a big one, wasn't it, Martijn?

Martijn KaterbargDefinitely and that's also why we had, well, we had three versions of that ballot before it actually passed, and it also has a fairly large run up time before the requirement goes actually into effect. That's in March next year, in which time we'll first move into a reporting only requirement, essentially. It means we do need to provide the checks, but we may still ignore any results, but then September of next year, it will actually go into effect, and we do need to keep the quorum count and potentially block issuance.

TCTim CallanAt that point, the quorum count is low, but it will rise in the years to come, until I think, if I recall, at the end, you're gonna have to have six different endpoints. Is that right? At least minimum?

Martijn KaterbargI believe the top is five, to be honest. But, yes, indeed. I would say, though, if a CA has done their initial development and deployment, it shouldn't be too hard to scale to multiple additional perspectives with the technologies nowadays. The first lift is definitely the biggest to do.

Jason SorokoJust in reflecting upon the previous couple years, I think if 2023 might have been categorized as the year of code signing changes, I think 2024 definitely I agree MPIC, we might call it the year of MPIC introduction.

TCTim CallanOr the year of DCV changes, because there was more to DCV than just that. What I was going to say is it's unusual to have to take multiple runs at a ballot. Like the fact that there were three before it passed. That's not very common is it?

Martijn KaterbargIt’s not. We usually see one follow up, not always, but in some cases. I mean, we have an official discussion period. If any changes are done in the ballot during that you need to launch a v2 essentially, just to make sure that it restarts. Three is not something we see that often.

And so the next topic, well, the next ballot, I should say, SC68 is a very short ballot. That's one I would call a clarification ballot, and it's the added allows for EU specific country codes. For the country codes in certificates, we usually have to follow the ISO 3166 country codes. But apparently there are some countries within the EU that internally use a different country code that's specified in a specific EU directive, and this ballot essentially added the option to use that directive for countries. I believe the countries currently are Greece, and I believe it's not in Ireland, so I may be stand corrected there.

TCTim CallanSo that's a very specific ballot.

Martijn KaterbargIt's a very specific and small ballot, and again, we've had multiple of those throughout the year. So next one also is a kind of a clarification ballot, and one that we actually run - SC69. A clarification of router and firewall logging requirements. This was one where we've had some discussions internally before of the existing language back then, which was we have to log router and firewall activity. What is routing activity? Is it routing of any packet an activity? One might say so, but if you have to start logging every packet, then that's gonna essentially turn into a DDOS attack against yourself. So that's not practical.

TCTim CallanFurthermore, the act of logging the activity is itself an activity. So do I have to log the act of logging? And do I have to log the act of logging that? And you could make an argument that, in fact, the requirement as written required infinite logging, which, of course, would be absurd, but it was the language we had. We had to rectify that language and clean it up, just so that there was no need to say, well, I know the language says A, but everybody knows I really have to do B. Instead of that, we just fix the language so everybody could do what the language said.

Martijn KaterbargIndeed, you're correct.

So next up we have a failed ballot. Well, it actually passed. This is an interesting one, clarifying the use of delegated third parties for domain control. This is one of the ballots that came out of what you guys called the Bugzilla blood bath time period. The ballot itself actually passed, but that was hit by an IPR notice. One of the CAs filed an IPR exclusion notice. IPR stands for intellectual property rights, and that process, which is followed after every ballot passes, allows any CA/Browser Forum member to file an exclusion notice against the ballot if they believe they have an IPR right that infringes on it.

TCTim CallanSo, I hold a patent on this. I don't intend to give my patent up. That kind of stuff?

Martijn KaterbargYes. Essentially, correct.

TCTim CallanAnd this also is extremely unusual, right Martijn?

Martijn KaterbargIt is. I believe the last time it happened was in 2018 prior to that. It's the first time I've seen it happen in my active time and but in the end, it was resolved, and the ballot, however, was retracted, so the language still hasn't made it into the BRs, but that is something that's being worked on through a different ballot at this point.

TCTim CallanSo that's a failed ballot.

Martijn KaterbargNext up, another one that came out of the Bugzilla time period is they're deleting the requirements for a CPS to be incorporated in EV TLS certificates. Again, that's almost a clarification ballot, but it removed a requirement. It's not something you would need to have any type of effective date for, because anything that's still allowed but no longer required, obviously some CAs can adjust to it on their own schedule.

TCTim CallanThat's a good point. When we pass the ballot, there will be an effective date, but if there's a ballot that's relaxing rules, there's no need for an effective date, because you can relax it. As soon as the ballot is passed, you can relax it or not whenever you want.

Martijn KaterbargNext up the weak keys ballot, and I think this is the ballot with the longest running time. I believe it was since 2021 under different name but essentially restructured the requirements around what we call DV weak keys, which is something from back from 2008 already, and added requirements for checking for few different private key vulnerabilities, such as the close primes vulnerability which we saw, I believe it emerged under 2023. So that one did pass after a very long, long time.

TCTim CallanAnd this just requires that CAs cannot allow these keys.

Martijn KaterbargAnd specifies how they should check for them, at least the minimum requirements for that. Next up, SC74 clarifying that CAs have to follow - here it is again – RFC3647 for the CP and CPS. That’s already a requirement but this one tried to clarify it a bit more in detail during the voting period, however, it was discovered that it might be a little bit too strict, and while a lot of CAs had already voted yes, essentially every CA changed their vote to no once that was highlighted. That's one another failed ballot in the end, which in this case is definitely a good thing.

TCTim CallanAlso very unusual to see CAs changing their votes during the voting period. Not something you see very often.

Martijn KaterbargNot that often. And let's try to not have it happen too often. Then SC75. Another important one – pre-signed linting, or pre-issuance linting. I hope the listeners know what linting is by now.

TCTim CallanWe have an episode called Don't Blame the Linter. Go listen to that if you want more on linting. Go on.

Martijn KaterbargIndeed. So yes, while most CAs did perform post-issuance linting already, pre-signed linting was apparently not done by every CA, and that is now an official requirement, and that very nicely coincided with our release of PKI metal just a few weeks after the ballot passed.

TCTim CallanSee our episode on PKI metal.

Martijn KaterbargThen SC76 added some again, clarified and improved the OCSP requirements, which essentially removed the concept of what we called reserved zero numbers, which I don't think any CA or very small number of CAs were using, and it allowed for a time between the signing of a certificate and publishing the first corresponding OCSP response. Previously, essentially, as soon as you had issued a certificate, the OCSP response had to be available.

TCTim CallanPreviously, essentially, as soon as you had issued a certificate, the OCSP response had to be available.

Martijn KaterbargYes. If you use the reserved serial numbers, technically, it would have been possible. But yes, this is a much better way. Well, using the resources essentially.

Then SC77 a very small cleanup item, essentially. Updating the Web Trust Audit name and version numbers. So Audit, Web Trust Audits are part of the requirements as well, and we just need to make sure that we keep up with the latest versions of their audit requirements.

SC78 - another realignment ballot, which allowed for the use of the DBA, or assumed name, together with a legal name and an organization name in a certificate. And this is something that interesting enough, was allowed for the EVGs. So for EV TLS, this was allowed. For S/MIME, this was allowed, but not for OV TLS certificates, which is unusual, and this ballot essentially realigned the BRs.

TCTim CallanWhich was a distinction that didn't have any value or purpose and certainly threatened to create a confusing situation where CAs doing their earnest best might nonetheless get it wrong, and is absolutely a good idea just to clean that up.

Martijn KaterbargAbsolutely. Another small, well, almost a realignment but not completely. It's a clarification and update to the use of certificate policies in cross-certified subordinate CA certificates.

So cross-signing is something that happens between CAs themselves. I mean, we cross-sign our root with our other root certificates, but it also happens between different CA owners. A different CA might want a particular CA’s ubiquity or being able to be trusted before they have their root included in a different root store. That’s not something allowed by default. You usually need to get permission from several root stores before doing that, but there was actually an option - - well, what we called the profiles ballot, which was done in 2023 missed a little bit in this section, where it didn't actually allow cross-signing root certificates, root CA certificates with multiple policy identifiers. We're getting a bit technical maybe now.

Policy identifiers essentially state what a CA is allowed to issue. Are they allowed to issue an OV certificate only, or a DV or an EV, but for root certificates in general, you would want to be able to issue all three of those. Even in the single purpose root world we're moving into, those still are all TLS. So you would still want to have the same root for all of your TLS issuance. Then coming to the last two ballots for the service or working group, the sunset of who is to identify domain contacts and relying DCV methods.

TCTim CallanSecond change to DCV this year.

Martijn KaterbargCorrect. I believe you've discussed this one as well, including the report so I won't dive too far into this ballot.

Then the final ballot went through voting, but failed, was the clarify CA Assistant DNS validation ballot, SC82. For this, we got some feedback during the voting period, after which several CAs voted yes, but none of the certificate consumers did, and thus it didn't meet the minimum requirements for the ballot to pass.

That's going back to CA/Browser Forum to the server cert working group, and it's being reworked into something that all parties are happy with. That's something we'll see coming back in 2025.

TCTim CallanThat's something we do see a lot. When a ballot fails, usually it doesn't just vanish. Usually what happens is it goes back to that working group, feedback is collected on why the ballot failed, and that group takes another run at it.

Martijn KaterbargYes, correct. And usually when someone votes no, there comes an explanation of why. It’s not a requirement, but it generally does happen, and obviously that's good feedback for the follow up process. Then, S/MIME. The last six ballots of our run this year. A lot of these are to align the S/MIME requirements, with the TLS BRs.

TCTim CallanThis is important, which is that each working group has to do its own balloting. So in the event that there's a requirement that we want to change, and we want the same thing to be true for both TLS and S/MIME, but it's going to require a ballot, it’s going to require two ballots, because there has to be one in each working group.

Martijn KaterbargYes, correct. Obviously, we really want this in general, because any differences in your requirements has a highly likely cost for errors in systems.

TCTim CallanIt makes development and design and QA much harder. It makes it harder for the consumers and the relying parties to understand what a certificate really means. There are great reasons for them to be as aligned as they can, considering that they are different use cases, but as much alignment as possible is a really smart idea.

Martijn KaterbargYes, S/MIME has a very effective process, in which usually multiple items are tackled in the same ballot, and they're very good to discuss during the calls.

So the first ballot, SMC05 is the adoption of CAA for S/MIME. Again, we have CAA for TLS. It is now also a requirement for S/MIME.

Next up, SMC06, a corrections and clarifications ballot. Obviously, the S/MIME BRs went into effect in September of 2023, so obviously, once everything was actually up and running items come forward which were not anticipated before. So clean up and corrections are definitely required there.

SMC07 - aligning logging requirements. That one lined with the previous battle we discussed, SC69. Essentially the same language imported. SMC08 is definitely a requirements change, however, and the deprecation of the legacy profile. And the legacy profile for S/MIME is a bit of an interesting one. It was essentially introduced to allow CAs and subscribers more time after the initial effective date to migrate to the new requirements. And it's a profile that allowed for more - what's the word I'm looking for?

TCTim CallanFlexibility.

Martijn KaterbargYes. Thank you. And it was also the only profile that allowed issuance for up to three years and with this deprecation, which will go into effect halfway of 2025, S/MIME will be limited to 825 days.

TCTim CallanAnd so the legacy profile was kind of a transitional thing. It was a way for people to transition, like you said, and we knew from the beginning. We knew before any S/MIME BRs were ever passed that the legacy profile, the plan was to deprecate it. And so this isn't a surprise. This is by design.

Martijn KaterbargIt is by design. I think some CAs would have preferred it to be a bit later. Others preferred to be earlier. There's different interpretations on that. I believe this in July of next year, and I think that's a perfectly reasonable days for this to be deprecated.

On to the last two. SMC09. Another one that aligns essentially. It’s for the WebTrust Audit schemes and pre-linting requirements. There's linting again. For S/MIME. Several of the linters out there already allow for the linting of S/MIME certificates. So it's very good to have a requirements for that. And the last ballot which passed - SMC10 - is still in its IPR review period, and that is MPIC for S/MIME.

TCTim CallanNow how do the dates on MPIC for S/MIME line up to the dates for TLS?

Martijn KaterbargFairly much the same, except that the initial requirement date is set two months later, and that mainly allows for the CAs that do S/MIME but don't do TLS to have some more time to align with that requirement. I think most CAs that are doing TLS won't have too many problems doing it for S/MIME at the same time.

TCTim CallanYes. You see a lot of alignment between the S/MIME, like you said. The CA for S/MIME, MPIC for S/MIME. Those other changes for S/MIME. You see where that's the strategy, and obviously, good strategy.

Martijn KaterbargAbsolutely. And we can also see that most of these, not all of them, but a lot of these are DCV and CAA, and that's why we haven't seen those on code signing yet, because CAA and DCV aren't really things for code signing.

TCTim CallanSo you said there's one ballot that's in flight right now. What's that?

Martijn KaterbargThere is a ballot in flight right now, which is a ballot we've launched. It's in our discussion period, and it's a cleanup ballot. I think we've tackled about 20 open issues on the CA/Browser Forum GitHub page, and all of these are essentially clarifications and cleanups. Some are typos, some are re-phrased wording. And then we have another ballot that might be started this year, or we'll see if that happens in the early weeks of 2025, which is SC81.

TCTim CallanBy the time this airs, it will be 2025 so the listeners may know the answer to that. But right now we're recording this in December, so we'll see how all of that plays out.

Let me ask you, Martijn, so we talked about how much more activity there was this year, and then the explanations you gave struck me as explanations that are going to be persistent. Like if there's always going to be a doubling of ballots across S/MIME and SC working group, when the two of those are both relevant, and if we're going to have a NetSec working group that's going to be more active than it was in the past, these don't feel to me like things that are going away. So I guess my question to you is, is this new volume of ballots, maybe more like 30 than like 10, is that the new normal? Is that what we should expect?

Martijn KaterbargWe might very well, Tim, indeed. I hope maybe we'll land on somewhere around maybe 25 or something. I think we can dial it down a little bit more. But obviously, if things need to change for a reason, we're not going to hold it because we think we've done too many ballots, but we do need to make sure that CAs are able to keep up with all the ballot setting requirements as well.

Jason SorokoMartijn, I'm not going to let you get away from this episode without peering into 2025, we try to make a categorization and an oversimplification of what 2023 was about, 2024. What do you think 2025 is going to be about?

Martijn Katerbarg2025. That's a good question. We have a moving from multi-purpose roots to single purpose roots. That's something I think we'll see a lot more about in 2025 and we also know that it's already been discussed somewhat, the removal of client authentication as an EKU from TLS certificates, at least. So that's another one. Moving the WebPKI really into specifically TLS, and not anything additionally that we can cram into the certificate is something that I believe we'll see more of next year, and obviously, like we already mentioned, SC81, the reduction in both lifetime for TLS certificates and validation and DCV reuse.

TCTim CallanThat's going to be the big story of the year. Pass or fail. That will be the big story of the year. And we'll cover it here. So thank you very much, Martijn. I think it was a big project to put that all together and giving the listeners the opportunity to hear just about what goes on that way in CA/Browser Forum I think, is interesting and valuable.

Martijn KaterbargI agree. And thank you very much, Tim and Jason.

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!