PKCS#11 and GnuPG

PKCS#11 allows the use of proprietary tokens. In fact that is the sole reason why this API has been established a long time ago. It is designed as glue code between between different proprietary applications. Instead of supporting PKCS#11 tokens, the FS community should demand the release of the token's specs to the public. For almost all tokens this is not the case; for some you can get the specs with a bit of trouble but most vendors try to lock users in to their products. This is the reason why GnuPG does not support PKCS#11 tokens but requires that the host side of the token is being implemented in GnuPG.

PKCS#11 is not a well defined standard. Granted, since a few years it has changed to the better but nevertheless it is, as stated in the article, a baroque thing and very low-level. Part of the reason that it is nowdays a bit better might be that one large OS vendor has turned away from PCKS#11 as primary method to access tokens.

NSS is very closely controlled by one vendor and worse it is a library which has been hacked together by the words of some standards without much thinking on whether it could be done better than stated in the standards. I was once involved in a project were we tried to renew Mozilla's S/MIME infrastructure to a modern profile so that it would have been useful for European administrations. The Mozilla Foundation refused our offer to do that and sticked for many more years to their barely unusable S/MIME stuff. Without the option to get our code into Mozilla we implemented it from scratch for GnuPG/Kmail/Mutt.

Gnome-keyring has been mentioned: It is less known that it hijacks the GnuPG interprocess communication (between gpgsm/gpg and gpg-agent) which has been the cause for many false bug reports and trouble. This badly reflects on the repudiation of GnuPG-2 because users notice only that gpg2/gpgsm do not work properly but can't see the real cause for it.

Now for some shameless self-advertising: For many years GnuPG provides nearly all the features the desktop crypto consolidation demands: X.509 key store and generation, OpenPGP stuff of course, ssh-agent with and without smartcards, re-use of keys for different protocols (in particular important for smartcards), clean separation of private and public keys (with 2.1-beta also for OpenPGP), a well tested and easily available smartcard with an open specification, passphrase cache (persistance is missing but easy to add), even an PKCS#11 interface to use GnuPG as a token, etc. This code is available for all kinds of platforms: Unix, Windows, WindowsCE, VMS. We have no marketing department, though.