----- Original Message -----
From: "John L" <johnl(_at_)iecc(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
John wants to know how a 2nd signature could invalid an already valid
message. This is really based on a "Good Citizen" model where
everything is done correctly.
Actually, it's based on the model in draft-ietf-dkim-base-04.txt.
As always, concrete scenarios would be a great help to understand the
problems you believe exist. In particular, a concrete example of a second
signature invalidating a message without breaking the first signature
would be extremely useful since it would point out a major flaw in
dkim-base that nobody else is aware of.
First, this is why I suggested the requirement: SSP Must Follow DKIM-BASE,
because there is going to be alot of revisiting here based on what
requirements are set or excluded.
Second, I don't think you can find an example because you provided a perfect
scenario where everything was done right with a mindset where we have a very
loose interpretation of multiple signatures.
Third, Not so John. Many were aware of the multiple signature issues. You
probably missed this discussions.
Eric, Jim, myself and others, were very aware of the problems because it was
discussed in quite detail that help shape the loose semantics of Multiple
Signatures as altered in base-01. The semantics were changed because of the
vague issues of multiple signatures.
In base-04 it says:
4. Semantics of Multiple Signatures
Signers should be cognizant that signing DKIM-Signature headers may
result in signature failures with intermediaries that do not
recognize that DKIM-Signatures are trace headers and unwittingly
It also says:
..... As with messages with a single signature,
verifiers are at liberty to use the presence of valid signatures as
an input to local policy; likewise, the interpretation of multiple
valid signatures in combination is a local policy decision of the
Do we have a consistent set of local policies for everyone?
I also had a problem with this statement:
Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified.
Because this prohibits (limits) the list server from having fun in the DKIM
sand box. It didn't help my list server change designs. It makes things
harder and to ignore it does not help address survibility issues.
But it is also flawed because it presents a high potential for failure for
the verifier to question. This we can demonstrate with Domainkeys in the
wild. Nearly all of this coming from what seem to be mailing list, fail.
You really need to read that interesting thread where multi-sigs discussed
in quite detailed with pseudo-code illustrations.
Also consider this:
6.1 Extract Signatures from the Message
A verifier SHOULD NOT treat a message that has one or more bad
signatures and no good signatures differently from a message with no
signature at all; such treatment is a matter of local policy and is
beyond the scope of this document.
When a signature successfully verifies, a verifier will either stop
processing or attempt to verify any other signatures, at the
discretion of the implementation.
Again, Local policies questions. No clear behavior on how to handle
multiple signatures and its possble failures.
John, the whole point here is that you presented the result where the
message was 'perfect' but it was based on ignoring if the 2nd signer itself
violated any SSP policy. Was it suppose to resign?
Excluding the possibility of exclusivity to help define policies that local
system may follow in order to help and/or increase the survibility of the
DKIM signed message is not a very good idea.
Hector Santos, Santronics Software, Inc.
NOTE WELL: This list operates according to