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

[Stef Walter]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20141212/5b6c12a0/attachment.sig>