[ietf-dkim] Alternative text for semantics of multiple signatures

Bill.Oxley at cox.com Bill.Oxley at cox.com
Tue Apr 4 13:44:37 PDT 2006


I like this version

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
bill.oxley at cox.com 

-----Original Message-----
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Michael Thomas
Sent: Tuesday, April 04, 2006 4:09 PM
To: Paul Hoffman
Cc: ietf-dkim at 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



More information about the ietf-dkim mailing list