[mail-vet-discuss] Fwd: Re: New draft for review

[Murray S. Kucherawy]

Charles Lindsey wrote:
> So, suppose it arrives at a mailing-list expander who checks its signature
> and wishes to record the fact (maybe because he is about to add some
> boilerplate to the message body that will invalidate the existing
> signature for subsequent recipients).
> 
> So he would add:
> 
> Authentication-Results: list-expander.example.com
>            header.dkim-signature=sending.domain; dkim=pass (good signature)
> Received: by list-expander.example.com ...........
> Dkim-Signature: ........... d=sending.domain; ..........

If you look in the examples for the most recent draft (5/31, posted to this list 
but not to the IETF yet) you'll see a better (and more current) example. 
Instead, your example above would read:

Authentication-Results: list-expander.example.com;
	dkim=pass (good signature) header.i=@sending.domain

> Note that he does not assert that the From or Sender fields had been
> validated (though he could do that as well if he wished). He simply
> asserts that he checked the signature provided by sending.domain against
> the message header fields and body, and that it passed (some later
> recipient can worry about whether signatures from sending.domain are
> useful and meaningful, or not).

Actually since RFC4871 stipulates that the From: header MUST be signed, you are 
guaranteed that at least that one was included in the verification (assuming, of 
course, you choose to trust A-R headers not added within your trust boundary).

> Now, he adds his boilerplate to the body (thereby invalidating the
> existing signature) and resigns it himself, including his own
> Authentication-Results header in the signature:
> 
> Dkim-Signature: ...... d=list-expander.example.com;
> h=...:Dkim-Signature:...; ...

To include the results in the signed content, that should be:

	h=...:Authentication-Results:DKIM-Signature:...

> BUT, header.dkim-signature=... is not allowed by the proposed draft and
> this needs to be rectified.

It is in the -05 draft, though it looks a little different than your example.

> Also, the usual problems of identifying which
> of the various Dkim-Signatures is referenced by which of the various
> Authentication-Results and other Dkim-Signatures arises. RFC 4817 deals
> with this, but not in an entirely satisfactory manner (it assumes that
> header order has been faithfully preserved).

This is something over which I've been puzzling.  For reasons to which you've 
alluded here, we can't guarantee the ordering (even though usually in practice 
it works out just fine).  There's nothing especially unique about two separate 
signature headers other than the signatures ("b=") themselves, and even those 
have some common bits (mostly the beginning few and end few bytes).

The best suggestion I've heard so far is to take the signature value, do an MD 
or SHA hash over that, then take the first several bytes from the hash, express 
them in hexadecimal, and call that the "signature ID" which can then be used to 
associate results with signatures.  The software making use of this information 
will have to re-do that association (you can't add a comment to the signature to 
assign it a signature ID lest you clobber downstream verification) but it should 
be isomorphic and then the MUA can make use of the data.