On Mon, Jan 30, 2023 at 10:49 AM Rob Sayre <[email protected]> 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 _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
