 Hi, guys. So for those of you who came in after the announcement, this is the link to the deck. It's been shared already. That way, you can take it with you when you go, and you don't have to wait for the OpenStack folks to post it after the conference. If you try to access it on mobile, it looks super wonky. So that's the disclaimer. Adi, are things not working? Nope. All right. So thank you, everyone, for coming to the state of SSL and TLS in Barbican. Actually, as people were wandering in, I had to ask if you were in the right place. I did not expect such a prolific turnout to talk about TLS certificates, usually when I start talking about them. People run in the opposite direction or look at me quizzically. So I've got a full room of people who actually want to hear this, which is very exciting. My name's Sheena Gregson. I'm a product manager at Morantis. In a recent previous life, I was the product manager for Barbican and SSL at Rackspace. So this topic is near and dear to my heart. And then my presenters, I'm joined by John Wood, who is an architect at Rackspace, focused on Barbican. And he was one of the original Barbican contributors. He's also one of the core contribs right now. And Adi Lee, who is another one of the core contributors, joining us from Red Hat. Is it working? I think it's working. And he's a core contributor from Red Hat, who's focused on the Barbican and Dog Tag integration for Secret Store and Certificate Authority. Sweet. It's working. Thank you. So today, we'll be talking about four general topics. The first is, what is Barbican? So if you accidentally wandered in here, we're just looking for a place to sit down. Or you have no context. You haven't heard about Barbican before. We're going to talk a little bit about what the goals are of the projects. Generally, we'll talk about where we are today with respect to TLS provisioning and life cycle management. We'll talk about where we're going. The long-term vision in Barbican for TLS life cycle management. And then we'll give you a couple of other opportunities for places to interact with Barbican team members, Barbican contributors at the summit over the next couple of days. So first off, what is Barbican? Barbican has two main goals. The first is to enable secret storage, so secure storage and generation of secrets. And much like any of the other open-stack projects, there's a plug-in-based approach used here. So you have multiple backends that you can choose from in your open-stack deployment, depending on your need. So we've got a HSM back-end that's been made available. We've got a KMIT back-end. You can use the DogTag secret store. And of course, if there's not a plug-in that you like, please feel free to come contribute to the Barbican plug-in options. And developer speak, pull request accepted. On the other side of the goals, we are looking at trying to do better certificate management. So Barbican is a secret store first and foremost, but one of the secrets that you guys obviously care very deeply about is TLS certificates. So we'd like to make that less painful. Painless is probably a bridge too far, but less painful and enable integration with multiple public and private certificate authorities. So before I hand off the clicker to Adé to talk about where we are today, I'd like to give you guys kind of the Barbican vision for the long-term TLS management roadmap inside of Barbican. I was in the Enterprise TLS space in 2014. And for those of you who joined me, that was a wild ride. In April, we had Heartbleed emerge, the Heartbleed exploit. And that affected hundreds of thousands of users that resulted in hundreds of thousands, maybe millions of certificates being rotated between the scope of the exploit and also the amount of media coverage it received. So I actually got calls from my parents, and they told me, like, have you heard about this thing? People are stealing our information. My parents are not tech folks. So it was really entertaining to hear their version of what the media was sharing with them about TLS exploits. So that happened in April. And then later in the year, Google made the announcement that they were going to deprecate support for certificates issued with the SHA-1 hash algorithm. And so that also affected, at the point of their announcement, more than 80% of certificates that were live in the wild. So lots of exploits, lots of changes last year. And I think because we're talking about a security product, it would be very naive to say that we won't see a year like 2014 again. Obviously, I'd like to see those years less frequently, but those types of changes are going to happen. Security is all about evolution and continuing to stay ahead of the most advanced attacks and all of the new technology that enables people to break the current methods. So we're going to need to be able to change out certificates in the next years for different reasons, but the same type of use cases or the same type of workflow would apply. And so in Barbican, in order to support enterprise-level survival of certpocalypse in the future, we will need to be able to order certificates from multiple CAs. So if we're talking about an enterprise-level use case for Barbican, maybe you want to talk to you multiple certificate authorities. You care about getting a certificate from Symantec. You care about getting a certificate from DigiCert. You want to issue certificates from your internal private CA. And you're going to want to do that through the same Barbican instance. So enabling that management at scale really means that we need to be able to plug and play multiple certificate authorities at the same time. In addition to that, being able to reissue certificates not only to address key compromises, but also to upgrade certificates. So last year, upgrading certificates from SHA-1 to SHA-256 in the future, enabling users to upgrade to elliptic curb cryptography certs and whatever comes after that. In line with that, you're going to want to see revocation capabilities. So Barbican should be capable of revoking certificates in order to help further the security story, make sure that you are revoking certificates if you've experienced a key compromise, or maybe you just have too many in the wild. You have two or three that are live at the same time. And if you're not using them, you might as well get rid of them to reduce your security scope, what you have to manage. And finally, renewing certificates very much in line with ordering. That's just part of the story for management. All of this needs to be a part of Barbican if we're going to realistically say that it is a complete certificate manager. And so with that in mind, I'm going to hand everything over to Adé, and he's going to talk to you guys about exactly what you can do in Barbican today. OK, so can you guys hear me? OK, good. It's actually a pretty simple story as to what we can do today if we actually just go back to the slide for a second. The majority of what we can do is pretty much that top right corner over there, which is to order, which is basically creating and getting out initial certificates. A lot of the support for the rest of that is in progress and will hopefully get done through Liberty, or most of it through Liberty. But I'm going to talk specifically about order the top part over there and how you can do that in Barbican today. So the first thing to talk about is what kind of clients we have available. So like every other OpenStack service, we have a rest interface that Barbican provides in order for you to generate a certificate. That's the orders interface on the Barbican side. And you can talk to that directly to the API. I mean, everyone can do curl calls and so on. It doesn't get any simpler than that. The problem of the thing, and you're very close to the Barbican code. You can get the latest changes and so on and so forth. It's not very user friendly, of course. You have to take the JSON that you get back from the curl. You have to parse it and so on and so forth. And it also ties your application very close to the Barbican. So if you want to be able to issue to other types of certificates or use other kinds of applications other than Barbican, you're kind of stuck if you go directly to the API. A little bit higher than that, of course, is a Python Barbican client. So just like the other OpenStack services, we all have a client as well, which also provides a CLI. This is still very close to the Barbican code. It's much more user friendly. It allows you to, especially if you use something like the CLI, it allows you to interact with the API. And you have objects that will take all the JSON and turn them into nice things that you can use. Again, your application is going to be very tied to Barbican because that's specific to the API. And then, of course, there are questions as to what happens in the future with the CLI and the client when we start moving into the Open SDK, things like that. Finally, there's Sirtmonger. Sirtmonger is a, if you didn't know, it's a widely used OS daemon. It has very generic interfaces, so things like GetSuit, for example, that you can use to talk to just about any kind of CA in the back end. The way it talks to, so what you can do, for example, you can say GetSuit. And then, Sirtmonger will generate some keys for you, will generate a CSR, send that over to your CA, get your certificate back. It may poll for your certificates periodically if that certificate has not yet been issued. And then you can ask Sirtmonger, for example, to track the certificate and wait to see when it starts to expire and when it starts to expire, when it's close to expiration, Sirtmonger will actually go and do a Sirt request to renew that Sirt if you choose to do so. The way that it does that kind of thing is by using helper scripts. So in this particular case, if you wanted to talk from Sirtmonger to Barbecue, and you'd write a helper script in Python or whatever language, in this particular case would be Python, using the Python Barbecue client, and you would ask it to do these things for, say, issuing a request or whatever the case may be. Relatively easy to do. Hasn't been done yet, that's the downside. But I would expect that it would be done by early Liberty, so within a month or a month and a half from now, I would say. So, Barbecue exposes ordering certificates through the orders interface. And there are three kinds of certificate orders that you are able to do these days. The last one over there, the custom request is actually the first one that was implemented. And that allows you to, if you know exactly which CA is in the back end over there, and you know how to communicate with that CA, you can send the specific CA parameters that you might, that you would need. So those would include things like a CSR and maybe other billing parameters and so on and so forth. Various things that are needed by that specific CA directly through Barbecue, and Barbecue just acts sort of as a pass through there. It will then pass all that information through to your CA and your CA will then act upon it and you can get your cert that way. We did that, that's been around since Juneau, and we did that sort of as a first pass as being able, if you really, really needed to get a cert out and or you needed something that was custom for a specific CA, this is what you needed to do. It kind of diminishes the power of the abstraction though because sometimes you don't want your client necessarily to know what CA is in the backhand or maybe your client doesn't care or your client wants his cert. And so that's why we added, in Kilo we added two additional types of requests. These two types of requests are generic parameters that you would expect to be able to see across all CA's. So for example, the simple CMC requests allows you to specify, I think it's even called request or something like that, but it's a basic CMC request which in its most simple form is a CSR. And so in what you would do there is you would use this interface to send a simple CMC request and we'll see an example of that in a few minutes. And that would go to your CA and you'd get your certificate that way. The stored key request is interesting. It allows you to, it takes advantage of the fact that Barbakan is a secret store as well as a certificate system. And the idea here is that you would store or generate an asymmetric key pair, so an RSA key pair ahead of time. And then you could ask Barbakan, you could just provide a reference to that stored key container to Barbakan and Barbakan would generate a CSR on your behalf and then send that off to your CA. There is a, this is particularly useful in sort of a provisioning case where you might want to provision some things ahead of time and all you would need, you would basically generate those suits ahead of time for your whatever client you wanted to create the suit and then just bring the suit down specifically for that CA. In that particular case, what would be returned could be conceivably both references to both the CA, both the certificates and any intermediate suits as well as the private and public keys. You can get everything all in one big container. So in fact, that is what this next slide shows you. So this next slide is what actually comes back from any of these calls. It's a certificate type container. A container is essentially just a Barbakan concept which is just a grouping of related secrets. And in this case, you have a, you always get a certificate. You might get intermediates, which is a PKC S7 chain, just showing everything you needed for your client to chain back to your root CA. And in the case of the stored key case, you'd get a reference to the private key and any passphrase that we use to encrypt that private key. And what the locks are representing over here is that these are actually stored as secrets within Barbakan. So you're not actually getting the actual secrets or anything in there, which are getting our references to the secrets, which you can then go get from Barbakan, assuming that you have the appropriate, you know, authorizations and so on and so forth. So just to give you an idea of the data flow for the certificates. There are four different boxes over here. You've got the client on the one side, which could be Sirte Monger or Python Client or Cruel or whatever the case may be. We've got Barbakan, which is going to process the order and it's gonna do it asynchronously. When the order is received, there'll be an asynchronous process that kicks off at some point and sends that over to the CA plugins. The Barbakan CA plugins are the things that actually talk to the various CA's in the backend. And as Sheena mentioned, you can actually talk to many different kinds of either private or public CA's. So Barbakan, the core itself can have multiple CA plugins and each of those multiple CA plugins can actually talk to multiple CA's. They talk to specific CA type, but they don't necessarily have to talk to just a single CA. In fact, one of the features that we're gonna add into Liberty, which has been implemented on one of the plugins that's there, which is the dog tag plugin, is the ability to create lots of subordinate CA's, which means that as a project admin, I might be able to say, create a CA for my project on the fly. So you could have a per project specific CA and per project specific identity domain. But that's coming up conceivably in Liberty as well too. So once the order, so there's an order that's generated on the client, it goes to Barbakan. Barbakan has some processing that takes place, ultimately requests the certificate from the CA plugin when ultimately then goes to the CA. Now at that point, one of two things can happen. The, it can sit on the CA and wait until the, an agent on the CA decides to approve it. That's the standard kind of a way. And when that happens, then the certificate generated or under certain circumstances, CA's will allow you an immediate issuance of particular certificates. This could be something like an anchor kind of thing or in the dog tag sort of thing. If you ask for a specific type of certificate, it automatically gets generated because the CA plugin talks to the CA through a sort of a trusted relationship. In any case, ultimately the CA is generated. The CA plugin will retrieve the certificate in the case where you have to wait for it to be approved and it isn't approved automatically. Barbakan and the CA will actually pull the CA periodically to check to see whether or not the CA has been, has been generated. The certificate is generated, it's retrieved, it's stored inside a certificate container and that's the thing that the client can actually extract. So just a simple demo using, we're gonna use Curl just so you can see all of the different parameters that are there. It's kind of the interface kind of thing of just doing a simple CMC order. I did this demo with a dog tag instance in the back end and if you're not familiar with what dog tag is, dog tag is an enterprise CA that is supported by Red Hat. It happens to be the one that I'm a lead developer on and it's been used in a lot of different places. It's in using some of the biggest PKI deployments in the world, all of the three letter agencies and so on and so forth. They tend to use dog tag to support their certificate issuances. But dog tag has the ability both to store secrets and so that's why at the bottom of here you can see there's a place here. Let's see if I can, this works, yeah, right there. So there's a secret store. So one of the secret store plugins is in fact a dog tag plugin and it could also be one of the certificate plugins so we can do both in this particular case. You don't have to, but you can. What's important here over here is that this is just basically some barbican configuration which tells it to basically use dog tag. There's a dog tag instance at this port over here. It has an NSS database in which it's stored a credential for a trusted agent to talk to it. And this auto-approved profiles means that if I send in a specific request for a certificate with that auto-approved profile I'll automatically get that search generated and it will go from there. So what's the first thing you might wanna do is to check out what CAs are installed. So you're gonna do a get on the CAs interface and you see, okay, there are two CAs there both of which have that CAID. Let's look at one of them and there's the CAID and you can see sure enough that's the CA and it's the dog tag CA. So we're gonna go ahead and use that one. And so I'm gonna generate my private key using OpenSSL. There's my private key. I'm gonna take that private key and I'm gonna generate a CSR. And I'm going to then base 64 encode it and turn it into one long string and that really, really long string which I've truncated over there. I'm gonna take that really, really long string. I'm gonna put it in an order. So you can see there I'm doing a post and it's of type certificates on the orders interface. Here's my data over here that's gone into that really, really long string. It's a simple CMC type. I'm gonna go to that CAID and I'm gonna use that profile. Again, this is the profile that is configured to be the one where you can automatically get a search generated. And I get back an order reference. So an order has just been created. At this point, asynchronously an order, it's being processed by Bobbican. So what I need to do is I need to get the results of that order. And so I'm gonna get that order. And I see that in this particular case because the order has been automatically, it would either come back as pending or it would come back as active pending if we were still waiting for someone to act on it on the CA, active if you weren't. The CA has been generated and there is a reference to my certificate container. So to get my certificate, I've gotta go ahead and get that container. I get that container, so I go to the containers interface. Here are two secret references. One's for the certificate, one's for the intermediates and the intermediates is the PKCS7. Let's go get it. So I get the payload of that particular ID and there's my certificate and I'm gonna do the same thing for the intermediates. So this is just a basic demo based on just using curl and you can kind of see how a certificate could easily be generated that way. So I'm gonna hand it over to John right now who is gonna talk about, just do a quick demo on how to do it using the store key case using the CLI. Looks pretty. Thank you, Adi. Appreciate it. So what's better than one demo? Two demos. So this one's gonna focus on our command line interface so you'll get to see a little bit of how that looks and works and we're also going to look at the stored key certificate type. So you actually create a secret up front, a key pair up front and then Barbecam will generate a certificate based on that. And so to create that public private key pair, we start with an order. That's an asymmetric type as you see up there. Let me make sure I get this laser pointer working here. Yeah, right there. And so just a familiar sort of mode of operation, you have your order create call, you pass in your parameters and you get your URI back out so you can check back on the status of that order just using a good old get call with the order. And you can see that once the order becomes active, now you have your container reference here and that contains your key pair container. And with that information then you can go ahead and follow up with another order that's going to create your certificate. And so you can see you pass in the certificate type, that's the type of the order that we're going to create. And the stored key is the mode that we want to use to create that certificate and then you can see our container, that was the container that we received back from the previous order call. And we get our new order ID that's related to this particular order creation step. And now we can follow up again with a get call and that's that new order ID. And once that becomes active, now our container reference has the certificate container in it that we care about. And so if we actually retrieve information on that particular container, you can see that we have our certificate and intermediates secrets that are created out of that process. So the worker actually took that private key that we provided and generated a CSR and then ran it through the process to generate the certificate. At this point in the demo, we would test if you're actually awake or not because you realize that there's actually a bug here. We should have put our private key here as well. So that'll be a little bug that we have to fix pretty quick. But the idea is that this would represent then a complete certificate that you could hand the container URI off to a provider and they would have all the pieces they would need to install that certificate onto a load balancer, a server, or what have you. And so this is just showing how you can retrieve the actual certificate information back out using the CLI. So again, it's just a simple get on the secret. And here's the URI that we had in that previous retrieve call. So where are we going? If you kind of revisit what Sheena had displayed earlier, this is kind of the end game for the TLS story and Barbican. And so it would be good to kind of assess where we are now, what still has to be done in Liberty and beyond. And so this graphic kind of depicts that we've spent a lot of time getting the order process beefed up in Barbican, especially on the dog tag front. So we have a lot of the interaction worked out between Barbican and the plugin to initiate a certificate and collect data from the API side and send it to the workers to process with the CA plugins. And as it turns out, a lot of those workflows are needed for the renew process. So we're kind of giving ourselves credit for having some amount of the renew workflow done as well. Reissue and revoke. We definitely need to get more work done on that. All three of these actually have blueprints that we're gonna look at in a second. So how can folks help out? So we have a number of blueprints that are hanging out there that need to be reviewed, approved, and then eventually coded. So anybody that has free cycles to at least give us some reviews that would be very much appreciated. We're also interested in use cases. If you have integration use cases that could benefit from having this Barbican SSL workflow management applied to, we'd definitely love to hear from you. We're here all week as they say, and I'll show you in a second the specifics from a scheduled perspective. So getting into the specifics of the blueprints themselves, here's the three basic actions that we wanna support in certificates. But we also want to support a mode where you don't even have a private key upfront. You want Barbican to actually generate the private key and CSR as well as the certificate. And that's kind of the true automation. I'm a provider that wants to help out a customer, provision something within the environment. That would be the mode that they would use for that purpose. But we also want a way for clients to discover kind of what's available in a plug-in, what certificate types are available, what profiles are available specifically. If I'm talking Symantec, what specific types of search from a product perspective does Symantec support in exposing that in a way that can be discovered with the clients. And again, some of these canceled update order, these are all about managing orders in general in Barbican, but they also have an impact on how that interacts with the CA plugins to gracefully handle those transitions with the CAs. On the coding front, we definitely wanna get more traction on Symantec and Digi-Sert plugins to have those available as options. And we also want to have some means of telling the world outside of Barbican when a certificate's ready to go. So a provider knows when a certificate's ready and can actually provision that onto load balancer servers, what have you. So we have a general link here. Obviously, you can go to Launchpad to our project location to see a list of blueprints, but also on this slide deck, we've included specific links to specific blueprints that were related to that previous slide. As far as implementations are concerned, on the dog tag front, you can certainly reach ADE if you're interested in helping out on the dog tag front. Symantec, Rackspace has really been doing a lot of work so far on that. So Chelsea, Chelygel, and myself are good points of contact. Jeff Fisher on the Digi-Sert front, if you're interested in helping out there, he would be a good guy to locate. And as usual, you can find us on our IRC channel anytime. Like I said, we're a very open community and we're always looking for help. We're always looking for reviewers. We're always looking for ways people want to use Barbican and leverage it for their problems that they're trying to solve. So please let us know. There's features that are missing. Now is a great time to let us know so that we can potentially get that rolled into Liberty. See what's next? I'm looking on time, looking okay on time. So we have a break working session coming up at 3.30. We do have a conflict at a later working session with the Enterprise Ready OpenStack Swords as a service. I believe they're going to talk about sender or Barbican interactions and encryption. So we're going to try to have people from our team in both places at once. And we have a later working session today that's also at the same time as a Swift on disk encryption working session. So just bear all this in mind. Tomorrow we have quite a few working sessions. As you can see, there's a Swift working session as well. And finally we have a common use cases and options for Barbican. So if you really want to see how current projects are interacting with Barbican, this is an excellent presentation to go to. You'll see a variety of use cases that are already implemented and already fleshed out to give you a sense for how you could potentially use Barbican. So that would be a great one to attend. And then finally on Friday, if people are still around for that and not flying out or they're not like often enjoying the wonderful weather here in Vancouver, please consider going to our contributor meetup. This is kind of a chance to recap what we've been doing this week. Hopefully nail down a roadmap. So if there's a feature you really want in, this would be a good time or before that to try to hit us up and see if we can potentially get that into the schedule. So if you have any questions, please let us know. Go for it, I guess we can start. Oh, yes, please. You don't mind using the microphone. Are you aware of the Let's Encrypt initiative from the EFF? I am not, personally. Okay, then I think you must have a look. That's, they provide an API and you can get free certs. And they do that because they want the world to be encrypted. So definitely supporting Let's Encrypt from the EFF would be great. Yeah, so actually I took a look at it and it's granted Ben a little bit. But Let's Encrypt is a really cool opportunity to use technology to, if I remember correctly, you actually get root access to the device and you apply a package and executable into the device and it goes and calls out and negotiates a certificate from there. It's been a while. But the moral of the story is last time I looked, I don't remember there being a clean way to integrate with Barbican, but I know that they've looked at it and I imagine it'll continue to be a point of interest as an easy and cheap way, an inexpensive certificate authority option for going forward. If I've totally mucked that up, Thomas, we work together so you can come find me and I can clarify anyone else that didn't like that explanation see me after and I'll be happy to revise, yes. Is OCSP part of your revoke plant? So I think, I mean, you'd be able to revoke suits from here. Typically you have a, within the suits you have a URL that you can go to to check the validity of the suits and do OCSP type queries and stuff like that. There isn't any current plan to do an OCSP server on Barbican, but, and I don't think there's a need to necessarily yet. If there is, then we may have to consider it. So Barbican is open for remit to be an interface to the CA and not to CA itself? Right. So for those of you who didn't hear that, I believe the phrase was Barbican is intended to interact with certificate authorities and not represent a certificate authority itself. So it would defer to the CA for the revocation source of truth. And for those of you who didn't catch him, Paul Kerr in the corner is another Barbican contributor that you're welcome to attack after this presentation if you have additional questions. Yes. Yes. I'm new to Barbican and I'm searching for a way where the private keys are stored in a more secure way. Is there an interface to HSMs and how, how, what do I have to expect? What can I expect? So all the secrets themselves are stored using an interface called a secret store plugin interface. And then that can work with what we call HSM or crypto store interfaces. And those are where you can introduce things like HSMs to actually back the secret. So we would use those to actually encrypt the secret. And Barbican would never have access to the actual encryption key that's being used by the HSM. And so everything stored outside of the HSM is encrypted by the HSM in that mode. And these integrations are already available? Yes, we're using a PKCS11 plugin right now to support that at the secret store level, which is kind of a level up from that. We have a KMIP implementation. If you have a KMIP device or service that you have available in your enterprise, you can use that instead. And you can also use DogTag as well, too. So DogTag also talks to different HSMs doing a safe net whatever it gets me. Thanks. I guess that's it. All right. Thanks again, guys. Thank you very much for coming. Appreciate it.