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

[Dennis Dayman]

I'm good with this.

-Dennis
 

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