Hi, Viktr Duhovni wrote: [...pretty much the same stuff...] "This document does not attempt to resolve the differences between the conflicting specifications."
I don't think we need to say this--it's obvious. "DNS names that conform to IDNA2008 are likely to face fewer interoperability barriers, while applications that conform to UTS-46 may be able to verify a broader range of certificates." I'd be fine with adding that to the end of what I wrote, but I do want to leave what ICANN said in the text. It seems to me that they covered the issue pretty well. thanks, Rob On Mon, Jan 30, 2023 at 11:17 AM Watson Ladd <watsonbl...@gmail.com> wrote: > On Mon, Jan 30, 2023 at 10:49 AM Rob Sayre <say...@gmail.com> 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 Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
