Root Causes 258: New S/MIME Baseline Requirements Ratified

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  There’s been a pretty important development in the world of S/MIME, and we wanted to catch the listeners up on it today.

• 

  Jason Soroko

  Email encryption. Let’s talk about it.

• 

  Tim Callan

  Not just email. That’s one of the things about S/MIME. The M in S/MIME stands for messaging, but S/MIME certs historically have been used for a broad variety of applications and that’s actually one of the bits of complexity here that definitely deserves a place in this conversation. But, yes. S/MIME certificates are broadly used to attach to email, or they’re often broadly used as device certificates basically. You put them on something like a laptop and it handles various login credentials. Try to log into a system, and it looks for the S/MIME cert and it says, ok, the cert is here; I’m gonna allow you to go in. These things very frequently are done through S/MIME.

  So the short, short on the headline is that the CA/Browser Forum very recently passed the first ever set of Baseline Requirements for S/MIME certificates.

• 

  Jason Soroko

  Ok. So, the SSL use case that we know and love which is putting TLS certificates on your webserver in order to be able to encrypt communications between webserver and the browser, you get the https, that’s a use case most of us know very well. It’s pretty intuitive in our minds. That has a lot of baseline requirements through the CA/Browser Forum. So, what you are saying now is S/MIME certificates, which are used for a number of reasons as you pointed out, email encryption and email system authentication being maybe the top two, you are saying now Baseline Requirements are coming out for that?

• 

  Tim Callan

  Absolutely. If we go back in time - and this will harken back to some of our other episodes we’ve had in the past – if you go back in time, once upon a time every CA made its own rules and those rules were often quite opaque and it was difficult for an outsider to judge to what degree can I trust this certificate and what do I trust about this certificate, and that was fundamentally the genesis of first, Extended Validation and later on, Baseline Requirements, and so possibly not surprisingly, it really all started with SSL. That being the biggest use case by a long shot. Then we saw code signing. Similar thing. And now, a decent number of years later, we have seen that S/MIME certificates are being brought under BRs because S/MIME today is exactly in the same situation. Every CA establishes its own S/MIME policies. CAs are expected to do a good job but there’s no definition of what good job means. And so that leads to the same problems that we had with SSL – inconsistent behaviors and inconsistent level of quality, lack of understanding of these behaviors and level of qualities, lack of information to judge which CAs are better and which CAs are worse. All of that stuff is just the day-to-day existence in the S/MIME world and so this was an effort, and it was a long and complicated effort by a number of dedicated people in the CA/Browser Forum to change that and make S/MIME certificates be more predictable, more understandable, and ultimately more universally trusted.

• 

  Jason Soroko

  What are the kinds of properties that are being ruled over here, Tim? Is it the validation process? Is it the certificate profile? What’s the main thing?

• 

  Tim Callan

  Yeah. It’s just like with the SSL BRs. It’s all that stuff. So, there are things like the morphology of a certificate. There’s a good amount of attention spent to validation, what a certificate can attest to or not attest to and if it is attesting to it, how that needs to be proven for the CA and there’s some other general CA operational requirements just like you have for SSL. You need to have, you know, physical security in your systems. Stuff like that. So, some of it feels a lot like SSL. It’s not really surprising. What’s interesting about S/MIME is that we did have to deal with these very many different ways that they’re being used. And so that’s kind of I think what we should maybe focus on today.

  When the BRs come out, there are four – and let’s get to dates too – but when the BRs came out, they have four different levels of validation and three different what I’ll call profiles and you can imagine it as a 4 X 3 matrix. So, there’s 12 boxes and a cert can sit in any of those 12 boxes. All of them at least on day 1 are equally legitimate.

  So, let’s start with validation levels. What do you say?

• 

  Jason Soroko

  Let’s do it.

• 

  Tim Callan

  Alright. S/MIME certs are used a lot of different ways. Sometimes an individual takes it, and they stick in on their email and get on with their lives. Sometimes the company is giving it to you, etc. Just like email is used in a lot of different ways. So, the validation levels reflect that.

  The first validation level is simply called Mailbox level, and Mailbox level validation is just we validate the email address. You have to have control over this email address. If you don’t have control of this email address, you don’t get the cert. We are not gonna attest anything else about you. That’s the S/MIME equivalent of a DV certificate. A DV certificate says all I’m gonna attest is that you control this domain. I don’t know who you are, where you are, or anything else. I just know you control this domain. Same thing with a mailbox level S/MIME cert. All we know is you control the certificate and just like with DV, this is likely to be the quickest one to issue because there will be an automated thing. You’ll be able to respond in real time. You get the email, you click on the thing, now you’ve validated that you control the mailbox, and you get on with your life. So, that’ll in many ways probably be the quickest and most convenient.

  Next is what we call Organization validation. And Organization validation also validates the email address. They all do. But it also validates the name of the company or other organization that you are using the certificate for. It does not validate any individual’s name. So, this is for the scenario where I want to put an S/MIME certificate on an email address that is not specific to a person. This is [email protected], [email protected], or my email program or my marketing promotion that I’m running right now @companyname.com. Right? And in that case, if you want to put an S/MIME certificate on that, it doesn’t get attached to an individual. It’s not your marketing programs manager. It is just the company. And so, under those circumstances, we validate the email and the organization name and that’s called Organization validation. And perhaps not surprisingly, Organization validation looks an awful darn lot like what we do today for SSL and code signing. Right? Of course, because we are gonna use the benefit of all that work, we’ve done for all those years getting those things optimized and dialed in.

  Then the third level is what we call Sponsored. And Sponsored is an individual in an organization. So, in this case, we have the email, the organization name and the individual’s name. So, if you, Jason, wanted to put an S/MIME on your work email, which I know from experience you have one, and you wanted it to be associated with your name, this is the one you would get. It would be this is Jason.Soroko as a Sectigo employee and the cert contains all of that information. So that’s what we call Sponsored.

  And then the last one is Individual. This is for an individual, but it isn’t supposed to be associated with an organization. So if you wanted an S/MIME certificate for your own personal email, which I bet you you have, then that’s what we would do in that case. It would be an email and it would be the natural person who gets that email regardless of where they are employed because the company or the organization is not part of this.

  So, those are those four validation levels and maybe validation level isn’t quite the right word but it’s the scope of what is validated.

• 

  Jason Soroko

  That’s great, Tim. Thanks for going through the typology of those. I think it does highlight the kinds of ways that we want to be representative and how our identities are tied to other things, so it makes a lot of sense.

• 

  Tim Callan

  Yeah. And a lot – thank you for that – a lot of attention was paid to this point, which is how are these used in the real world? How can we lasso this craziness without breaking people who are using certificates because there was a general acceptance of the idea of well, if we just chase people away from using certificates to not using certificates, we didn’t make it better. So, let’s not do that. Let’s try to figure out a way where we don’t do that.

  Then there were profiles and I want to think of whether I want to do this. I think let’s start, let’s go strictest to loosest.

  So, the first profile is what we call Strict. So, a Strict S/MIME certificate is only used for the S/MIME purpose. You attach it to email. That is what you do and if that is set, if it’s set that way in the certificate, then that is the only thing you can actually use it for legally. That’s the strictest profile. It is called Strict.

• 

  Jason Soroko

  Thanks, Tim. Just want to connect that real quickly to private TLS certificates. A lot of you might not know but you can utilize TLS certificates for a lot of things including encryption, signing, etc. and I think that what is interesting about that is actually regarding the ability to restrict a certificate’s usage to one of those things or two of those things out of three and so, Tim, what you are saying here is the rule sets for that are now being brought into S/MIME, which is what you were saying?

• 

  Tim Callan

  Yes. Absolutely.

  The next one up the scale or down the scale depending on how you look at it is called Multi-purpose. And Multi-purpose allows multiple defined purposes. For example, S/MIME and document signing. So, you say I’m gonna put this on your laptop. You are gonna be able to sign documents. You are also gonna be able to use it to attach to your email. This is a multi-purpose certificate. The EKU is set that way, and that’s how you use it. Now, the S/MIME and multipurpose profiles are capped at two years in term. So, you’ll be maxed out at two years and right now, there’s no rules. In principle, you could issue a 20-year S/MIME certificate. We don’t, but you could. There are no rules. And so, those two will be capped at two years.

  And then the last profile is what we call Legacy and Legacy is up to three years in term and the rules in general are looser. The idea there is that’s where we are giving everybody a chance to transition. So, you can order Legacy certificates. They work pretty effectively in the scenarios you are using them for today. You start plugging them in and then you know that you are gonna have a certain amount of time where you are gonna have to be able to fit into the specific set of requirements that are in the BRs and in that kind of timeframe, that’s gonna have to happen. But there’s a lot of time built in there because the terms are allowed to be up to three years, and there’s time between now and when the new S/MIME BRs actually come into effect, and there will be time between when the BRs come into effect and when those get deprecated. But the understanding that is unambiguous that has already been discussed in the CA/Browser Forum discussion about this (and everybody who is involved is really kind of in principle in agreement) is we are going to return to this and build a deprecation plan and a deprecation schedule into the rules so that the legacy profile in the long run will go away. If you telegraph it well in advance, let people know that this is coming so they can see it, don’t break what they have today but also make it clear that, look, here’s a clear schedule and in this schedule you are gonna have to transition. And that’s believed and I think correctly that’s believed to be the best alternative for enforcing rigor around S/MIME without just chasing people away from certificate use altogether.

• 

  Jason Soroko

  That seems very reasonable. I think two years is well considered timeframe and the ability to allow for legacy usage with that well-telegraphed timeframe change, Tim, I think this really sounds like somebody did some really good hard thinking about this.

• 

  Tim Callan

  It was a lot of work.

• 

  Jason Soroko

  Yeah. I’m sure it was and it’s not easy to bring that many people with different opinions all together, so I’m glad it happened.

• 

  Tim Callan

  Then the other thing probably is the timing. So, as I said, the Baseline Requirements were passed. There’s always some amount of time between when a requirement is passed and when it goes into effect. Because we all understand that people don’t just snap their fingers and things are done. In this case, the exact date is still a little wiggly but more or less September 1, 2023, basically, will be the date that this goes into effect. So, by that date, then, CAs will need to follow these rules for the public S/MIME certificates that they issue. The exact same way they need to follow the rules for the TLS and the code signing certificates that they issue.

• 

  Jason Soroko

  So, for the end user of S/MIME certificates – and I’m thinking especially at the enterprise level or even at the personal level – there doesn’t seem to be a ton to have to worry about. A lot of it is at the CA end. And it’s all about keeping ourselves honest and making sure that we are measurable against a set of rules and that’s all very, very good. Thinking of those end users, it does sound like there will be some options probably when you are subscribing to an S/MIME, when you are going to get S/MIME provisioned to yourselves, it does sound like there will be some decisions to be made which are all positive and for those of you who are security conscious, that’s why I did bring up that extra little point about the ability to think about your S/MIME certificates the same way as TLS in the sense that you can now restrict, which I think is a great option. If you are just using them for email, use that strict option. It just makes sense.

• 

  Tim Callan

  For the end user, the individual who has it on their computer and they are just doing their thing, it’s not gonna really change in a meaningful way. You are right. The CA actually hasn’t done a bunch of stuff. The organizations that are getting these certificates for their employees to use are gonna have to understand, right? What certificate do I think I’m getting? Am I getting the certificate that I really want? You know, there are four different validation profiles. There are three different purpose profiles and how am I going to make sure that I am picking the right things. And so, that might require a little bit of thinking that isn’t really required when one kind of certificate can do everything. But this isn’t difficult. IT organizations do harder things all the time. It's just it’s now a part of the consideration set that will have to be in the mix when right now there’s not really a choice to be made.

• 

  Jason Soroko

  Ultimately, it’s positive because both dimensions of the matrix, both decision making trees that you have to go down basically are security context. How are you using these certs? And it’s a good thing to make those choices explicitly and now you’ll be able to. So, it’s positive.

• 

  Tim Callan

  I agree with you. I think this was well done. It’s a tough one and early on when we were discussing this, everybody kind of said, this is gonna require a lot of thought and consideration. And I think that thought and consideration occurred. I think we wound up in the right place. I think we have the right first draft BRs. We will change them, of course. We always change them, right? But we have the right first draft BRs, and this is definitely positive step forward for S/MIME certificates.

• 

  Jason Soroko

  Great podcast, Tim. I now know a lot more about what this change is. I’ve heard a lot about it and now I feel like I’ve got a grasp on it, and I could probably re-pitch it. So, thanks for that.