On Fri, Jan 06, 2017 at 04:24:19PM +0000, Viktor Dukhovni wrote:
> On Fri, Jan 06, 2017 at 04:55:42PM +0100, Daniel Margolis wrote:
>
> > On Fri, Jan 6, 2017 at 2:08 PM, Viktor Dukhovni <[email protected]>
> > wrote:
> >
> > > For domains that actually have MX records (not just implicit "domain.
> > > IN MX 0 domain.") the MX records will already be in A-label form,
> > > since they're the result of a DNS lookup. Nobody should have to
> > > convert these to U-labels just in case the domain owner's STS policy
> > > uses unicode.
> >
> > The opposite, I assume--that you would convert the U-labels in the policy
> > to punycode before comparing to the MX records.
>
> I am suggesting that policies should not contain U-labels, and
> therefore, there should be no conversion requirement.
>
> > But as I said in my first reply, I think keeping everything A-form makes
> > everything easier.
>
> Exactly. STS should require A-labels in the mx policy attribute.
>
> > On the other hand, as Alberto says, simply converting
> > everything to A isn't that big a deal. *shrug*
>
> Unnecessary complexity. The client will already have the A-label
> forms of both the domain name and the MX hostnames, and should not
> have to generate A-label encodings. Nor should it have to compute
> the A-label forms of the policy data. Especially because wildcards
> are not valid domain names, and U-to-A libraries may not directly
> support converting these, making the code to do so a bit more complex.
You'd be making the code more complex but the policy writing simpler, so
it wouldn't be entirely unnecessary.
Whether it is a worth tradeoff, I'm sure it's arguable :)
In any case, the main objective of my comment was to suggest that it's
worth picking an option (A/U/both) and making it explicit, to avoid
inconsistencies from appearing once implementations and policies start
to appear.
Thanks,
Alberto
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
