I'm good with this. -Dennis
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thomas > Sent: Tuesday, April 04, 2006 3:09 PM > To: Paul Hoffman > Cc: ietf-dkim@mipassoc.org > Subject: [ietf-dkim] Alternative text for semantics of > multiple signatures > > [transmogrified from Paul's original text] > > > Rationale: > > Signers need a way to attach multiple signatures when transitioning > > from one signature algorithm to another, when transitioning > from one > > hash algorithm to another, and even from one protocol > version to another. > > Further, there are many scenarios where a sender is forwarding a > > message that is already signed, and wants to add its own > signature. > > This can be done in a way to allow parallel signatures > during transitions. > > Change section 4 to read: > > 4. Semantics of Multiple Signatures > > A signer that is adding a signature to a message merely creates > a new DKIM-Signature header, using the usual semantics of the > h= option. A signer MAY sign previously existing DKIM-Signature > headers using the method described in section NN to sign trace > headers. Signers should be cognizant that signing DKIM-Signature > headers may result in signature failures with intermediaries that > do not recognize that DKIM-Signature's are trace headers and > unwittingly reorder them. > > When evaluating a message with multiple signatures, a receiver > SHOULD evaluate signatures independently and on their own merits. > For example, a receiver that by policy chooses not to accept > signatures with deprecated crypto algorithms should consider such > signatures invalid. As with messages with a single signature, > receievers 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 receiver. > > Signers MUST NOT remove any DKIM-Signature headers from messages > they are signing, even if they know that the headers cannot be > verified. > > Mike > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
