[ietf-dkim] Revised proposal for specifying syntax and semantics for multiple signatures

[Paul Hoffman]

Revised to:

- remove verification passthrough
- change the canonicalization to what is being used anyway
- removed the ordering requirement
- softened the wording about bid-down attack

---------------------
Summary:
A sender signing a message that already has one or more DKIM-Signature
headers keeps the earlier headers and signs over them.

---------------------
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.

---------------------
Changes:

Add to section 3.5:

	p= Earlier signatures (plain-text; REQUIRED if there is already one
	or more DKIM-Signature headers in the message). This tag lists the
	hashes of the DKIM-Signature headers that exist before this
	DKIM-Signature header is added. The hash is computed using the hash
	algorithm that is used in the signing algorithm (taken from the "a="
	tag), using same header canonicalization on the DKIM-Signature
	headers as is being used already. The order of the hashes is not
         significant.

	sig-p-tag = %x70 [FWS] "=" [FWS] sig-p-tag-hash
	                   0*( *FWS ":" *FWS sig-p-tag-hash)

	sig-p-tag-hash = base64string


Change in the "h=" description of section 3.5:
OLD:
	The field MUST NOT include the DKIM-Signature header field that is
	being created or verified.
NEW:
	The field MUST NOT include any DKIM-Signature header field.

Change section 4 to read:

	4.  Semantics of Multiple Signatures

	A signer that is adding a signature to a message inherently signs
	all DKIM-Signature headers that exist in the message before the new
	signature using the "p=" tag. If a single signer adds multiple
	signatures, such as using different signing or hashing algorithms,
	each signature stands on its own, meaning each signature covers all
	of the previous signatures, even ones from the same signer.

	A signer applying multiple signatures with different signing
	algorithms SHOULD first sign with the signer's most-preferred
	algorithm, then with the next-most-preferred, and so on. This ordering
	prevents an attacker from removing more-preferred signatures from a
	message without the recipient being able to detect the removal. Note
         that the recipient MAY ignore such removal, such as if the recipient
         is satisfied with the strength of the remaining signature(s).

	Signers MUST NOT remove any DKIM-Signature headers from messages
	they are signing, even if they know that the headers cannot be
	verified. Doing so would break the chain of signatures.