[ietf-dkim] over-the-wire (in)compatibility between pre-IETF
DKIM and (eventual) IETF DKIM
mike at mtcc.com
Wed Oct 19 12:22:39 PDT 2005
I'm catching up, so pardon me if I didn't see a response to Dave's
Stephen Farrell wrote:
> t this that there'll be (though there'll always be some:-)
> But, I think the charter text is fine btw.
>> Is it ok with folks to be required to replace essentially all of the
>> current software, administration and user deployment?
> That's three things.
> First, the current s/w will have to change since we're changing
> the signature construct (c14n & maybe the digest thing).
When did we agree to this?
> its signing, a single bit is enough to require new s/w anyway
> and there's 99.999% certainty that we'll at least change
> one bit in an on-the-wire imcompatible way. Don't you agree?
Maybe. Adding new options to dkim can often be done in a
backward compatible way. On the other hand, pre-judging
that there will be incompatible changes leaves the protocol
open to changes great and small, from the technically/security
needed, to the purely aesthetic. The barrier should be first and
foremost "is it broken", not "is it the way I would have designed
> Once that happens, many further changes have no additional impact
> on incompatability, but of course, all changes do need to be
That is simply untrue. There is dev, test and interop considerations.
> PS: I still didn't hear much about what specific parallel scenarios
> we'd like to support btw. e.g. if a single message can have both
> new and old signatures from the same domain, do we require that
> the same public key be usable to verify both, or should we remain
> silent on that, or something else? And which of those signatures
> should encapsulate the other, or do we care? ...
I'll bite: how can you stop me from using the same key?? And as a
receiver, why would I be motivated to support such a proscription
which undoubtably lowers my verification rate?
More information about the ietf-dkim