Stephen Farrell wrote:
However, I'd quibble with the above (which is btw, *much* better
than the "minimal" phease), in that I don't believe there is a
requirement for the dkim standard protocol to be backwards
compatible on-the-wire with what's deployed today, but rather
that the dkim standard be such that it's not a problem to migrate
from today's deployments or perhaps even to run them in parallel.
(Questions: Is parallel operation needed? If so, need that apply
to a single message?)
Concrete example: if the dkim wg decided to move the DKIM-signature
field as input to hashing from after the body to being the first
input (e.g. so we could perturb hashing with some of our own
randomness), then that'd be incompatible on-the-wire, but no
problem for migration.
A real concrete example is the issue of the nowsp
canonicalization and the issue of mime bodies. That
certainly got our attention and I think there's
good consensus that we ought to close the hole even
though it's going to cause some churn. We will be
proposing a new mechanism to deal with it.
I think it demonstrates a good test case: if it materially
affects the security or deployability of the protocol,
that's why we want it vetted by ietf. If it's merely
cosmetic or a marginal design choice or is otherwise
churn for no huge gain, then that's counterproductive
and should be frowned upon.
I'm not sure that I agree that your example rises to
that standard though, but it might well be that I don't
think the problem you suggest is correct.
Mike
_______________________________________________
ietf-dkim mailing list
http://dkim.org