Podcast
Root Causes 179: Standards for Certificates Apart from SSL
Hosted by
Jason Soroko
Fellow
Original broadcast date
August 24, 2021
Regular followers of this podcast hear a great deal about SSL, the CA/Browser Forum, and the standards governing public SSL. But SSL is not the only regulated type of public digital certificate. There are also things like S/MIME, eIDAS, code signing, document signing, and SSH certificates. In this episode our hosts discuss these "other" certificate types and the rules and regulations governing them.
Podcast transcript
Lightly edited for flow and brevity.
TCTim CallanSo, today, we are gonna talk - - so, we talk a lot just because it’s a big part of the world of certificates in general, we talk a lot about SSL and in the world of public certificates, oftentimes people sort of, they make, they almost use the words interchangeably. Right? You almost talk about certs when you mean SSL certs in particular and so, today, we thought we would talk about kinds of certs that aren’t SSL.
Jason SorokoPrivately trusted certificates. Would that be the main category?TCTim CallanWell, privately trusted certificates, yes. What I actually wanted to go was a slightly different direction that that, which is - - because SLL, of course, could be privately trusted. Right? Public/private trust is just a function of the root and where the roots are sitting. You know, are they sitting in the publicly trusted root stores that are in major operating systems and browsers? If so, they are called publicly trusted; otherwise, they are called privately trusted.
Jason SorokoThat’s true.TCTim CallanYou can issue private trust SSL certs. But…if we look at the world of public trust, SSL isn’t the only type of certificate. There are others out there as well.
Jason SorokoSure. That sounds really interesting, Tim. I mean I deal with all kinds of certificates out there, so, interested to hear the ones you’ll be talking about.TCTim CallanYeah. So, and, so, if you look, you know, in principle, you could issue all kinds of certificates on your public root and the CA only has to follow their Certificate Practices Statement for that. So, if I wanted to give you public trust client certs to put on your laptop, I can do that. Right? Um, in the world of what I want to call regulated certificates, let’s just say through the CA/Browser Forum and the major root store programs, there are a few kinds of certificates that you are gonna see. SSL, of course, is the big one. But, in addition to that, we have Code Signing certificates. Code Signing certificates do have regulations. There are S/MIME certificates, of course, which we attach to our emails. There are things like document signing certificates and eIDAS certificates and these are all out there in the world as well.
Jason SorokoThat’s exactly right. That’s exactly what I was thinking when you were going down that road. Code Signing especially - - I think the big one to me, maybe the next big one just in terms of volume would be S/MIME. Potentially.TCTim CallanYeah.
Jason SorokoBut I do think that Document Signing certificates are coming up a close second or third.TCTim CallanYeah. And so, these things - - what are the rules around these things? Right? Becomes kind of an interesting question. So, in the case of the eIDAS certificates, they are all based on ETSI? So, ETSI is a European standards organization. ETSI wanted to have these reliable certificate types and they built the eIDAS standard around that and so if you want to issue eIDAS-compliant certificates, you are issuing certificates that are based not on the CA/Browser Forum based on requirements and EV Guidelines but based on ETSI eIDAS standards instead.
Jason SorokoI would say, Tim, it used to be it was a very small list of vendors or providers of those certificates. That list has grown but it hasn’t exploded. It’s not easy to get that designation.TCTim CallanYeah. And it’s not, they are not - - it’s a non-trivial certificate base certainly but it’s nowhere near the size of the certificate types that have been around for a long, long, long, long, long time, especially SSL and so, just the total scope of what you are dealing with is so much bigger in the SSL world than the eIDAS certs but it is a very important one.
Another one you mentioned is Code Signing. Code Signing is venerable. Code Signing has been - - or I guess it’s one I mentioned is Code Signing. Code Signing is venerable. Code Signing has been around almost as long as SSL has and Code Signing is kind of an interesting animal because for a long time – so we had regular Code Signing and we have EV Code Signing and all Code Signing certs were considered to be covered by the baseline requirements. Same thing that covers SSL. And the EV Code Signing certificates were covered by the EV Guidelines. Same thing that covers EV SSL and what’s interesting about that of course was that they are, and have been, they are different certificate types. So, for instance, there is a lot of focus on domain validation in the BRs and there are no domains in Code Signing certificates. Right? And timestamping is an important part of Code Signing and there is no discussion of timestamping in the BRs. So, what has been needed and the CA/Browser Forum has put together is specific guidelines that are focused on Code Signing so that you can understand what the rules look like in a Code Signing scenario in particular since it is a different kind of cert and it is focused on a very different use case.
Another one you mentioned is Code Signing. Code Signing is venerable. Code Signing has been - - or I guess it’s one I mentioned is Code Signing. Code Signing is venerable. Code Signing has been around almost as long as SSL has and Code Signing is kind of an interesting animal because for a long time – so we had regular Code Signing and we have EV Code Signing and all Code Signing certs were considered to be covered by the baseline requirements. Same thing that covers SSL. And the EV Code Signing certificates were covered by the EV Guidelines. Same thing that covers EV SSL and what’s interesting about that of course was that they are, and have been, they are different certificate types. So, for instance, there is a lot of focus on domain validation in the BRs and there are no domains in Code Signing certificates. Right? And timestamping is an important part of Code Signing and there is no discussion of timestamping in the BRs. So, what has been needed and the CA/Browser Forum has put together is specific guidelines that are focused on Code Signing so that you can understand what the rules look like in a Code Signing scenario in particular since it is a different kind of cert and it is focused on a very different use case.
Jason SorokoYeah, Tim. And, in fact, just to blend in another type here which is another typing of signing, Document Signing, both Document Signing and Code Signing have that importance of timestamping. I would say that there is an interesting parallel between SSL certificates and the signing types of certificates. Even though we don’t call them the same thing, the SSL certificates have the CT logs as a way of publicly tracking.TCTim CallanRight.
Jason SorokoI would say that for Code Signing timestamping, both these things exist on Merkle trees, right?TCTim CallanRight.
Jason SorokoSo, therefore, they are one-way hash lists that are published publicly typically on more than one node and the reason I spell all of that out is because that’s a long way to almost being blockchain.TCTim CallanYeah. Yeah.
Jason SorokoRight. It’s not blockchain. It’s not. But it employs a lot - - it does the same things for a lot of the same reasons, which are you want to have more than one publisher of the hash list and the fact that it is a hash list and the fact that it is one way. So, it accomplishes that capability of the public being able to look at what has been published in terms of SSL certificates and the timestamps.TCTim CallanRight. Right. And then, the other thing that’s interesting of course about document signing is it lives in its own different ecosystem. Like, so, for example, if you want to sign PDFs then the compliance requirements you need to follow are the Adobe compliance requirements. It’s a program called AATL and that is actually the owner. Adobe is the owner of that particular trusted root store. So, for the CA to participate in that world it doesn’t matter what they do with regard to baseline requirements, what matters is what they do with regard to Adobe’s program. So, that’s another way that these different certificate types have different compliance rules and different rules that you need to follow. Just like with the eIDAS and ETSI.
Now, we haven’t talked - - what you did mention in the beginning and we haven’t really talked about is S/MIME. So, S/MIME is basically unregulated right now. So, again, the CA is expected to follow their Certificate Practices Statements but other than that, there is not really a program anywhere that says this is what you must do to issue a compliant S/MIME certificate and as a consequence, there is a lot of latitude and there could be a lot of variability and so the CA/Browser Forum recognizes this and has formed a working group, subcommittee, to create, to author and ratify a series of S/MIME baseline requirements essentially. So, you’ll have requirements for issuing S/MIME certificates the same way that there are requirements for let’s say SSL or Code Signing certificates and that, of course, has a few positive consequences. It creates a certain level of consistency so parties can know what to expect in terms of what information there is, what that information means and how it works and then also, there is a certain level of quality enforcement. Right? Practices that are deemed to be reliable and high-quality practices become codified and practices that are not become omitted and, in that way, CAs can do the things that are known to work. And so, - - and those of course can be adjusted over time just like has happened let’s say with the baseline requirements or the EV Guidelines. And so, that is on the way, too. I can’t tell you exactly when that will be ready but that is something that is in the works.
Now, we haven’t talked - - what you did mention in the beginning and we haven’t really talked about is S/MIME. So, S/MIME is basically unregulated right now. So, again, the CA is expected to follow their Certificate Practices Statements but other than that, there is not really a program anywhere that says this is what you must do to issue a compliant S/MIME certificate and as a consequence, there is a lot of latitude and there could be a lot of variability and so the CA/Browser Forum recognizes this and has formed a working group, subcommittee, to create, to author and ratify a series of S/MIME baseline requirements essentially. So, you’ll have requirements for issuing S/MIME certificates the same way that there are requirements for let’s say SSL or Code Signing certificates and that, of course, has a few positive consequences. It creates a certain level of consistency so parties can know what to expect in terms of what information there is, what that information means and how it works and then also, there is a certain level of quality enforcement. Right? Practices that are deemed to be reliable and high-quality practices become codified and practices that are not become omitted and, in that way, CAs can do the things that are known to work. And so, - - and those of course can be adjusted over time just like has happened let’s say with the baseline requirements or the EV Guidelines. And so, that is on the way, too. I can’t tell you exactly when that will be ready but that is something that is in the works.
Jason SorokoThat’s a really positive development. Obviously, the CAs have a lot of interest in that. I would say though, the other people who would be interested – and this is the parallel I would draw S/MIME to SSL is this is one of the certificate types where artifacts you see, elements you see on your client that is consuming or utilizing that certificate are very important. So, therefore, when you use SSL you typically, using that your client is the browser. With S/MIME, it’s gonna be your email client.TCTim CallanUh-huh.
Jason SorokoAnd I would say that what you’ve just told us – which is the fact that there’s gonna be some established rules around S/MIME is very positive because it’ll really help to drive not just usage of SSL overall, I think, but it definitely will help the look and feel potentially of how S/MIME works within the clients themselves so that would make the customer’s experience of using S/MIME just that much better. So, that’s very positive.TCTim CallanIt certainly could and that’s definitely one possible outcome. Right? If the S/MIME cert is known to contain information of a certain type and it means a certain thing and it’s consistent then clients have the potential to do things with that information that’s tough when it’s not consistent. So, yeah. So, those are probably the main certificate types and those are the various groups that have a hand in determining what they are and what the rules are and this is just good to know because as a public CA, you know, again, we talk so much about SSL and we talk so much about BRs and that’s fine but as a public CA, we are obliged. If we want to issue these other kinds of certificates to work with and follow the rules and the guidelines and the root program requirements that exist for those as well.
Jason SorokoTim, just before we go, I’d like to introduce another important certificate type that you might not have heard about but you will in the near future.TCTim CallanWhat’s that?
Jason SorokoAnd that’s SSH certificates.TCTim CallanOh, sure. Ok. Yeah.
Jason SorokoAnd, so, therefore, I think every - - well, I would say most people listening to this podcast are probably very used to dealing with SSH keys.TCTim CallanYeah.
Jason SorokoKey pairs generated. Right? In order to be able to allow you to authenticate into remote systems - typically, Linux systems – with SSH protocol and that’s a huge positive. The problem, of course, is that key management is not easy and having a certificate allows you to envelope that key material with policies such as expiry date. Right? Very important.TCTim CallanYeah. For sure.
Jason SorokoAnd, so, therefore, what are the PKI concepts that now we can bring to bear against those certificates, just like we do with any of our other public and private certificate types. That’s a very interesting topic that I don’t think has gone through the scrutiny yet - outside of just simply the standard being defined, I don’t think that, you know, it hasn’t gone through the maturation cycle yet of having a BR Forum type, you know, a CA/Browser Forum.TCTim CallanNot at all, and it’ll be interesting to see. One wonders who would pick that up? Right? Might that be something that CA/Browser Forum decides to pick up? It might. Or it might not. Right? It’ll be interesting to see who ultimately is gonna say I feel that I have the authority and I have some stake in it and ultimately, I have some ability to enforce rules which probably means a root program and that’s going to be the company or group of companies that ultimately start setting down these rules.
Jason SorokoYeah. And I’m wondering if it’s entirely necessary because of the fact that there is not too many public trust scenarios with SSH that I know of.TCTim CallanRight.
Jason SorokoBut the thing is, I think that SSH certificates will become such an important aspect for the future that it might grow into things that we never suspected. So, that’s the thing to keep an eye on, is who knows what it might be used for simply because it will such a good authentication form factor.TCTim CallanRight. Yeah. That’ll be interesting. We should keep watching that. That’s a good topic for us to keep an eye on.
Jason SorokoI just wanted to add that one. That’s a good cert type.TCTim CallanYeah. I love it. Cool. Alright. Thank you, Jason.
Jason SorokoThank you, Tim.TCTim CallanThis 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!
