[ietf-dkim] Delegating responsibility: a make vs. buy design
decision
Wietse Venema
wietse at porcupine.org
Fri Aug 18 12:14:13 PDT 2006
Damon:
> On 8/18/06, Wietse Venema <wietse at porcupine.org> wrote:
> > Damon:
> > > > In (1) the public key is listed under the author's domain, while
> > > > the secret key is operated either by 1a) the author's MTA or by
> > > > 1b) the signing party's MTA. This is what I called a first-party
> > > > scenario above. The verifier can't distinguish between 1a) and 1b)
> > > > except by parsing the contents of Received: message headers.
> > > >
> > > > In (2) the public key is listed under the signer's domain, and the
> > > > secret key is operated by the signing party's MTA. There is no
> > > > relationship between author-domain and signing-domain. This is what
> > > > I called a third-party signature above.
> > > >
> > > > In both (1) and (2) an assessment can be made on the basis of the
> > > > the signing-domain. If I get mail with a signature from some no-name
> > > > signing domain, then the author-domain (rfc822.from) is mostly
> > > > irrelevant. And if I actually do have reasons to trust the
> > > > signing-domain, then the author-domain is mostly relevant in case
> > > > (1), and mostly irrelevant in case (2).
> > >
> > > Wietse,
> > > Thank you for the clearest definition I have seen to this point.
> > > What is the mechanism for depreciating (2)?
> >
> > In case (1), when the trusted signer-domain matches the author-domain,
> > I might trust that the mail actually originates from the rfc822.from
> > domain. In case (2), when the trusted signer-domain is not related
> > to the author-domain, I might trust that mail was distributed by
> > the mailing list that I subscribe to, or that it was processed by
> > the malware removal service that I subscribe to. Thus, in (2) the
> > author-domain (rfc822.from) is relatively unimportant compared to
> > the signing-domain; even in (1) its importance is only secondary.
> >
> Wietse,
>
> But this takes away my control over who can sign for me.
> In my opinion there _must not_ be a way for someone to sign for _me_
> without my approval.
I think it is a mistake to attach significance to the author-domain
(rfc822.from) unless there is a reason to trust the signing-domain
for this purpose (for example, scenarios 1a or 1b above).
Wietse
More information about the ietf-dkim
mailing list