----- Original Message -----
From: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
To: <dcrocker(_at_)bbiw(_dot_)net>;
<ned+dkim(_at_)mauve(_dot_)mrochek(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Monday, July 24, 2006 9:07 AM
Subject: RE: [ietf-dkim] 822/2822 or just 2822
On the face of this it looks like a third party is molesting the message
after signing but before delivery. If the third party does not currently
do DKIM then the signature will result in failure. If the third party is
DKIM aware then it could verify the signature, make needed changes then
re-sign the message and forward it to the recipient. This brings us back
to 3rd party signatures that break the original signature and into
policy issues.
+1.
Question:
If it not possible to have a complete stripping of the CR/LF for hashing
purposes? That would address this particular mixed bag EOL issue for both
the signer and verifier.
I believe from a security standpoint that this is not as secure as a SIMPLE.
So maybe we can two hashes:
- a hash that is part of the signature using a STRIP canonicalization,
- a hash of the original body,
The gives the verifier two new capabilities:
- It will increase hash repeatability using the STRIP method, and
- It provides a way to check for original mail integrity changes.
This can produce an interesting result with the DKIM signature calculated as
valid but with feedback that the originality of the message has change.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html