On Friday 15 January 2016 17:13:29 Brian Smith 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. > > 3. You get better interoperability with TLS 1.2's NSA Suite B profile > [1]. > >> (I don't have any particular affinity for that profile other than > >> it seems to have made choices that have historically been shown to > >> be above average, and it might be a good idea to avoid interop > >> failure with other implementations that might have a special > >> affinity for it.) > > > > What interop faliures are you worried about here? > > The way I proposed things to work for TLS 1.3 is what the Suite B > profile does for TLS 1.2. A Suite B client cannot describe the Suite > B profile policy with the signature_algorithms extension as-is, so in > theory if a Suite B profile client even exists, it would work better > if servers assumed that ecdsa_sha256 implies P-256 and ecdsa_sha384 > implies P-384. I don't know if any such "Suite B client" actually > exists, though.
OpenSSL since version 1.0.2 has a setting to enforce strict Suite B compliance -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
