Subject: [ietf-dkim] Signature identifier proposal

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Mar 2006 11:53:50 -0800 (PST)

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 20 Mar 2006 21:04:03 -0800

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.
>
> (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 [email-masked] sends a message through
[email-masked], you want to know whether it's a signature on behalf of
the user or the list.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Mar 2006 09:40:26 -0800 (PST)

> [email-masked], you want to know whether it's a signature on behalf of 

The same signer might sign the message twice, with two different 
algorithms.  If on arrival one verifies and one does not (an ambiguous 
result), the recipient might be interested in the details of which 
algorithm was used in which case in order to make a go/no-go decision. 
This might be especially interesting if rsa-sha256 failed and rsa-sha1 
succeeded, for example.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Mar 2006 09:54:43 -0800

Murray S. Kucherawy wrote:
>> 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 [email-masked] sends a message through 
>> [email-masked], you want to know whether it's a signature on behalf 
>> of the user or the list.
> 
> 

If you're looking for a fingerprint, is there something wrong with b=?

		Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Mar 2006 10:01:46 -0800 (PST)

> If you're looking for a fingerprint, is there something wrong with b=?

Actually yeah, using the first several bytes of the signature might work 
just fine.  Then we don't need to change -base at all, and 
Authentication-Results: can just cite a piece of b=.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html