James Scott wrote:
Jim Fenton wrote on: 21 July 2005 11:37 a.m.
1. What signatures are required? None, third-party, or first-party
(From: address) only?
The current "o=-" policy specification allows signing by third parties
without restriction. This appears to open the way for any person to send
properly signed messages without any authorisation to use the particular
RFC2822 "From:" address.
DKIM does not assume or enforce a relationship between the signing entity
(specified by the "i=" flag in the signature field) and the message
originator (RFC2822 "From:" or "Sender:" field). This is left to the policy
of the message originator.
It also depends on the policy of the message verifier. A relationship
between the i= value and some other header field asserts the role of the
signer. But it is a fallacy to assume that such a relationship provides
any extra security: the third party is capable of adding or changing
header fields before signing the message, so the third party's address
can be made to match the Sender, Resent-From, or List-ID header field
(for example), even if they're not really, say, a mailing list.
It would therefore seem useful to be able to specify a policy that allowed
*SOME* third party signatures, but did not allow an arbitrary third party to
sign. Neither of the "o=-" or "o=!" policies appear to permit this.
Is there a practical way to specify a third party signing policy that
restricted valid signatures to a subset of all possible third parties?
Third party signatures will probably end up having a bigger dependency
on reputation/accreditation than first-party signatures. The
"reputation" might be local as well: I could whitelist messages signed
by owner-ietf-mailsig(_at_)imc(_dot_)org because I know it's really a mailing list
I subscribe to.
In other situations, one would want to make the signing address visible,
but that's a very MUA-dependent proposition.
-Jim