[ietf-dkim] Itemized Summary of SSP Requirements-00

[Hallam-Baker, Phillip]

> From: Douglas Otis [mailto:dotis at mail-abuse.org]  
> On Aug 29, 2006, at 11:28 AM, Damon wrote:
> 
> > On 8/29/06, Hallam-Baker, Phillip <pbaker at verisign.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.com but not ceo at example.com.
> >
> > +1
> >
> > Are we going to specifically disallow fred the ability to sign for 
> > ceo at example.com by policy or say that fred can only sign for 
> > marketing at example.com?
> 
> 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 sales at example.com

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=sales at example.com" 
_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.