Paul Hoffman <paul(_dot_)hoffman(_at_)domain-assurance(_dot_)org> writes:
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.
I don't know what's being proposed here, but as a technical matter
it's not really the case that you can't individually insulate each
header from breakage without doing a separate signature for each
one. Rather, you could simply include digests for the header value in
the header specification, i.e.,
DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=(_at_)eng(_dot_)example(_dot_)net;
t=1117574938; x=1118006938;
h=from=<digest-value>:to=<digest-value>:subject-<digest-value>:date=<digest-value>;
...
Again, I'm not offering an opinion on what should or should not be done
here, merely on what's possible.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html