Message189928
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. |
|
Date |
User |
Action |
Args |
2013-05-24 20:23:20 | loewis | set | recipients:
+ loewis, pitrou, christian.heimes, Arfrever |
2013-05-24 20:23:20 | loewis | set | messageid: <1369427000.59.0.626985373989.issue17997@psf.upfronthosting.co.za> |
2013-05-24 20:23:20 | loewis | link | issue17997 messages |
2013-05-24 20:23:19 | loewis | create | |
|