[gnutls-dev] GnuTLS 1.7.8.p11.0

[Alon Bar-Lev]

On 5/4/07, Simon Josefsson <simon at josefsson.org> wrote:
> "Alon Bar-Lev" <alon.barlev at gmail.com> writes:
>
> > Hello,
> >
> > I was about to get this implementation and suggest an alternative,
> > only to discover that you are not doing any private key operations.
>
> Hi!  Right.  I wanted to get things out as soon as possible, and right
> now getting the CA trust stuff is all that I can show to be working.

As I said before... Most tokens do not hold certificate chain within
them, it is just a waste of memory when you have 16K, 32K or 64K.
Also I already warned you that this is highly insecure... Since anyone
can store whatever certificates as public objects, thus modifying the
trust.

> It will be something like that.  It may start out as somewhat simpler,
> to better fit with how the GnuTLS API works today: right now
> applications can be invoked with a callback to retrieve the appropriate
> cert+key.  They need some function to get the user certificates and key
> handles from the PKCS#11 layer.  I'm thinking this interface will be:
>
>   int gnutls_pkcs11_get_user_certificates (gnutls_x509_crt_t ** cert_list,
>                                                 unsigned int *ncerts);

But you will be able to to implement the above using the API I suggested.
As I see it you can have the PKCS#11 stuff maintained separately, as
an optional components, something like gnutls-pkcs11 that will use the
engine API in order to add the above function.

You also don't handle much of the issues related of token management...
1. Tokens are ****SLOW***** enumerating the certificates takes
****LONG**** time.
2. Tokens are dynamic, you can remove them and insert them, so
enumerating all available tokens every time is not wise.
3. You may have more than one token available at the same time, you
may need to handle this state.
4. As I understand from your API documentation, gnutls_x509_crt_t  has
nothing to do with the private key, which is the one that really
important when you handle hardware tokens.

> When an application, in the certificate callback, indicate that the
> private key is 'NULL', they will have to provider another callback to
> perform the sign operation, otherwise the user certificate will be
> ignored.  That function should likely receive the user certificate or
> similar.  GnuTLS should have an API available to perform the sign
> operation using PKCS#11, but it could also let the application perform
> the sign operation in any way it chose.  This way, the interface will
> not be specific to PKCS#11, but it will be easy to make PKCS#11 work.

I don't understand the above... How do you set the callback in the
certificate object?
How do you set user defined data for the callback to be used?
I did not see this in the GnuTLS documentation.

Anyway... I think that your implementation should not be differnet
than any other one.
If you have such a generic mechanism, use it, don't implement two
different methods.

> I started providing such an API, but then I realized that it doesn't
> work with the callback approach that GnuTLS offers.
> gnutls_certificate_set_key etc doesn't do anything if used within a
> callback.  Hence the current more flexible approach, which doesn't
> involve modifying the gnutls_certificate_* functions or structures.

OK... But as I said... It is the least important... :)

> > As I said before, if you provide such interface, I will provide a
> > *COMPLETE* and *WORKING* PKCS#11 support for GnuTLS, after a day or
> > two.
> >
> > It will also clean up your implementation, and allow many other
> > engines to be added.
> >
> > Another alternative is to wait for you to have a remotely working
> > solution, and create a patch for the above (this is what I intended to
> > do now...), but it would be much cleaner if you create the interface
> > as you know GnuTLS best, and it will save a lot of work for all.
> >
> > Please consider to cooperate, you loose nothing, as you will be able
> > to use the same interface for your implementation as-well.
>
> Of course!  I think the best is for me to produce an API that works for
> me and fits with how GnuTLS works.  I believe it will be quite close to
> what you need, even if not perfectly the same.  The API will not be
> fixed until it is merged into the normal experimental branch.  There
> will be several iterations of release on the PKCS#11 branch until that
> happens, and your input is valuable here.  I think it would be useful to
> demonstrate interoperability with at least some other PKCS#11 provider
> than Scute until the API is ready.

All I suggest is an API that fits GnuTLS!
But I suggest that the low-level PKCS#11 will reuse current effort and
knowledge.
Also I think it would be best if the PKCS#11 support will be provided
as a separate library, that uses GnuTLS API.

The functions:
gnutls_pkcs11_set_config() /* Set providers and parameters */
gnutls_pkcs11_enum_certificates() /* Enumerate available certificates */
gnutls_pkcs11_serialize_certificate() /* Serialize specific
certificate so we don't need enum again */
gnutls_pkcs11_deserialize_certificate() /* Deserialize certificate,
good for configuration files */

Can be implemented using PKCS#11 code and GnuTLS with engine API as a
separate library.

Also, if you would like to be more generic you should provide an
engines much more powerful and allow gnutls to serialize/deserialize
any certificate includeing the engine specific information, and allow
callbacks for an engine to enumerate certificates.

Best Regards,
Alon Bar-Lev.