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

[Dave Crocker]

Stephen,

> The point is that changes to the signing process are always
> imcompatible - the best you can do for backwards compatbility
> is sign twice or else allow an option to produce a backwards
> compatible signature format. But I believe we're likely to end
> up with the MUST-implement being the more secure option we have,
> which is also not likely to be compatible. I may be wrong there
> but we'll see.

Changes are changes.  That means incompatibilities.

What is at issue is how existing behavior is supported or deprecated as 
a result of revising the specification. 

Can old senders interoperate with new recipients?  Can new senders 
interoperate with old recipients? 

When the answer to either of these is 'no' then we must be explicit that 
that bit of non-interoperability is acceptable.


>>> 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.
>
>
> It is true, so I mustn't have been clear. If we fiddle with the
> signing process at all, then doing that twice is usually no worse
> than doing it once, e.g. if we created a new MUST c14n then it'd
> make no difference (wrt imcompatibility) if at the same time we
> created a new MUST for the body-hash stuff.

If we created a SHOULD, rather than a MUST, it would make a difference. 

Again, the point is that there are choices technology and requirements 
that affect compatibiliy compatibility.  They are not minor issues with 
automatic resolution, and they often are not simple.  They always 
require being careful and explicit.

d/