Fixing NSS and p11-kit in Fedora (and beyond)

Stef Walter stefw at
Fri Dec 12 00:22:31 PST 2014

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 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:

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:

And Gcr also has such an API for doing this using the GLib async style
of code:

> 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.

>  - Modify NSS to automatically load p11-kit modules.
> Maybe slightly saner than hacking the apps, we could make NSS
> automatically load (-trust) whenever the database is
> initialised. Or even better, perhaps it could use p11-kit and
> p11_kit_modules_load() directly instead of

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.


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.

> 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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the p11-glue mailing list