----- Original Message -----
From: "John Levine" <johnl(_at_)iecc(_dot_)com>
Right. So the question is, can a signature be constructed
such that it doesn't interact with SSP to infer a binding
above and beyond "I claim it passed through me"?
I'm increasingly getting the impression that we don't
really understand the semantics of SSP. If a domain uses
SSP to say that it signs everything, and a message from that
domain has both the domain's signature and someone else's, is
that OK? I can easily imagine interpretations of SSP that
would go either way.
Here is the current proposed policies:
NONE (no policy)
o=? WEAK (signature optional, no third party)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
Note: WEAK proposed by Arvel.
For the given above condition, the DKIM VERIFER would only allow it if
the domain declared a STRONG (o=-) policy.
In addition, the SECOND signer (someone else's) or 3rd party signer
(3PS) was allowed to sign it as a 3rd party only because the Original
Address (OA) domain allowed it.
So the 3PS needs to check the OA policy as well if it wishes to resign
it, otherwise it will fail at the final DKIM verification.
This chart should help see the process.
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verification against SSP.
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER | NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | | |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | warn | accept | reject | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn | warn | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL 3PS | reject | warn | warn | reject | reject | warn |
+------------------------------------------------------------------+
Note, the above is not a suggestion on how a system should behave but
rather showing the logical conditions that must exist when the protocol
is consistently followed 100%.
As you can see, there are some hard accept/reject deterministics
conditions that can be followed both automated signers and verifiers.
There are the ACCEPTS and REJECTS.
There are also the indeterminates too, which I labeled as WARN.
Example readings of table:
Never Column. The NEVER column must be all rejects.
Exclusive column. The old time that should be a ACCEPT is with a VALID
(PASS) signature from the original domain. Any attempt by 3rd party
Signer (3PS) PASS or FAIL should be a REJECT. If the verify fails,
then is labeled WARN because we don't know why it failed. I believe
others has suggested that should be a REJECT, I agree too.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org