[gnutls-dev] RFC: PKCS#11 plans

[Simon Josefsson]

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
>> > 2. If you wish to use a daemon, the daemon interface can be PKCS#11...
>> > so actually this is a separate project... To write a PKCS#11 provider
>> > that interacts using sockets with a daemon which loads several
>> > providers into its namespace. I have this in my TODO list... It can
>> > also provide single sign on for the user.
>>
>> PKCS#11 isn't a protocol-like API, so we'd have to serialize the
>> requests.  But that shouldn't be too difficult.  I'm thinking a
>> protocol similar to the GnuPG 2.x daemons, a'la:
>
> GnuPG is bad bad bad bad example.
> PKCS#11 is a standard, supporting this will enable you to reduce
> development maintenance.
> If you support PKCS#11 directly and I develop PKCS#11 provider that
> route all requests to a daemon which in turn forward the request to
> "real" PKCS#11 module you get the security you like, without adding
> daemon component to your development cycle.
> If I, as a user, don't wish to use a daemon, I will load the "real"
> daemon and not the proxy one.

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:

READCERTS
...
READKEYS
...
SIGN

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.

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

>> GnuTLS's needs are not complex, so the protocol could be simple.  The
>> gnutls-daemon would then be responsible for loading the appropriate
>> PKCS#11 plugins, or other crypto providers.  All complexity would be
>> in gnutls-daemon.
>
> 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?

>> > 3. You should handle dynamic events such as token remove, token
>> > insert, PIN request.
>>
>> I don't see what would be gained by having GnuTLS be aware of those
>> concepts, so I'd prefer to keep that in the gnutls-daemon, or
>> possibly, inside each PKCS#11 provider.
>
> Since the application would like to display a dialog of its own...
> Prompt some other information to the user, or just ignore the
> prompt...
> GnuTLS is a library not an application, you cannot take decisions from
> the developer.

One of my ideas is that all such interaction happens in gnutls-daemon.
GnuTLS shouldn't know private keys, PINs etc.

>> > 4. What happens if signature/decrypt is requested and the token is unavailable?
>>
>> 1) The TLS handshake fails.
>> -or-
>> 2) GnuTLS hangs waiting for gnutls-daemon to return, and gnutls-daemon
>>    could ask the user to insert its smartcard etc.  The operation can
>>    be canceled, and can timeout.
>
> Well... I think the developer should decide, and prompt the user to
> insert his token so that the session will not disconnect... But this
> should be the application decision.

The problem is that it's not very generic... The PKCS#11 plugin that
gnutls-daemon loads can also ask the user to insert the token etc.
That seem to be a better design to me, but I may be missing something.

>> I'm looking at it now, although I'm not sure I understand whether or
>> how I could use it.  It seems as if applications might use
>> pkcs11helper, but it isn't applicable to GnuTLS or gnutls-daemon.
>
> 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.

/Simon