Hi, the consensus call is over. Based on the discussion on the mailing list the chairs believe that the consensus is to keep the current (-10) text and not to go into the details of explaining the current far-from-ideal state of arts in the area of Internalized Domain Names.
That said, we think that some points raised during discussion may need to be addressed before the document is sent to the IESG (explanation what "delegated domain" means in the context of this document, reference IDNA2008 for definitions, clarification that name constraints evaluation in certificates must also use A-labels, etc.). Regards, Valery (for the chairs). > Hi, > > this message starts a one week consensus call for the following > proposed changes to draft-ietf-uta-rfc6125bis-10. The call > will end on Thursday, 9 February. > > 1. Section 2: > CURRENT: > 2. 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. > > PROPOSED: > 2. "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." > > 2. 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. > > PROPOSED: > The IETF document covering internationalized domain names is > "IDNA2008" [IDNA-DEFS]. The Unicode Consortium publishes > a similar document known as "UTS-46". > > UTS-46 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 correspondingly recommends against emoji characters in DNS names. > However, the internet contains old content published under IDNA2003, > and people enjoy emoji characters, so consumer applications often > end up using the approach in [UTS-46]. 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. > > The conversion from a U-label to an A-label MUST be done once and > used both to carry out the DNS lookup and the evaluation of the end > entity cert. Name constraints MUST be evaluated against the A-label > converted name. This ensures that the same DNS entity as is actually > connected to is validated against the certificate even in the presence > of bugs in the conversion process. > > > (I hope I accurately caught all the input from Rob, Viktor and Watson. > The note from Corey is reasonable, but it's difficult to incorporate it > without going into very deep nuances). > > Regards, > Valery (for the chairs) > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
