Murray S. Kucherawy wrote:
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).
I don't understand the value of knowing which signature(s) succeeded
beyond knowing what the signing identity/ies (i= or equivalent) is
associated with the successful signature(s). One of the primary reasons
for i= is to clarify the role of the signer when the domain isn't
enough, i.e., when user(_at_)example(_dot_)com sends a message through
list(_at_)example(_dot_)com, you want to know whether it's a signature on
behalf of
the user or the list.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html