gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] RFC: PKCS#11 plans


From: Alon Bar-Lev
Subject: Re: [gnutls-dev] RFC: PKCS#11 plans
Date: Sun, 22 Apr 2007 16:13:42 +0300

On 4/22/07, Simon Josefsson <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]