[ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

[Michael Thomas]

I'm catching up, so pardon me if I didn't see a response to Dave's 
question on
this too:

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?

> Since
> 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
   it".

> Once that happens, many further changes have no additional impact
> on incompatability, but of course, all changes do need to be
> justified.


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?

       Mike