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
