Re: [TLS] Next steps for Client Certificate URL

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

At Fri, 28 Mar 2008 13:28:02 -0700,
Nelson B Bolyard wrote:
> 
> 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?

Why do you think it requires CA key compromise or collusion?

-Ekr
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls