On 11.12.2014 10:12, David Woodhouse wrote: > I'd love to have a Fedora Feature in F22 for PKCS#11, where keys+certs > from installed PKCS#11 modules are expected to Just Work™ in all > applications that can use certificates. Using consistent PKCS#11 URIs > where appropriate. Even if we aren't ready for a Feature, I'd love to > make some more progress in that direction. Obviously none of this is > really Fedora-specific, but if we can get it right in Fedora (as we did > for the trust stuff), other distributions can follow.
I believe there's an open process for proposing Fedora Features and I think it's going on right now. But I agree that doing all of this in a few months is a bit much to bite off, even for someone as tireless as you :D But progress in that direction is great. > With OpenSSL there's ENGINE_PKCS11, and I have a proof-of-concept patch > to make it load p11-kit-proxy.so instead of *having* to be told which > module to load, and to make it use PKCS#11 URIs. So although OpenSSL is > painful, it's a tractable problem. I've got OpenConnect, for example, > using standard PKCS#11 URIs and Just Working when built with OpenSSL. > > OpenVPN also uses OpenSSL but without the ENGINE; it uses pkcs11-helper > instead. I've also fixed *that* to use PKCS#11 URIs for its > serialization format: https://github.com/OpenSC/pkcs11-helper/pull/4 Wow nice :) > Then there's NSS, and there are a few things we (might) need to address. > > The PKCS#11 URI thing is probably simple enough — we can provide a > helper function which iterates over the available tokens in NSS and > finds an object matching a given URI. And which generates a URI for a > given object, if that's required. But in a pure GUI application like > Firefox/Chrome/Evolution/Thunderbird this isn't relevant. They have > their own certificate choosers. And I already said I was going to gloss > over the need for GCR to do this sanely for us in the general case. You probably already know this, but p11-kit has an API to do this that could be vetted and exposed publicly: http://cgit.freedesktop.org/p11-glue/p11-kit/tree/p11-kit/iter.h And Gcr also has such an API for doing this using the GLib async style of code: https://developer.gnome.org/gck/stable/GckEnumerator.html <snip> > This works for the NSS applications which actually *use* /etc/pki/nssdb. > Which is relatively few of them. I've fixed Evolution to do so, but even > then it'll *only* do so if the NSS "Shared System Database" is enabled, > which provides an 'overlay' from $HOME/.pki/nssdb. Otherwise you end up > with a read-only database which is not acceptable for most applications. Note that /etc/pki/nssdb is also not completely safe on multi-user systems. One user can easily lock the database and prevent any other user from doing NSS crypto with that database. Correct me if I'm wrong. <snip> > - Modify NSS to automatically load p11-kit modules. > > Maybe slightly saner than hacking the apps, we could make NSS > automatically load p11-kit-proxy.so (-trust) whenever the database is > initialised. Or even better, perhaps it could use p11-kit and > p11_kit_modules_load() directly instead of p11-kit-proxy.so. Not sure this solves the actual problem (given that NSS apps do not use a consistent database location) but NSS actually can ask a PKCS#11 module if it wants to load more modules. NSS_ReturnModuleSpecData() I believe this is undocumented. But Bob has mentioned it as something that p11-kit should be doing in order to tell NSS about which other PKCS#11 modules to load. <snip> > Any thoughts on how best to sort this out would be much appreciated. We > need to do *something*, but it's not entirely clear what. Indeed Stef
signature.asc
Description: OpenPGP digital signature
_______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/p11-glue