On Tue, Oct 10, 2017 at 11:42 PM, Viktor Dukhovni <[email protected]> wrote:
> ... > > - The other thing I found unusual is that (unless I am reading it > > incorrectly), certificate validation is done in a kind-of round-about > way: > > when connecting to an MX server, the certificate is considered valid if > it > > matches any MX pattern from the policy. This is very unusual and > requires a > > custom hostname matching algorithm. > > See the list archives, this is deliberate. The idea is to not > override MX selection, and to support sites with UCC certifcates > where the identity is the receiving domain name and not the MX > host. > Well, you don't have to override the MX selection. Select whichever MX you want and then, just prior to connecting to it over TLS, verify that the hostname matches one of the patterns provided. Treat it as authentication failure if it doesn't. I think this is simpler, faster in case of failure, and also allows you to use standard TLS hostname verification. There's nothing in this approach that would prevent you from using UCC/SAN certificates or SNI. Is there a specific scenario that would work with the current wording and not with my more-standard approach? -- Ivan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
