Douglas Otis wrote:
Changing a reference of RFC3490 to RFC5890 already represents an
incompatible change.
Your assertion is noted.
John, it is correct to reference RFC5890 but for any implementations
that currently have RFC3490 support there is a conflict verifiers need
to be aware of. A proposed text change addendum as follows is both
protocol consistent and provides compatibility insight:
Internationalized domain names MUST be represented as A-labels
as described in [RFC5890]. For public key lookups, verifiers
MUST transform internationalized domain names already encoded as
described in [RFC3490] to A-labels.
or in less text without a RFC3490 reference:
Internationalized domain names MUST be represented as A-labels
as described in [RFC5890] for both DKIM-Signature domain values
and for Public Key DNS lookups.
The desire is not to increase anyone's workload, but the reasons for
developing DKIM will become even more apparent during the introduction
of UTF-8.
IMO, if someone begins to start thinking about UTF8 support for DKIM,
they will need to view this expensive revamping for their general
5321/5322 mail I/O operations. In the mean time, AFAMUG, RFC5890
offers an isolated DKIM transition for implementing in operations not
yet wrapped with Unicode support.
Unfortunately, the current DKIM specifications ignore
important aspects about where A-Labels are to exist within a protocol.
Are we not specifying all the IDNs within RFC5322 including
DKIM-Signature, in particular d=, s= and i=?
A-Labels are NOT intended for human consumption.
+1, neither is Unicode outside their locales. But displays are
expected to translate all that for human viewing.
DKIM also failed to ensure resources are only obtained at valid
A-Labels or NR-LDH defined locations.
Does that mean we need affirmation if we are just talking about
A-label as input for DNS lookups only.
A significant security flaw, especially when definitions of
valid A-Labels has significantly changed for the better.
Lost me. Better for security? Or worst? Or better for something
else, worst for security?
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html