On 4/19/11 3:35 PM, John R. Levine wrote:
Sorry, this message makes no sense. The IETF has been working on
non-ASCII domain names and e-mail for over a decade, and we are
certainly not going to do random things that ignore that effort and
the many RFCs that describe the use of IDNs in the DNS.
The suggestion was to remove the MUST requirement to encode DKIM related
domains within the header fields as A-labels. This represents the wrong
approach.
From a security aspect, DKIM should also acknowledge there are no
A-Label requirements for selectors and acknowledge the possibility that
UTF-8 hostnames may resolve SMTP resources as well.
Lets review some of the RFCs then.
http://tools.ietf.org/html/rfc2277 section 2,
,---
Internationalization is for humans. This means that protocols are not
subject to internationalization; text strings are.
'---
http://tools.ietf.org/html/rfc5894#section-4.2
,---
The IDNA protocol does not
necessarily affect the interface between users and applications. An
IDNA-aware application can accept and display internationalized
domain names in two formats: as the internationalized character
set(s) supported by the application (i.e., an appropriate local
representation of a U-label) and as an A-label. Applications may
allow the display of A-labels, but are encouraged not to do so except
as an interface for special purposes, possibly for debugging, or to
cope with display limitations.
'---
http://tools.ietf.org/html/rfc2181#section-11
,---
The DNS itself places only one restriction on the particular
labels that can be used to identify resource records. That one
restriction relates to the length of the label and the full name.
The length of any one label is limited to between 1 and 63 octets.
A full domain name is limited to 255 octets (including the
separators). The zero length full name is defined as representing
the root of the DNS tree, and is typically written and displayed
as ".". Those restrictions aside, any binary string whatever can
be used as the label of any resource record. Similarly, any
binary string can serve as the value of any record that includes a
domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
and any others that may be added). Implementations of the DNS
protocols must not place any restrictions on the labels that can
be used.
'---
http://tols.ietf.org/html/rfc6055#section-3
,---
Shortly after the DNS Clarifications [RFC2181
<http://tools.ietf.org/html/rfc2181>] and IETF character
sets and languages policy [RFC2277 <http://tools.ietf.org/html/rfc2277>]
were published, the need for
internationalized names within private namespaces (i.e., within
enterprises) arose. The current (and past, predating IDNA and the
prefixed ACE conventions) practice within enterprises that support
other languages is to put UTF-8 names in their internal DNS servers
in a private namespace. For example, "Using the UTF-8 Character Set
in the Domain Name System" [UTF8-DNS
<http://tools.ietf.org/html/rfc6055#ref-UTF8-DNS>] was first written in
1997, and
was then widely deployed in Windows. The use of UTF-8 names in DNS
was similarly implemented and deployed in Mac OS, simply by virtue of
the fact that applications blindly passed UTF-8 strings to the name
resolution APIs, the name resolution APIs blindly passed those UTF-8
strings to the DNS servers, and the DNS servers correctly answered
those queries. From the user's point of view, everything worked
properly without any special new code being written, except that
ASCII is matched case-insensitively whereas UTF-8 is not (although
some enterprise DNS servers reportedly attempt to do case-insensitive
matching on UTF-8 within private namespaces, an action that causes
other problems and violates a subsequent prohibition [RFC4343
<http://tools.ietf.org/html/rfc4343>]).
Within a private namespace, and especially in light of the IETF UTF-8
policy [RFC2277 <http://tools.ietf.org/html/rfc2277>], it was reasonable
to assume that binary strings
were encoded in UTF-8.
'---
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html