Root Causes 201: What Are the Baseline Requirements?

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

January 24, 2022

The CA/Browser Forum Baseline Requirements (BR) are hugely influential in the world of public-trust certificates. In this episode we explain what the Baseline Requirements are, how they are created, and why they matter.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanThis is one of our explanation episodes. Sometimes we just like to take something and define it and explain it for people who aren’t really insiders and, in this case, we want to explain what are the Baseline Requirements. So, this is a phrase that shows up in this podcast once in a while and I’ll say, wow, the Baseline Requirements say this and that but what does that word really mean? We know what baseline is. We know what requirements are but when Tim says, “the Baseline Requirements” what is he referring to?

Jason SorokoI think everybody who listens to this podcast, or any technology podcast, uses a web browser. I don’t think most people realize the enormity of the work that goes into making browsers safe, the technologies around it, including things such as your certificate root store, which involves a lot of vendors. From the browsers, vendors themselves, to the CAs and other people that are part of the ecosystem and you’re involved very heavily, Tim. With the CA/Browser Forum which is involved with that. And you guys have rules and the BRs are a big chunk of that.

Tim CallanOnce upon a time there weren’t rules. Like if we go back to the mid-90s, to 1995, what happened was this thing called the World Wide Web was taking off and people needed to be able to have secure connections, they needed to be able to do cryptic connections and they needed to be able to reliably understand that they were connecting to the machine they thought they were connecting to and so in order to do this, existing schemes were modified and we came up with this thing called at the time an SSL certificate. Later they were named TLS, but SSL stuck. But there weren’t really any codified rules around how these Certificate Authorities, these CAs, created SSL certificates and so VeriSign made up a set of rules and Comodo made up a set of rules and they just kind of all had their rules and they were running their rules and different CAs had very different approaches and this was considered to be secret sauce so CAs didn’t know what the other CAs did. They didn’t tell anybody. They sort of kept it behind closed doors and the CA/Browser Forum in the early 2010s took on this challenge and said there needed to be a reliable visible set of rules that CAs are following. We need to know that they’re uniformly high. We also need to know that they are uniform. What they are and what they aren’t and there needs to be transparency. The public needs to know what it’s getting and after a good deal of work in 2012, the CA/Browser Forum established these rules, the Baseline Requirements, which is to say the minimal requirements that a public CA must follow for inclusion in the popular browsers’ root stores. Then the popular browsers have added into their own root store policy frameworks that the CA/Browser Forum BR compliance is a requirement for inclusion in their root stores. And in so doing, they’ve taken these rules and they’ve given them a strong degree of power in terms of what public CAs must do.

Jason SorokoSo, Tim, you guys meet from time to time and I’m sure that there’s healthy debate on current rules and new rules. How fluid is it? I get the impression that even though there used to be a time when there was none, the codified set of rules we have right now don’t change often but they are still is sometimes new and modified rules that take place.

Tim CallanThere are multiple ballots a year that are passed and most of them change the Baseline Requirements. Some of them change the EV Guidelines which is the guidelines for extended validation specifically. But, most of them are quite specific and minor and relatively esoteric. But once in a while they’re really big. So, I think you and I talked in an earlier podcast about earlier this year a pretty major form of domain control validation was modified in a very significant way and there was a deadline and after the deadline we could only do it the new way and you couldn’t do it the old way anymore. And that sort of thing does occur and there are major ballots like that at least annually, maybe a couple times a year and then there’s a nice cadence of small ballots that are going on all the time and so, CAs do have to remain current with this. Now at the same time, I think there’s still a lot to be done. So, even though it feels like it’s been almost 10 years, it’s been going on 10 years since they were published in 2012 originally, nonetheless there are sections of the Baseline Requirements that are open to interpretation. There are things that aren’t really spelled out. There are things where you might debate exactly what is required and meant and oftentimes what happens is people look at precedent. It’s almost like common law. You go, oh, well this is what other people have been doing and it has been deemed ok so we are going to assume that we will be ok if we do the same thing. There is a great deal of that and the reason is because this document is huge. It’s very long. It covers lots of things. It covers physical security, IT security, authentication practices in various forms and there’s just certificate morphology. There’s just a lot there. Because there’s a lot there, there is a lot that could still be I think filled in and tightened down and that’s a lot of what these ballots are about is exactly that – filling in the gaps, tightening things down, clarifying things where before they were not quite clear.

Jason SorokoTim, maybe you won’t be able to hit every one of them but give me some categories of the types of rule sets that there are just in general. I can think of two off the top of my head which is, rules around how you validate a domain. Rules around the fields in a certificate and those are two real basic categories at a very high level. What would be some other categories that people might know or not know?

Tim CallanThose are some of them. Absolutely – how do I validate a domain but how do I validate other information that’s in that side of certificates. So, if I’m gonna say that the certificate has been issued to this organization name, how do I know that’s really that organization name? What are the rules that I follow to determine that? How do I determine that the person who has requested the certificate is authorized to do so? There are rules around how I do that. How do I determine that the domain name is really in control of that person? How about things like term? What’s the maximum term for certificates of various types. That’s laid out. Things like physical security requirements, network security requirements that you need to operate, be operating your CA successfully and not just what fields are included but what is the nature of the information in those fields. I’ll give you an example of that.

So, one of the fields is called state name. There is a field called country name and for any OV, organization-validated certificate, you need to have a country name. You need to say what country this organization is in and then there are a pair of fields. One is called state name and the other one is called locality name. For an OV certificate, you must have at least one of these two. So, you must have a state name or you must have a locality name or you may have both. There is some logic behind there. You can take that concept I just said, and you can kind of unpeel it and I can state it a different way, which is if state name is not present you must have locality name. If locality name is not present, you must have state name. When you start thinking about it that way you see there’s also some logic around what and cannot be included or what must be included under certain circumstances.

This is my point earlier about how these things get pretty complex. There’s a lot going on and then another major one that’s very important is that the CA’s practices need to match the CA’s CPS. So, a CPS is a Certificate Practice of Statement. This is where a CA publishes this is what we do. This is how we might authenticate your domain name. What we call DCV. This is how we might authenticate your organization. This is how we might etc., etc. All of those things the CA has to spell out in the CPS and then part of what the Baseline Requirements say is that what you actually do has to correspond to what’s in your CPS. That’s about this visibility point that I made before where people or anybody who knows how to read these documents can go to your website, get these documents, read them and have a good basic understanding of what it is that the CA does and they can know that so that when they look at one of these certificates they can safely make certain assumptions about what that certificate does and does not mean.

Jason SorokoThere’s different ways we can go here but I think the consequences of not following the rules are something that we have seen in the past and we’ve even podcasted on this of various CAs that consistently not following the rules. What’s the mechanism of dealing with this, Tim, and what is the history of it?

Tim CallanThis is a very important point about Baseline Requirements and about the CA/Browser Forum in general, which is the CA/Browser Forum is not any kind of legally mandated or government mandated organization and as such, it has no enforcement power. It is literally a voluntary group of industry peers who come together to create standards. Where does the enforcement power come from? The enforcement power comes from the browser root programs. If one of the major root programs decided to distrust your roots, then your public certificates would not be viable for general use cases. Maybe a specific use case but general use cases your certs would not be viable. Let’s say the entire Apple technology stack stopped paying attention to your certs, I can’t put that on my website anymore because I can’t rely on the fact that people aren’t coming to me with an Apple device. That’s an example. Apple is one of the root store programs. That’s the ultimate consequence.

The ultimate consequence is that one or more root store programs say, look, we just can’t trust you. We’ve seen that. You and I have podcasted on that. That happens once every couple years or so to a CA in one place or another and very, very visibly and very obviously in 2017 to Symantec. That was a big deal when that occurred. But that’s sort of the nuclear option. That’s the death penalty.

Without getting to the death penalty, there are other consequences, and a lot of the consequences are that the CAs have to publicly report any violation. Anytime a CA becomes aware of anything that is non-compliant with the Baseline Requirements, they have to do a detailed public report and they are subject to public scrutiny and they oftentimes are subject to a great deal of scrutiny and depending on exactly what went wrong, various outsiders might go onto the forum where this occurs called Bugzilla and ask the CA very detailed questions and the CA is expected to respond to these and deal with them and satisfy the community that the problem that occurred won’t occur again.

And so, that’s the biggest mitigation because, as I said, these rules are long, they are complicated, they are in places vague and it still occurs on a regular basis that CAs unwittingly find themselves out of alignment with something in these rules and often it’s something quite subtle. But under those circumstances, the CA is expected to report it, the CA is expected to understand why it happened and what to do about it and to have a clear plan and then the public is allowed to ask questions and clarify and criticize that plan and things along those lines and the public does and that’s the main mechanism and that’s going on all the time. Day in and day out that’s going on. It’s just part of running a large, complicated web PKI with many players.

Jason SorokoTalking about running a large, complicated PKI and CA, that’s why I’m very glad that you are focused individual as a Chief Compliance Officer on that, Tim. It’s quite a job. I think though, in order to make it work, we all have to be aligned right behind you in terms of making sure we are all doing the right thing and I think that that’s what a good CA should be doing. Having a focused office on this.

Tim CallanIt’s interesting. Like every new employee at Sectigo must go through a kind of lengthy training around the expectations of a public CA and I mean it’s like an hours’ worth of training. It’s a lot. And this is no matter what you do. You might be in accounting, you might have nothing to do with it at all but our believe is that there is a certain basic level of knowledge that every single employee needs to have. And then, of course, obviously, if you are specialized, if you are a validation specialist or something like that you have a great deal more training. But everybody is expected to have a certain – I don’t want to say baseline, but I guess I will, a certain baseline knowledge that they have coming into it because that’s what we are and that’s what we have to be.

Jason SorokoThat’s great, Tim. Thank you for that. I think we’ve had a lot of podcasts and we’ve mentioned BRs and Baseline Requirements and various rules around publicly-trusted certificates a lot. It was great to start 2022 with setting a baseline of knowledge of what these things are and thank you for that, Tim.

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!