ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] IDNs, was Proposed new charter

2010-03-03 15:38:40
On 3/2/10 6:47 PM, John Levine wrote:
RFC 4871, top sentence on page 20, in the description of d=
       
...
     
RFC 4871, second paragraph on page 21, in the description of i=
       
For the bis effort, I'd recommend this clarification.  I think it would fall
within acceptable boundaries of change while going to Draft.
     
I agree the two sentences should say the same thing. Don't feel
strongly about the wording since the way UTF->punycode works is the
same for all domain names everywhere.
   
Disagree.  One should not assume there is a unitary conversion of UTF to 
punycode.  The informational RFC 5242 has changed this one-to-one 
relationship.  As such UTF->punycode will produce a more than one 
conversion, depending upon conversion rule-sets applied.  There is a 
genuine need for the additional rule-sets, so don't assume there is a 
unitary conversion of UTF to punycode, or that there are even just two 
possibilities.

This issue will impact ADSP more than DKIM base.   ADSP is based upon 
what is seen in the From header.  Conversions of the From header may not 
resolve to a specific domain, depending upon the evolving conversion 
rule-sets.  The solution sought to deal with this issue is to use 
"equivalent" names to intercept these possible conversions.  The set of 
overlapping UTF names can be rather large and evolving.

ADSP may consider advising the use of double conversion.  Convert UTF 
into punycode using RFC5242 rules, and then convert punycode to UTF-8.  
Since there is no definite conversion that might be used, assured 
compliance may depend upon methods that allow use of third-party 
signatures, which could apply whenever the conversion rule-sets between 
sender and receiver are not the same.

-Doug




_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html