On August 17, 2005 at 08:26, Michael Thomas wrote:
PS: as I said, take a look at l= and z= and their implications
for mailing lists.
l= is a massive security problem. If you are relying on it, then
you are relying on a exploitable aspect of DKIM. How verifiers
deal with l= either needs to be revised or this tag needs to
be dropped.
As for z=, the draft states that z= data should not be part
of validation.
I don't think it works to let a signer make assertions about what kinds
of transformations a message might or might not undergo after the
message is signed.
On the other hand, if a signer wants to put redundant information in a
message as a means of recovering from subsequent ... "transmission
errors", and a verifier wants to make use of that redundant information
to recover the original message and verify that it was recovered
intact, I don't see anything wrong with that - provided that the
verifier only uses that signature to establish trust in the original
message, and not in the modified message.
So for instance a verifying MUA that displays an indication that a
message was signed should display the original message, rather than the
modified message. If it provides an option to display the modified
message, it should make it clear that the message was modified in
transit after being signed. (I can imagine an MUA showing diffs
between versions with strikethroughs, underlines, and change bars, but
I doubt most recipients would bother with such.)
Seen from that perspective, a filtering verifier might reasonably pass a
signed message if the original content could still be recovered and
verified by the filter, and presumably, by any subsequent verifier and
the recipient's MUA.
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org