> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Delany > On Tue, Feb 28, 2006 at 11:06:35AM -0800, Jim Fenton allegedly wrote:
> I'm all for supporting multiple signatures in the first DKIM > standard simply to give us some chance of avoiding that > disaster. That way I can configure a subset of my outbound to > generate two signatures using different hashes, just to catch > bugs in the early stages of deployment. I agree emphatically with Mark. I believe that the best way to do this would be to introduce a signature counter so that the order of signing can be recovered even if a message has its headers reordered. The rules for signing then become: If the message to be signed contains a signature header the signer must include a counter attribute in the signature scope that has an integer counter value that is greater than all the counter values present in all othe signature headers present in the message to be signed. A good way to test this out before we need to use it for rolling algorithms would be for people to test for the case where there are multiple signatures from different signers. A verifier needs to be able to avoid being confused. The simplest (but not necessarily the best) non-confusion algorithm being to look at only the signature with the highest counter value. This is always going to be the message with the highest probability of verifying correctly. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
