Hello,
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 specification exists. 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? Best Regards, Alon Bar-Lev. _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
