> From: Douglas Otis [mailto:[EMAIL PROTECTED]
> On Aug 29, 2006, at 11:28 AM, Damon wrote:
>
> > On 8/29/06, Hallam-Baker, Phillip <[EMAIL PROTECTED]> 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 PROTECTED] but not [EMAIL PROTECTED]
> >
> > +1
> >
> > Are we going to specifically disallow fred the ability to sign for
> > [EMAIL PROTECTED] by policy or say that fred can only sign for
> > [EMAIL PROTECTED]
>
> 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 PROTECTED]
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 [EMAIL PROTECTED]"
_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
