PKCS#11 support and proxy providers

[Simon Josefsson]

Craig Ringer <craig at postnewspapers.com.au> writes:

> Hi
>
> I've been doing some research into PKCS#11 support in GnuTLS and into
> PKCS#11 proxy providers. There was some discussion on both some time ago
> on the GnuTLS devel list, but I've been unable to find much more recent
> than 2007. Current GnuTLS sources do not appear to support loading and
> using a PKCS#11 provider module.
>
> Is there PKCS#11 support in GnuTLS that I'm missing? Or did the PKCS#11
> work done in 2007 not come to anything?
>
> The reason I'm interested is that some apps I use, including Evolution
> Data Server's Camel mail client module, use GnuTLS for their crypto
> needs. This not only prevents them from talking to smart cards and other
> hardware keys, but it prevents them from using centralized PKCS#11-based
> certificate stores like the GNOME Keyring Daemon. Users must instead
> configure each GnuTLS-using app to load their certificate from a PKCS#12
> file.
>
> I'm looking into ways to get a centralized key store, including PKCS#11
> proxying for smart cards and the like, into wider use on Linux desktops.
> As part of that I'd be really interested in any progress on PKCS#11
> support in GnuTLS. For my purposes I'd only need single-provider
> support, since GnuTLS would talk to the proxy provider over a UNIX
> socket and that'd manage the keystore as well as any smart cards and the
> like.
>
> I've been unable to find any suitable existing proxy provider
> implementations, so I was thinking of writing a thin PKCS#11 provider
> module and a daemon that uses libnss to handle the keystore, card
> proxying, and the like. Is anyone here aware of a suitable existing
> PKCS#11 proxy daemon and provider that might do the job?

Hi.

You should be able to implement what you need using the sign callback in
GnuTLS:

http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#index-gnutls_005fsign_005fcallback_005fset-268

This lets you send back the sign request to where the private keys is,
which can include a PKCS#11 provider.

However, I would agree with you that something more would be useful.

We have been thinking about a 'gnutlsd' daemon that can sit in the
background and hold private keys, or tunnel them to PKCS#11 providers.
See some ideas on:

http://redmine.josefsson.org/projects/gnutls/wiki/GnuTLSExternalValidation

Seahorse could implement the same protocol, and would then be able to
hold private keys and serve GnuTLS clients.

I think it makes more sense for these daemons to do the PKCS#11
integration than including that code in the TLS client library.  It
makes things simpler and easier to debug.

I wish I had more time to work on this, it would be quite interesting.
If you want to help, now is a good time to do it, since we have just
opened the 2.9.x branch.

/Simon