--- Begin Message ---
On Monday in the APPAREA meeting, I mentioned some upcoming work regarding the
Authentication-Results: header field. I've split the two changes I'm seeking
to make into separate drafts because one is fairly trivial and only requires an
IANA registration action to complete while the other touches a potentially
complicated security issue, involves a format change, and thus probably
involves a full spec revision. So rather than hold up the simple one waiting
for the complex one, I've split them.
One thing that was brought up way back in the early DKIM years, but dropped
then as unimportant, was the idea that Authentication-Results needs a way to
specify which signature a DKIM result is conveying. Since more than one
signature might be on a message from the same domain, we can't rely on
"header.d" and "header.i" to be able to make this distinction.
For example: A message comes to you with two signatures, both from the signer.
The only distinction is that one signature has an "l=" tag and one does not.
The message was altered by a mailing list. Therefore, the signature with "l="
passes when you try it, and the other one fails. You create a compliant
Authentication-Results: header field to add to the message. With the current
specification, the best you can do is say "dkim=pass header.d=example.com;
dkim=fail header.d=example.com" and perhaps rely on signature order to match
them up.
I propose that we need a new tag, "header.b", which will contain the first
several characters of the actual digital signature, which is pretty much
guaranteed to be unique among signatures present. This will allow unambiguous
matching of signatures with results.
I have this now in a draft that I plan to move through the Applications area of
the IETF as an individual submission since it's fairly minor:
http://datatracker.ietf.org/doc/draft-kucherawy-authres-header-b/
Comments welcome.
-MSK
--- End Message ---
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html