PKCS#11 support for gpg-agent

[Alon Bar-Lev]

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.