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:[email protected]] Sent: Friday, April 29, 2011 4:27 PM To: Murray S. Kucherawy Cc: [email protected] Subject: Re: [ietf-dkim] Output summary On 4/29/11 12:48 AM, Murray S. Kucherawy wrote: -----Original Message----- From: Rolf E. Sonneveld [mailto:[email protected]] Sent: Thursday, April 28, 2011 2:12 PM To: Murray S. Kucherawy Cc: [email protected]<mailto:[email protected]> 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/[email protected]/msg11105.html /rolf
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
