While considering the idea of multiple signatures on a message, I realized
that it may be desirable or even necessary to be able to indicate to the
MUA or some other agent which signatures succeeded verification and which
did not. However it's also conceivable that two signatures on the message
could come from the same domain and even use the same selector.
Moreover, it's possible that headers (and therefore signatures) can
be reordered in transit. Thus, some other way of uniquely identifying
which result applies to which signature, regardless of the method used to
relay these results, becomes necessary.
I'd like to suggest another signature tag, perhaps "I=" (for "identifier")
or "f=" (for "fingerprint"), be defined. Its purpose is to identify
uniquely the signature header from all others that may be present. The
tag is required. Its value is generated by taking the first four bytes of
the message's hash and expressing them in the usual hexadecimal way, with
no restrictions on case. Like "b=", the tag is present when the signature
header is appended to the hashed data for the purposes of completing
canonicalization, but the value of this tag is the null string in that
instance.
Unfortunately this means the identifier/fingerprint/whatever is
unprotected text in the signature, so a bad-guy can add two signatures
(perhaps in conjunction with a collision attack) with the same signature
identifier. I can't think of a nice way to protect it though without
doing something like hashing twice, once with a blank identifier (to get
the identifier) and then once with the identifier inserted (to get the
final hash to sign).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html