Re: [TLS] Next steps for Client Certificate URL

[Nelson B Bolyard <nelson at bolyard.com>]

Pasi.Eronen at nokia.com 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 at ietf.org
https://www.ietf.org/mailman/listinfo/tls