Hi Corey, thank you for this work. Folks, please use Corey's PR when commenting on proposed changes for this consensus call.
Regards, Valery. > Hi Valery, > I took a stab at creating text to resolve this issue: > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/88. I went ahead > and incorporated Rob's and Watson's suggestions into this PR so that we have > a comprehensive view of the suggested changes. > > Thanks, > Corey > > -----Original Message----- > From: Valery Smyslov <val...@smyslov.net> > Sent: Wednesday, February 1, 2023 8:32 AM > To: Corey Bonnell <corey.bonn...@digicert.com>; uta@ietf.org > Cc: uta-cha...@ietf.org > Subject: RE: [Uta] Consensus call for proposed changes to > draft-ietf-uta-rfc6125bis-10 > > Hi Corey, > > > > (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). > > > > I think it would be unfortunate if the usage of terms that are defined > > in RFC 5890 is not aligned with their definitions. > > > > If we are not opposed to introducing new terminology to the document, > > then I suggest the following: > > > > 1. Replace all instances of "A-label" with the term "P-label" from the > > CABF Baseline Requirements [1]: "P-Label: A XN-Label that contains > > valid output of the Punycode algorithm (as defined in RFC 3492, > > Section 6.3) from the fifth and subsequent positions." > > 2. For U-label: > > a. Punt and call it "Unicode representation" instead (this is what > > the CABF Baseline Requirements does, although that may not be > > appropriate for this document). > > b. Create a new term that is defined as "A non-LDH label that > > contains valid output of the decoding algorithm for Punycode (as > > defined in RFC 3492, Section 6.2)." and use this new term instead of > "U-label". > > > > I'd be happy to work on concrete text to this effect if there's > > agreement this is a good path to resolve the issue. > > My only concern here is that we can go into too much details that are only > partially in scope of this document. If you manage to craft accurate, but > concise text, it will be great. > > Thank you, > Valery. > > > [1] > > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.6.pdf > > > > -----Original Message----- > > From: Uta <uta-boun...@ietf.org> On Behalf Of Valery Smyslov > > Sent: Wednesday, February 1, 2023 3:38 AM > > To: uta@ietf.org > > Cc: uta-cha...@ietf.org > > Subject: [Uta] Consensus call for proposed changes to > > draft-ietf-uta-rfc6125bis-10 > > > > 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
