On Fri, 17 Sep 2004, David Woodhouse wrote:
Here are some of the criteria which I think any RFC2822-level signature
scheme should meet.
First, it should handle multiple signatures. A recipient may quite
reasonably want to verify and or all of the addresses in the From:,
Sender, Resent-From: and/or Resent-Sender: headers.
The signature should in itself contain "from" lines at the time email
was signed so as to allow to verify it at any point in the future.
Second, it should be resilient to the common mangling which messages may
encounter in transit -- in particular the addition of text to the end of
a mail by mailing lists, by idiotic disclaimers and by self-advertising
virus checkers.
Obsolutely.
Also, as an adjunct to the above, it should ideally survive the
stripping of MIME parts which some mailing lists perform. Signing each
MIME part separately would be useful, rather than signing the message as
a whole.
This was originally in my system in the version never publicy published,
but I found it too much extra work to deal with each mime part necessry
and that in 99.9999% of the cases mime do not get reordered or changed.
The change I made then was to have one central signature for entire
body but to have sender (first MTA that deals with message) have an
option of adding signature for each mime part and in case central
signature fails the final recepient can then go through that original
signature and verify each mime part individually. For more info see
sections 3.4.2 and step 3 of signature verification in section 3.7.2
of http://www.elan.net/~william/asrg/mta_signatures.htm
I'll note that my MTA Signatures proposal is the only one that is
capable of dealing with additions of emails text and new mime parts
at the end of email (by very design of the proposal it has no problems
with such additions) and still pass signature end-end and not move this
system to authenticing only the very last signature. The next version of
proposal (0.06 to be released in October) will have a refined system that
takes care of some canonicalization errors and allows to double-check on
the body of the message to see if it has been changed (prior to checking
the signature) and should cut chance of falsely labeling email as having
failed signature verification to almost 0.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/