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: Simon Josefsson
Subject: Re: [gnutls-dev] RFC: PKCS#11 plans
Date: Wed, 25 Apr 2007 11:38:26 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.98 (gnu/linux)

Nate Nielsen <address@hidden> writes:

> Simon Josefsson wrote:
>> Serializing PKCS#11 is not simple, and I don't know if anyone has done
>> this before.  Further, the serialization of PKCS#11 doesn't have to be
>> exactly mapped to the PKCS#11 API, it only have to support the same
>> things that PKCS#11 support.
>
> Yes, it's certainly not simple.
>
> gnome-keyring-cryptoki is serializing same of the PKCS#11 calls for
> communication with its daemon. It's similar to  how a smart card driver
> might send requests to its hardware component.
>
> I would recommend that any such serialization remain an internal API
> rather than trying to spec it out. As Alon is saying, implement PKCS#11
> as the 'spec' or supported API, and then a certain PKCS#11 driver could
> choose to serialize requests to a daemon (much as a smart card driver
> would internally serialize or process requests).

Right, and that's what I'm doing in my initial work.

However, I'm not yet convinced that GnuTLS should only support PKCS#11
directly, and no other crypto hardware abstraction layer such as CAPI or
GnuPG 2.x gpg-agent, possibly through a gnutls-daemon.  Still, adding
support for more abstractions can be done later on.  I guess that since
nobody else is working on this now, PKCS#11 will be all that I will
implement unless I run into serious problems with that choice.  The
choice can be revisited in the future.

For example, to support TLS OpenPGP with keys on smart cards, I don't
think I can use PKCS#11 via Scute.  It is X.509 only.  Or?

With the current approach of using PKCS#11 directly, there is the
problem of how to load the PKCS#11 module.  Right now, it is linked at
build-time.  Presumably, it would be nice to have it linked at run-time
via dlopen(), but that creates more problems for applications.  I think
they are already unhappy with how (relatively) complex it is to use
GnuTLS.  Having to deal with loading of PKCS#11 providers is probably
not what they are hoping for.

There is also the problem of having more code (the PKCS#11 provider) run
in the same process as GnuTLS.

Still, this approach is simpler for me to code. :)

/Simon



reply via email to

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