[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