On Thu, Jul 07, 2016 at 07:29:08PM -0700, Watson Ladd wrote: > On Jul 7, 2016 12:29 PM, "Eric Rescorla" <e...@rtfm.com> wrote: > > How about limit to ECDSA certificates? This eliminates the > Bleichenbacher issues. We can also make this opt in via an extension > to the EE certificate: since the certificate is not a CA certificate > (even if used that way) the extension can be noncritical.
You mean ECDSA legacy signature type (TLS_ECDHE_ECDSA_WITH_* ciphersuites)? There's EdDSA too (and it would meet the above definition)? New extension would need CAs to issue it, and getting them to do that could be, erm... "laborious". > As for format we know we have a TLS 1.3 signed structure that doesn't > overlap. Option 2 is easy: throw a key and TAI seconds for interval > start and end. I hope we won't need more structure then that. Using > X509 runs a risk of cross-format issues, and showing there aren't any > is likely to be hard. Or use POSIX time notation if you can tolerate being off by a second due to leap secods. Then the proposal had server name or server name list. Dunno if those are needed. > I don't think we can use name constraints here. Yes, they are opt-in > and clients can indicate support, but it may well be that a TLS > implementation doesn't know if its X509 validation code will support > them as it hands the certificate to a system provided validator. (I > believe there was a longstanding Chrome on Windows XP bug for a > similar reason). The nasty Chrome on WinXP bug I was aware of was that WinXP code couldn't handle certificates that were like "allow all, except .foo". LE X1 intermediate hit that bug, causing lots of trouble, even with WinXP being EoL'd. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
