[ietf-dkim] Output summary

[Dave CROCKER]

On 4/28/2011 2:47 AM, MH Michael Hammer (5304) wrote:
>> Mike, I believe you are continuing to different parts of the architecture.
>>
>> The DKIM verifier does not know anything about the "type" of the signature,
>> such as whether it is first party or third.  An architectural function
>> that is outside of DKIM signing makes those sorts of higher-level,
>> integrative analyses.
>>
>> The current discussion is only about signature validation and how to report
>> them.
>
> I understand that Dave. My point is that if we follow the logic that John
> laid out and we end up with outcomes that leave one scratching their head,
> there is a potential issue. We have been round and round the block on the 1st
> party vs 3rd party issue but this specific point is in the context of
> multiple signatures on a single message rather than the general discussion of
> evaluating a message with a single signature.

Mike,

With respect, I believe you do /not/ understand the architectural point at issue 
here.

The confusion that you are experiencing is between the component of the system 
that validates and reports signatures, versus other components that evaluate 
additional aspects of signatures, such as the correlation of the SDID with other 
identifiers in the message..

The fact that the current discussion is about multiple signatures does not 
change the scope of DKIM Signing, nor does it change the fact that correlation 
with other identifiers is outside the scope of DKIM Signing.

I believe that the core confusion here is a tendency to think only in terms of 
the whole system rather than being able to isolate aspects of the system into 
components.

Nothing in the current discussion prevents:

    a) other parts an implementation to make correlations

    b) specific implementations from reporting more information that is 
specified formally for DKIM Signing.  (The only issue with reporting more is 
making sure that no one believes that both sides of the signing process will 
know about these extensions.)


>> To make this more direct:  For DKIM signing, there is no such concept of
>> "From domain signature".
>>
>> The issue for payload at the level of DKIM Signing, the issue needs to be
>> kept quite simple:  Report signatures that validate and I guess also
>> report signatures that get a temporary failure.
>>
>> No other formal payload comes out of the DKIM Signing spec, no matter what
>> other sorts of cleverness a particular implementer might provide.  The
>> cleverness is fine, but it goes beyond the spec.
>
> That's what I said. Report the domain and the outcome for each signature and
> leave something else to sort things out. Don't try and do it within DKIM
> itself. The decision choices by that something else could be based on
> reputation or authoritative assertion, or a combination of the two. I was
> simply responding to the choices within DKIM that John was laying out.

If, by this, you mean report validation failures then you are trying to change a 
core aspect of DKIM.  The reason for treating verification failures equivalent 
to the absence of a signature is a fundamental feature of DKIM.  We should not 
have to re-discuss that issue.

Again, a particular software implementation might choose to do more, but the 
formal DKIM Signing specification MUST NOT.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net