[gnutls-dev] GnuTLS 1.7.8.p11.0

Alon Bar-Lev alon.barlev at gmail.com
Fri May 4 17:21:46 CEST 2007

On 5/4/07, Simon Josefsson <simon at josefsson.org> wrote:
> I don't understand this.  It seems to me that anyone who can make the
> PKCS#11 provider give GnuTLS an insecure CA cert can also provide GnuTLS
> directly with a insecure CA cert.
> Could you describe how the attack would work?

You insert your token in my computer, I put my own self-signed
certificate as trusted in your token, then you come back to your token
and work with my fake TLS server side certificate.

> I don't know how to solve this yet.  If you want to work on it, that
> could help, although right now I just want to get client-PKI via the
> OpenPGP smart card to work, and that's my main priority.

Well... I see we are not communicating well... So I say this last time
and I say this clearly.

I offer you the quickest way to achieve your goal.
Split the work into two parts, one part is the GnuTLS infrastructure
missing external private key implementation, the other is PKCS#11
You implement the GnuTLS stuff, I implement the PKCS#11 engine, this
way everyone is doing what he is best of.

Now, you will have "A" working PKCS#11 implementation. Why "A", since
you may decide you can do this better, and implement "THE" PKCS#11
engine on your own later, it will take you a while to mess with
PKCS#11, learn how people are using it, where and when, address
different provider implementations and incompatibilities etc...

But you will have "A" working provider so you can learn and copy
whatever you like, it will be GPLed, so no licensing problem here.

This means that you STOP writing PKCS#11 low level code, and
consentrate on the missing functionality of GnuTLS, document the
engine interface and then test out if my implementation meets your

Best Regards,
Alon Bar-Lev.

More information about the Gnutls-devel mailing list