W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: Digest mess

From: Dave Kristol <dmk@bell-labs.com>
Date: Wed, 07 Jan 1998 09:55:27 -0500
Message-Id: <34B3975F.63DECDAD@bell-labs.com>
To: Scott Lawrence <lawrence@agranat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5102
Scott Lawrence wrote:
> [...]
>   - Without at least a limited mechanism for message integrity, no
>     scheme is useful for POST or PUT.

Repeat after me "Digest is meant to replace Basic."  Basic provides no
message integrity.  There may indeed be a need for a lightweight way to
detect POST/PUT message integrity.  But let's not necessarily force the
latter on the former.

>   - A scheme that won't work through proxies that don't understand it
>     isn't deployable and won't be accepted.

Are you saying that the original Digest wouldn't play through proxies? 
If so, how would the more recent version do any better?  (Unless you're
referring to the way proxies may mung headers.  Original Digest wasn't
dependent on other headers.)

>   I, for one, would oppose advancing any derivative of the current
>   draft without addressing these problems.
>   I have already said that I think that we will need to change the
>   scheme identifier token anyway because the entity digest calculation
>   will need to change [both to remove certain header fields and
>   possibly also to change from H(A1) to H(H(A1))].
>   Perhaps it _is_ time to admit that we need a major rewrite and call
>   it something else.  I hope that can be avoided, but I volunteer if
>   it can't be.

I would hate to see the best be the enemy of the good here.  I have had
server support for Digest for nearly three years (and SimpleMD5 before
that), and I've longed for widespread support of Digest in clients. 
Sure, let's continue to work on other, better authentication methods. 
But let's not burden Digest with capabilities for which it was not

Dave Kristol
Received on Wednesday, 7 January 1998 07:00:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC