certificate validation callbacks [was: Re: validating SAN URIs in gntls]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Mon Mar 7 20:19:56 CET 2011

On 03/07/2011 01:30 PM, peter williams wrote:
> One might want to think about enabling GNUTLS server's to easily add a
> validation callback *mechanism* for the case that SAN URI(s) (possibly
> plural) are received in client certs.

certificate validation callbacks would be a very nice thing to have,
particularly if they include information about which particular session
is triggering the verification.

That is, an application knows how it is using a given TLS connection --
it might be using it to connect to a mailserver or a web server or a
database or some other peer with a protocol that GnuTLS doesn't even
know about.

The application might have several TLS sessions running at once (e.g. an
MUA fetching IMAP messages and pulling RSS feeds via HTTPS
concurrently).  So the callback would need to allow the application to
distinguish which TLS session the certificate is for, and accept the
application's approval/rejection of the certificate for that purpose.
This is a different problem than asking an application to approve or
reject a certificate in its own right.  For example, a "valid"
certificate for an HTTPS web server might be considered invalid when
used as client-side auth for an LDAP session.  More prosaically, an
certificate that is valid for a web server at https://example.net/ might
not be acceptable for a web server at https://example.com/

The callback will probably also need to also include the entire
certificate chain, not just the end-entity certificate.

Since the application's particular use of any given TLS session can be
tightly-bound to the qualifications of a given certificate, i think this
kind of callback would be an important thing to have.

There's no reason that GnuTLS should need to know (or be told) about all
the different ways that an application might make use of TLS or decide
to validate certificates, so exposing those configuration choices to the
application is a responsible (and simplifying) approach.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110307/db75b803/attachment.pgp>

More information about the Gnutls-devel mailing list