This must
be done in a way to prevent bid-down attacks during transitions,
I believe that Mark also has a proposal on the table for how to deal
with bid-down attackes.
And actually, as I recall the discussion in Dallas it seems that even
Russ and EKR were not worried about this issue. The idea was that it's
down to the verifier to determine which algorithms it's willing to
accept, and the removal of a "stronger" signature only matters if the
verifier isn't willing to accept the remaining, "weaker" one. I have no
opinion on this; I'm just bringing it up to the mailing list from the
session in Dallas.
also must be done in a way so the recipient can unambiguously determine
the order in which the signatures appeared.
The downside of this are MTA's that reorder headers, which they do
unless they know it's a trace header. Which they don't for DKIM
since it's new.
Someone else had suggested adding some sort of signature sequence field,
which, if we did that, could robustly identify the order, and could make
is clear which are missing. Something like this:
DKIM-Signature: seq=3,1,1; ...
DKIM-Signature: seq=2,2,2; ...
DKIM-Signature: seq=2,1,2; ...
DKIM-Signature: seq=1,1,1; ...
...where the numbers represent signer sequence, signature sequence for
this signer, number of signatures that this signer added. Mike is right
that we can already sign all the existing sigs when we add a new one, so
it's really only the ordering that we have to worry about.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html