I don't quite see what the objective is here.
There is a lot of information that a sufficiently dedicated client might infer
from multiple signatures made by the same signer but I am not sure that there
is much value to be gained unless particular multiple signature practices are
in widespread use.
Multiple signatures made by different signers are an entirely different matter,
in a store and forward world there will always be the possibility of damage
occuring. But all we need for the purposes of spam control is one trusted party
that volunteers to be held responsible.
Equally multiple signatures of the same content under different signature
algorithms are useful to allow transition from a legacy signature algorithm to
a stronger one.
If the purpose of the signature is for debugging the sending path rather than
for accepting responsibility then I think we are talking about something that
is beyond base.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of EKR
Sent: Tuesday, December 26, 2006 7:08 PM
To: Paul Hoffman
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Base issue: multiple linked signatures
Paul Hoffman <paul(_dot_)hoffman(_at_)domain-assurance(_dot_)org> writes:
At 3:43 PM -0800 12/26/06, EKR wrote:
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>;
...
This is actually less information than the z= tag, which
says what the
value was when signed.
Yes, that's true, so even without this optimization it's not
true that you need to a separate signature for each header.
That said, this representation is more compact, so it's a tradeoff.
It also doesn't come with this restriction:
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
But of course that restriction could be relaxed.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html