Mike,
Michael Thomas wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
You are correct that this is an enhancement and not a bug-fix.
But if the WG consensus turns out to be for it, then that's
where we end up, right?
During the chartering phase, the key concern that I -- and I
think many others -- was introducing gratuitous backward
incompatible changes from allman-01.
This is not a gratuitous change since there are folks who
believe it offers sufficient advantage. Whether it is
warranted is another issue, but I can't see that that
description is fair.
However, given that we have agreed to basically move to sha256,
signers who use sha256 will be signing incompatibly with allman-01
verifiers so I don't see why this change would be significant,
following on from that change.
I don't consider sha256 a very good counterpoint: we're making
that change because we _have_ to, due to forces outside our
control. This change is in our control, however.
That's not my point. To reiterate: *given* that we already have
a backwards incompatible change, your argument that this is
another such, is much less telling.
That doesn't affect your argument that this may be a slippery
slope of course, but the two are separate.
As I said, this would set the barrier for incompatible changes
*much* lower than before, and I worry greatly about the stability
of the spec were that to happen.
That's a fair point.
Having a way to detect which broke -- header or body -- does not
require breaking backward compatibility.
Sort-of. Adding the putative "X=" header-hash you mentioned would
also require a verifier to do more than allman-01, so detecting
which is broken would require a verifier change, although such
signatures would remain compatible with allman-01 as you point
out.
It does not break current implementations though. As Murray
and Arvel's implementations can attest.
Again, I didn't say your "X=" broke anything. I said that it
requires a change in the signer and verifier in order to detect
which of the header or body broke the signature.
> The current proposal
will break all of our implementations. Needlessly, IMO.
s/break/change/ is true, but I'm quite sure folks could code
up the new signature scheme just as well, so I don't find that
argument very telling since you need to update the signer and
verifier code at some point to comply with the eventual RFC.
As I read it, the core of your argument is that you don't
find the change compelling and that you are concerned about
the precedent. Both are reasonable points to make, but neither
really touches upon signature format incompatibility, given
the sha256 change, IMO.
Again, I'd like to hear more voices, so that we can figure
where the consensus lies.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html