John R. Levine wrote:
I agree that it is better to include this information in the signature
itself, which is why draft-fenton-dkim-reputation-hint does it that
way. But the constraints on the output of the verifier being proposed
would mean that the assessor can't depend on that additional tag/value
being available to it.
Right. You say this as though it's a bad thing, but as I've said
three times, constraining the interface is key to interoperating.
How does one "say that field is passed...to the assessor"? The
signer certainly can't, and it shouldn't be necessary to modify the
verifier to do that.
I'd do it by writing up an I-D and specifically saying what to pass to
the assessor. Unless you expect the assessor to make an end run
around the verifier, you're going to have to change the verifier
anyway to expand the set of stuff it exports.
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. Requiring the verifier to change in order to support a
new tag/value introduces a significant barrier to the deployment of new
tags.
Consider the case of DNS resolvers. Many resolvers can support new RR
types without modification, and for those resolvers the addition of new
RR types isn't a problem. However, a few resolvers do require
modification, and it is because of these resolvers that it is extremely
difficult to add a new RR, contributing to the need to overload TXT.
Let's not make the analogous mistake with DKIM.
Here's a list of things that a verifier might pass to the assessor:
* The number of fields in the DKIM-Signature header
* The order of the header names in h= field
* The number of headers in the message which are out of order relative to
their order in h=
* Whether the signature includes q=dns/txt or defaults it
* The number of characters in the DKIM-Signature header, mod 17
I hope you'll agree that it would be pretty stupid for the assessor to
depend on any of those. So, for a standard protocol, one where the
goal is to allow every mail system in the world to interoperate, where
do you draw the line for verifier outputs? If you want to
interoperate, you make it as small as possible, which means it's just
the signing domain in each valid signature. (If you use ADSP, there's
also two bits of ADSP output.)
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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html