Since fingerprints have specific meaning in cryptography, can you
change the name to something like "Unique Signature ID" (i.e. "u"
although personally I like "u"s for URLs).
How you planning to make reference to specific header field by using
this tag? Are these going to be similar tricks to what I have used?
(i.e. allowing simple regex after header field name in list of fields;
2nd trick was encoding unique id as part of header field name, which
does not apply here).
Is my understanding correct that using "f" would make using "i"
requirement as well? You probably want this mentioned ...
Can you explain why you need this tag and can not put unique info
in timestamp tag (i.e. allow for optional milliseconds to distinguish
signatures)? That seems better then extra tag...
On Wed, 12 Apr 2006, Murray S. Kucherawy wrote:
Following up on prior discussion, I'd like to start working on some formal
wording for a fingerprint tag. This will be used to describe the results of
verifying a message with multiple signatures present, so that the receiver
can match up each result to its respective signature even if there's been
some reordering.
This would be added to the section describing the tags present in signature
headers, namely "3.5 The DKIM-Signature header field" section:
f= Signature fingerprint (plain-text; OPTIONAL)
The fingerprint of the signature. This is a short string which is used to
distinguish between two different signatures of the same message, which may
have been added at the same time by the same signer, so that the receiver can
decide which of two or more conflicting results makes a more desirable
assertion. The fingerprint SHOULD be fairly short but MUST be unique among
signature headers added by the same signer. Thus, the concatenation of the
values of "f=" and "i=" will uniquely distinguish this signature from any
others that might be added between the originator and the receiver.
INFORMATIVE IMPLEMENTATION NOTE: It is likely sufficient to do something akin
to encoding the first four bytes of the body hash in hexadecimal, e.g.
f=44:4B:49:4D or f=444b494d.
If the "f=" tag is absent, a verifier can infer its value by using the first
four bytes of the actual (i.e. base64-decoded) "bh" tag's value when
describing its results to receivers. However, since the base64-decoded
version of the "bh" tag is not easily visible upon simple header inspection,
signers SHOULD add this tag for clarity.
This would also work even without the "bh" change to the specification;
instead the signer would just use the first few bytes of the single generated
hash that we have today.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html