ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Output summary

2011-04-28 17:50:53
-----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
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.  The reverse, however, is not a constraint; an assessment module that 
knows it's consuming DKIM output is allowed to know something about what's 
coming up from below.  That's consistent with the idea that such a layer knows 
DKIM only validates header fields from the bottom up.

If you're adding DKIM to an application, it doesn't seem a layer violation to 
me to understand and apply what it's telling you, provided it's well-documented.

As another example, your web browser chooses how to render pages by parsing the 
content it's given by the TCP stack and applying it accordingly.  The transport 
layer doesn't know anything about the data it's handing up the chain, but the 
layers sitting on top of it do have some idea of how to make proper use of it.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html