On Fri, Jan 15, 2016 at 10:13 PM Brian Smith <br...@briansmith.org> wrote:
> David Benjamin <david...@chromium.org> wrote: > >> (Whether such certificates exist on the web is probably answerable via CT >> logs, but I haven't checked.) >> > > Me neither, and I think that's the key thing that would need to be checked > to see if my suggestion is viable. > Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more often than not. https://crt.sh/?CN=%25&iCAID=1516 But it's not actually all that many hostnames (all of which presumably don't speak TLS 1.3 yet), the existing semantics of TLS 1.2 won't change, and whether sigalgs are stronger than a hint w.r.t. X.509 is... controversial. I wasn't able to find anyone else doing it. So +1 from me on dropping the 3x3 product to just the three you listed. I'm less confident about the consequences of reusing the TLS 1.2 ecdsa_* allocations, but I can't think of any weird behaviors, so it seems reasonable. (The one thing I can think of is requires we keep ecdsa_p384_sha256. Then a client wishing to advertise ecdsa_p384_sha256 and not ecdsa_p256_sha256 and yet still speaking TLS 1.2 would have problems. But if we're actually limiting to those three, that can't happen anyway, and this hypothetical client seems pretty weird.) If other people still want to allow ecdsa_p384_sha256 and friends, I'm also happy with allocating 6 values and throwing out ecdsa_p256_sha384, ecdsa_p256_sha512, and ecdsa_p384_sha512. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
