PKCS#11 in GnuPG (yes, again!)
Werner Koch
wk at gnupg.org
Mon Jul 18 18:37:32 CEST 2011
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.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel
mailing list