1) ± can determine if body or headers are broken; - because it can
be done in a backward compatible fashion.
2) + can determine early on if header signature is valid; weak
because you won't ordinarily have the key, and most especially
not from malicious domains
3) + can hash a body once for redistribution; a fairly marginal
feature that might help mass mailers, but Moore's law is just
as likely to help, um, more.
4) - breaks backward compatibility
5) - no way for signer to determine when it's safe to not send
-allman-01; the longer we wait for the RFC #, the bigger this
problem becomes
6) - canonicalization/hashing agreement is the hardest part of the
spec to get right from an interop standpoint.
So the way I look at it you've got one nice benefit that can be
implemented in a backward compatible way, and two benefits that
are of fairly marginal utility. The downside is that we get churn
in the part of the spec that's hardest to get right, and a not
terribly easy way for a signer to know when it's safe to deprecate
-allman-01.
If (2) were more a reliable feature this would be harder call, but
absent other upsides I've missed, I really don't see the overall
benefit.
When Mike posted this the first time, I thought he made a couple of good
new points with items 2 and 5. I decided to leave my "chair" hat on and
see where we went with those, and I don't think they've been adequately
responded to so far. Comments addressing those are cetainly new input,
and are welcome.
I do think we can write the spec so that the proposed change doesn't
break old signers with new verifiers. I think that's the side of
compatibility that's most important.
I think we cannot make old verifiers work with new signers in any case,
if we encourage new signers to move to SHA-256 (unless the signers
double-sign).
I think Mike's still right that the advantage in item 2 is weakened by
the fact that we still have to retrieve the key, and we might as well
continue sucking down the message body while that happens.
---------------------------------
Back to "chair" hat again:
I agree with Stephen that we need to finish up this issue. I've seen a
few posts supporting the change, so I'd like to ask specifically if
anyone besides Mike thinks that we should NOT change the spec to hash
the body separately as discussed.
If you have not yet said that you support the change, please post here
and say that you DO support the change, that you DO NOT support the
change, or that you DON'T CARE. Further discussion is also fine if
there's something NEW to add, but please don't rehash what's already
been said. The key point is, as Mike makes clear, whether the
advantages of this are worth the incompatibility that it causes.
I plan to get minutes posted tomorrow, and we'll have a comment period
on the minutes, including this issue.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html