* “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.”
RFC 5890, section 2.3.2.1 [1] defines “U-label” as:
“A "U-label" is an IDNA-valid string of Unicode characters, in
Normalization Form C (NFC) and including at least one non-ASCII
character, expressed in a standard Unicode Encoding Form (such as
UTF-8). It is also subject to the constraints about permitted
characters that are specified in Section 4.2 of the Protocol
document and the rules in the Sections 2 and 3 of the Tables
document, the Bidi constraints in that document if it contains any
character from scripts that are written right to left, and the
symmetry constraint described immediately below.”
Section 4.2 of the Protocol Document (RFC 5891) [2] proceeds to define
requirements for IDNA2008-valid labels which would exclude strings that would
be valid in UTS-46 (as has been exhaustively discussed the past few days on
this list). Given this, I don’t believe that U-Label (and perhaps the other
terms defined in RFC 5890) would be the correct term to use to encompass those
labels that are valid for UTS-46 but not IDNA2008.
Thanks,
Corey
[1] https://www.rfc-editor.org/rfc/rfc5890#section-2.3.2.1
[2] https://www.rfc-editor.org/rfc/rfc5891#section-4.2
From: Uta <uta-boun...@ietf.org> On Behalf Of Rob Sayre
Sent: Monday, January 30, 2023 1:49 PM
To: Valery Smyslov <smyslov.i...@gmail.com>
Cc: uta@ietf.org; Peter Saint-Andre <stpe...@stpeter.im>; Salz, Rich
<rsalz=40akamai....@dmarc.ietf.org>; uta-cha...@ietf.org
Subject: Re: [Uta] UTS-46 / WHATWG
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.
---
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].
---
That's it, and I must say I'm a bit dismayed that argument has continually
drifted to the /people/ rather than the content of the document.
thanks,
Rob
On Mon, Jan 30, 2023 at 6:07 AM Valery Smyslov <smyslov.i...@gmail.com
<mailto:smyslov.i...@gmail.com> > wrote:
Hi,
thanks to all for very interesting discussion (and thanks
to John and Patrik for the explanation of the history of the problem).
Before issuing a consensus call, the first question is to Rob:
can you propose concrete text changes that you want to see in the draft?
Regards,
Valery (for the chairs).
> On 1/29/23 1:14 PM, Salz, Rich wrote:
> >
> >> It seems to me that It remains the case that this I-D is not the best
> >> forum to litigate which U-labels are valid candidates for turning into
> >> A-labels. Surely that belongs elsewhere.
> >
> > I agree that this kind of thing belongs in the DNS groups.
> >
> >> However it is that
> > applications (or their libraries) turn U-labels into A-labels, this I-D
> > describes how to match them against presented identifiers in
> > certificates.
> >
> > *EXACTLY*
> >
> > Really all this draft says is "compare A labels."
> >
> > What else do we need to say? In my view nothing.
>
> Completely agree.
>
> And that's what draft-ietf-uta-rfc6125bis (even RFC 6125 before it) has
> always done, with version -10 now including additional security
> considerations and pointers to relevant specifications.
>
> Chairs, can you please initiate a consensus call on whether or not we
> need to make changes to draft-ietf-uta-rfc6125bis on this topic? As far
> as I can see, we have one person loudly in the rough, but a consensus
> call would enable us to determine whether there is broader support for
> modifications to the draft (which, I would like to point out, has
> already completed two working group last calls).
>
> Peter
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org <mailto: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
