[gnutls-dev] RFC: PKCS#11 plans
simon at josefsson.org
Sun Apr 22 16:11:05 CEST 2007
"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:
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:
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
>> > 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
> 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.
>> 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
* 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.
More information about the Gnutls-devel