On Jun 13, 2009, at 12:02 PM, Charles Lindsey wrote:
On Sat, 13 Jun 2009 01:06:59 +0100, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com
wrote:
On Jun 12, 2009, at 6:34 AM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
<Bill(_dot_)Oxley(_at_)cox(_dot_)com>
wrote:
Okay, I would like to keep what we have, removing pieces is not a
good idea, people don't have to use the tags if they don't want to
Implementors have to, for DKIM verifiers at least. Also, even DKIM
signers have to either understand the semantics of each and every
tag,
even if they don't use them, or ignore the spec and use a subset of
possible configurations as advised by a third-party deployment
document.
That is not so. All verifiers have to do is to check whether the
signature is good, and report accordingly to the Assessor. That
should include pointing out whether the signature matches the From,
and also indicating exactly which headers were signed, and reporting
on any tags seen. For that purposes it is entirely unnecessary to
understand what most of the tags are supposed to do. Just enough to
identify how it was signed and whether it was valid.
You might wish it were the case (and I do too, somewhat), but it just
isn't so.
As a concrete example, if you have a public key containing the string
"g=hatstand" and a signature that does not contain the string
"hatstand" then any DKIM verifier must return that the message is
unsigned, by the definition of a DKIM verifier - something that
follows the explicit rules of section 6.1 of RFC 4871 (plus the
implicit rules from other sections[1]).
It cannot do that if it ignores the "g=" or the "i=" flag.
It's easy to construct equivalent proofs for pretty much everything
else (anything other than the PK n= flag, I think).
And as for assessors, they can take as much or a little notice of
unusual tags as they see fit. There will care about some tags, and
simply ignore the ones they don't understand (this in spite of the
fact that understanding the more unusual tags may enable their
assessments to be more accurate). But it will take years of
experience for the assessment community to discover which tags they
need to take note of. A Best Practice will arise over time, but even
that may have to change as the Bad Guys find ever more ingenious
ways to get around the system.
and we MAY have a need for them in the future.
We may. Verifiers will need to support them pretty much forever
whether we do or not, though. ...
No, that is just my point. They can probably ignore most of the
unusual ones, just so long as they include them in their hashes when
verifying.
A piece of software that ignores any feature that can affect whether a
signature is valid or not is not a DKIM verifier, and will give the
wrong answer in some cases. That might be acceptable to some users
(including me, in some cases) but is not a DKIM verifier as designed
by spec.
I think your argument boils down to "we don't need to change the spec,
because everyone implementing it can ignore the bits they don't like".
Apart from anything else, that seems as though it would lead to an
awful lot of interoperability failures if some "DKIM verifiers"
consider a message signed while some consider it unsigned.
Cheers,
Steve
[1] 6.1 doesn't explain that the verifier must check the v= tag, for
instance
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html