Root Causes 225: The Difference Between Relying Parties and Certificate Consumers

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  We are going to discuss what is the difference between a Certificate Consumer and a relying party. Sounds like the same thing, wouldn’t you think?

• 

  Jason Soroko

  Sounds like the same thing, but I have inside information that is it very different.

• 

  Tim Callan

  They are not. They are not the same thing in any way. Pobably to do it properly, we should discuss four different defined terms in a PKI system. It would be a Certificate Authority, a Certificate Subscriber, a Certificate Consumer, and Relying Party. And that will give us all aspects of it.

  So we know what a Certificate Authority is, of course. A Certificate Authority is the organization that is trusted within the PKI system to issue certificates and is viewed as the authority over what those certificates are and that if certificates come from that CA, the rest of the system is going to choose to trust it. Is that a fair layman’s definition?

• 

  Jason Soroko

  I like that. It’s good.

• 

  Tim Callan

  And then, a Subscriber is the party that chooses to use that certificate on a machine. So the Subscriber is somebody who says, I want to obtain a certificate, and I want the certificate to sit on a machine or a process to vouch for the identity of that machine or process when it’s connecting to a client, to another party over a network. That’s the Subscriber.

  So the CA creates the certificate. The Subscriber wants the certificate, obtains the certificate for use. Sound good so far?

• 

  Jason Soroko

  Sure, Tim. I’m going to let you keep going, but then I got some questions.

• 

  Tim Callan

  The relying party is the flip side of the Subscriber. The Relying Party is the other machine or process or the user of that machine or process who wants to connect to the Subscriber and know that it’s connecting to the correct entity, and then other benefits come with certificates like encryption and that scenario are then enabled as well. That’s the Relying Party. So, the Relying Party is an outside party somewhere in the world that is connecting to the Subscriber that needs to be able to trust that that certificate from that CA is doing things correctly including vouching for the identity of the Subscriber correctly.

  So, the Certificate Consumer is essentially the root store. The Certificate Consumer is the piece of software or service that is going to look at the root, watch the root chain up to the CA and agree that that is an acceptable CA in this scenario. So, the Consumer and the Relying Party are very different. The Consumer is a software manufacturer. In the case of a public certs, the Consumer is a browser manufacturer, and Relying Party is a browser user. Just to put those in to terms we can all understand. In the case of a private CA, the Consumer is the system internally that is going to trust your internal private CA root. That is the Consumer as opposed to the relying party which is the machine or the person who inside of your walled garden is connecting and wants to know that that connection is secure. So, with that, fire away on your questions, Jay.

• 

  Jason Soroko

  You actually answered the questions because I wanted you to bring it back to the real world. So, when I think about it, Tim, the reason why there’s some confusion and the reason why we talked about doing this podcast was because of the fact that there is – words are important. You and I both agree on that, and the words can actually be confusing if you're not an inside-baseball-type person in this world of certificates. And so, there’s word confusion, but there’s also this difference between public and private trust. Tthings like the root store, which are so intimately tied to your browser, it’s the vendor, the software vendor of the browser are the people who run their own root stores and implement them within the browser that you, as the person running the browser, will use. Even if you don’t know it’s there, it’s there. Therefore, these terminologies, they’ve been around an awfully long time, and yet, just by their usage, the usage of those terms, it’s a bit confusing. I think you laid out very clearly what they actually are.

• 

  Tim Callan

  Every one of those four parties has a unique role in the ecosystem. We need them all, and they all do a different thing, and they all interlock very, very well. So, maybe we could describe it in terms of responsibilities and benefits.

  So, the CA’s responsibility is to, well, I guess it’s really two things - one of which is it has to run a proper CA from a computer science perspective. So things have to be secure, and the crypto has to be current and the expiration dates have to be on time, and things along those lines. So, let’s take that, let’s put that aside because that’s a different point, and we could easily spend 100 podcasts on that topic. But assuming that it’s running itself correctly, then the CA’s responsibility is basically to vouch for the identity of the subscriber. The CA says within whatever the parameters are that we’re identifying the Subscriber – and this would varies by certificate type, but let’s say in the case of public SSL cert, I’m vouching that this organization really controls this domain name and that in the event that you are getting an EV or an OV certificate that there are these sort of other data about the organization that I’m going to share with you, and that information is vouched for by the CA. That’s really the CA’s responsibility in this. The CA’s benefit is that the CA is here to run a PKI. The CA is here to run a secure PKI so that all these other interactions can take place. That’s why the CA exists. So, by doing that correctly, the CA is fundamentally achieving its goal in the world. So, that’s the CA’s responsibility and the CA’s benefit.

  The Subscriber’s responsibility is to use the correct types of certs in all of its network-facing machines and operations, essentially. Because in the absence of that, you can get man-in-the-middle attacks and any number of other problems. And so, the Subscriber’s responsibility is to have certificates that are correct, that are current, that are unexpired, and that are following secure methodologies for now, todays and time. And then the Subscriber’s benefit is secure connections with other parties is protecting from all those attacks we just described and therefore, also probably enablement of communication at all. Because there are plenty of circumstances where in the absence of that, just that client-server communication would be deemed unsafe and just wouldn’t occur. So, that’s the subscriber’s benefits and the Subscriber’s responsibility.

• 

  Jason Soroko

  The Subscriber – can we think about a Subscriber – the real world definition here as being – an example – being an organization that is running a farm of Apache servers and is utilizing certificates. They obviously didn’t issue those certificates themselves. It’s not self-signed certificates, they’re taking these in from a CA. The certificates they are using have been signed by a CA.

• 

  Tim Callan

  Let’s use a real simple, real world example. So, Corner Pizza Place wants to take orders online. This CA is Sectigo or another public Certificate Authority. The pizza place is the Subscriber. The pizza place gets the certificate, puts it on a server. The Relying Party is somebody who goes to the website, pays for their pizza with a credit card before they drive down and pick it up. And the Consumer is the manufacturer of the browser that that individual used.

• 

  Jason Soroko

  That’s a perfect, perfect real world example, Tim. And my goodness, is it ever confusing when you look at the words. Because when you’d see the word “consumer,” it’s not what you’d think at all.

• 

  Tim Callan

  Consumer is the tricky one, yes. Yes. And it’s not a consumer like we talk about consumer-based marketing and consumer products. It is the software that consumes that certificate. That is a Consumer.

• 

  Jason Soroko

  Literally the browser. In most real-world scenarios.

• 

  Tim Callan

  It wouldn’t have to be a browser. It could be your phone, it could be another internal server. The Consumer is just the thing that sits on the other end but not that individual instance of it, not your individual telephone, but the phone OS. Not your individual, not an individual server that’s sitting in a rack. That’s a Relying Party. A server can actually be a Relying Party but the operating system that’s running on that server. That’s the Consumer. So the Consumer - -

• 

  Jason Soroko

  But, Tim, here’s a weird way - -

• 

  Tim Callan

  - - is the software that - - Yes.

• 

  Jason Soroko

  Got it. So, you’re out there ordering your pizza on pizzaplace.com and you're the Relying Party who is utilizing Consumer software in order to be able to order your pizza. That’s a weird way of saying it, but that’s what it is.

• 

  Tim Callan

  That’s exactly right. That’s precisely correct, Jay. Just finishing up the responsibilities. The responsibility of the Relying Party isn’t that much. The responsibility of the Relying Party is that, to know that you’re connecting to the entity you expect to connect to, and so, in our pizza place scenario, like, really navigate to the real pizza place and not somebody who’s phishing you and pretending to be the pizza place. Maybe that’s not a perfect analogy, but, know that you’re going to your real bank and not a spoofy site that’s pretending to be your bank. That’s the responsibility of the Relying Party, and the Relying Party’s responsibilities are the lowest, as you would expect, because they’re the ultimate customer for all of this. But the Relying Party’s benefits are the highest because they are enabled this way to connect to other machines across the network and reap the benefit of those. So the Relying Party’s benefits are very high, and just as the Subscriber’s benefits are very high.

  And then the last one’s Consumer. The Consumer’s responsibility is to maintain a list of trusted CAs that is accurate and current so that I know, ok, you can connect to this, and you cannot connect to that. So, again, in our public scenario world, that is the browser manufacturer who says, ok, I’m going to let you connect to these certs, and I’m not going to let you connect to those certs. That one’s fairly easy. What’s a little more interesting is in your walled garden, your private scenario, the Consumer is, somewhere someone’s got to maintain a root store. They got to make sure that the roots are in that root store, or your systems aren’t going to work, and they also have to make sure that they don’t have roots in that root store that they don’t want because those are exposure. Those are risks. You shouldn’t have roots there you’re not using. You shouldn’t have roots there that you don’t think you can fully trust. And so, that winds up being the consumer in that particular scenario.

• 

  Jason Soroko

  That was very close to my heart in the private trust world, Tim. People might say to me, Jay, isn’t private trust just a bunch of self-signed certificates? Well. By definition, yes, it is. However, it doesn’t mean you don’t treat them well.

• 

  Tim Callan

  Extra special! I mean, you're the one who’s determining what certs are trustworthy and what certs are not. I mean, you got to treat those super well because no one else is going to. You are the only one who can.

• 

  Jason Soroko

  So, here’s me going into full shell mode just for like a microsecond. It does make sense even in private trust scenarios - self-signed certs. If you're going to do self-signed certs, do it with a partner who knows how to sign a root CA and maintain it, and maybe even should maintain it for you. Therefore, a company like Sectigo, this is big chunk of what we do, which is to host PKI systems and to host root CAs, issuing CAs for organizations that want to have private trust scenarios. And so, therefore, what you just said, Tim, the Consumer aspect to this, this maintenance of what are the trusted signed certificates that ultimately are the basis of the issuance for the entire system, and therefore, if that key material was to be stolen, the whole thing would unravel - you want it to be done very, very well, so therefore, maybe don’t do it yourself with some open source tools and just say, well, this is just self-signed certs so it don’t matter. No, if it’s important to you, perhaps seek out some help for that, and I don’t think people talk about that often enough.

• 

  Tim Callan

  Alright. So, definitely people don’t talk about this topic often. But, we like to dive deep on things and explain things sometimes, and I think this is a good one per what you said Jay. If you just heard people throwing these words around, you might make assumptions about what those people meant, and those assumptions wouldn’t necessarily be right. Another good clue when these things are in writing is Subscriber and Consumer will be capitalized if we mean it in a PKI context, as opposed to just consumer goods, which in case it would not be capitalized, and if you’re seeing things written, that kind of helps you understand what’s being talked about.

• 

  Jason Soroko

  Tim, I’m going to tell you. For the average person who’s either getting into this field or if you’re more of a governance person and not a pure technical person, and you're throwing around these terms and they’ve been confusing to you, put this podcast link into your bookmarks, because Tim, I think, laid out perfectly in a very clean way what those terms really mean and how to think about them. So, that’s a great job, Tim. Thank you.