[ietf-dkim] Possible C14N incorporating MIME decoding

Note change of Subject at request of Barry Leiba. The original thread
(Introducing Myself) was fine when I first joined this list with a long  
list
of issues I was concerned about, but it is well past its sell-by-date now.

In due course, this needs an I-D draft with a definite proposal, but the  
issues
could use a little more informal discussion first.

On Thu, 07 Dec 2006 11:14:16 -0000, Hector Santos <hsantos(_at_)santronics(_dot_)com>  
wrote:
> Charles Lindsey wrote:
> > On Wed, 06 Dec 2006 20:25:39 -0000, John Levine <johnl(_at_)iecc(_dot_)com> 
> > wrote:
> > In particular, it will not be adopted in countries (esp those in Asia)  
> > where the character sets used are totally unlike ASCII if it can only  
> > be made to work by forcing everything to be sent as 7bit.
> You're assuming MUA are involved. Right? This all can be 100%  
> transparent if we keep DKIM out of the Presentation Layer.
No. AIUI DKIM is supposed to operate mainly between the 1st MTA after the  
sending MUA and the last MTA before the receiving MUA (though smarter MUAs  
that sign their own, or verify their own are welcome to try). But  
nevertheless the form of the message as processed by MTAs 'on the wire'  
does get looked at and needs to be looked at for all sorts of odd reasons,  
and if the people looking at it find it squashed into 7bits that they  
cannot readily interpret, they are going to revolt (and are doing so). It  
is ridiculous that in the 21st century the mail protocols are still  
cramming 8bit material into 7bits using abo9ut 6 different coding  
mechanisms. That is the logjam that EAI is trying to break.
> Ok, if a transformation has to be done, then the DKIM owner will know  
> how do deal with this when it finds out that a failed outcome can not be  
> avoided.   Or maybe they have worked out a route so that there will be  
> known middle ware who will alter and but also resign the mail.  As long  
> as the final system validates and authorizes the domain signature , its  
> fine.  You can't use certain technologies in all systems and that  
> applies in many areas.
That might work for an 'owner' who regularly emails to the same group of  
people and knows the routes by which they can be reached with 8BITMIME  
supported all the way. But knowledge of detailed routes largely  
disappeared 20 years ago when 'bang' paths went out of fashion, and any  
need for such knowledge was finally outlawed with RFC 2821. And it is no  
use at all if the 'owner' wants to communicate reliably, with the full  
protection of DKIM, with arbitrarily selected people the world over.
> > That is why the parallel EAI effort has been mentined so often in these  
> > discussions, because it is pulling in exactly the opposite direction to  
> > this WG, and it is the Chinese and the Japanese who are pulling the  
> > hardest.
> I don't see how it applies and IMV, its no different when there are  
> other mid-stream transformation requirements and a DKIM owner who is or  
> not aware of it.  Regardless of the transformation requirements, whether  
> its for Americans, British, Chinese or Martians, DKIM still needs  
> knowledge of any mail integrity change and signing/resigning entities.
How DKIM will work in an EAI context is not yet clear. For messages which  
remain in an EAI (aka UTF8SMTP) environment throughout their journey, DKIM  
should work OK, provided implemetors heed the advice in dkim-base to  
maintain 8bit cleanliness in strings. But if a UTF8SMTP message has to be  
downgraded by some MTA en route, then secondary signing by that MTA is  
just not an option. The best solution so far seems to be for the verifier  
to upgrade the message to its original form before checking it. That  
should in principle be possible as things are being defined, but whether  
with sufficient robustness to always work is as yet far from clear.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html