PKCS#11 in GnuPG (yes, again!)

Werner Koch wk at
Mon Jul 18 18:37:32 CEST 2011

On Mon, 18 Jul 2011 10:55, sebastien.lorquet at 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.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list