> >The problem may be that we don't agree about what DKIM versions mean. > >Here's what I would like them to mean: ...
> >c) Whenever we add new tags that require that the verifier understand them > >to get the right answer, we increment the version number. > Ned pointed out that we could add an indicator on a tag that means > that interpreting the tag is mandatory, so if the verifier doesn't > understand the tag, the verification fails. This would decrease the > need for future version bumps. > So for example: > DKIM-Signature: v=2; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example; > h=From:To:Date; l=0; !cs=fs; fs=t; > bh=... > b=<this is a "weak" forwarding signature that covers part of the message> > The ! in !cs= means that the verifier MUST handle the cs= tag or fail the > message. First, credit where credit is due: This is basically the criticality indicator found in X.400, X.500, and various other protocols. The idea dates back to at least the mid-1980s, if not earlier. Second, I didn't originally mention this because I intended to propose adding it, but having thought about it, I find myself liking the idea, especially since it gives you a more general capability-based mechanism for future extensions. In fact I could see this effectively obsoleting the version field in DKIM. Since there's substantial operational experience with this sort of mechanism - not all of it good - it's important to access it in light of that previous experience. The obvious issue is that it makes it possible to create myriad incompatible but nevertheless legitimate variants of DKIM. Since an important aspect of DKIM is use by bilateral agreement, and since nothing prevents you from attaching multiple DKIM-Signature header fields, even if this happens I don't see it as a problem. A second, more subtle, issue, and one that definitely happened in the X.400 space, is that the way this stuff ended up getting deployed created incentives for implementations to simply ignore the criticality bit. This happened because in an effort to create vendor lock-in several implementations decided to decorate all their messages with critical extensions containing who knows what. None of this stuff seemed to matter; messsages could be read and processed in spite of it. So the result was a lot of processors simply ignored the criticality, or at least could be set to do so. I don't see this as likely to happen with DKIM for several reasons. For one thing, the failure to interpret a paritcular DKIM-Signature field isn't supposed to render the message unprocessable - in fact it's required that it not have that effect. And there's so much flexibility along so many other axes - multiple DKIM-Signature fields, fields with different names, etc., that I don't see a serious concern here. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
