RE: 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:address@hidden 
Sent: Monday, March 07, 2011 11:20 AM
To: peter williams
Cc: address@hidden
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