[gnutls-dev] RFC: PKCS#11 plans

[Alon Bar-Lev]

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.

> to talk with a PKCS11 provider

Well... You have:
http://gnupg-pkcs11.sourceforge.net

Which already is the daemon side... But I hate it! (Although I wrote
it... So I can use my token to S/MIME in KMail).

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

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

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

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

> Yes, I also think that would be the Right Solution, although it
> requires slightly more work than supporting PKCS#11 directly.

True... But after you do this, I will be able to provider the provider...

Best Regads,
Alon Bar-Lev.