ietf-dkim
[Top] [All Lists]

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

2005-10-20 08:48:43
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/

_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>