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
[email protected]
https://www.ietf.org/mailman/listinfo/uta
