----- Original Message -----
From: <ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com>
To: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
Cc: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>;
<ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, July 14, 2006 9:34 PM
Subject: Re: [ietf-dkim] More on naked CR canonicalization
Like it or not, you are not going to be able to define a canonicalization
that
can tolerate all the cases and possible transformations. My best advice is
not
to try. Signing messages that are syntactically invalid is going to be
unreliable and the only solution is to stop creating such messages.
That might be more easily said than done. I think the issue is more about
"easy of use" vs. "required processing." For legacy reasons, the "simple"
method is not going to be as easy to support.
Thomas is theoretically correct, for canonicalization purposes, all bare CR
and LF eol delimiters should be corrected to CRLF pairs. This would
theoretically resolve the problem and it will reduce integrated framework
implementation issues.
I can attest that would be the case for us. DKIM is not as easy to
implement as Crocker believe it is. Software Change is required and the
more integrated your system is, the more changes it needs.
All signers and verification used a single transformation or a consistent
method this would solve the problem and then Crocker would be more correct -
Less software changes is requires because now the DKIM Function Generator
will be independent of feed type.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html