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.
(For now I'm going to gloss over the UI implications, partly discussed in https://bugzilla.gnome.org/show_bug.cgi?id=679860 and https://bugzilla.gnome.org/show_bug.cgi?id=719982 at least for NetworkManager, and concentrate on the back end). With GnuTLS-using applications we're fairly much already there. It mostly just does the right thing and accepts PKCS#11 URIs in place of filenames. Yay Nikos! :) 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 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. So the main interesting question is how we get NSS to automatically load the PKCS#11 modules that are configured in p11-kit. Note that NSS applications *sometimes* want the system trust database to be present (and will load libnssckbi.so if so), and sometimes don't. NSS applications should theoretically use one of the two databases in /etc/pki/nssdb, but often (Firefox, Thunderbird, Chrome, etc.) don't. In Fedora we have already hijacked NSS's own libnssckbi.so with the trust roots, and symlinked it to p11-kit-trust.so to give the trust database configured by the sysadmin. So here are some of the options for making NSS apps behave nicely: - Add p11-kit-proxy.so to {sql:,}/etc/pki/nssdb modules list 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. It also has the problem that it's loading the default trust, even into applications which didn't *want* that. So if we do this (or most of the other options below, in fact), we'd probably want to load p11-kit-proxy.so in a mode which *doesn't* load the System Trust and Default Trust slots. - Symlink libnssckbi.so to p11-kit-proxy.so instead of p11-kit-trust.so This actually worked fairly nicely in testing. It *does* fix Firefox and Chrome, etc., and indeed *most* user-facing applications, since most of them *do* want the system trust and do load libnssckbi.so. But there are some things, like pam_pkcs11, which *don't* load the system trust but which *should* have the p11-kit PKCS#11 modules loaded. Perhaps we could explicitly configure them to load p11-kit-proxy.so (-trust) for themselves. - Explicitly add SECMOD_LoadUserModule(p11-kit-proxy.so) to apps We *could* do a bombing run on the relevant applications and make them all load p11-kit-proxy.so (-trust) explicitly for themselves. Let's not. - 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. I don't know how much resistance there would be to doing this kind of thing *in* NSS, or what the disadvantages would be. But at first cut, this seems like it might be the best solution. And if it's done *in* NSS then we can make a sane decision about which of the NSS_Init* functions should do this, and which (perhaps NSS_NoDB_Init() for example) should not. I'll largely defer to Bob for NSS expertise and strategic direction though. 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. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/p11-glue
