On 8/16/10 1:35 PM, Hector Santos wrote: > 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.
Per the Abstract: "DKIM separates the question of the identity of the signer of the message from the purported author of the message." The AUID and the purported Author indeed are different identities within DKIM. However, any alleged separation is not absolute. The optional Agent or User Identifier (AUID) shares a parent domain with that of the signer. When the AUID matches with the purported author, it indicates the signature is on behalf of the author identifier. It still requires some Out-Of-Band signaling before any assumption of authentication or authorization is possible. In the case of authorization by the Author Domain through OOB signaling, DKIM allows name-based Author Domain assertions about authentication and/or source identifiers. > I propose that a better wording be used or even removal of the 3rd > (separation) sentence in entirety. I think the first two sentences are > good enough. Its pretty straight forward - the signer is responsible. Agreed. The sentence is a bit overly broad. > 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. > > If ASDP is going to happen or have any hope of happening, DKIM-BASE > needs to have some semantics that this separation is not CUT and DRY. Agreed. But any conclusion drawn, especially from third-party signatures, needs to depend upon OOB signaling. > 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. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
