* What sort of ripple effects are you thinking? Purely editorial within the document which talks about one or more DNS-ID/URI-ID in a couple of places.
* I agree that, in practice, the use of multiple names has been normalized beyond the "SNI workaround" (e.g. the discussions on cross-SNI resumption or the ORIGIN frame), so removing that text seems acceptable, but I suspect that we'd both be on the same page of wanting to say _something_ about the risks, such as cross-protocol attacks. And if we're going to discuss those, would it also be appropriate to discuss the concerns about accepting multiple different _types_ of identifiers within a message, and the intersection that can play with, for example, nameConstraints. Yes I think we are. * That is, I've seen far too many implementations that will accept (DNS-ID || URI-ID) within a TLS endpoint, but will happily ignore that while a DNS-ID will be constrained by DNS nameConstraints, those same nameConstraints won't constrain the URI-ID unless URI nameConstraints are included, and notably... they aren't required to be included in popular PKIs like the Web PKI. I didn’t even realize URI nameConstraints were possible. * Happy to suggest text if folks think it's worth tackling during this revision, although it seems a separate-but-related attack to the cross-protocol attack. Please do!
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
