Actually I interpret the message you cited as supporting the current effort to
declare that the required output is "d=" plus success/TEMPFAIL, while also very
clearly stating that a DKIM verification module is certainly within its rights
to provide more than that.
Indeed, OpenDKIM makes a ton of information about the message and signatures
available to the caller, so it would be fairly hypocritical for me to be saying
"don't do that" while doing it myself.
But I don't think the current language encourages any specific next-layer
applications, nor does it discourage any. The DKIM key and signature tag sets
were deliberately made extensible, and so too is the proposed mandatory output
description. If someone were to invent a policy or reputation or other
evaluation mechanism that requires the AUID, then one could either create a
DKIM validator that provides it to that module (which would still be fully
compliant with RFC4871bis), or one could create a "DKIM+" defined in that way
and publish that specification.
The strict layer separation you're talking about would prevent some systems
from working. DNS, for example, alters the way it behaves based on whether the
layer below it is TCP or UDP; it has to, because the two transport mechanisms
have distinct properties. If you accept that, then it's also OK for an MUA to
understand that a validated DKIM signature definitely included the lowest of
the From: fields in its header hash, even if many were signed.
-MSK
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Friday, April 29, 2011 4:27 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary
On 4/29/11 12:48 AM, Murray S. Kucherawy wrote:
-----Original Message-----
From: Rolf E. Sonneveld
[mailto:R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl]
Sent: Thursday, April 28, 2011 2:12 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org<mailto:ietf-dkim(_at_)mipassoc(_dot_)org>
Subject: Re: [ietf-dkim] Output summary
b) If an application is presented two different From: fields and
handed them to DKIM, and the signature passes, the bottom one is the
one that was signed. We verify from the bottom up specifically to deal
with the case where a message has "m" signed instances but "n" total
instances, where "m" is less than "n".
Right. But this is DKIM logic, 4871bis. By not specifying the address in
the output, it means that the upper layer application needs to follow
the DKIM spec (4871bis) in order to be able to determine which From
address it should use for whatever function it provides (e.g. determine
1st vs 3rd party signature or determine whether something is an author
domain signature). In other words: by not specifying this type of
information in the output of DKIM we create a layering violation, as the
upper layer needs to be aware of the way DKIM deals with this kind of
situation. Or we rest with a situation where all sorts of functionality
in layered applications will never be developed, as the required
information is missing.
Layering design stipulates that the lower layers don't depend on the upper ones.
Don't get me wrong, I just wanted to demonstrate that, IF we follow the logic
of not crossing protocol boundaries strictly, THEN communicating the d= payload
/without additional information/, we
* either enforce upper layers to violate layers or
* in advance we discourage in advance the design and development of a number
of useful applications that otherwise could have been built on top of DKIM.
In the archives I found exactly this same concern and discussion, see for
example the contribution of Jim:
http://www.mail-archive.com/ietf-dkim(_at_)mipassoc(_dot_)org/msg11105.html
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html