On 11 August 2015 at 12:05, Ilari Liusvaara <ilari.liusva...@elisanet.fi> wrote: >> I don't see how that would work. A client that understands the cert >> to be ECDSA won't pair the key with the server's ECDH share, they will >> sign the session transcript with it. > > a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is > no ECDSA-specific keytype in X.509.
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. I checked NSS and there doesn't seem to be any way that it could be coerced into using the (EC)DH pair from a client certificate in a key exchange. Even though it supports some fixed (EC)DH suites. 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 :) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
