Wietse:
I like this. This is very close to what I want: signed mail that
speaks for itself, whether it's first-party or third-party signed.
Dave Crocker:
and just to make sure *I* understand what you mean: mail signed by the
author,
or mail signed by an operator?
Wietse:
Whether the signing domain is the author's domain (1) or whether
the signing domain is an unrelated domain (2)
(1) Secret key with the author, or delegated to author's ISP.
(2) A mailing list operator, an operator that stamps mail as
"no known virus present", or some other transit service.
Dave Crocker:
right.
(1) uses a domain directly associated with the author domain.
(2) uses some other domain (that is associated with the operator doing the
signing.)
I see where the confusion comes from, namely the scenarios where
both (1) and (2) involve a third party.
To clarify myself a little further:
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html