Subject: RE: [ietf-dkim] Base issue: multiple linked signatures

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Jan 2007 09:18:37 -0800

> [mailto:[email-masked]] On Behalf Of Arvel Hathcock

> I believe the current text is meant to do (a) but the 
> "checking the signatures in any way" language implies (b).
> 
>    Verifiers MUST NOT use the header field names or copied values
>    for checking the signature in any way.  Copied header field
>    values are for diagnostic use only.
> 
> To my way of thinking the language in DKIM-01 was better:
> 
>    Verifiers MUST NOT use the copied header field values for
>    verification should they be present in the h= field.  Copied
>    header field values are for forensic use only.
> 
> Perhaps an alternative might be:
> 
>     Note:  Signature verification is determined using the content of
>     the headers identified by the h= tag.  Copied headers and header
>     field values presented by the z= tag are not intended to be used
>     for signature verification.  Any signature verification which
>     requires the use of the z= tag content does not conform to this
>     standard.

To write normative language we have to use MUST or SHOULD.

I suggest rewriting as follows:

      Copied header field values are intended to be used only for 
      diagnostic purposes. Verifiers SHOULD NOT use the header field 
	names or copied values for checking the signature in any way.  

Reordering the sentences means that the text flows from the rationale to the conclusion rather than the other way round which results in a stronger message.

Replacing MUST NOT with SHOULD NOT preserves the consensus of the WG that using the information to verify signatutres is a very bad idea while ensuring that every MUST remains auditable.

If we are using the information for diagnostic purposes we are still using it in conjunction with a signature verification. So I don't think that MUST NOT is even consistent with RFC 2119 which states that MUST NOT is an ABSOLUTE prohibition.

The language of 2119 is very clear:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Is anyone arguing that

1) This condition is ACTUALLY REQUIRED for interoperation?

2) This condition limits actual HARM?

I really don't think that anyone has made either case at any time in the discussions either before or now. 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 4 Jan 2007 18:41:58 -0000

>1) This condition is ACTUALLY REQUIRED for interoperation?

Well, yeah.  If the verifier is a separate module from the one that sorts
mail based on the verification result, the sorter is going to act
differently with results from a strict verifier vs. a squidgy one.

>2) This condition limits actual HARM?

If we consider unwittingly accepting mail with bad signatures as harm, yes.

I would prefer language along the lines of what I proposed last week, that
the copied values are not for signature validation, but you can do whatever
you want with them to decide what to do with a message whose signature
didn't validate.

R's,
John