ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue 4871bis - DKIM Definition Separation of domains conflict

2010-08-18 01:15:29
Douglas Otis wrote:

I don't think a reference to POLICY needs to be made, but 
only focus on the idea that the LAST SIGNER is the 
responsible party.

What conclusions would you draw from the last signer, when 
there is also a valid Author Domain authorized third-party 
signature?  It seems wrong to suggest there would be 
great significance in the last signature added.

The last DKIM (re)signer message handler is the final arbiter of the 
next handler DKIM message verification result.  With 4871bis, it (last 
handler) has complete and as the 3rd sentence implies, unrestricted, 
control over the absolution of any previous single or collective 
domains responsibility.

Lets restate the 3rd sentence:

     DKIM separates the question of the identity of the signer
     of the message from the purported author of the
     message.

First of it, it DOES NOT separate any "question" because the 5322.From 
header is a required DKIM hash binding and hence it is always bound to 
any and all signatures.  As long as the 5322.From binding is a 
requirement, there is always an association with the signer and the 
original AUTHOR.

Second, I think we can all understand the historical perspective why 
the 3rd sentence exist, to break away from POLICY driven resigning 
restrictions.

This is an inherent subjective POLICY and I believe it needs to be 
noted the long required multi-protocol synergism necessary to engineer 
DKIM properly, not only for POLICY for Reputation based models, needs 
to be considered in 4871bis.

So if we don't want 4871bis to be specific, it needs to at least 
remove any semantics that suggest 4871bis has no signing restrictions.

The only way to truly "separate the question" of the signer and author 
domain, is to remove the DKIM requirement to include the 5322.From 
header in the bind.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


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

<Prev in Thread] Current Thread [Next in Thread>