ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Reading the entrails, was Moving to consensus

2009-03-22 20:45:17
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.

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.)

It's fine to do experiments and fool around with signatures and verifiers 
and assessors any way you want, and to propose updates to standards based 
on the results of the experiments.  But operations and experiments are 
different.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>