PKCS#11 support for gpg-agent
alon.barlev at gmail.com
Sat Aug 20 16:01:04 CEST 2005
Thank you for your reply!
> > PKCS#11 is a standard specifying how to access cryptographic token.
> > Must smartcard vendors provide PKCS#11 library that allow simple
> > smartcard integration with applications.
> For legal reasons you are anyway not allowed to use almost all of them
> with GPL software. So it does not make any sense to support it.
I don't see any conflict between GPL and using PKCS#11 standard.
The disclaimer at http://www.rsasecurity.com/rsalabs/node.asp?id=2133 states
that you only need to specify the following in documentation: "RSA
Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki)"
Even if you would have written PKCS#11 implementation "RSA Laboratories
also makes no representations regarding intellectual property
coverage or ownership of the reference implementations."
RSA Laboratories does not provide precompiled libs... PKCS#11
is 3-4 include files and a PDF... (NO SOURCES)
gpg already uses S/MIME standard that is based on PKCS#7
standard... and this is based on PKCS#1, etc... etc..
Can you please tell me where the conflict is?
Since if there is none, I don't see any reason why every project
should implement its own standard of smartcard structure.
If there will be (In the future) GPLed smartcard, it should also
support PKCS#11 standard... So standard application will work...
> > Mozilla, Firefox, Thunderbird and now Java support PKCS#11 standard in
> > order to access cryptographic tokens, gives these software an edge in
> > smartcard integration.
> Writing a pkcs#11 module to connect Mozilla with GnuPG is possible and
> actually on my whish list.
I am glad... But I still think it should be supported in the core
agent... As primary
cryptographic device access.
> > But then I've seen that only proprietary smartcard tokens are supported
> > (directly) and ssh-agent... No standard way to access external
> Proprietary? We use a card specification which is entirely open and
> may be implemented without fearing legal department actions. There
> are not that many open specifications. (Don't say pkcs#15 - this is
> just a framework)
But your card specification which is entirely open is specific to gpg...
I am calling this proprietary... You cannot use keys and certificates
that were enrolled for other application. This makes the use of gpg
and smartcard very difficult to manage.
I think gpg like other cryptographic software should allow the use
of pre-existing objects on the smartcard. As far as I know PKCS#11
is the most common, implemented, cross-platform, application API
And no... I don't say PKCS#15 since it too has the same limitations
as your implementation... It forces a format for the whole smartcard,
PKCS#11 is an API allowing the vendor to manage the smartcard format
independently of the software implementation.
> > I will be glad to discuses the need of implementing PKCS#11 support for
> > gpg-agent, and helping in the implementation process...
> Pretty easy to write, the interface of gpg-agent is documented.
> gpgsm and gpg are expample on how to use it. gpg-connect-agent may
> even be used to script to this interface.
Yes, I figured this out...
But... I don't think that maintaining a separate branch for
it is a good idea...
Most of the code will be the same as gpg-agent... So it will
be very difficult to synchronize the two.
Had gpg-agent been extended so that modules
can be plugged into it, it would have been a good idea.
Had such extension been implemented... I suggest it would
have been implemented using PKCS#11 :-) So that you can
use software token to store the keys, PKCS#11-ssh bridge,
Smartcard access, etc...
Can you please reconsider the PKCS#11 support, without
a new agent branch?
More information about the Gnupg-users