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

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

> From: Douglas Otis [mailto:[email-masked]]  
> On Aug 29, 2006, at 11:28 AM, Damon wrote:
> 
> > 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]?
> 
> Such granularity will be difficult to administer and resolve.   
> Message annotation can help resolve this issue by allowing 
> for a "direct" affirmation versus "indirect".
> 
> When the "indirect" annotation is used, the identity of the 
> signing party should become visible in some manner to be part 
> of the trust relationship.

Whether we put the information into the key record or the message header is not critical. I agree that there are benefits to putting the information in the message header.

> It is even possible there is greater trust in the signing 
> party than there is in the email-address. : )

True, but irrelevant for the purposes of policy compliance.

Lets work through a more concrete example. Let us imagine for a moment I am going to use a hosted Webmail provider, lets call it Vmail.

Unlike other hosted mail providers this one is going to allow me to use my own domain name. I am going to buy my domain name service from another party, DNS-outsorce.com

It seems to me that the only information flows that should be necessary at the user level are as follwos

ME to DNS-outsource.com
	My email provider is Vmail.com, delegate signing authority to them for the email address [email-masked]

ME to Vmail.com
	I want you to sign messages on my behalf

So DNS-outsource.com creates:

example.com                     MX   1 1 mail.vmail.com    [1]
delegate._domain.example.com    TXT  "delegate=vmail.com address=[email-masked]" 
_SSP.example.com                TXT  "DKIM"

Vmail.com already has MX and key record:

_mailsend.vmail.com             SRV 1 1 25 mail.vmail.com   [1]
key._domain.vmail.com           TXT  "key=23897293847982374qwir=="

Vmail.com adds signature records of the form

DKIM-Signature: signer=vmail.com selector=key pp=example.com ....

Note [1]: we can use the SRV record for service discovery here and avoid the need for mail configuration.

Using this scheme we achieve the following

1) All instructions map directly to commands.
2) I have delegated exactly the degree of signature capability that I want and no more.
3) My administration procedures are completely decoupled from those of Vmail.

This approach is much more robust as it allows us to deal with corner cases such as the one where the sender does not have DKIM support and is going to have to put in a NULL header. In that particular case I really really have to ensure that the delegation of signature authority is limited and under my control.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 29 Aug 2006 16:33:22 -0400

I'm sorry, a correction to my question:

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> The delegation example is relevant because it is only the
> policy mechanism that creates the need to count a signature by
> Fred as a domain signature for example.com.

Ok, but you think it will still work or its consistent with the discovery
requirements 5.1.1 and 5.3.1?

| 5.1.1  [_] MUST use DNS RR TXT for Policy record.
| 5.3.1  [_] MUST use 2822.From domain only.

Or is this a DNS record preparation issue?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com