Dave,
Dave Crocker wrote:
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.
Agreed. It'd be good if someone wrote down a bit of text on that
for inclusion in the base protocol spec (or maybe the overview
thingy?) at some stage. The type of text I mean is along the lines
of "if you take this and that options then you'll interop with
old stuff, but if you do the other thing, then you won't" - probably
can only be a placeholder at first I suppose but should get
interesting as the base protocol is finalised. Note: I don't
think anything more than a placeholder is needed for now, but
it might be no harm to add that in if there's time. Could even
be part of the existing base section 7 I suppose?
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.
Fair enough - the actual MUST/SHOULD/MAY discussions are clearly
for later on.
I would be surprised though if the result for the signature construct
(which may be a bit of a special case here) didn't have the "best"
security option as the MUST-implement, even if it has the legacy
signature construct as a MAY-emit. But we'll see when we get there...
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org