RE: 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:address@hidden 
Sent: Monday, March 07, 2011 8:17 PM
To: peter williams
Cc: address@hidden
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