Re: Digest mess

On Tue, 30 Dec 1997, Dave Kristol wrote:

> I thought the original idea for dheader-content was that the receiver
> could verify that the message headers were unchanged from what the
> sender had sent.  But we discovered that proxies, particularly, might
> change the actual message headers.  So we created dheader-content, so
> the information in the headers would be captured somewhere that proxies
> wouldn't muck with.
> 

No, the point is for the receiver to know what headers the origin
server sent.  It is ok if a proxy has changed them and they no longer
match dheaders.  In this way the receiver can, for example, tell from
the dheader status code that the server acknowledges a successful PUT,
even if some proxy has removed this information by changing the status
code.  Also a receiver can see that the origin server sent no Date
header (maybe no clock) and even though a proxy has added one, the
receiver knows not to use it when calculating the entity-digest.

> But, as far as I know, we haven`t said that the receiver should verify
> that the stuff in dheader-content matches the stuff in the message
> headers.  For example, we didn't say the first component ought to match
> the received response status code.  (And it might not, because of
> intervening proxies.)
> 

It might not match, but the receiver doesn't care.  The receiver
should not expect dheaders and actual message headers to match.
If the entity-digest checks out then the dheaders matched the
origin servers headers.

> 
> If we're not going to specify how to verify that the stuff in
> dheader-content matches the stuff in the message headers, then how does
> dheader-content differ from just some arbitrary nonce string that gets
> tossed into the digest? 

The main difference is that nonce is opaque and dheaders has
semantics.  The contents of dheaders is certifiably created by someone
who knows the shared secret.  We trust them to be telling us the true
values of the origin headers: date, expires, l-m-d and status.  The
dheaders field could not have been changed en route if the
entity-digest checks.


> And if that's all we're doing, then let's
> simplify the specification and not pretend we're using headers.
> 

Maybe "origin-headers" would be a better name.


John Franks
john@math.nwu.edu

Received on Tuesday, 30 December 1997 15:36:06 UTC