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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
