Barry Leiba wrote:
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.
That might be ok too. I get the impression that DKIM is in the
crossfire of a larger discussion where these issues make a lot
more difference. I'm all for keeping some perspective.
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.
Somebody needs to help me out here. What problem is getting solved with
this geneology exercise? I've been at this a while, and I've never had
a moment where I thought "it would really be nice to know which begat
what".
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html