Did we really put this in base? Yes we did. Its not enforceable as it is at the option of the receiver and so cannot be a MUST NOT, it could be a SHOULD NOT.
If the signer gives information to the receiver the receiver can use it for any purpose they choose. We are not doing a rights management scheme here. If a recipient determines that a signature does not verify but does find that it verifies if the headers are substituted then there are many situations in which it would make excellent sense to treat the message as authentic. I don't think that it would make a lot of sense to implement that type of logic, and the sender certainly should not depend on the logic being implemented but its at the option of the receiver to do what they like with the information provided. People seem to have a very imperative view of this specification. It is important to remember that a specification is not a program. A specification should almost always be written in declarative form and describe the semantics of the messages exchanged and not attempt to dictate the decisions that parties make on the basis of those semantics. The only case where an imperative view is appropriate is in the case that there is a finite state machine and the semantics of the messages are inherently operational, i.e. they describe transitions between the set of defined states. This cannot be the case in our example since there are no states. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Levine > Sent: Tuesday, December 26, 2006 8:24 PM > To: [email protected] > Subject: Re: [ietf-dkim] Base issue: multiple linked signatures > > > 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. > > > >But of course that restriction could be relaxed. > > My recollection is the point of that restriction is that a > verifier has to use the actual values of the headers in the > message, not the copied versions in the z= header. There had > been some suggestions that if a header were "close enough" to > the copied version, the verifier might substitute in the > copied version. As always, this was part of the mailing list > argument, with the idea to have signatures tolerate subject > munging that lists like this one do. We decided against it > both because nobody proposed a concrete version of close > enough, and because nobody could say how a verifier would > distinguish algorithmically between an inserted [ietf-dkim] > and an inserted [EMAIL PROTECTED] > > A perfectly legitimate diagnostic use on a failed signature > is to detect what header(s) don't match the copies, and > whether the signature would have verified had the current > versions matched the copied versions. But I don't know what > you'd do operationally once you figured that out, and I don't > recall any other suggestions that didn't involve considerable > hand waving. > > > That said, this representation is more compact, so it's a tradeoff. > > You're right, but in an era when one line messages routinely > contain 20K of HTML style goop, compact headers are the least > of our worries. > > R's, > John > > _______________________________________________ > 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
