ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ISSUE: non-ascii header text

2011-04-22 17:22:08
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