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
