We've still got a fairly basic disconnect here.
The verifier doesn't need to do anything with the additional field, so
if it just passes all unknown fields to the assessor it doesn't need to
change at all.
OK, so you're saying that the verifier should consume the fields it knows
(let's say the fields listed in 4871), and pass along the unknown ones.
But a couple of messages ago you said that the assessor should look at the
existing h= value to see if an auxiliary header is signed.
It's not my goal to tie you in knots here; I'm trying to figure out what
you have in mind. Expecting on people who read the spec to interpret
vague sections in ways we approve of is not likely to lead to happy
results. Perhaps Dave can offer a few RFC 822 horror stories here.
Requiring the verifier to change in order to support a new tag/value
introduces a significant barrier to the deployment of new tags. ...
The DNS analogy doesn't strike me as a useful one here. Nearly everything
in the DNS except for SOA and NS is intended for the consuming
application*, but everything in DKIM beyond the signing identity is
intended as ingredients for a complicated recipe producing one bit**,
signed or not. The more stuff you allow the assessor to peek at, the more
you encourage people to invent bogus "more signed" or "almost signed"
heuristics that will make it harder to interoperate reliably.
The fact that there are silly things that a verifier could pass to an
assessor does not convince me that there aren't any useful ones.
There may well be useful ones, but the way to make systems that
interoperate is to document the useful ones and forbid everything else,
not to allow everything and have the rule be "don't do anything that Jim
thinks is silly."
R's,
John
* - Even in DNS, leaking internal info is bad. Remember the arguments we
had about SOA based tree walks for SSP, enabled by the partial leakage of
internal DNS zone cut info to clients.
** - disregarding l= which should be a poster child for what not to do
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html