ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposed fingerprint tag description

2006-04-12 15:10:04

Hi Murray,

What would be wrong with the option of using the first N bytes of the
actual signature value?

If that were ok (and I've no idea really), then presumably the shortest
N that disambiguates the signatures could be used.

But its not entirely clear to me who's putting this value where, when. I
guess I should go re-read your draft!

Cheers,
Stephen.

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