Murray S. Kucherawy wrote: >> I have trouble with the 3rd separation sentence and the potential >> ignorance it presents by breaking the original responsible party. >> >> What is the actual question does it separate? >> >> An association between the purported author and the signer? >> Is an authorization question? >> Does it absolve the responsibility of the original domain signer?
> The sentence is meant to make explicit the fact that the author > of a message and the signer of a message are not necessarily the > same thing. So I guess then the first of your three examples is > the right one. Which implies the 2nd and 3rd? But consider, if the 5322.From is a required DKIM signature binding requirement, including for all collective signatures, there will always an association that can not be removed. So I can only see that this is an attempt to remove a possible recognized association, remove any signing restrictions by ignoring any possible unauthorized signing restriction and by absolving any previous single and/or collective signer responsibility. >> I don't think the raw DKIM-base document should be making any >> conclusion about that it intends to separate or absolve by moving the >> responsibility to that of the signer. > > But the signer (d=) is the only provable entity on a signed > message. This was what was said in the update draft as > well (RFC5671). I don't follow. 5322.FROM is a required binding. While d= is the domain required for verify, the 5322.From is bound to it as a provable entity as well, i.e - you can't change it. >> By having it, it implies that those using the DKIM-BASE >> implementation can effectively 100% ignore the original >> responsible domain own signature without technical and even >> possibly legal repercussions. > > I think the problem is that terms like "original responsible > domain" are undefined given that there are no assurances > of the validity of any other part of the message. If you mean > the From: field domain, that domain may or may not match "d=" > even if there's a plurality of signatures. Does "Previous Single or Collective Responsible signing domains" help better express the concern? >> 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. > > I don't think that's necessarily a correct assertion. If a > message has four valid signatures on it, then four parties > have accepted some responsibility for the message. The From: > domain doesn't need to match the "d=" on any of them. I can understand the historical perspective why the 3rd sentence is there as a statement to remove any non-authorized 3rd party signing by DKIM-CORE. But please note this is not a ADSP policy concern, but also REPUTATION, including MLM issues since we are trying to give it a "DKIM Permission Slip" to not only absolve all previous single or collective responsible signing domains, but also break any bound "entity" used to couple policy and trust concepts from previous responsible resigner(s), and it can do so as a whole or selectively. It is the final arbiter. So even with future unknown reputation ideas, or with MLM with its List-ID proposals, or anything else down the pike, the concern is that it equally applies and in even more possibly undesirable ways - because 4871bis says not about these "entities." The 3rd sentence is an old idea that still based on the idea that POLICY would never emerge as a standard. It was a mentality that perpetuated the long time conflicts we had here. I believe we need to be honest about these conflicts if we wish to get any workable widely endorsed usage of this stuff. One doc that implies "ignore it" while we are still talking about DKIM Protective Wrapper technology, since to be counterproductive for a long time. So I all am just suggestion that we take the opportunity now with 4871bis to add compromising semantics that inform readers that SIGNING is not always desirable or the right thing to do and they should be aware of any current or future augmented DKIM related technology or functional specifications. -- 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
