On 11 August 2015 at 16:38, Clemens Hlauschek <clemens.hlausc...@rise-world.com> wrote: >> Maybe I should have been clearer. The certificate might not include a >> (strong) signal that allows the client to distinguish between ECDSA >> and fixed ECDH, but the client might be configured with that >> knowledge. > > There is no difference between an ECDH and an ECDSA, apart from > (possibly) the KeyUsage Extension.
I'l try again. Even if the certificate does not include that signal, the software that accepts that signal might make assumptions or have configuration that cause it to only be used in one way or another. See NSS. >> NSS (incorrectly) adopts the posture that _ECDH_ suites are >> half-static: the server share is in the certificate, but the client >> side is fully ephemeral. This is clearly in violation of RFC 5246, >> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >> that right now :) > > Please elaborate. I do not see how this half-static behaviour > constitutes any violations of the mentioned RFCs. Both the above cited sections say very clearly that for fixed (EC)DH cipher suites the client where the client has a fixed (EC)DH certificate, the client MUST send an empty ClientKeyExchange. Of course, you might say that this is simply a consequence of not supporting fixed (EC)DH for client authentication, and then it's not technically in violation. The value of the ClientCertificateType from the CertificateRequest is likely important here, but that field is systematically ignored in practice (NSS ignores it). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
