On 8/18/06, Wietse Venema <wietse(_at_)porcupine(_dot_)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. In this example you are showing what (1) might do
if they receive email from (2) which has nothing to do with the (1)
and has everything to do with (2). Having said that, there should be
no relationship between (1) and (2) in this example. Trusted or not
trusted... You are mixing the receiver and the sender policies.
Damon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html