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

[peter williams]

In the webid protocol, folks have taken a slice out of the original openid protocol proposal: test that a user has write permissions at a server to store a [client] cert/pubkey in an XML document reference by a URI located to that server. Then, rely upon SSL's RSA signature for client authn to prove the user has control over the private key, presenting the cert with associated pubkey in support. To complete the loop (ie. validate the cert's bindings now), from cert retrieve name, which points to server resource, which shall be tested for presence of cert/pubkey under the assumption that only the user has write permissions.

What one needs is the cert is self-signed (or the client cert is trusted by the verifier due to a cert chain, alternatively, that speaks for that URI namespace). Only the user controlling the private key - tied to pubkey - can thus bind pubkey to SAN URI, using that private key.  An https MITM proxy cannot manufacture a false pubkey/URI binding for a self-asserted cert - but it HAS to be self-signed, and be confirmed as such during SSL server procedures.

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

On 03/07/2011 03:51 PM, peter williams wrote:
> 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.)

Why would it matter to validate the self-signature?  If we've established that the peer is in control of the secret key that is contained within the certificate, why do we care that the certificate is properly self-signed?  Couldn't a peer in control of its own key craft any arbitrary self-signed certificate they wanted?

Is there a risk that an attacker could somehow inject a bad cert (albeit one that contains the same key) without it becoming apparent to both parties in the negotiation?

> 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.

Why so complicated?  Why not just a callback to the application with the following arguments:

 0) some way the caller can identify the particular TLS session

 1) the certificate list offered by the peer (including the EE cert)

> 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.

GnuTLS is a library, not a server.  What do you mean here?  I'm proposing that GnuTLS itself makes it easy for the library to punt entirely on the validation process by handing the relevant information back to the application for verification.

	--dkg