Message-Id: <9603140046.AA26635@zorch.w3.org>
To: jg@zorch.w3.org, <masinter@parc.xerox.com>
Subject: Content-MD5 
Date: Wed, 13 Mar 96 19:46:36 -0500
From: hallam


Issue: content-Md5 is listed in the index of the HTTP/1.1 draft but
no detailed spec has been given.

Concern: Content-MD5 seems to have been specified in the belief that
	MD5 is an ideal digest function which is likely to be in use
	for the forseable future. This is in my view a dangerous 
	assumption. MD5 is a realatively simple modification of MD4 
	wehich has recently been broken. MD5 was written in response
	to the compromise of two of the three rounds of MD4, adding
	an extra round and introducing a set of additive constants.
	There are continuing concerns about the MD5 compressor 
	function and it is not unlikely that MD5 will cease to be
	widely used in the near term.

While compromise of MD5 as a cryptographic digest need not compromise its 
usefullnes as a message checksum such a compromise would inevitably lead to 
a reluctance to employ MD5 generally. In particular there are a number of 
quasi security uses such as as using MD5 digests as database keys which 
might be changed. It is clearly in the interest of long term usefullness of 
the spec for there to be a means of specifying other algorithms.


The rationale for specifying Content-MD5 and not Content-Digest: RSA-MD5 ...
appears to lie in RFC 1864 which is a standards track proposal. When I 
objected to this proposal to the last HTTP/1.1 editor he seemed to be of the 
opinion that the Content-MD5 RFC prevented this from being corrected.

There are a number of problems with using the 1864 draft in the context of 
HTTP:

1) It violates the RSA license agreement for use of MD5 which requires it to 
be identified as being from RSA labs whenever used. Hence the IANA 
identifier for MD5 is in fact RSA-MD5.

2) The draft specifies MIME canonical form, a processing step which in the 
HTTP environment is unnecessary.

Recommendation: Remove Content-MD5 from the current spec. Introduce a 
	Content-Digest header/footer in the HTTP/1.2 spec unless this
	change is uncontrovertial enough to make it in 1.1.


 		Phill