Hmmn, I'm starting to see the depth of the disconnect here.
DKIM iss a security protocol that allows a signer, identified by its
domain, to take responsibility for a message. But it appears that you're
also seeing it as a way for a signer or a sender to attach a grabbag of
assertions to a message.
To reiterate a point I made a message or two ago, since senders are all
hostile and incompetent until proven otherwise, the only reasonable way to
treat such assertions is to assume that they're all self serving lies
and/or mistakes. If you know you trust the signer, you may be able to
believe the other assertions, but even if the signer is honest, they may
have unfortunate security consequences, e.g., l= can let bad guys add
extra MIME sections if the message isn't carefuly crafted to prevent that.
Requiring a modification to the verifier to support a new tag/value that
is not intended for its consumption is unnecessary and inhibits
deployment of new DKIM extensions.
Right, it's a security protocol. Making random changes to a security
protocol is widely seen as a Bad Thing. Maybe in the future we'll agree
that there is other stuff that might be good to pass with the signature,
but at the moment, we have no such agreement, and the right way to extend
a security protocol is to design the extention and go through the usual
review process, not just do ad hoc hacks that seem like a good idea at the
time.
Also, please don't forget the as-if rule. If you want to experiment with
DKIM, you can write your code any way you want, so long as its external
behavior matches the spec. If you want your local verifier to export
field names and signature length mod 17 so you can do experiments, that's
fine, go right ahead. But the spec as I read it says that all that's
exported is the signing identity, and that's all a conforming
implementation not doing an expriment should use.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html