Trust assertions
Walter, Stef
In order to provide a usable foundation for crypto on the desktop, the various crypto libraries need a way of accessing common information about the user's preferences with regard to certificates and 'trust'. "Trust Assertions" provide a way to represent certificate authority anchors, 'pinned' certificate exceptions, revocation lists, and other bits of trust information. A common method of accessing this information is missing from the open source desktop. We will show how we can make this information available through PKCS#11, so the user's applications (regardless of crypto library) can act consistently when making trust decisions. We'll present one solution, but more importantly: kick start progress in this area and discuss how we can move forward together.
 I'm Steph Walter and I am really interested in desktop crypto, making desktop, 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. Apps 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 using 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 going to be 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 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 is going to think something completely different. It's 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. Now 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 assertion. Trust assertion represents the trust of the user or the application that's running in 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. 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 cart-lash trust in the world. Most people don't even trust themselves. Here's an example of a trust assertion that you might have seen. A certificate authority is a trust assertion. 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. Here we have the certificate as a subject, introducer level of trust and server authentication, in the case of this first checkbox, is the purpose. 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. Here we have a different level of trust. Just trust it. It's not an introducer anymore. 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 as the public key, trusted level, and the host as the purpose. When you cut yes, it actually adds a trust assertion to your known host file. These are all stored in different ways in different places, but they're essentially the same concept. Again, this is a positive trust assertion. We are building trust. Here's a negative trust assertion. I couldn't get a screen trial 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. It turns out that with distrust, the purpose of being carte blanche makes much more sense. You cannot 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 a falsifying trust is 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. Untrusted subject is something that you don't know the trust of. You use positive trust assertions to build up trust. You look for, how can I do I have any information to make up positive trust assertions about this? Once you have that, in this instance 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. Positive trust assertions operate on something that would otherwise be trusted. This is in the case of the CRL. Then we found one of these certificates are our revoked. We falsified the trust of the whole chain. How does this help us to share trust decisions? How do users see a consistent or predictable principle of least surprise trust decisions from all these different applications and crypto libraries? What we've done is we've stored trust assertions in PKCS11. Just like certificates are stored in PKCS11 and keys are stored in PKCS11. 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 PKCS11 where you have a public key class or private keys. And then you have different types of public keys, similar concepts. 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 PKCS11 because it just makes it simpler to access, simpler to look at more consistently. So here we have an example of a trust assertion stored in PKCS11. 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 anchored certificate, 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, the Duran coding of an OID as is used elsewhere in PKCS11. But a string really gives us the flexibility that is needed for new uses of trust assertions. So that, for example, trust assertion unrelated to certificates could also be stored in this proposal. Then the subject is the certificate value, the entire certificate Duran coding. Some other concepts that are similar to this might use hashes. But we live in a world of completely unstable in relation to hashes. They're going out of style like it's closed these days. So we trust to use the entire certificate value as the subject. And here is another one, a pinned certificate. And there is an extra field here, which is the peer that certificate is pinned 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 issue 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 Duran coding of it is or even half or anything like that. This is a negative trust assertion. These are the implementations of trust assertions in PKCs 11. They have new TLS support and the implementation that's going to be merged is it uses PKCs 11 trust assertions to look up information like about the CAs on the system about storage exceptions and about CRLs and things like that. Now, Kering has support for storing these. And LiveGCR is a GUI library that has support for looking about for using them. 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 that 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. And as we get a better foundation for a consistent crypto experience, then things can develop even further. And we have more glue. The PLM 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 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 PKCS 11 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 that 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? He finalizes. One guy comes in and finalizes, tears it off, and the other guy, nobody finalizes, and resources are 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 PKCS 11 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've been the spec a little bit. Then it counts how many times finished 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 PKCS 11 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, will 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 PKCS 11 modules on the system, they're there. Or you can be aware of PKCS 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 rep 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 Pat Choi, is that how you say it? I don't know. And perhaps PKCS 11, you are all support if we want that. But essentially the problem is that if we're going to use PKCS 11 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 as marked as fragile or something, could coordinate access to it so that 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. BSD 11, I'm sorry, BSD licensed. You say PKCS 11 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, PKCS 11 is 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 PKCS 11 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. That in this detailed aspect 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, which 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 GNOME 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 CA is from GNOME 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, the things 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. I like that communication. We're going to have more of it. I already subscribe. We have that mailing list. It's a news group, actually. Are you aware of that? Tech Crypto. Yes, of course. I'm on that mailing list. I posted some stuff earlier about trust objects and things. Do you got a big thing? No, I don't. Don't remember. Ah, fine. Okay, well, thanks a lot. That's great. Now, 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, when 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 E-Level Kit is having to enter the PIN caching. It's a 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 want actually the user to try to use it. I have a question. Why all the applications want to cache the PIN? Which say they should be done in the first place? Well, all the users. Yes, in many cases, I mean, it depends. I think that's smart cards that shouldn't cache the PIN should provide an outside way to do it. Of course, that's more expensive. So that is a... I didn't say the application had to do it. I said that 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 trusted services. So you 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 as he has gone on trust? Because if anyone can remove negative trust assertions... Who can trust the trust assertion? Well, yes. It's always a problem to start the watchers. Especially if you're removing the CRLs into single trust assertion that can 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 whole case of trust assertions and in the search, we signed typically the N and then we sort of extract the QDN or something like that from that. And increasingly, we sort of have court members sitting alongside the QDN or in case of email addresses, we get similar variations. A lot of this could be there. It makes 500. This would take that variance into a capital. So we sort of start to pay for all the QDN and things like that. And as we sort of get also in the 2ID world now, that starts to increasingly become a problem. Right. Is the point, do you think that what you're doing right now in trust assertions is robust enough or is it a point where we need an extra dimension where you say like XDI only trust in this context, which is either for a growth or even more narrow permutation suitable for enterprise use where you go like that, load balancing and things like that where one idea has to be met. Are you talking about the CKX peer attribute? 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, reinforcing 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. That's a good point. 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 Gunonma Q&A. Oh, generally we just support consuming the stuff on the smart card. But Seahorse is a key manager that's growing PKCS11 support. So you're probably able to do basic things on it like export and 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 Pegasus and that is 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 do the work on it. That's true. And one last thing I want to say is that we're using PKCS11 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 PKCS11 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 PKCS11 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 Nicos talk that maybe a configuration API is really the minimum sort of puzzle piece of a puzzle that is needed to not have to enter the path of a PKCS11 provider viewer in my settings because that's what I want to get away with. And using PKCS11 to as a conduit, be it not perfect, but maybe with good buy-in, doesn't really solve that. Well, what solves it is... You have the API. Yes. Right? So in the next seven kits, if it's going to become the place for desktop applications or applications that have multiple PKCS11 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 the 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 PKCS11 modules and expose them as one module that's ref counted, that uses the config API internally to actually load those things. But we also expose that so if your application is aware of P11Kit 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 I can go and check those things out. So those are the kind of things that we'd like to see come together. Time's up. All right. Really very, very great stuff. Thanks. Thank you. Thank you.
 I'm Steph Walter and I am really interested in desktop crypto, making desktop, 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.  Apps 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  using 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 going to be 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 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  is going to think something completely different.  It's 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.  Now 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 assertion.  Trust assertion represents the trust of the user or the application that's running in  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.  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 cart-lash trust in the world.  Most people don't even trust themselves.  Here's an example of a trust assertion that you might have seen.  A certificate authority is a trust assertion.  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.  Here we have the certificate as a subject, introducer level of trust and server authentication,  in the case of this first checkbox, is the purpose.  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.  Here we have a different level of trust.  Just trust it.  It's not an introducer anymore.  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 as the public key, trusted level, and the host as the purpose.  When you cut yes, it actually adds a trust assertion to your known host file.  These are all stored in different ways in different places, but they're essentially  the same concept.  Again, this is a positive trust assertion.  We are building trust.  Here's a negative trust assertion.  I couldn't get a screen trial 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.  It turns out that with distrust, the purpose of being carte blanche makes much more sense.  You cannot 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 a falsifying trust is 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.  Untrusted subject is something that you don't know the trust of.  You use positive trust assertions to build up trust.  You look for, how can I do I have any information to make up positive trust assertions about  this?  Once you have that, in this instance 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.  Positive trust assertions operate on something that would otherwise be trusted.  This is in the case of the CRL.  Then we found one of these certificates are our revoked.  We falsified the trust of the whole chain.  How does this help us to share trust decisions?  How do users see a consistent or predictable principle of least surprise trust decisions  from all these different applications and crypto libraries?  What we've done is we've stored trust assertions in PKCS11.  Just like certificates are stored in PKCS11 and keys are stored in PKCS11.  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 PKCS11 where you have  a public key class or private keys.  And then you have different types of public keys, similar concepts.  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 PKCS11 because it just makes it simpler to access, simpler to look at more consistently.  So here we have an example of a trust assertion stored in PKCS11.  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 anchored certificate, 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, the Duran coding of  an OID as is used elsewhere in PKCS11.  But a string really gives us the flexibility that is needed for new uses of trust assertions.  So that, for example, trust assertion unrelated to certificates could also be stored in this  proposal.  Then the subject is the certificate value, the entire certificate Duran coding.  Some other concepts that are similar to this might use hashes.  But we live in a world of completely unstable in relation to hashes.  They're going out of style like it's closed these days.  So we trust to use the entire certificate value as the subject.  And here is another one, a pinned certificate.  And there is an extra field here, which is the peer that certificate is pinned 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 issue 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 Duran coding of it is or even  half or anything like that.  This is a negative trust assertion.  These are the implementations of trust assertions in PKCs 11.  They have new TLS support and the implementation that's going to be merged is it uses PKCs  11 trust assertions to look up information like about the CAs on the system about storage  exceptions and about CRLs and things like that.  Now, Kering has support for storing these.  And LiveGCR is a GUI library that has support for looking about for using them.  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 that 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.  And as we get a better foundation for a consistent crypto experience, then things can develop  even further.  And we have more glue.  The PLM 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 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 PKCS 11 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 that 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?  He finalizes.  One guy comes in and finalizes, tears it off, and the other guy, nobody finalizes, and resources  are 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 PKCS 11 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've been the spec a little bit.  Then it counts how many times finished 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 PKCS 11 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, will 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  PKCS 11 modules on the system, they're there.  Or you can be aware of PKCS 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 rep 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 Pat Choi,  is that how you say it?  I don't know.  And perhaps PKCS 11, you are all support if we want that.  But essentially the problem is that if we're going to use PKCS 11 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 as marked as fragile or something, could coordinate  access to it so that 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.  BSD 11, I'm sorry, BSD licensed.  You say PKCS 11 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, PKCS 11 is 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 PKCS 11 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.  That in this detailed aspect 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, which 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 GNOME 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 CA is from GNOME 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, the things 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.  I like that communication.  We're going to have more of it.  I already subscribe.  We have that mailing list.  It's a news group, actually.  Are you aware of that?  Tech Crypto.  Yes, of course.  I'm on that mailing list.  I posted some stuff earlier about trust objects and things.  Do you got a big thing?  No, I don't.  Don't remember.  Ah, fine.  Okay, well, thanks a lot.  That's great.  Now, 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, when 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 E-Level Kit is having to enter the PIN caching.  It's a 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 want actually the user to try to use it.  I have a question.  Why all the applications want to cache the PIN?  Which say they should be done in the first place?  Well, all the users.  Yes, in many cases, I mean, it depends.  I think that's smart cards that shouldn't cache the PIN should provide an outside way  to do it.  Of course, that's more expensive.  So that is a...  I didn't say the application had to do it.  I said that 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 trusted services.  So you 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 as he has gone on trust?  Because if anyone can remove negative trust assertions...  Who can trust the trust assertion?  Well, yes.  It's always a problem to start the watchers.  Especially if you're removing the CRLs into single trust assertion that can 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 whole case of trust assertions and in the search, we signed typically the  N and then we sort of extract the QDN or something like that from that.  And increasingly, we sort of have court members sitting alongside the QDN or in case of email  addresses, we get similar variations.  A lot of this could be there.  It makes 500.  This would take that variance into a capital.  So we sort of start to pay for all the QDN and things like that.  And as we sort of get also in the 2ID world now, that starts to increasingly become a problem.  Right. Is the point, do you think that what you're doing right now in trust assertions is  robust enough or is it a point where we need an extra dimension where you say like XDI  only trust in this context, which is either for a growth or even more narrow permutation  suitable for enterprise use where you go like that, load balancing and things like that  where one idea has to be met.  Are you talking about the CKX peer attribute?  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, reinforcing 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.  That's a good point.  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 Gunonma Q&A.  Oh, generally we just support consuming the stuff on the smart card.  But Seahorse is a key manager that's growing PKCS11 support.  So you're probably able to do basic things on it like export and 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 Pegasus and that is 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 do the work on it.  That's true.  And one last thing I want to say is that we're using PKCS11 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 PKCS11 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 PKCS11 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 Nicos talk that maybe a configuration API is really the minimum sort of puzzle piece of a puzzle that is needed to not have to enter the path of a PKCS11 provider viewer in my settings  because that's what I want to get away with.  And using PKCS11 to as a conduit, be it not perfect, but maybe with good buy-in, doesn't really solve that.  Well, what solves it is...  You have the API.  Yes.  Right?  So in the next seven kits, if it's going to become the place for desktop applications or applications that have multiple PKCS11 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 the 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 PKCS11 modules and expose them as one module that's ref counted, that uses the config API internally to actually load those things.  But we also expose that so if your application is aware of P11Kit 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 I can go and check those things out.  So those are the kind of things that we'd like to see come together.  Time's up.  All right.  Really very, very great stuff.  Thanks.  Thank you.  Thank you.
security_1630_trust_walter_qW_62Gaoqjk_2_0_263.png security_1630_trust_walter_qW_62Gaoqjk_2_264_311.png security_1630_trust_walter_qW_62Gaoqjk_2_312_431.png security_1630_trust_walter_qW_62Gaoqjk_2_432_1067.png security_1630_trust_walter_qW_62Gaoqjk_2_1068_1151.png security_1630_trust_walter_qW_62Gaoqjk_2_1152_1199.png security_1630_trust_walter_qW_62Gaoqjk_2_1200_4871.png security_1630_trust_walter_qW_62Gaoqjk_2_4872_6119.png security_1630_trust_walter_qW_62Gaoqjk_2_6120_7343.png security_1630_trust_walter_qW_62Gaoqjk_2_7344_7607.png security_1630_trust_walter_qW_62Gaoqjk_2_7608_8075.png security_1630_trust_walter_qW_62Gaoqjk_2_8076_9143.png security_1630_trust_walter_qW_62Gaoqjk_2_9144_9383.png security_1630_trust_walter_qW_62Gaoqjk_2_9384_9443.png security_1630_trust_walter_qW_62Gaoqjk_2_9444_9491.png security_1630_trust_walter_qW_62Gaoqjk_2_9492_9731.png security_1630_trust_walter_qW_62Gaoqjk_2_9732_10151.png security_1630_trust_walter_qW_62Gaoqjk_2_10152_10307.png security_1630_trust_walter_qW_62Gaoqjk_2_10308_10943.png security_1630_trust_walter_qW_62Gaoqjk_2_10944_11171.png security_1630_trust_walter_qW_62Gaoqjk_2_11172_11579.png security_1630_trust_walter_qW_62Gaoqjk_2_11580_11627.png security_1630_trust_walter_qW_62Gaoqjk_2_11628_12059.png security_1630_trust_walter_qW_62Gaoqjk_2_12060_12131.png security_1630_trust_walter_qW_62Gaoqjk_2_12132_13619.png security_1630_trust_walter_qW_62Gaoqjk_2_13620_15599.png security_1630_trust_walter_qW_62Gaoqjk_2_15600_19607.png security_1630_trust_walter_qW_62Gaoqjk_2_19608_19799.png security_1630_trust_walter_qW_62Gaoqjk_2_19800_21767.png security_1630_trust_walter_qW_62Gaoqjk_2_21768_21995.png security_1630_trust_walter_qW_62Gaoqjk_2_21996_22091.png security_1630_trust_walter_qW_62Gaoqjk_2_22092_22367.png security_1630_trust_walter_qW_62Gaoqjk_2_22368_28751.png security_1630_trust_walter_qW_62Gaoqjk_2_28752_33203.png security_1630_trust_walter_qW_62Gaoqjk_2_33204_44915.png security_1630_trust_walter_qW_62Gaoqjk_2_44916_45023.png security_1630_trust_walter_qW_62Gaoqjk_2_45024_45083.png security_1630_trust_walter_qW_62Gaoqjk_2_45084_45215.png security_1630_trust_walter_qW_62Gaoqjk_2_45216_45491.png security_1630_trust_walter_qW_62Gaoqjk_2_45492_45887.png security_1630_trust_walter_qW_62Gaoqjk_2_45888_46315.png
I'm Steph Walter and I am really interested in desktop crypto, making desktop, 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. Apps 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 using 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 going to be 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 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 is going to think something completely different. It's 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. Now 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 assertion. Trust assertion represents the trust of the user or the application that's running in 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. 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 cart-lash trust in the world. Most people don't even trust themselves. Here's an example of a trust assertion that you might have seen. A certificate authority is a trust assertion. 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. Here we have the certificate as a subject, introducer level of trust and server authentication, in the case of this first checkbox, is the purpose. 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. Here we have a different level of trust. Just trust it. It's not an introducer anymore. 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 as the public key, trusted level, and the host as the purpose. When you cut yes, it actually adds a trust assertion to your known host file. These are all stored in different ways in different places, but they're essentially the same concept. Again, this is a positive trust assertion. We are building trust. Here's a negative trust assertion. I couldn't get a screen trial 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. It turns out that with distrust, the purpose of being carte blanche makes much more sense. You cannot 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 a falsifying trust is 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. Untrusted subject is something that you don't know the trust of. You use positive trust assertions to build up trust. You look for, how can I do I have any information to make up positive trust assertions about this? Once you have that, in this instance 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. Positive trust assertions operate on something that would otherwise be trusted. This is in the case of the CRL. Then we found one of these certificates are our revoked. We falsified the trust of the whole chain. How does this help us to share trust decisions? How do users see a consistent or predictable principle of least surprise trust decisions from all these different applications and crypto libraries? What we've done is we've stored trust assertions in PKCS11. Just like certificates are stored in PKCS11 and keys are stored in PKCS11. 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 PKCS11 where you have a public key class or private keys. And then you have different types of public keys, similar concepts. 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 PKCS11 because it just makes it simpler to access, simpler to look at more consistently. So here we have an example of a trust assertion stored in PKCS11. 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 anchored certificate, 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, the Duran coding of an OID as is used elsewhere in PKCS11. But a string really gives us the flexibility that is needed for new uses of trust assertions. So that, for example, trust assertion unrelated to certificates could also be stored in this proposal. Then the subject is the certificate value, the entire certificate Duran coding. Some other concepts that are similar to this might use hashes. But we live in a world of completely unstable in relation to hashes. They're going out of style like it's closed these days. So we trust to use the entire certificate value as the subject. And here is another one, a pinned certificate. And there is an extra field here, which is the peer that certificate is pinned 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 issue 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 Duran coding of it is or even half or anything like that. This is a negative trust assertion. These are the implementations of trust assertions in PKCs 11. They have new TLS support and the implementation that's going to be merged is it uses PKCs 11 trust assertions to look up information like about the CAs on the system about storage exceptions and about CRLs and things like that. Now, Kering has support for storing these. And LiveGCR is a GUI library that has support for looking about for using them. 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 that 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. And as we get a better foundation for a consistent crypto experience, then things can develop even further. And we have more glue. The PLM 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 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 PKCS 11 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 that 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? He finalizes. One guy comes in and finalizes, tears it off, and the other guy, nobody finalizes, and resources are 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 PKCS 11 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've been the spec a little bit. Then it counts how many times finished 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 PKCS 11 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, will 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 PKCS 11 modules on the system, they're there. Or you can be aware of PKCS 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 rep 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 Pat Choi, is that how you say it? I don't know. And perhaps PKCS 11, you are all support if we want that. But essentially the problem is that if we're going to use PKCS 11 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 as marked as fragile or something, could coordinate access to it so that 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. BSD 11, I'm sorry, BSD licensed. You say PKCS 11 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, PKCS 11 is 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 PKCS 11 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. That in this detailed aspect 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, which 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 GNOME 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 CA is from GNOME 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, the things 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. I like that communication. We're going to have more of it. I already subscribe. We have that mailing list. It's a news group, actually. Are you aware of that? Tech Crypto. Yes, of course. I'm on that mailing list. I posted some stuff earlier about trust objects and things. Do you got a big thing? No, I don't. Don't remember. Ah, fine. Okay, well, thanks a lot. That's great. Now, 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, when 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 E-Level Kit is having to enter the PIN caching. It's a 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 want actually the user to try to use it. I have a question. Why all the applications want to cache the PIN? Which say they should be done in the first place? Well, all the users. Yes, in many cases, I mean, it depends. I think that's smart cards that shouldn't cache the PIN should provide an outside way to do it. Of course, that's more expensive. So that is a... I didn't say the application had to do it. I said that 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 trusted services. So you 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 as he has gone on trust? Because if anyone can remove negative trust assertions... Who can trust the trust assertion? Well, yes. It's always a problem to start the watchers. Especially if you're removing the CRLs into single trust assertion that can 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 whole case of trust assertions and in the search, we signed typically the N and then we sort of extract the QDN or something like that from that. And increasingly, we sort of have court members sitting alongside the QDN or in case of email addresses, we get similar variations. A lot of this could be there. It makes 500. This would take that variance into a capital. So we sort of start to pay for all the QDN and things like that. And as we sort of get also in the 2ID world now, that starts to increasingly become a problem. Right. Is the point, do you think that what you're doing right now in trust assertions is robust enough or is it a point where we need an extra dimension where you say like XDI only trust in this context, which is either for a growth or even more narrow permutation suitable for enterprise use where you go like that, load balancing and things like that where one idea has to be met. Are you talking about the CKX peer attribute? 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, reinforcing 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. That's a good point. 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 Gunonma Q&A. Oh, generally we just support consuming the stuff on the smart card. But Seahorse is a key manager that's growing PKCS11 support. So you're probably able to do basic things on it like export and 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 Pegasus and that is 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 do the work on it. That's true. And one last thing I want to say is that we're using PKCS11 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 PKCS11 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 PKCS11 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 Nicos talk that maybe a configuration API is really the minimum sort of puzzle piece of a puzzle that is needed to not have to enter the path of a PKCS11 provider viewer in my settings because that's what I want to get away with. And using PKCS11 to as a conduit, be it not perfect, but maybe with good buy-in, doesn't really solve that. Well, what solves it is... You have the API. Yes. Right? So in the next seven kits, if it's going to become the place for desktop applications or applications that have multiple PKCS11 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 the 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 PKCS11 modules and expose them as one module that's ref counted, that uses the config API internally to actually load those things. But we also expose that so if your application is aware of P11Kit 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 I can go and check those things out. So those are the kind of things that we'd like to see come together. Time's up. All right. Really very, very great stuff. Thanks. Thank you. Thank you.
usable on the desktop security that's integrated way. And so what we need is a way to access the have to store keys and certificates and present order to have a consistent user experience but we is whether to trust a certificate authority or decisions themselves. They represent information that applications and libraries can then use to pinned to. Essentially this is a certificate foundation for a consistent crypto experience, slots from those guys as slots in one library, in using that method to access the various installed like certificate exceptions, where in addition to outside a little bit longer? We will open the about the CKX peer attribute? Well, I'd like to other bits and parts of it to make it work. So PKCS11 users to kind of come together, coordinate