From: "John Levine" <johnl(_at_)iecc(_dot_)com>
What I am mostly seeing here is that we don't have a clear model of
the ways that people will use multiple signatures. Let's say your
message has three sigs from Able, Baker, and Charlie (in that order if
you care about order.) Able and Charlie verify, Baker doesn't. Now
what do you do?
First, I would say the order is how they are prepended.
ABLE
BAKER
CHARLIE
To move away from this would be silly.
Second, at the very least, the original (first) signing (CHARLIE) should be
the most important one. Once the first original signature is not verifiable,
everything else is now suspicious for whatever reason, most likely being
broken integrity. So the original signature is the most important one.
Third, it depends on the reason why BAKER fails. This is where SSP
verification comes into play.
Did BAKER fail because of signature itself failed or because the SSP
indicated no 3rd party Signing is allowed?
Is SSP verification in play (which I believe is requirement, not an option),
and BAKER failed because its SSP says NO 3RD PARTY SIGNING allowed, then we
have a reasonable action to take or work with.
If it failed due to broken integrity, and the last signing (ABLE) was
verified (and SSP verified as well), then this *should* fail into the
"warning" category.
I refer people back to the DKIM Verification State table I presented a few
months ago which provides all the theoretical states and possible action to
take.
Verify Results:
NONE - No signature in mail
PASS - Good Signature, Original Address Signer
PASS 3PS - Good Signature, 3rd party Signer
FAIL - Bad Signature, Original Address Signer
FAIL 3PS - Bad Signature, 3rd party Signer
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 |
+------------------------------------------------------------------+
I believe this applies at all levels for each signature.
The point is, assuming any ABLE, BAKER and CHARLIE is OK signature wise, if
any SSP says it has an EXCLUSIVE policy, then we know we have a SUSPICIOUS
message here regardless of how many signatures we have and whether the
signing fails or not.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org