Subject: RE: [ietf-dkim] Itemized Summary of SSP Requirements-00

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Aug 2006 12:11:33 -0700

> From: Damon [mailto:[email-masked]] 

> On 8/29/06, Hallam-Baker, Phillip <[email-masked]> 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 
> [email-masked] but not [email-masked].
> >
> 
> +1
> 
> Are we going to specifically disallow fred the ability to 
> sign for [email-masked] by policy or say that fred can only 
> sign for [email-masked]?
> 
> 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

---

From: Jim Fenton <[email-masked]>
Date: Tue, 29 Aug 2006 13:27:52 -0700

> The principle of least privillege would argue for the second. 
Is there some reason we don't use the delegation mechanism in -base to
accomplish this?  Presumably Example Corporation has the ability to
publish delegated key records for itself.

-Jim