[gnutls-dev] GnuTLS PKCS#11 Engine
alon.barlev at gmail.com
Mon May 14 12:44:43 CEST 2007
On 5/14/07, Simon Josefsson <simon at josefsson.org> wrote:
> It doesn't seem to work. Here is what happens. Any ideas?
It seems that it forks.
After fork, I must call C_Initialize/C_Finalize again to cleanup state
in child. This is part of PKCS#11 spec.
Nobody thought about a provider that doing fork()... :)
So I guess scote should have somekind of recursion protection on
C_Initialize/C_Finalize and also have reference counter so that
multiple call of C_Initialize will be allowed.
> > Some questions:
> > 1. Do you have any comments regarding the API?
> > 2. Do you want me to add the gnutls interface to pkcs11-helper (as in
> > OpenSSL case) or leave it as a separate module?
> > 3. Do you think there is advantage of creating subset API of
> > pkcs11-helper available (current state), or have the developer access
> > pkcs11-helper directly and provide some utilities for GnuTLS
> > environment (as in OpenSSL case).
> I haven't really made up my mind about how things should work here.
> One concern I have is any OpenSSL dependency.
Can you please explain...?
There is none.
> Another concern is that I would like GnuTLS to include some native
> PKCS#11 interface, to support the OpenPGP card, GNOME Seahorse, and
> possibly NSS's provider directly. I think it doesn't make sense for
> GnuTLS to handle pin's etc. I think GnuTLS should assume the PKCS#11
> provider takes care of PIN entry internally. (Although I don't know how
> the NSS provider works.) I don't yet know how this is best implemented.
> Including a copy of pkcs11-helper and your gnutls-pkcs11 library
> (assuming the copyright and license situation is suitable) is a
Why not just maintain it as sepearate component?
What is the benafit in maintaining one large library?
More information about the Gnutls-devel