Re: Digest mess

  > The receiver is expected to re-calculate the entity-digest and compare
  > that with the value of the entity-digest sent in the
  > Authentication-info header to make sure they agree.  The sender could
  > indeed have sent garbage and have it check out, but only if the sender
  > knows the secret password (or more precisely H(H(A_1)) which is the
  > hash of the hash of the password).  This is because both the shared
  > secret and dheader-content are ingredients of the entity-digest.  All
  > that we can hope to do is assure that the response was sent by someone
  > who knows the password.

I think you missed my point, which no doubt I made badly.  I'm assuming
the sender and receiver agree on their shared secret.  The question I'm
asking is, What's the purpose of dheader-content?

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.

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.)


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?  And if that's all we're doing, then let's
simplify the specification and not pretend we're using headers.

Dave Kristol

Received on Tuesday, 30 December 1997 15:18:19 UTC