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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
Sent: Tuesday, December 26, 2006 8:24 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
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 [buy-v1(_at_)gra-at-www(_dot_)p1llz(_dot_)com](_dot_)
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