Re: Content-MD5

>for MIME objects already. If you think Content-MD5 is broken it must
>be generally broken and any fix that's made should not be specific to HTTP.

I do think it is broken.  I exchanged a half-dozen messages with the
authors.  The history of this particular RFC is a little funny; it went
through a long revision time because it was worded badly.  Content-MD5
has been around for years, the fact that the RFC is just now coming out
is funny timing.  The phrase "years of compliant behavior" was quoted
to me by Mr. Gardiner.

Just as HTTP as extension headers, so does IETF email.  Just as HTTP
is free to accept Content-MD5, the email-wg is free to accept any improved
header that we come up with here.

>Its going to be tough to change it at this late date, but if you think you have
>a case to make for an alternative by all means present it in the form of a new
>specification. That's how it needs to be done. Having two different mechanisms
>for mail and HTTP simply encourages everyone who comes along with the new
>protocol that uses MIME to roll yet another one of these, and we really
>don't need that.

Yes.  Has either "side" made a strong commitment to convergence?

>My position at the present time is that the relative speed issues are more
>important than the minor observed weakness in MD5. This is especially true
>given the relative infrequency of use of content-md5 to actually provide some
>form of security, so RFC1874 is acceptable to me for the time being. But that's
>just my take on the situation.

I disagree.  MD5 is routinely used in production RPC systems all the time.
I expect that for some time most hashes (and signings) will be done off-line
where speed is not an issue, and also verified while the document is being
displayed where, again, speed is not an issue.
	/r$

Received on Friday, 3 November 1995 18:18:43 UTC