Re: [TLS] Next steps for Client Certificate URL

[<Pasi.Eronen@xxxxxxxxx>]

This issue was originally raised by Ray Perlner from NIST:
http://www.ietf.org/mail-archive/web/tls/current/msg00881.html

Basically, without the hash, the client and the server could have
different idea on what client identity was authenticated, if there
exists several certificates containing the same public key. Note 
that all those certificates can be totally valid, and the situation 
doesn't assume key compromise or CA misbehavior.

Best regards,
Pasi

> -----Original Message-----
> From: ext Nelson B Bolyard [mailto:nelson@xxxxxxxxxxx] 
> Sent: 28 March, 2008 22:28
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: tls@xxxxxxxx
> Subject: Re: [TLS] Next steps for Client Certificate URL
> 
> Pasi.Eronen@xxxxxxxxx wrote, On 2008-03-28 07:13:
> 
> > Given this, would everyone be OK with updating the existing
> > client_certificate_url extension so that including the hash is
> > mandatory (client MUST send, server MUST NOT accept without hash)?
> > This behavior would be independent of the negotiated TLS version.
> 
> I'm trying to understand the attack against which this hash is going
> to protect, that is not already adequately protected without it.
> Can someone outline that attack here?
> 
> Presumably, the attack involves substituting a different certificate
> than the one intended by the client.  To succeed the substitute cert
> must bear a public key that will verify the client's signature in the
> Certificate Verify message, and must bear a signature verifiable with
> the public key from some CA trusted by the server for issuing client
> auth certs.  That would seem to necessitate CA key compromise, or
> client key compromise, or CA collusion with the attacker.  The hash
> would not protect against client key compromise.
> 
> Is this hash intended to detect CA key compromise and/or collusion?
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls