ietf-dkim
[Top] [All Lists]

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

2006-04-04 13:54:07
I like this version

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
bill(_dot_)oxley(_at_)cox(_dot_)com 

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

<Prev in Thread] Current Thread [Next in Thread>