On Tuesday 01 August 2006 10:56, Michael Thomas wrote:
Dave Crocker wrote:
Tony Hansen wrote:
Dave Crocker wrote:
Alas, it was pointed out to me that SSP does indeed have a requirement
for a lookup even when the message is signed. This is when there is
so-called third-party signing. (I believe this means when the domain
in the rfc2822.From does not make the DKIM d= domain.)
I would at a minimum include rfc2822.Sender in this check: third part
signing is when the DKIM d= domain is not equal to either the
rfc2822.From's domain nor the rfc2822.Sender's domain.
Tony, et al,
Switching back to the 'requirements' suggestion I have been making:
I would like to see a scenario described that explains exactly what
problem needs to be detected and why it is a compelling, immediate
requirement.
I would like to see the description done in a way tht talks about
particular individuals and organizations, without referring to particular
protocol units.
In other words, I'd like to see the non-technical description of the
requirement and its rationale, before it gets translated into the
technical details, such as citing particular header fields.
Right, this would be enormously helpful I think.
Scenario 1:
1) A sends to B with a missing or broken DKIM signature
2) B would like to know whether that is an acceptable state of affairs.
Scenario 2:
1) C sends a message on A's behalf by having been delegated a selector by A
This is a normal -dkim-base usage scenario, but there are some deployment
related issues related to how the delegation is done. What are the
requirements
from that?
Scenario 3:
1) C sends message on A's behalf using C's identity
2) B would like to know if C's signature has any relationship to A
This is the "ISP" scenario discussed on the list often. It has scaling
issues
naively because the number of acceptable third party signers for A may be
large, and perhaps troublingly not uniform in the trust of the third
parties.
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message rejections for
messages that don't carry a valid signature by A (or a designated third
party) than to have messages that are unsigned or signed by other parties
delivered.
2) C sends message on A's behalf using C's identity.
3) B would like to know if C's signature has any relationship to A.
4) If C's signature does not have a relationship to A, then A prefers that the
message not be accepted for delivery (note that I say prefers because I
understand we can't mandate receiver policy).
This is only a variant of #3 and not an entirely new scenario. It's intended
to highlight was Stephen referred to as an expected signature missing.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html