ietf-dkim
[Top] [All Lists]

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

2006-04-04 18:41:52
I'm good with this.

-Dennis
 

-----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 3: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