[gnutls-dev] RFC: PKCS#11 plans

[Alon Bar-Lev]

On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
> GnuTLS can't talk PKCS#11 to the gnutls-daemon, can it?  I want GnuTLS
> and gnutls-daemon to be separate processes.  So GnuTLS will have to
> use some protocol to talk with gnutls-daemon, and the protocol could
> be something like:

Why reinvent the wheel?
PKCS#11 is an API... A generic interface to access crypto devices.
Your daemon can expose such an interface, and route all PKCS#11
commands into providers loaded.

If you implement:

Application -[API]-> GnuTLS -[PKCS#11]-> Provider

Then you will be able to use a proxy provider without extra development.

Application -[API]-> GnuTLS -[PKCS#11]-> Proxy Provider -[Socket]->
Daemon -[PKCS#11]-> Provider

The proxy provider will be a different project and will provide the
same level of security you are interested in to any PKCS#11 enabled
applications.
While GnuTLS keep standard interface.

> etc.  That is quite similar to the GnuPG 2.x protocols, I was just
> using them as an anology for how the protocol would work.

Why not serialize PKCS#11 request and simply forward them to the daemon?
Why reinvent the wheel and have a different spec?

> >> to talk with a PKCS11 provider
> >
> > Well... You have:
> > http://gnupg-pkcs11.sourceforge.net
>
> That seem to use the scdaemon protocol, but that protocol isn't
> sufficient for what GnuTLS needs -- for example, I can't read
> certificates from the smartcard via that protocol for OpenPGP cards.
> GnuTLS needs the certificates.

Yes it does... Your example of OpenPGP cards is incorrect.
This implementation work with gpgsm, loading certificate objects too.

> > If you wish to do this properly you should consider how application
> > will use your API....
>
> I proposed APIs that the GnuTLS application would use in my initial
> post.  Do you think the APIs need to be more advanced?  What more is
> needed?

Yes... A library API should be generic...

Have a look at my high-level certificate API:
http://www.opensc-project.org/files/pkcs11-helper/doc/api/group__pkcs11h__certificate.html

These are the atoms required for certificate management.

Also please have a look at the core API:
http://www.opensc-project.org/files/pkcs11-helper/doc/api/group__pkcs11h__core.html

Required to manage the providers.

I don't think GnuTLS can provide good service with much simpler API.

> > There is a lot of logic to find the right objects, to cache sessions
> > so user will not be prompt every time for passphrase, track the same
> > token if it moves from one slot to another, support serialization,
> > multiple providers at the same times and much more.
>
> Ok.  gnutls-daemon could then support, say:
>
> * Any PKCS#11 token via libp11
>
> * Simple PKCS#11 tokens directly (it takes < 50 lines of code to sign
>   something with scute, and I have this code working now).
>
> * GNOME Seahorse crypto provider (although possibly this will happen
>   via PKCS#11).
>
> * gpg-agent for OpenPGP keys + OpenPGP signing.
>
> * Microsoft CAPI
>
> * Other crypto providers...
>
> If the protocol to gnutls-daemon is well-specified, anyone can write a
> replacement for their own neat stuff, although I hope that the
> 'default' gnutls-daemon will be sufficient for most users.

OK... I got your view.

I understand we going to loose another open source project accessing
smartcards correctly.

In the end we will have a different daemon for each open source project...

We have one for OpenSSH, a differnet one for GnuPG, for Gnome... Now
we have something new! We have a daemon for an API.... A daemon for
GnuTLS...
The poor user will have to run about 20 daemons for interactive
system, all loading the same PKCS#11 provider which could have been
directly used by applications.

My "mission" is to help open source projects to realize that the above
scenario is invalid, so they must focus on standardization. PKCS#11 is
the only independent standard available to access cryptographic
devices. Even if the standard seems a little complicated it is of our
users based interest to support it.

It is true that loading a library into your process is dangerous, but
it can be solved using a proxy PKCS#11 provider that will enable
safe-guarding all PKCS#11 enabled applications, while being
transparent.

It is true that without a daemon, multiple instances or applications
cannot share the same authenticated sessions, but the same PKCS#11
proxy will be able to provide a solution for this issue as well, while
being transparent.

So you have a simple option to use libassuan and work with gpg-agent
not developing any PKCS#11 code, while users may use my
gnupg-pkcs11-scd implementation to access PKCS#11 tokens (But I think
many users will tell you that the application->gpg-agent->scdaemon
implementation is much too complex for them to use).

You have an option to reinvent the whole wheel... Writing your own daemon.

Or you can design an in-process interface and allow to separate GnuTLS
from the decision of where and how crypto is implemented. Keeping
GnuTLS at the API domain.

Best Regards,
Alon Bar-Lev.