On 15 September 2015 at 20:12, Karthikeyan Bhargavan <karthik.bharga...@gmail.com> wrote: > I assume the client hello extension still has the certificate digest, yes? > This means that the analysis probably relied on agreement of the certificate > hash from the client hello.
This was only in the 1.3 context, and the certificate digest was completely removed from the handshake... It was pointed out to me separately that this doesn't work for static RSA because you need to include the public key in the transcript there to avoid having an attacker impose a PMS (one of the components of triple-handshake). That means that we need a strong hash for that case. However, if this is only used for PFS modes, then the analysis suggests that we are OK to remove or truncate, assuming session-hash. > For example, is it possible for a website to use the same public key on two > certificates for two different purposes? Is it possible for an attacker to > obtain a certificate from a CA for a public key even though it does not know > the corresponding private key? Does any of the existing analyses of TLS permit these changes? If the same key is used for two different purposes, then the risk of reaching a state where the purposes are confused seems to be too easy. Similarly, if I can obtain a certificate for a key without demonstrating proof of possession, then we're in a bad state. I would hope that the ACME protocol does not permit that, certainly this is a fundamental part of the certificate signing request. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
