> (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.
[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
