[gnutls-dev] RFC: PKCS#11 plans
alon.barlev at gmail.com
Mon Apr 23 15:39:49 CEST 2007
On 4/23/07, Simon Josefsson <simon at josefsson.org> wrote:
> > The proxy provider will be a different project and will provide the
> > same level of security you are interested in to any PKCS#11 enabled
> > applications.
> > While GnuTLS keep standard interface.
> Ah, I now understand what you mean. And yes, the
> gnutls_1_7_8_with_pkcs11 branch will support PKCS#11 directly, thus
> allowing for the approach you refer to here.
I tought that by now we can get to a conclusion that the branch should
provide a generic crypto interface... :)
> However, does any proxy providers exist? If not, then GnuTLS will
> link directly to the PKCS#11 providers, either directly or through
> dlopen(), which is something that I'd really want to avoid. (The code
> on the branch do that, just as a proof-of-concept.)
As I said I have this in my todo list... Once I will see enough open
source use PKCS#11 correctly. The problem is that people use PKCS#11
as they handled files so far...
> Serializing PKCS#11 is not simple, and I don't know if anyone has done
> this before. Further, the serialization of PKCS#11 doesn't have to be
> exactly mapped to the PKCS#11 API, it only have to support the same
> things that PKCS#11 support.
The important feature would be to expose PKCS#11 interface to the
application. The serialization protocol is irrelevant.
> > Yes it does... Your example of OpenPGP cards is incorrect.
> > This implementation work with gpgsm, loading certificate objects too.
> But not with OpenPGP cards:
I told you not to use this hacky environment...
> Since I don't have anything other than OpenPGP cards available, that's
> what is the main priority for me right now. I don't even know
> how/where to purchase one X.509 smart card for a reasonable price with
> sufficient documentation for me to be able to use it.
OK... As you wish... You will solve problems that not actually exist.
> Well, let's see, I'm close to having PKCS#11 via Scute work in GnuTLS
> with just one API.
Well... I really don't understand... I offer my experience and help...
Smartcards are not just a neat API.... All I ask is for you to provide
a generic API for crypto modules, and I will implement this engine...
This engine will use all knowedge gathered for years and will work
with many providers.
You dismiss this and go and implement a partial solution...
I really don't undestand...
> I have not yet decided though, this discussion is input to that
> decision. And anything that is decided now can be revised after
> review. And if you don't like the decisions, you can always fork or
> send patches.. ;-)
As I said, I am willing to WRITE the engine, one you define a generic interface.
I won't send specific patches or branch GnuTLS... I just offer my help
and experience, it is clear that you make your first steps in this
> Applications don't want to load PKCS#11 providers. They don't want to
> know what a PKCS#11 provider is. Thus, GnuTLS should offer to hide
> this stuff from applications. Some applications may want to know the
> details, but then they can use other APIs to solve what they want.
Here I also disagree... The application should use several APIs in
order to control its resources? So why don't you follow OpenSSL
foot-steps and provide RSA object which has several callbacks, the
application register this object within GnuTLS, so that GnuTLS is not
aware how the signature/decryption are performed?
> > My "mission" is to help open source projects to realize that the above
> > scenario is invalid, so they must focus on standardization. PKCS#11 is
> > the only independent standard available to access cryptographic
> > devices. Even if the standard seems a little complicated it is of our
> > users based interest to support it.
> But PKCS#11 is not a protocol...
> > It is true that loading a library into your process is dangerous, but
> > it can be solved using a proxy PKCS#11 provider that will enable
> > safe-guarding all PKCS#11 enabled applications, while being
> > transparent.
> Do such a PKCS#11 proxy exists?
As I said I will implement one, once I get people to understand
something about smartcards.
> I think an assumption here has been that GnuTLS should support
> PKCS#11, and since gpg-agent cannot solve one problem (I can't read
> certificates via it) we have to consider options.
For OpenPGP only.
Most users DO NOT use this card.
But I agree pgp-agent is bad bad bad approach.
> > You have an option to reinvent the whole wheel... Writing your own daemon.
> That may be the most flexible and simplest solution. It is not
> completely reinventing the wheel, since I do not know about any other
> solution that provides the same features.
You are going to write native PKCS#11 code, while I already
implemented, tested, integrated and maintain...
If this not reinvent the wheel, I don't know what is to reinvent the wheel.
> This is what I'm doing now on the gnutls_1_7_8_with_pkcs11 branch.
> However, if there are no PKCS#11 proxy providers, I don't think this
> will be the ultimate solution. Then we need to come up with something
> to proxy the signing requests. In that case, using PCKS#11 is no
> longer a generic good idea. It isn't compatible with Microsoft CAPI,
> for instance, something I'd want to support in the long run.
Implement generic interface and people may use it to access CAPI as well.
More information about the Gnutls-devel