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

[peter williams]

Consider how it was done in windows NT 4 (a wee while ago).

A [client] certificate is presented for evaluation.

A factory for trust models fires, looking at the cert for help for which trust model dll to load. In windows, this is called the wintrust framework. One modern way to know which trust model dll the factory should load is to consider the ApplicationPolicies extension in the cert. There are lots of legacy kludge ways, that are just too embarrassing to discuss.

The trust model is always responsible for 2 processes: discovery of chains, validation of chains. Discovery may be nothing more than consult the chain of authority certs presented alongside the client EE cert, originating from the record layer. Validation may consume services, including OCSP, CRLs, or webid protocol... for one or more of those authority + EE certs. It's also responsible for enforcing X.509 chaining semantics (if the chain requires them).

Presumbaly, given a self-signed client cert, GNUTLS _today_ already validates the self-signed signature? (I ask, as I noted that the close protocol was only recently confirmed to be implemented, correctly.)

Obviously, there is then a discovery factory and a validation factory, which knows to load the discovery dll and validation dll. Modern ways to choose them include consulting cert fields, such as AIA (which points at the OCSP server) or the CRLDP (which points at CRL documents). Metadata from those resources can drive the factory to make a provider.

What GNUTLS needs at this point is, probably, just the framework itself. The first providers need be nothing more than discovery = use cert chain given by SSL, and validation = check signatures in a chain of certs. The second provider should be able to punt, up to the likes of the perl libraries mentioned.

What would be nice, for use in the webid world (which is just self-signed client cert with an URI name within) is to be able to easily control which CA's are sought by the GNUTLS server, during client authn. Ideally, it would be trivial to select a null list of CAs, per full handshake.


-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: Monday, March 07, 2011 11:20 AM
To: peter williams
Cc: gnutls-devel at gnu.org
Subject: certificate validation callbacks [was: Re: validating SAN URIs in gntls]

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.

	--dkg