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