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