[gnutls-dev] sign callback for certificate authentication

[Simon Josefsson]

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 5/11/07, Simon Josefsson <simon at josefsson.org> wrote:
>> Hi.  I'm making Scute an optional dependency on the branch now.
>
> OK.
> Just reference me to the place I can sync your modifications.

See:

http://josefsson.org/gnutls/releases/pkcs11/

The announcement (and likely, this message too) didn't make it to the
gnutls-dev list because I recently changed mail server to one that
doesn't have any reverse-dns.  Sigh...

There is a branch in CVS too:

http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/?root=GNU+TLS+Library&only_with_tag=gnutls_1_7_8_with_pkcs11

I'm going to set up a Git server for it today.

>> > BTW2: You should add cleanup callback, so that resources can be
>> > released on session end.
>> > http://lists.gnupg.org/pipermail/gnutls-dev/2007-May/001557.html
>>
>> This seem to be bloat to me, since it offers no additional
>> functionality.  Applications can cleanup resources when they deinit the
>> particular GnuTLS session that uses the sign callback, can they not?
>
> We would like to add a layer for application to use...
> So except get certificate/credentials/whatever, the layer should be
> able to free its resources.
> So if we put this at gnutls_certificate_credentials_t we should have
> gnutls_certificate_free_credentials() call callback cleanup so that
> resources may be released.

The application calls gnutls_certificate_free_credential, so it should
be able to call another function at the same place to clean up the
resources that itself allocated.  This seems a better API separation to
me: the application is responsible for deallocating what it allocates,
and GnuTLS deallocate what it has allocated.

> So that user code will look like:
> gnutls_pkcs11_set_certificate (gnutls_certificate_credentials_t *cred, <id>)
>
> And that's it!

That API could be the same with my approach.

However, I don't think strongly about this, and when I get around to
changing the API to be certificate_credential-specific rather than
session-specific, we'll see how it works out.

/Simon