 I'm Steph Walter, and I am really interested in desktop crypto, making crypto usable on the desktop security that's integrated between all the applications where developers have a real solid foundation to build on. I'm excited by different advances in crypto, different sometimes crazy, sometimes fascinating ideas. And I think all of that comes out of a real solid base for understanding and using the crypto that we already have. I work for Calabra, and I'm the maintainer of Nome Keyring and Seors Developer. So, what brings me here is that we've been using PKCS11 as a glue to bring together different crypto libraries. Projects like OpenSC, NSS, GNU TLS, all really excellent, good, good stuff. I mean, with different focuses and stuff, and that kind of diversity is what we need in the Linux desktop. That is the real key of open source, is that evolution through diversity. And so, on the other hand, users are kind of torn between having to choose. Some applications use a crypto library one way, others use it another way. And so, what we need is a way to access the same certificates, keys and stuff across all the different crypto libraries. Now, Nicos talked a little bit about that, and together we've been doing some interesting research on the different problems that you face when you try to do that. So, today I'm going to talk about one of those problems and a solution that we found for it, and hopefully if we have time, touch on a few that more than are in progress, kind of tagging on to what Nicos discussed earlier. Sorry. Okay, I'm talking about trust. Not only do we have to store keys and certificates and present them to all these applications and libraries in order to have a consistent user experience, but we have to have applications make consistent trust decisions. Like, for example, the most obvious one is whether to trust a certificate authority or not. Now, trust is a very ambiguous word. And if you say trust in a room full of people, everyone's going to think something completely different. The kind of word we shouldn't be using, especially not in user interfaces. In security, we want unambiguous words. We want precise definitions. Trust is precisely imprecise. So we shouldn't abuse that word, but I'm going to abuse it today a whole lot. I'm going to abuse it enough to make Jean-Luc Picard do this. But we have a specific concept that I want to talk about. It's called trust assertions. And rather than being an imprecise concept, trust assertions represent something very... It's a standard concept that we've all seen in different forms, but it's boiled down into this phrase, this tag. Trust assertions expose little bits of information that are necessary to make a trust decision. Trust assertion represents the trust of the user or the application that's running in a subject like a certificate for a given purpose, connecting to a website. Trust assertions don't represent the decisions themselves. They represent information that applications and libraries can then use to make a decision. Trust assertion is essentially a tuple, or triple, containing these three things. A subject, a level of trust, and a purpose. A subject might be a fingerprint, it might be a certificate, it might be a public key. A level of trust, trusted, distrusted, or might have an introducer level of trust, or introduce another subject, and a purpose. Trust without a purpose is something that you don't see very often in the real world. You trust your bank with your money, your school with your kids, but not necessarily vice versa. There's very little carte-lange trust in the world. Most people don't even trust themselves. So, here's an example of a trust assertion that you might have seen. A certificate authority is a trust assertion. It's a fact. It's a piece of information that's stored that represents that piece of information can then be used by an application to make a decision. We have the certificate as the subject, introducer level of trust, and server authentication, also in the case of this first checkbox, is the purpose. And this is the Firefox screenshot. These three different checkboxes represent, really, three different trust assertions. When you check that box and install this CA in your browser, you are creating trust assertions. Here's another example. This is a certificate exception. When you access a site that the CA is not installed, it's routed one way or another, it prompts you to either leave the site and run away, or to add a certificate exception. We call it a PIN certificate. So, here we have a different level of trust, just trusted. It's not an introducer anymore. And the purpose is further refined. The purpose is to connect to a single website. Notice that these are positive trust assertions. They tell you information that builds trust, that adds to a trust decision in a way that eventually, if all the criteria were met, that subject would be trusted. Here's another one. This one's a little different. You've all seen it. SSH, when the first time you connect to a host, you have the subject of the trust assertion is the public key, trusted level, and the host adds the purpose. And when you connect, yes, it actually adds a trust assertion to your known host file. These are all stored in different ways and different places, but they're essentially the same concept. Again, this is a positive trust assertion. We're building trust. Here's a negative trust assertion. I couldn't get a screenshot of a CRL, so I got this ugly icon. Basically, a CRL consists of a bunch of trust assertions. We are stating that this subject, represented by a serial number and an issuer, is distrusted for purpose, actually any purpose. Turns out that with distrust, the purpose being carte blanche makes much more sense. You can not trust someone to do anything. You can distrust someone for any purpose whatsoever. Here's one more foundation concept before we get into the actual details of how this helps us. Building and falsifying trust is kind of a process that you go through with trust assertions. Initially, you start off while making a trust assertion. Initially, you start off with an unknown trusted subject. So, untrusted subject is something that you don't know the trust of. You use positive trust assertions to build up trust. Do I have any information to make a positive trust assertion about this? In this case, for example, we build a certificate chain. Oh, look, there's the anchor. We found that as a trust assertion. We load some certificates. They introduce each other. We have that. Then we use negative trust assertions to check if we should falsify that trust. The important concept is that positive trust assertions operate on untrusted subjects. We don't know yet the trust of them. We build up the trust with positive assertions. Negative trust assertions operate on something that would otherwise be trusted. So, this is in the case of a CRL. Maybe we found one of these certificates on our revoked. So, we falsified the trust of the whole chain. So, how does this help us to share trust decisions? Help the user see a consistent or predictable principle of least surprise trust decisions from all these different applications in crypto libraries? Well, what we've done is we've stored trust assertions in PKCS 11. Just like certificates are stored in PKCS 11 and keys are stored in PKCS 11. Now, we store trust assertions as one object per trust assertion. They don't necessarily have to be stored on the same token as the subject that they are representing or referencing. They can be stored somewhere else. They don't have to be stored with the certificate that they're representing. Each one has a class and different types, kind of like public keys in PKCS 11 where you have a public key class or private keys, and then you have different types of public keys, a similar concept. The theory of trust assertions is kind of obvious and simple, but as so often happens when theory meets reality, things get a little messy. So, we might turn things around a little bit when I show you the attributes that we use in PKCS 11 because it just makes it simpler to access, simpler to look at more consistent. So, here we have an example of a trust assertion stored in PKCS 11. These are the different attributes that we use. We have a class of CKOX trust assertion, and here's the type. Now, in this case, we're representing an anchored certificate. So, here's the type that represents it. We have a purpose. The purpose is a string. We were thinking it could be an OID perhaps or something like that, you know, the DER encoding of an OID as is used elsewhere in PKCS 11, but a string really gives us the flexibility that is needed for new uses of trust assertions. So that, for example, trust assertions unrelated to certificates could also be stored in this proposal. Then, the subject is the certificate value, the entire certificate DER encoding. Some other concepts that are similar to this might use hashes, but we live in a currently, in a world of completely unstable in relation to hashes. You know, they're going out of style like clothes these days. So, we're chosen to use the entire certificate value as the subject. And here is another one, a PIN certificate. Notice there's an extra field here, which is the peer that certificate is PIN to. Essentially, this is a certificate exception. This is what you would look up if you wanted to check if there was a special exception for you, a given host, connect to that. And we have the distrusted certificate trust assertion. Now, this one is a little different. A subject, we use the issuer and the serial number together to comprise the subject of the trust assertion so that we can represent things like certificate revocation list, which certainly don't contain the entire certificate, and we wouldn't know what that certificate actually, the DER encoding of it is, or even HAT or anything like that. This is a negative trust assertion. These are the implementations of trust assertions in PKCS 11. It's being implemented in GLIF. They have new TLS support, and the implementation that's going to be merged is, it uses PKCS 11 trust assertion to look up information like about the CAs, on the system about storage exceptions, and about CRLs and things like that. Now, Keering has support for storing these, and LibGCR is a GUI library that has support for looking about for using them. And we're looking forward to new TLS supporting them in some way. And we also have a compatibility layer that exposes trust assertions as NSS trust objects, so that NSS can use them too. In the specification, there's a bunch of answers as to why we do things a certain way and the decisions that are made, and it talks a little bit about NSS trust objects as well. So that's part of the glue that we are using to connect applications. When it turns out on the desktop, people are really interested in making certificates in his work, but they're even more interested in the problem of having to install the certificate authority in 100 places. And basic things like that don't yet even exist. So that's why we're coming from this angle, solving those problems. As we get a better foundation for a consistent crypto experience, then things can develop even further. And we have more glue. The P11 hit that Nicos mentioned, I've been working on that, but this is really working progress, so I haven't had time to flesh it out, at least specify it. And we'd love as much participation as we can get because this is the kind of thing that everyone, we need, in order to solve this problem properly, we need lots of people to get behind it. Now, the first problem was the initialization problem that Nicos talked about. Multiple users of the PKCS11 module in the same process have this problem where they both try to initialize it. On initialization, the second guy gets an error, CKR already initialized, and would you know the error? Which is not actually an error, but let's say you ignore it. You say, hey, okay, fine, I know that guy, ignore him. Then when you come around to finalize, then what do you do? You finalize this. One guy comes in and finalizes, tears it out from the other guy, nobody finalizes, and resources aren't free, stuff's locked. It's just, it gets kind of messy. So what we've done is come up with a concept that you could have a single PKCS11 library that loads a bunch of different other ones and coordinates access to them, and it breath counts, initialization, and finalization of them all. So you basically, it exposes all the slots from those guys as slots in one library, in one module. And by doing that, you can call initialize as many times as possible and never actually return CKR if already initialized. We thin the spec a little bit, and it counts how many times it's been initialized, and then you can finalize it the same number of times, and it fixes that problem. In addition, once you have all those different users on a desktop or on a in a distro, using that method to access the various installed PKCS11 modules, it brings you into a single place where you can also do configuration, which ones are installed. Well, obviously, this module will need to know which ones are installed. We'll need to decide on a configuration standard, whether it's files in a directory or a config system like Nicos is talking about. And we can also expose library functions. So you can use this as a module. For example, NSS can load this module, this proxy module, and boom, all the installed PKCS11 modules on the system, they're there. Or you can be aware of PKC P11. Let's say you want to link to it directly. You can link to it as a library. And then you have access to all those modules, the information you can initialize stuff, and it will ref-count stuff for you. And you can access the config. Let's say you have special config options, and we work out some kind of config system. You can access the config in different ways. I've been talking with Joe Orton of perhaps bringing in some functionality from Patrick Choi, is that how you say it? I don't know. And perhaps PKCS11, you are all supported if we want that. But essentially, the problem is that if we're going to use PKCS11 on the desktop and we're going to have the diversity of crypto libraries that we currently do, then we need a coordinating factor in there. This P11 kit could also, if a library was marked as, you know, fragile or something, could coordinate access to it so that only one could initialize, sorry, only one could perform an operation at a time or something like that. It could do things like that if we wanted to. Of course, we want to keep this simple. We want to keep it to the point of what we're trying to do. So P11 kit is currently kind of in a prototype stage. BSD11, I'm sorry, BSD licensed. You say PKCS11 too much. You start fitting it in everywhere. And it has no dependencies. I mean, I guess it has P thread dependencies because, as you know, PKCS11 essentially, it needs some kind of threading going on there. But hopefully, we can have this project take off and solve this problem. Without it, we're kind of up a creek as far as using PKCS11. Robustly on the desktop. So that's all I had. Any questions? Yes, I have two questions. First one is, why did you prefer to invent new trust objects instead of using the same model that NSS uses for trust objects? Yes. It's detailed in the spec towards the end. I actually went through and documented the NSS trust object model because it hasn't been documented and added to the documentation. And I was really hoping we could use that. But there are several reasons that we didn't. One is that it stores multiple trust assertions on the same object. It really gets complicated as far as looking up and especially storing them. It's not extensible. You can't add more different purposes than NSS and Firefox use. And most importantly, it doesn't support things like certificate exceptions where in addition to the purpose, it consists of type of use and a host or an email address or those things. So those things just don't exist. And once you run into those problems, you realize that it makes sense to start afresh. I think that trust objects was a good idea, but it's like 10 or 15 years old. And now here we're in kind of a different climate and different stage. But I've known key ring exposes all the trust assertions it contains as trust objects, as NSS trust objects as well. So you plug that in, boom. Your CAs from known key ring automatically work there. So you can do stuff like that. Okay, thanks. And the second one is actually more command. You might have heard that Fedora has also introduced some new system-wide PQC S11 token or the global shared database. So you can have a global list of your system-wide trusted CAs. So do you think there is need for coordination between your coordination attempt and that one, that thing that Fedora and NSS are trying to do? Yes, we should definitely coordinate. What we're trying to do here is provide it to everyone. And sometimes with NSS, I like to coordinate with them, but it's hard to, in many cases, get them to understand that there are other crypto-libraries on the market. I like that communication. We're going to have more of that. We have that mailing list. It's a news group, actually. Are you aware of that? I'm on that mailing list. I posted some stuff earlier about trust objects and things. Do you got a big thing? Not much, don't you remember? Not much. Okay, well, thanks a lot. That's great. There are many things you provide as a library that could make sense also as a service. We talked about hearing, but there are different needs about revocation, the fact that you need to update URLs, things that are maybe implemented in NSS, where you have refreshing OCSP checking stuff. And one of the things that will be useful for desktop that can't be used when each application uses your proxy of P11Kit is having to enter the PIN caching. It's kind of a tricky question because you might want sometimes to actually have a user... The talk is not yet over. Could you please wait outside a little bit longer? We will open the door when it's finished. So please close the door so we can listen better. Thank you. PIN caching is an issue that is useful for the desktop. And sometimes you want it and it would be good that something would be done as a service and sometimes you don't want it when you don't actually have the user to use it. I have a question. Why all the applications want to cache the PIN? You said it should be done in the first place. While all the users... Yes, in many cases, I mean, it depends. I think that's a smart card that shouldn't cache the PIN to provide an outside way to do it. Of course that's more expensive. I didn't say the application had to do it. In some users, you don't want the user to re-authenticate all the time. As far as CRLs, I'm working on a module that exposes directory of CRLs as trust assertion. So they can just be looked at however they want and anything can update them, a demon or whatever. Now, of course, there's many issues to work out there and that's where I'd like to collaborate with NSS. That's the kind of thing that would be perfect to collaborate on. And so I hope that... And how about ACS on own trust assertions? Because if anyone can remove negative trust assertions... How can we trust their trust assertion? Well, yes. It's always a question to watchers. Especially if you're speeding up CRLs into single trust assertion that can't be verified anymore, it becomes a little bit difficult. That's a good point. And NSS makes it so that you can expose the entire CRL as another object. So if you want to access the whole CRL and get involved in that, you can. So right now in the walkie-stress search and in the search, we sign typically the Dn, and then we sort of extract the Dn, Qdn, or something like that from that. And increasingly, we sort of have port numbers sitting alongside Qdn or in case of email addresses, we get similar variations. A lot of stuff in there makes 500. This would take that variance into a capital, so we sort of start to anchor all of Qdn and things like that. And as we sort of get also into two IP roles now, that starts to increasingly become a problem. Is there a point... Do you think that what you're doing right now in trust acres is robust enough, or is there a point where we need next to a dimension where you say, like, XDI, I'm only interested in this context, which is either forward or approachable, or even more narrow permutation suitable for enterprise use where you go like that, load balancing and things like that, where one IP of us is needing that kind of thing. Are you talking about the CKX peer attribute? For example, with XDI, it's throughout the whole standard. Well, I'd like to flush that out. I think it's... Yes, I agree that it's kind of naive right now. It might be good to use something like subject alt name string, like the way that they're represented in most user interfaces with that. Something in a colon, DNS colon, and then the host name or email colon, and then an email address or something like that. And then you could work like that. The concept here is to make something that is robust and flexible enough to use, not just for certificates, but also other uses. And so maybe something like that would fit the bill. That's why I want to shy away from using... Enforcing OIDs. I'd like to make it available in the purpose field. It's the same kind of thing. Maybe an application wants to store trust assertions that only it can then... specific to itself. Then perhaps it wants to just put a string in there or something. So that's the kind of stuff we need to fine tune. It's a good point. Yes. Do you plan to manage a little bit of the life cycle of the smart card like initialization and transfer, or leave it for NSS? In which part? In... Okay. In Gnome Q&A. Oh. Generally, we just support consuming the stuff on the smart card. But Seahorse is a key manager that's growing PKCS 11 support. So you're probably able to do basic things on it, like export a certificate or maybe put something on there. We're not sure how far we'll go. Once you get into initialization, it starts to get very specific to the smart card as well. There are two comments to remember. One is from Robert on the Netscape list that they basically gave up on personalization. And the other comment is from PKCS 11 specification that says that initialization is usually left to outside of the scope of Netscape. So there are kind of... You can do some stuff, but in real life it's kind of limited. So we need to work on it. That's true. And one last thing I wanted to say is that we're using PKCS 11 for this stuff. Now, we're using it because it's there and it's implemented in all these different places. It's not necessarily perfect, but we're using it pragmatically because it already has such a big user base. We're storing trust assertions in PKCS 11, not because that's the perfect way to do it in theory, but because it works. You can do things like using the login system, the PIN system of PKCS 11, and all sorts of other bits and parts of it to make it work. So here's a thought on that note. I commented during Nico's talk that maybe a configuration API is really the minimum piece of a puzzle that is needed to not have to enter the path of a PKCS 11 provider viewer in my settings because that's what I want to get away from. And using PKCS 11 as a conduit, be it not perfect but maybe with good buy-in, it doesn't really solve that. Well, what solves it is... You have the API. Yes. Right? P11 kit, if it's going to become the place for desktop applications or applications that have multiple PKCS 11 users to kind of come together, coordinate, and ref count their usage, we are adding, and it's already there, a configuration API into that place. We're going to use a single library. It's a small little library to coordinate this stuff. You might as well do as a configuration thing that just works. Of course, an application that's free to ignore it, but it's there and it's usable. And it's already kind of prototyped a bit. We have one file module so that applications like OpenSC can install a file in a known location, and then it becomes available to other stuff. There's global settings that could be there and then per module settings that can be used in different ways. The proxy module that I talked about, that loads all those PKCS 11 modules and exposes them as one module that's ref counted, that uses the config API internally and we actually love those things. But we also expose that so if your application is aware of P11 kit and actually links to it, then it can use those config things. It can load up stuff like perhaps there might be settings, we might define settings that say on this token, these algorithms are hardware accelerated. So if it's an application from us that it can go and check those things out. So those are kind of things that we'd like to see come together. Time's up. Great stuff. Thank you.