Podcast
Root Causes 451: A Year in CABF Ballots


Hosted by
Jason Soroko
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.
All right, so tell us about your LinkedIn exercise. What did you do?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
