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".
Well, the issue is that if, say with the above example, signer #3 signs
the other three signature headers, and then the next hop re-orders them,
the verifier can still figure out which records signed which others.
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