----- Original Message ----- From: "John L" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]>
>> 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 reorder them. 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 verifier. 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. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
