On Mon, Jan 30, 2023 at 10:48:42AM -0800, Rob Sayre wrote: > 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. > ---
This change (saying nothing about either IDNA2008 vs. UTS-46) is fine by me. The suggestion below is more contentious: > 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]. > --- How about: The IETF specification covering internationalized domain names is "IDNA2008" [IDNA-DEFS]. The Unicode Consortium publishes a related specification known as "UTF-46". The latter allows names that are valid in IDNA2003 but not IDNA2008, and additionally allows characters that are not valid in either IETF specificaiton, such as emoji characters. That more lenient approach carries additional risk of semantic ambiguity and additional security considerations. This document does not attempt to resolve the differences between the conflicting specifications. DNS names that conform to IDNA2008 are likely to face fewer interoperability barries, applications that conform to UTS-46 may be able to verify a broader range of certificates. -- Viktor. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
