On 4/13/11 12:23 PM, Dave CROCKER wrote:
On 4/13/2011 12:21 PM, John R. Levine wrote:
i'm also tempted to suggest using months in a different language,
with enero or
Januari...
If you're going to change it, change it to 一月 or يناير
not after i just got done trying to avoid unicode issues...
DKIM has not properly considered the security ramifications related to
IDN usage.
See http://tools.ietf.org/html/rfc6055#section-4
,---
Instead, conversion to A-label form, or any other special encoding
required by a particular name-lookup protocol, should be done only by
an entity that knows which protocol will be used (e.g., the DNS
resolver, or getaddrinfo() upon deciding to pass the name to DNS),
rather than by general applications that call protocol-independent
name resolution APIs. (Of course, applications that store strings
internally in a different format than that required by those APIs,
need to convert strings from their own internal format to the format
required by the API.) Similarly, even if an application can know
that DNS is to be used, the conversion to A-labels should be done
only by an entity that knows which part of the DNS namespace will be
used.
'---
See http://tools.ietf.org/html/rfc4952#section-4.2
,---
There are many places in MUAs or in a user presentation in which
email addresses or domain names appear. Examples include the
conventional From, To, or Cc header fields; Message-ID and
In-Reply-To header fields that normally contain domain names (but
that may be a special case); and in message bodies. Each of these
must be examined from an internationalization perspective. The user
will expect to see mailbox and domain names in local characters, and
to see them consistently. If non-obvious encodings, such as
protocol-specific ASCII-Compatible Encoding (ACE) variants, are used,
the user will inevitably, if only occasionally, see them rather than
"native" characters and will find that discomfiting or astonishing.
Similarly, if different codings are used for mail transport and
message bodies, the user is particularly likely to be surprised, if
only as a consequence of the long-established "things leak"
principle. The only practical way to avoid these sources of
discomfort, in both the medium and the longer term, is to have the
encodings used in transport be as similar to the encodings used in
message headers and message bodies as possible.
'---
The presumption of A-Label use within a domain name is likely wrong from
a security or standardization perspective. It would be incorrect to
expect email applications using standard resolving APIs will only accept
A-Labels. Email should not depend upon an older view of a DNS
limitation that does not exist.
Although the definition for a domain made in section 2.3.5 of RFC5321
limits domains to ldh characters, this clearly represents an archaic
definition in conflict with rfc6055 and rfc4952. Users that see
punycode versions for the signing domain, in conjunction with the UTF-8
versions within email addresses are not afforded added comfort nor
reliable assurances which resource had been selected when making the
verification.
http://tools.ietf.org/html/rfc5321#section-2.3.5
Clearly, this issue requires at minimum a section added that reviews the
issue and consensus established in how this information is to be
encoded. Clearly, the requirement to use A-labels binds DKIM to now an
obsolete limitation.
Remove the requirement to use A-labels since SMTP and resolvers can not
be expected to enforce this type of restriction.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html