Re: [gnutls-dev] GnuTLS PKCS#11 Engine

[Alon Bar-Lev]

On 5/14/07, Simon Josefsson <address@hidden> wrote:
> It doesn't seem to work.  Here is what happens.  Any ideas?

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

Why not just maintain it as sepearate component?
What is the benafit in maintaining one large library?

Best Regards,
Alon Bar-Lev.