PKCS#11 support and proxy providers

Simon Josefsson simon at
Thu Jun 11 12:20:04 CEST 2009

Craig Ringer <craig at> 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?


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

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:

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.


More information about the Gnutls-devel mailing list