Well, I certainly think past the Web PKI, because one of the cases I care about is WebRTC, which doesn't do any PKI validation at all.
In any case, I think there are two issues: 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1. 2. Require a specific failure if the peer presents such a certificate. There was pretty strong consensus to do #1 and I don't support removing it. That seems like a pretty modest layering violation. If people think that the mandate for this specific alert is too onerous, I could live with removing that. -Ekr On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > On May 22, 2017, at 1:37 PM, Salz, Rich <rs...@akamai.com> wrote: > > > > I strongly believe the text should stay as it is, for the most good to > the most people. Viktor is in the weeds, arguably by himself. > > Right, all by myself... With support from Nico, Ilari, and others who've > upthread > accepted that certificate verification is properly RFC5280 and not TLS, > before I > suggested removal of the text in question (which solves no real problem, > but does > create needless interoperability issues for various TLS use-cases). > > The dominant use case is not the only one that needs consideration, > and text that breaks other use-cases is NOT just fine, and the TLS > WG really does need to think more broadly than the Web PKI. This is > not the HTTPS working group. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
