- From: <hallam@w3.org>
- Date: Fri, 26 Apr 96 20:14:56 -0400
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: hallam@w3.org, fielding@avron.ICS.UCI.EDU
Roy writes >The obvious way to handle a new digest algorithm like SHA is > > Content-SHA: 2A1238912371239587 > >which is exactly how the HTTP protocol is designed. Leave it be. This means that each time the digest algorithm has to be changed we should issue an RFC for a new version of HTTP. It would be nicer to be able to simply add an entry in the IANA registry. I disagree with Roy, I know of no other tag where the algorithm is embedded. We do not have Content-Text-HTML, we dont have Content-GZIPPED. I think that HTTP is designed in exactly the opposite manner. One of the reasons why protocol specifications should not have dependencies on the security on particular algorithms is that it means that if the algorithm is compromised a few days before its due to be published it is not necessary to consider late changes. For the sake of getting the spec out the door, I'll agree with Roy provided he agrees not to object to my proposals for Content-SHA, Content-RIPEMD and Content-MD6. Paul writes: >Digest Auth already has the algorithm as a parameter. The name >"Content-MD5" can't be changed for historical reasons. The problem with digest auth that I hadn't anticipated is that as presently stated the spec means that if you change the keyed digest algorithm you also need to exchange a separate shared secert. This is bad practice cryptographically, (mea culpa). The shared secret generation step uses only the one way property of MD5. The authentication function uses the collision resistance funtion and the one-wayness. Its only the collision resistance that is compromised, not the one-wayness. Ie refering to the spec where we have Digest = H ( H(A1), nonce, H(a2)) A1 = username : realm : password a2 = Method : URI The password file stores H(a1), so it is convenient to use a single digest function for all keyed digests ie we have Digest = SHA ( MD5(A1), nonce, SHA(a2)) Its the SHA(a2) component that is really sensitive. Phill
Received on Friday, 26 April 1996 17:18:01 UTC