Paul Hoffman <[EMAIL PROTECTED]> 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; [EMAIL PROTECTED];
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
