[gnutls-dev] RFC: PKCS#11 plans

[Alon Bar-Lev]

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:
>
> http://lists.gnupg.org/pipermail/gnupg-users/2007-April/030898.html

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
world...

> 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...

Wrong again!
But nevermind....

> > 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.

Best Regards,
Alon Bar-Lev.