Martin v. Löwis added the comment:
As a policy, the standard library should accept non-ASCII host names
("U-labels") wherever possible. I.e the hostname parameter of match_hostname
should allow for U-labels (as well as A-labels).
When returning names, it should always return the data "as-is", which typically
means A-labels. Anybody wanting to display U-labels will need to decode them
explicitly.
I believe that the matching of IDNA names doesn't currently happen according to
6.4.2 of RFC 6125, however, this is not actually the issue that Christian
reported (which was only about wildcard matching). I suggest to create a
separate issue for that.
As for 6.4.3: I find the text to be quite ill-formulated. Specifically, I'm
referring to the sentence
However, the client SHOULD NOT
attempt to match a presented identifier where the wildcard
character is embedded within an A-label or U-label [IDNA-DEFS] of
an internationalized domain name [IDNA-PROTO].
First, in the context of X.509, a wildcard *cannot* be embedded "with an ...
U-label"; the certificate can only possibly contain A-labels (because the
datatype of dNSName is IA5String).
Second, as written, it *does* allow to match 'götter.example.de' against
"x*.example.de", since "x*.example.de" is not an A-label. An A-label is defined
as
An "A-label" is the ASCII-Compatible Encoding (ACE, see
Section 2.3.2.5) form of an IDNA-valid string. It must be a
complete label: IDNA is defined for labels, not for parts of them
and not for complete domain names. This means, by definition,
that every A-label will begin with the IDNA ACE prefix, "xn--"
(see Section 2.3.2.5), followed by a string that is a valid output
of the Punycode algorithm [RFC3492] and hence a maximum of 59
ASCII characters in length. The prefix and string together must
conform to all requirements for a label that can be stored in the
DNS including conformance to the rules for LDH labels
(Section 2.3.1). If and only if a string meeting the above
requirements can be decoded into a U-label is it an A-label.
Since an A-label is required to conform to the LDH label syntax, it cannot
possibly contain the asterisk (LDH labels can only contain letters, digits, and
the hyphen. Hence, the entire requirement is irrelevant (as literally written).
They might mean something else, but I cannot guess what it is that they mean.
I disagree with the classification of this issue as critical. It does not
involve a crash, a serious regression, or a breakage of a very important API.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue17997>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
