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

[Daniel Kahn Gillmor]

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

-------------- 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/d4cc4783/attachment.pgp>