On Mar 31, 2006, at 10:31 AM, Dave Crocker wrote:
Barry Leiba wrote:
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.
So what?
There are many "interesting" things that we might build into a
protocol.
The question is what compelling need is served by the feature?
The goal is to ensure when there are two signatures added to the
message, an attacker does not toss out the stronger signature in
order to exploit the weaker signature added within a transition period.
There could be a flag that marks the signature as primary or
secondary. Only seeing a secondary signature from the same domain
should cause the message to be refused.
The concept of signature roles at the meeting was to do this and also
allow the MDA to add a signature to protect results information and
ensure this signature was not mistaken as being from a sender. The
same flag that marks primary/secondary signatures could also
differentiate signatures added by senders or by the MDA.
This approach would be far simpler, as in most cases it would be a
static bit of information, such as "w=S" (primary) or
"w=s" (secondary) or "w=d" (mda).
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html