Re: [Uta] UTS-46 / WHATWG

[Watson Ladd <[e-mail]>]

On Mon, Jan 30, 2023 at 10:49 AM Rob Sayre <[e-mail]> wrote:
>
> Hi,
>
> That is a reasonable thing to ask for, and I will supply edits below. They might sound like me rather than the authors, so I wouldn't mind if they write something substantially similar in their own voice.
>
> I also understand the point of view that says "Really all this draft says is 'compare A labels.'" But this is incompatible with strenuous objections to changes to IDNA text in the document, so I don't understand this behavior. When I read the document, I thought "that's not how it really works, and I sure wish I didn't have to read the WHATWG document to get the truth, because it's really long". In fact, this very mailing list even runs on UTS-46. See https://mailarchive.ietf.org/arch/msg/uta/KbtvWrG5vdW6iq0scwWpBc1xeM8/
>
> In Section 2, the current text is incorrect, because UTS-46 domains sometimes don't conform to these validity checks. So, the document is inconsistent in making this claim. Citing UTS-46 here would be correct, since that would also cover IDNA2008, but it doesn't seem like that will fly.
>
> Current:
> ---
> An "internationalized domain name", i.e., a DNS domain name that includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range and conforming to the processing and validity checks specified for "IDNA2008" in [IDNA-DEFS] and the associated documents. In particular, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels.
>
> New:
> ---
> An "internationalized domain name", i.e., a DNS domain name that includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range. In particular, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels. Refer to [[Section 7.3]] for further details.
> ---

I think that's right.

>
>
> Then, in section 7.3:
> Current:
> ---
> As with URIs and URLs, there are in practice at least two primary approaches to internationalized domain names: "IDNA2008" (see [IDNA-DEFS] and the associated documents) and an alternative approach specified by the Unicode Consortium in [UTS-46]. (At this point the transition from the older "IDNA2003" technology is mostly complete.) Differences in specification, interpretation, and deployment of these technologies can be relevant to Internet services that are secured through certificates (e.g., some top-level domains might allow registration of names containing Unicode code points that typically are discouraged, either formally or otherwise). Although there is little that can be done by certificate matching software itself to mitigate these differences (aside from matching exclusively on A-labels), the reader needs to be aware that the handling of internationalized domain names is inherently complex and can lead to significant security vulnerabilities if not properly implemented.
>
> New:
> The IETF document covering internationalized domain names is "IDNA2008" [IDNA-DEFS]. The Unicode Consortium publishes a similar document known as "UTF-46". This document allows names that are valid in IDNA2003 but not IDNA2008, and additionally allows characters that are not valid in either IETF document, such as emoji characters. This more lenient approach carries additional risk of semantic ambiguity and additional security considerations. ICANN recommends IDNA2008 [https://features.icann.org/ssac-advisory-use-emoji-domain-names] and against emoji characters in domain names. However, the internet contains old content published under IDNA2003, and people enjoy emoji characters, so consumer applications often end up using the more liberal approach in [UTS-46].
> ---

I think we actually need to say more here: the A-label used in the
X509 comparison needs to be the A-label derived and used to do the DNS
lookup. Otherwise we have the issue of bugs that change the IDN
behavior between application and X509/TLS library breaking the
relation between what the user put in and the cert presented.

Also I don't think comparison is enough: don't name constraints need
to be included in the calculation?

Sincerely,
Watson Ladd