[ietf-dkim] mutant message validation, was Base issue: multiple linked signatures

[Michael Thomas]

Wietse Venema wrote:
> John Levine:
>   
>>>>> From my perspective having a message have a valid signature with one
>>>>>           
>>>> implementation and having a broken signature with another is an
>>>> incompatibility.  I don't think that's speculation. ...
>>>>         
>>> No, it merely reflects a difference of opinion by the sites concerned as  
>>> to what changes it will tolerate in a message before it recommends to its  
>>> clients that the message should be dropped. It is not the job of our  
>>> standard to dictate local policy issues at that level of detail.
>>>       
>> I agree that we are not dictating local policy.  But I really think that
>> it's our job to dictate the definition of what the signature validation
>> algorithm is.  As I've said before, everyone remains free to do whatever
>> they want with messages whether or not the signature verifies, including
>> applying various heuristics to develop opinions about unsigned messages.
>>     
>
> Perhaps some people are confusing verification and presentation.
>
> Verification: it is critical that all DKIM verifiers agree on what
> is a valid DKIM signature, without falling back on heuristics, such
> as heuristics to repair messages.
>
> Presentation: after the valid/invalid decision is irevocably made,
> it is up to application/policy to decide how/if things will be
> presented to users.  Heuristics of various sorts can be useful in
> this domain, such as message repair, known signer associations,
> etc., but those heuristics must not determine the validity of the
> DKIM signature.
>   
I really don't understand all of this hand wringing about True Verification
vs. Mutant Verification Intent on Taking Over Earth. The protocol document
needs to be precise about what it takes for a properly written verifier to
verify a properly signed message. That's it. Trying to make normative any
or all of the ways _not_ to verify a signature is not only a waste of 
time, it's
a hopeless task. Having informative text to guide implementors with
potentials gotchas, corner cases, and other possible misinterpretations 
is fine
to a point, but making them _normative_ makes no sense whatsoever.


       Mike