From: Damon [mailto:deepvoice(_at_)gmail(_dot_)com]
On 8/29/06, Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
The requirement that I believe that the delegation
discussion highlights is the need for controlled delegation.
I.E I delegate to Fred the ability to sign on behalf of
marketing(_at_)example(_dot_)com but not ceo(_at_)example(_dot_)com(_dot_)
+1
Are we going to specifically disallow fred the ability to
sign for ceo(_at_)example(_dot_)com by policy or say that fred can only
sign for marketing(_at_)example(_dot_)com?
Regards,
Damon Sauer
The principle of least privillege would argue for the second.
According to my scheme:
1) Each key record is a policy statement that specifies an allowable signature
key.
2) The policy record only states that there should be a DKIM header.
So the key record selector is always in the signer's own domain.
The key record MAY reference a delegation selector in the purported sender
domain which MUST in turn delegate authority back to the signing key record.
Alternatively the link that claims the right to sign on behalf of another party
could be carried in the signature header itself. This approach has the
advantage that the recipient can immediately identify the signature header they
need to verify to check for policy compliance.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html