John R. Levine wrote:
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.
If you remember, I started out using Jon Callas's suggestion of adding a
header field and signing it, and you and I agreed that a better approach
is to add a new tag/value instead. So now I'm discussing the use of a
new tag/value, and not h=. 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.
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.
We may agree to disagree whether existing DKIM fields are useful to the
assessor, but DKIM is extensible and I can think of several things (one
of which is described in draft-fenton-dkim-reputation-hint) that might
be included in the signature and are specifically intended for the assessor.
The DNS analogy points out that there's a problem with APIs that
unnecessarily restrict information about unknown RR types, as there is
with unknown (to the verifier) tag types.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html