- From: John Franks <john@math.nwu.edu>
- Date: Mon, 29 Apr 1996 10:41:29 -0500 (CDT)
- To: Paul Leach <paulle@microsoft.com>
- Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'hallam@w3.org'" <hallam@w3.org>, "'fielding@avron.ics.uci.edu'" <fielding@avron.ICS.UCI.EDU>
On Fri, 26 Apr 1996, Paul Leach wrote: > > > >From: hallam@w3.org[SMTP:hallam@w3.org] > > > >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. > In light of the problem raised by Phill I suggest the following. We had already decides to try to "dock" the digest auth document with HTTP/1.0. I think that a reasonable thing to do now would be to separate the digest auth spec into two parts, only one of which would dock with HTTP/1.1. Unless I am mistaken the only part parts affected by the MD5 weakness is the optional "digest" field of the the response header and the optional "digest" field of the AuthenticationInfo header. I think we should "fire the explosive bolts" on this part making it a separate option extension described in a separate document (and emphasing the use of a different algorithm). Meanwhile the authentication role of digest, i.e. its use as a replacement for basic would still be intact and still secure. Thoughts? John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Monday, 29 April 1996 08:47:01 UTC