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(_dot_)i=(_at_)sending(_dot_)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.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html