>1. I wasn't recommending making the new feature optional. Merely >noting the considerable benefit that accrues if you can live with it >being optional.
You might want to reread my draft, because this discussion has no relationship I can see to anything it says. The DKIM spec says a signature is valid if a list of things are true, e.g, the hash of the message's body matches the bh= value. But since the spec says that unknown tags are ignored, there's no way that you can add a new tag that adds a new condition to the existing ones. All you can add are tags that are comments. You could hypothetically add a tag that would make an otherwise invalid signature good, e.g., here's another place to look for the key, but that seems to me like a bad idea and nobody I know has done it. What I want to do is add new optional conditions, this signature is only good if all of the normal things are true, and these other things are true, too. Someone (not me) had the bright idea to use an indicator, currently an exclamation point, to say that a tag adds a new condition, so the verifier fails if it can't check all the tags with that indicator, and we can add more condition tags later without another version bump. But now the syntax has changed, so if a signature uses the new kind of tag, it has to be a v=2 signature. If a signature doesn't, it's still v=1, so everything that used to work still works. If an old verifier sees a v=2 tag it'll fail, so this fails closed. This is about this simplest version of upward compatibility I can imagine. You could do a hack to put this in an otherwise invalid v=1 signature, e.g., put the body hash in a bh2= field and omit the bh= so only a verifier that knows about bh2 will succeed, but why bother? It's ugly and would work in exactly the same places that v=2 does. R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
