- From: John Franks <john@math.nwu.edu>
- Date: Tue, 30 Dec 1997 13:19:08 -0600 (CST)
- To: Dave Kristol <dmk@bell-labs.com>
- cc: Scott Lawrence <lawrence@agranat.com>, paulle@microsoft.com, ietf-http-wg@w3.org, http-wg@cuckoo.hpl.hp.com
On Tue, 30 Dec 1997, Dave Kristol wrote: > John Franks wrote: > > [...] > > transaction-info = > > H( > > Method ":" > > digest-uri-value ":" > > media-type ":" ; Content-Type, see section 3.7 of [2] > > content-coding ":" ; Content-Encoding, see 3.5 of [2] > > dheader-content > > ) > > > > dheader-content = *DIGIT ":" ; HTTP response status code > > *DIGIT ":" ; entity-length, see ?? > > date ":" ; contents of origin HTTP date header > > last-modified ":" ; last modified date > > expires ; expiration date > > It's time for me to be stupid again. > > The dheader-content gets digested in transaction-info, and it gets sent > in the clear as part of Authentication-Info. Is there any expectation > (or requirement) that a receiver will validate the individual pieces of > dheader-content? If not, then the sender could put arbitrary garbage in > dheader-content, and as long as the same garbage appeared in both > places, the bits will come out right, but nothing useful will have been > accomplished. > 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. John Franks john@math.nwu.edu
Received on Tuesday, 30 December 1997 14:19:27 UTC