Fwd: Re: PKCS#11 in GnuPG (yes, again!)
cryptostick at privacyfoundation.de
Mon Jul 18 17:08:23 PDT 2011
Right now are the pros and cons of a consistent PKCS11 interface
discussed at the GnuPG developer mailinglist. It might be interesting to
get P11-glue's opinion on this.
See email below and the archive:
-------- Original-Nachricht --------
Betreff: Re: PKCS#11 in GnuPG (yes, again!)
Datum: Mon, 18 Jul 2011 18:37:32 +0200
Von: Werner Koch <wk at gnupg.org>
An: Sébastien Lorquet <sebastien.lorquet at gmail.com>
CC: gnupg-devel at gnupg.org
On Mon, 18 Jul 2011 10:55, sebastien.lorquet at gmail.com said:
>> The reason why GnuPG does not support smartcards which are only
>> accessible due to proprietary pkcs#11 middleware should be well known:
>> The GPL does not allow for this and even more relevant: We don't want to
>> support proprietary applications. Ask the vendors of those smartcards
>> to release the specs and write a new module for scdaemon; if required.
> nice piece of software, but what about the reverse, eg using other cards
> with gnupg?
That is what my above response is all about about. "proprietary pkcs#11
middleware" is what most vendors call a "pkcs#11 driver". The term
driver is usually only used to implement a certain hardware access
software. "pkcs#11 driver" often implement much more and sometimes even
parts of stuff should be done in the smartcard.
> What about OpenSC? Was this already discussed in the past? They provide a
Actually GnuPG once used OpenSC to access PKCS#15 structured cards and I
wrote the TCOS support for OpenSC. We dropped that because OpenSC is
more about creating PKCS#15 structures than to access those structures.
PKCS#15 was developed to make access to cards easier. Indeed with about
3000 SLoC we do this now directly in GnuPG (scd/app-p15.c). The problem
is only that there are not many PKCS#15 compliant cards and if they are
you need to add a few hacks nevertheless.
> pkcs11 lib that may be usable. Or is the problem in the PKCS11 API itself?
A pretty old fashioned and only partyly specified API. For Scute we
even had to write a free replacement for the PKCS#11 header files
because at that time no free header files were available.
More information about the p11-glue