Re: Digesting the digest...

On Wed, 28 Feb 1996, Paul Leach wrote:

> Peter said:
> ----------
> ] From: Peter J Churchyard  <pjc@trusted.com>
> ] To:  <"john@math.nwu.edu">;  <john@math.nwu.edu>
> ] Cc:  <"http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com">;
> ] <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> ] Subject: Re: Digesting the digest...
> ] Date: Wednesday, February 28, 1996 2:10PM
> ]
> ] As I see it the optional message-digest and or digest-messagedigest is
> ] only advisory since it can be removed in transit and the receiver doesn't
> ] know it was there..
> 
> A client that cares about modification in transit can reject repsonses 
> without it, when talking to a server that it knows supplies it.
> 

I agree with this.

> ] We might want to put into the "digest hashed data" a flag that is set if
> ] you also sent a Digest-MessageDigest so that it's removal could be detected.
> 
> That's not what you need. The client needs to be able to ask the server 
> to send Digest-MessageDigest. A new parameter in the Authorization 
> field is what you want. If it got snipped out, then the client wouldn't 
> get the D-MD it asked for.

...


> So, how about the following parameter for both Authorization and
> WWW-Authenticate headers:
> 	digest-required=<"message" | "header" | "response">
> where "message" means the receiver must include
> 	message=<message-digest>
> in the response, "header" means the receiver must include
> 	header=<header-digest>
> in the response, and "response" means the receiver must include
> 	response=<response-digest>
> in the response.
> 

I don't like this.  How can you require an optional header.  The client
has to take it or leave it.  The alternative is something much different
from a drop in replacement for Basic.  If the client asks for it and the
server can't provide it, then what?  This opens a whole new set of 
issues.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Wednesday, 28 February 1996 18:09:25 UTC