Podcast
Root Causes 355: Should a Managed PKI Provider Do Whatever the Customer Wants?
Hosted by
Jason Soroko
Fellow
Original broadcast date
January 19, 2024
In this episode we explore whether a managed PKI provider should give complete control over PKI decisions to the end customer or enforce certain minimum standards and principles regardless of what the customer asks for.
Podcast transcript
Lightly edited for flow and brevity.
TCTim CallanOk, so our topic today is - - How about if I say the topic and then frame it a little bit for the listeners, and then you and I can dig in? Does that sound ok?
Jason SorokoLet’s do it.TCTim CallanOk. So our topic today is, should a managed PKI provider do whatever the customer wants? And if you start to say, what the heck do you mean by that topic, I think I can explain it a bit. So let's start with the world of public CA.
So, in the world of public CAs, the public CA, somebody like Sectigo, has to follow a very specific set of rules and these rules are clarified in a few different ways. They're in the CA/Browser Forum and the ETSI requirements and browser root store requirements basically. And these rules are intended to ensure at a high level that that PKI is reliable, that the encryption is reliable, that the authentication methods are reliable, the physical network security is reliable - all these various things that in the end of the day mean that a relying party and a subscriber, that both subscribers and relying parties can trust that the PKI is doing what it's supposed to do. That it's authenticating the identity of a digital actor, that it's ensuring encryption and non-repudiation. And that's the basic, that's the basic reason that those rules exist at a very high level. So does that make sense so far?
So, in the world of public CAs, the public CA, somebody like Sectigo, has to follow a very specific set of rules and these rules are clarified in a few different ways. They're in the CA/Browser Forum and the ETSI requirements and browser root store requirements basically. And these rules are intended to ensure at a high level that that PKI is reliable, that the encryption is reliable, that the authentication methods are reliable, the physical network security is reliable - all these various things that in the end of the day mean that a relying party and a subscriber, that both subscribers and relying parties can trust that the PKI is doing what it's supposed to do. That it's authenticating the identity of a digital actor, that it's ensuring encryption and non-repudiation. And that's the basic, that's the basic reason that those rules exist at a very high level. So does that make sense so far?
Jason SorokoYes.TCTim CallanNow, that's because these CAs are really doing something for a set of customers that are out of their control. Those customers are the people out in the wide world who are using it.
In a private CA scenario, it's long been considered that you get to do whatever you want. You're building the PKI. You're building the CA. It's your code. It's your network. It's your risk. It's your use case, and you get to decide what you want to do. If you want to issue shorter lived certificates because you want them to turn out faster, that's up to you. If you want to issue longer lived certificates, that's also up to you. Right? And it makes perfect sense.
If we wanted to use an analogy, if I'm, let's say if I'm selling packaged food goods in the grocery store, there's a lot of regulation and testing and inspectors and stuff to make sure it meets certain standards of quality. But if I'm cooking at home, then nobody is watching to see if I give myself botulism, right? Because that's the nature of the beast. I'm cooking at home. No one is watching. And the same was considered to be true for a private CA setup. If I'm a private CA, and I want to make decisions that somebody else feels are overly risky or are overly risk averse, that's fine. That's my decision to make and everybody else just gets to be quiet about it. Once again, so far, do you agree?
In a private CA scenario, it's long been considered that you get to do whatever you want. You're building the PKI. You're building the CA. It's your code. It's your network. It's your risk. It's your use case, and you get to decide what you want to do. If you want to issue shorter lived certificates because you want them to turn out faster, that's up to you. If you want to issue longer lived certificates, that's also up to you. Right? And it makes perfect sense.
If we wanted to use an analogy, if I'm, let's say if I'm selling packaged food goods in the grocery store, there's a lot of regulation and testing and inspectors and stuff to make sure it meets certain standards of quality. But if I'm cooking at home, then nobody is watching to see if I give myself botulism, right? Because that's the nature of the beast. I'm cooking at home. No one is watching. And the same was considered to be true for a private CA setup. If I'm a private CA, and I want to make decisions that somebody else feels are overly risky or are overly risk averse, that's fine. That's my decision to make and everybody else just gets to be quiet about it. Once again, so far, do you agree?
Jason SorokoYes.TCTim CallanOk. Now…let's roll into the world of a managed PKI provider.
So a managed PKI provider is a third party technology provider who is expert in the realm of PKI or CA. And this typically is a SaaS service. You operate a SaaS service, you say, I'll stand up your CA for you. It's running using my tech off of my infrastructure in my cloud, but you're using it. You're the user. So the customer, the enterprise, or government entity, or NGO, or whoever it is, or school, is using it, but the technology provider is owning and operating that infrastructure and that service and the reason you do that as a managed PKI provider is because you're focusing and you're specializing on something that you can get expert at, and you're taking the burden of that expertise off of these other organizations. So that university doesn't have to sit and develop its own internal PKI, which is, as you've pointed out on many occasions, Jason, not for everyone, right? But you can get an organization - and Sectigo is one of those - that can offer this as a service and then you can build a center of excellence inside that organization, do it right, and make it available as a service. And that's a real market that really exists today that people really use.
So now, the question is should a managed PKI provider - who is in principle expert in this - give that customer, that end using entity, complete latitude on the choices that it makes around its PKI or should the managed PKI provider itself, impose certain rules and requirements and say I will do this, but I won't do that, even though you're the paying customer, because my role in this is to be your expert advisor. Just as my doctor won't just prescribe anything I want. My doctor is supposed to be my expert advisor. And there will be rules and requirements around what the doctor was willing to give me or do for me. So that's the question. And I think it's probably not as simple yes, no answer. It's probably nuanced and complex. And I thought it would be fun to get into it today. So, Jason, react.
So a managed PKI provider is a third party technology provider who is expert in the realm of PKI or CA. And this typically is a SaaS service. You operate a SaaS service, you say, I'll stand up your CA for you. It's running using my tech off of my infrastructure in my cloud, but you're using it. You're the user. So the customer, the enterprise, or government entity, or NGO, or whoever it is, or school, is using it, but the technology provider is owning and operating that infrastructure and that service and the reason you do that as a managed PKI provider is because you're focusing and you're specializing on something that you can get expert at, and you're taking the burden of that expertise off of these other organizations. So that university doesn't have to sit and develop its own internal PKI, which is, as you've pointed out on many occasions, Jason, not for everyone, right? But you can get an organization - and Sectigo is one of those - that can offer this as a service and then you can build a center of excellence inside that organization, do it right, and make it available as a service. And that's a real market that really exists today that people really use.
So now, the question is should a managed PKI provider - who is in principle expert in this - give that customer, that end using entity, complete latitude on the choices that it makes around its PKI or should the managed PKI provider itself, impose certain rules and requirements and say I will do this, but I won't do that, even though you're the paying customer, because my role in this is to be your expert advisor. Just as my doctor won't just prescribe anything I want. My doctor is supposed to be my expert advisor. And there will be rules and requirements around what the doctor was willing to give me or do for me. So that's the question. And I think it's probably not as simple yes, no answer. It's probably nuanced and complex. And I thought it would be fun to get into it today. So, Jason, react.
Jason SorokoI can tell you where the, the answer is, yes, in the sense that you can give the customer a lot of latitude and that is where the customer is choosing cryptographic algorithms and bit lengths that are sometimes more secure than they need to be. I've been involved in a number of implementations and customer discussions where, because of regulatory constraints, or there's somebody in the company who is very forward looking, and they want this PKI to live a very long time because this is quite often what the customer is thinking about, you know, the smart customer is thinking about, wow, this has to live a lot longer than what's usually - - what we think about in tech. So I'm gonna plan ahead. And so I've seen them choose bit lengths that are unusual, long, you know, sometimes they're told to do this because of the consortia they're in, because of the regulatory constraints that they're under or sometimes it's just creativity of just hey, I'm going to pick something that's just bigger because I just think that's a good idea.TCTim CallanYeah. It’s hard to see where someone is hurting themselves in that scenario. There might be a performance hit that they're not thinking about. Right?
Jason SorokoYep.TCTim CallanMaybe you give them some advice on that.
Jason SorokoAnd here's where I was going with that, Tim, is that might change in the future because post-quantum algorithms and the choices are going to become wider and the performance implementations, the amplitude of the differences between the small differences and largest differences will become gigantic.TCTim CallanAre vast. The differences are enormous in different aspects of performance, like key size, encryption time, decryption time, data transmission time, orders of magnitude difference sometimes. It's crazy.
Jason SorokoYou got it. So let's flip it now. Let's flip it and say, where are some of the hard nodes? Because I bet you there's a whole bunch of mushy in this right?TCTim CallanRight. So I was gonna say, so what about making it shorter? What about going with a key length that's less than the advised - - Like, I'll give you I'll give you a - - let's go all the way to the extreme end. Should a managed PKI provider allow 40 bit RSA?
Jason SorokoNo.TCTim CallanOk. Just no. So you're gonna say you're the customer, you don't know what's right. Sorry. I'm just not gonna let you do it?
Jason SorokoI can tell you that, you know, if you choose a primitive like SHA-1, or you choose, as you say something with a bit length that is crackable by, you know, a script kiddie in minutes, right? I think that the issue there is, if you're the managed PKI provider, you might ask them the question, hey, is this like an experiment?TCTim CallanRight.
Jason SorokoI can tell you that, you know, if you choose a primitive like SHA-1, you know, and, you know, or so, or you choose, as you say, you know, something with a bit length that is crackable by, you know, a script kiddie in minutes, right? I think that the issue there is, if you're the managed PKI provider, you might ask them the question, hey, is this like an experiment?TCTim CallanRight.
Jason SorokoBecause or are you a white hat, who is essentially experimenting, and you're just wanting us to host the, the managed PKI? That could be a reason why you might say yes, and that's where it starts to get mushy. It’s like what's the purpose here. But if it's something that's going to be something other than, you know, a test bench, and it's going to be used in the public domain, then my goodness, I'll tell you right now, I'd be running to my legal counsel, my corporate legal counsel to say, what's our liability here? Because this is gonna blow up.TCTim CallanYeah. That's interesting.
Now, of course, if I were to say no, and my competitor were to say, yes, I might be chasing business to my competition. But I think your point is that, as an expert advisor in a pretty esoteric, and foundational aspect of an organization security, a managed PKI provider has a responsibility to kind of stick with certain standards that they're not really willing to compromise. Is that right?
Now, of course, if I were to say no, and my competitor were to say, yes, I might be chasing business to my competition. But I think your point is that, as an expert advisor in a pretty esoteric, and foundational aspect of an organization security, a managed PKI provider has a responsibility to kind of stick with certain standards that they're not really willing to compromise. Is that right?
Jason SorokoCorrect. I think so, Tim, because, you know, there's a certain amount of ethics, like you brought up doctors, right? Doctors work in an ethical framework that they can't really, they don't have a lot of latitude. And they do have a ton of latitude in deciding how to prescribe the right thing and they don't always get it right. There's a set of unknowns. I think with managed PKI, I don't know if it gets so much into the ethical as it gets into the purely, hey, if our name is behind this, I would rather let my competitor make that bad boneheaded decision of taking money to make a totally boneheaded decision, than I do it and then have to face the consequences of being in the news of setting up something that was just terrible. That's just one way of thinking about it.I would hope all of our competitors would think in lockstep. We're all, you know, long term professionals in this industry. And, we all, you know, we don't say an oath the way doctors do but there's almost like an unwritten oath I think amongst ourselves that it's like, eh, not sure I would give that kind of implementation to a customer.
TCTim CallanSo what about certificate term? You know, there are specific term limits on certificates in the public web PKI, or the public PKI and you've, you know, you and I have talked in the past about the benefits of shorter term certificates. This is one where historically there's been huge amount of latitude given to the customer. You want to issue five year certs, you issue your five year certs, that's between you and your people. I don't need to be in the middle of that decision. Should a managed PKI provider cap that also?
Jason SorokoI think that's a really good question. I can tell you that, right now, that's probably one of the mushiest ones. It's mushy because of the fact that we give the customer bad advice or something. I'll give you a perfect example. Fire forget certificates is as a reality in a lot of IoT, for example. And those certs are gonna live pretty much forever.TCTim CallanI'm never gonna get these devices back. I can't get them back. I can't update them. By their nature, whatever is on it when it goes out the door, is the only thing that's ever gonna have.
Jason SorokoYou got it. So what I would say is, it absolutely depends on the implementation rather than on just a hard number. I would say, as time goes on, you know, a server, a very centralized, very important server that has a root certificate for itself, it was common in the past to say 20 years, 30 years, like a consortia in a root certificate, lasting decades, right. And that may still end up being the case.I would say the advice, the proper advice, to give now is, hey, with CLM, certificate lifecycle management, and automation, and better ways of handling these things, let's architect your security in such a way, where we can go to something that's a lot more reasonable. Just like the CA/Browser Forum with its rules about roots not lasting past a certain period of time. Even those things are shortened, right?
TCTim CallanYeah. Roots are down to 15 years now.
Jason SorokoSo I think in the private world, that's where the private world should be looking to the public world and saying, hey, something is changing over the public world. They're shortening. And so for certain use cases, shortening it down to less than two decades - it makes sense. And I would say as technology is changing, as CLM continues to develop, as the provisioning technologies continue to get better and better. As people's knowledge of these things gets greater and greater, I think that it's a very use case dependent question, Tim. And I think shortening is the right mode. However, I think that's the one where if the customer comes up with a darn good reason - and there are darn good reasons - if the darn good reason is presented, I think a managed PKI provider can flex with that.TCTim CallanI think for leaf certs, I really see that. For roots and intermediates, in general, I would expect that the customer, the private enterprise, has much more control over the relying party devices, than does the public PKI.
So one of the reasons you want to have long roots is because there's some dentist office somewhere that needs the old root, right? We are picking on dentists today, I'm not sure why. And so, that would be the direction that that takes.
In a typical enterprise, in just a company, you have enormous control over the devices that actually need to be able to connect to your network and you don't want just any random device connecting and in fact, you do want everything to be something that you have and is blessed and you cycle these assets out after a certain amount of time and you don't really want a 7 or 10 year old asset in the mix to begin with.
So under those circumstances, it feels like shorter roots, probably most of the time, are more tolerable. And we may even go the opposite direction. We might argue that a private PKI setup should encourage, let's say, even shorter root lifespans than you see in the public. PKI today.
So one of the reasons you want to have long roots is because there's some dentist office somewhere that needs the old root, right? We are picking on dentists today, I'm not sure why. And so, that would be the direction that that takes.
In a typical enterprise, in just a company, you have enormous control over the devices that actually need to be able to connect to your network and you don't want just any random device connecting and in fact, you do want everything to be something that you have and is blessed and you cycle these assets out after a certain amount of time and you don't really want a 7 or 10 year old asset in the mix to begin with.
So under those circumstances, it feels like shorter roots, probably most of the time, are more tolerable. And we may even go the opposite direction. We might argue that a private PKI setup should encourage, let's say, even shorter root lifespans than you see in the public. PKI today.
Jason SorokoYes. I agree with that completely.TCTim CallanNow, maybe, again, ah, well, you see, we have all these IoT devices that have been blah, blah, blah, and you can make your case and I get that. But I think for most companies, that would probably prove to be true.
Jason SorokoTim, I'm gonna to issue something here slightly controversial, because it's, it's an analogue to what you have been talking about here, which is, what happens if the way in which most OpenSSH implementations have been done, in most enterprises across the world, were something that you did as a managed PKI vendor? Would you have allowed the absolute nightmare mess of unmanaged key pairs that exist?It's interesting, isn't it? Because it's like, here we are, you know, we're ultra scrutinizing just, you know, managed PKI, when in reality, other forms of asymmetric based secrets, when they're implemented without those kinds of expertise, is quite often the source of just an absolute nightmare. And so, hey, enterprises, oh, my goodness, let's look at when there are no rules or experts or - - it's a disaster.
TCTim CallanYeah. So, I mean, this is interesting. Let's riff on this a little, because, on the one hand, and this - - I know, this wasn't your argument, but I can kind of take a parallel argument to what you said, which is to say, you're putting so much effort into trying to completely lock down this one aspect of it and I can just take one step to the right, and walk right through an open door. So why are you being so anal about this particular part of things? Right? I know that wasn't what you were saying but that could be an argument someone can make.
Jason SorokoNo. It is pretty much what I was saying. I agree.TCTim CallanBut then you turn around and say, ok, fine. But how is the fact that another aspect of your security is lacking any kind of excuse for the part I'm in charge of to be lacking? Right?
Jason SorokoRight on.TCTim CallanIt feels like they're independent. And, at the end of the day, whatever I can control that's inside of my purview, I've got to make sure that's buttoned up, even if other people have to be responsible for being buttoned up on their parts. That would be the counter argument.
Jason SorokoTim, I remember back in the day, we're talking 2010 to 2013, back when I was told I was thoroughly insane for thinking that mobile devices could ever be used in a security context. Sure enough, MFA became a gigantic industry. We now have certificates. Mobile phones are all over the place within our security ecosystem.TCTim CallanYeah, absolutely.
Jason SorokoAnd it was so funny, because the arguments against me were always Jay, we gotta hold this to the highest standard like military levels. It turned out that the good enough of a mobile device - far better than good enough - ended up creating whole industries, which improved endpoint security and other forms of authentication, etcetera, etcetera, etcetera. So what I'd like to argue here is, I see the same issue of what we're talking about, is, guys, you have very dirty floors, very dirty laundry rooms, with all your other security aspects and yet you hold, you know, your managed PKI to this incredible level and some of you want to dictate the terms below what experts tell you to use. And I can tell you, whether it happened by default because of an open source or whatever - anytime enterprises were just allowed to choose their own thing, it was a disaster.
TCTim CallanOh, yeah. There's a huge risk, right, that they're going to choose all kinds of things. They're going to choose the least work model, right? That's a big risk. Whatever requires less effort for me, I keep getting help desk calls. Turned down the volume on the security and I stopped getting help desk calls, right? Or that they're going to use the least expense model, or they're going to use the this is what we did last time model or the I don't want to do an upgrade model. And those are all things with real pressure on them inside of the modern enterprise that could lead to the kind of decision that you're talking about.
Jason SorokoYeah. First of all, if you have come to a security vendor, you know, that does manage PKI, first of all, congratulations. You've decided to do the right thing, which is don't roll your own stuff. And then listen to the advice and trust me, we will listen very carefully to your use case. And we've almost seen it all. Right? There will be new stuff as quantum comes and new use cases come about within the cloud and etc. etc. That's fine.
TCTim CallanThere's going to be a whole quantum versus RSA, single use versus hybrid certificate. All of these decisions will have to be made as well that we haven't really dealt with today but they're coming and they're going to be made by every organization on the planet.
Jason SorokoTim, we've been through this so many times. I gave you the mobile example. I still talk to customers who sometimes feel that they need to hug that server in the server room, and the cloud isn't good enough. Meanwhile, it’s like no, the cloud is probably way better for you, my friend.You know, on and on and on. And so listen to your experts. Please, please, please, please go to the experts and listen carefully. And on a use case by use case basis we’ll do the right thing with you.
TCTim CallanRight. And to your other point, I think the managed PKI provider also has an obligation, like your doctor, to pay close attention to your situation, your requirements, your use case, your hygiene, and make sure that they are giving you a solution that doesn't just - - it isn't just Titanium plated, but rather something that pragmatically will do what you need it to do, as a provider – or as a user, as an institution. And it's got to be both.
Jason SorokoKey lengths. Key cryptographic algorithms. CPCPS papers, and all the various things that come with that. You know, and with quantum…multiply everything by 100. So it's gonna be a very interesting time to be alive over the next X number of years.
TCTim CallanIt is going to be. Well, thank you, Jason. That was a good meaty conversation. I didn't know where it was gonna go. But I think I agree with where we ended up.
Jason SorokoYeah, exactly. Folks, we're all in this together. We're all on the defensive side. Thank goodness for asymmetric secrets. Hooray that we have them.TCTim CallanAbsolutely.
Jason SorokoAnd so we've got something that works. Thank goodness it's not the Wild West. So let's implement it right. That's all.TCTim CallanAll right. I love it. Thank you very much, Jay.
Jason SorokoThanks, 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!
