At 11:21 AM -0500 12/26/06, DKIM Chair wrote:
In discussions with the IESG to sort through their "discuss"
comments, I had a talk with Lisa Dusseault, and she had one point
that I want to bring back to the mailing list: I don't think we
considered, in our discussions of multiple signatures, multiple
*linked* signatures, which could work TOGETHER to convey
information, and the protocol doesn't allow that sort of thing. The
way dkim-base is set up, I don't think this could easily be added as
an extension, and it'd be a significant change at this point.
Here's the concept:
* Signer puts on two signatures (maybe as two header records, maybe
as one that contains two sigs).
* One of the signatures has minimal scope, maybe signing only
"from:", with l=0.
* The other signature covers as much of the message as possible...
most headers, all the boby.
* The two signatures work together. If one verifies and the other
doesn't, the verifier can consider what was changed in the message,
and possibly use that information to deal with mailing list
modifications or whatnot.
I also discussed this with Lisa, and came to a very different conclusion.
What is being proposed above is that an additional signature be
generated and validated for every "important" header. That is a huge
waste of energy, and it will cause massive unnecessary resource
usage, particularly for recipients who don't care why a signature
might not have validated.
If the concern is "accidental" breakage, Michael's point is exactly right:
At 8:36 AM -0800 12/26/06, Michael Thomas wrote:
One can already do this by copying the relevant headers into the signature
using z=. I already do this and it works just fine for mailing lists.
If the concern is "purposeful" breakage, encouraging signers to sign
messages covering only the From header and none of the body is
incredibly bad. Wayne is exactly right:
At 11:49 AM -0600 12/26/06, wayne wrote:
Wouldn't signing just the 2822.From: header be close to useless since
it could trivially be replayed on all forged email? Even if you throw
in things like the 2822.Message-ID:, and 2822.Date:, etc., you really
have more "security" with the Habeas haiku.
--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html