On 10/3/2015 5:23 PM, Murray S. Kucherawy wrote: > On Sat, Oct 3, 2015 at 4:49 PM, Dave Crocker <d...@dcrocker.net > <mailto:d...@dcrocker.net>> wrote: > > Claiming that something is mandatory, as part of a version bump, is > meaningless, when the installed base will be using the older version and > ignoring the supposedly-mandatory new feature. > > If the installed base can legally ignore a new feature, then it is not > mandatory. > > > I think there's possibly an issue with terminology here. > > In DKIM v1, a verifier that sees a tag it doesn't understand simply > ignores the tag and continues processing the signature. There are no > "mandatory" tags other than the few without which a signature can't be > evaluated at all (h, b, bh, d, s, c, and a come to mind).
Right. > Something > using, for example, the ones defined in RFC6541 or RFC6651, won't > prevent verification by a verifier that doesn't implement those. > > In the proposed DKIM v2, a verifier that sees a tag prefixed with "!" > that it doesn't understand has to fail the signature without further > processing. It's not mandatory that the tag be present, but it is > mandatory that the verifier has to do something with it or fail. The > "mandatory" describes the handling of the tag, not its presence. Understood. However this does not change my point at all. The language you are using dictates mandatory behavior by the signature validation engine. But it is not really mandatory, since no legacy engine will understand it. Rather, they will ignore it. Being allowed to ignore a parameter means that the parameter is optional, not mandatory. Or it means that you folk are using the term 'mandatory' in a way I've never encountered before and really don't understand. > A v1 verifier would also ignore a v2 signature. I had not noticed -- and still don't quite understand -- what it is about the new stuff that will cause a legacy engine to fail the signature validation. Yes, I see that it will ignore all the !* new stuff, but that doesn't mean it will fail the evaluation. However to the extent that v1 engine evaluation failure is a target outcome, that merely further underscores my point that you are creating a new and incompatible protocol. The way to signal that is at the entry point to the evaluation engine, not buried amidst the parameters given to it. The entry point is the header-field name. At base, the spec defines a meta-syntax that appears to entirely miss the point of creating signer/validator (or any producer/consumer) compatibility. The challenge in getting a consumer to process new, mandatory fields is not syntax. It's semantics. And once you get the consumer to understand the semantics, you don't need the meta-syntax. > The only way to make a feature mandatory in a new version is to provide > it in a fashion that makes it only available to folks adhering to the > new set of mandatory features.[*] > > > Doesn't this do that? No. Legacy engines will see it ignore it. That does not match the 'mandatory' semantic being asserted in this spec. > > FWIW, this is equivalent to saying that adding new > mandatory features is equivalent to creating a new > protocol. > > So if you want to modify DKIM to change the set of mandatory features, > then specify that the signature use a /different header field name/, > such as DKIM-Signature2. Only adherents to the new scheme will see > this. > > > Isn't it true that we've found all current DKIM implementations would > ignore a "v=2" signature? If so, I'm not understanding the distinction > between "DKIM-Signature: v=2; ..." and a wholly different field name. Ignoring v=2 is not the issue. Ignoring the other, new and supposedly mandatory parameters is the issue. > If the signer wants legacy folk who only understand older DKIM to also > be able to evaluate a signature, then the signer needs to create two > signatures. > > > It could do a v=1 and a v=2, certainly. In fact in the instant > proposal, that's actually necessary. Which DKIM engine should I apply? v1 or v2? That gets answered at dispatch time with header field name. It gets answered after that with the version number model. And a legacy engine will incorrectly process the v=2 signature as if it were v=1. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
