On Jun 13, 2009, at 12:02 PM, Charles Lindsey wrote: > On Sat, 13 Jun 2009 01:06:59 +0100, Steve Atkins <[email protected] > > wrote: > >> On Jun 12, 2009, at 6:34 AM, <[email protected]> >> <[email protected]> >> 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
