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

[Daniel Kahn Gillmor]

On 03/07/2011 11:37 PM, peter williams wrote:

> but it HAS to be self-signed, and be confirmed as such during SSL server procedures.

I'm afraid i'm still not following this argument.  We're talking about
client-side authentication, and the cert in question belongs to the
client in the TLS session?

I think the entire TLS handshake (up through and including the
client-side cert) get certified by the client's secret key in the
"certificate verify" message [0].  So the client is cryptographically
demonstrating:

 (a) control over the public key, and
 (b) a certification that covers the client certificate.

I imagine two types of threat we're concerned about:

 0) a network-based attacker who wants to use their own key in place of
the client's key, and

 1) a network-based attacker who just wants to swap out the client's
certificate with a different certificate (the replacement cert contains
the client's own key).

In scenario 0, the attacker presents the server with a certificate
derived from her own key -- since she controls the key, she can
certainly make the certificate self-signed.  The validity of the
self-sig on the certificate doesn't provide us with a way to distinguish
the attacker from the client in this situation.

In scenario 1, the attacker is maybe trying to convince the server that
the client is presenting different data from the data in the client's
actual certificate.  The server could distinguish the two cases based on
whether the certificate is properly self-signed (the attacker's bogus
cert could not be self-signed because the client's secret key is
unavailable to the attacker).  But since the client doesn't see the
replacement certificate, its computed "certificate verify" message will
not verify anyway.  So again, i don't think the validity of the self-sig
on the certificate buys us anything in this situation.

Another way of looking at it: doesn't the "certificate verify" message
offer an assertion that the client is vouching for the data in their
certificate?  What additional benefits do we get from validating the
self-sig on the cert anyway?

Can you help me understand *why* either party would care that either
cert be self-signed if the session initiation has already established
that both parties saw the same certs and are in control of their
respective secret keys?

It's certainly possible that i'm misunderstanding something about how
TLS works -- feel free to point it out to me, even if the flaw in my
reasoning is glaringly obvious.  I can take it :)

Trying to understand,

	--dkg

[0] https://tools.ietf.org/html/rfc2246#section-7.4.8 (there are
comparable sections in TLS 1.1 and 1.2)

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