[ietf-dkim] DKIM BOF -- draft charter and agenda

[Michael Thomas]

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