Wow, excellent message and good thinking here.
Or from a technical standpoint, we have a generic
"3rd party" situation when the:
"DKIM d=domain" IS NOT EQUAL to "ORAD"
Where
ORAD is the Originating Responsible Address Domain.
"3rd party" signing can come about through several mechanisms but mailing
lists come to mind immediately. If a mailing list signs a message and does
not change the FROM this is automatically a "3rd party" signing situation.
You'll have a message signed by a domain that does not match the ORAD.
It seems to me that a 3rd party signer needs to look
up the ORAD SSP to see if any 3rd party signing is
allowed in the first play.
Humm... interesting idea. This would make it the responsibility of the
signer to do the policy checking but it seems that this move wouldn't change
verifier requirements. The verifier can't assume that a "3rd party"
signature which it finds in a message was placed there by a signer that
played by the rules and did an SSP check first. Since this is the case,
might as well leave the responsibility on the verifier IMO. In other words,
since the verifier can't trust the signer and must do an SSP anyway why have
the signer go to this trouble? What do you think?
In short, it seems that signers need to take into
account the ORAD SSP before any signing takes
place to see if its allowed. If not, then we really
have PHISHING and SPOOFING problems.
Currently, when you allow third party signatures you can be phished and
spoofed. But this is no different than being phished and spoofed by not
using DKIM at all. Even if we changed the spec to say that signers must
comply with the SSP wishes of the ORAD, this does not eliminate the attack
vector because phishers and spoofers can just not do that and sign anyway.
So, verifiers must be responsible for SSP right?
This is an example of what Dave Crocker is always saying - that the
phishing/spoofing problems are more complicated than appears on the surface.
My own feeling on the "3rd party" signing issue, if you want to specify the
authorized "3rd parties", this needs to be done in the policy record. I'm
hoping there is something we're overlooking (like a mechanism that involves
just using a different selector or something entirely) to get around this
problem. It seems like there's a better solution but I can't grasp it.
--
Arvel