W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1997

Re: Digest mess

From: John Franks <john@math.nwu.edu>
Date: Sun, 21 Dec 1997 14:02:25 -0600 (CST)
To: Scott Lawrence <lawrence@agranat.com>
cc: jg@w3.org, paulle@microsoft.com, ietf-http-wg@w3.org
Message-ID: <Pine.LNX.3.96.971221133125.4616A-100000@hopf.math.nwu.edu>
On Fri, 19 Dec 1997, Scott Lawrence wrote:

>   Ok; that makes sense, but I don't think that we need the dates - they
>   are not essential to detecting response replays and they are many more
>   bytes.

Let me suggest a compromise here that might meet everyone's needs.

To the Authentication-info header we add a "digested-headers" 
field with the form


but we add the proviso that a server MAY omit any or all of the
dates.  Here are the advantages I see:

1.  Proxies may now muck with date headers, content length, or status
code as much as they wish with no ill effect on digest.  This is the
most important plus since making sure all proxies don't change or even
canonicalize headers was looking hopeless.

2. This provides the security of digested status code and when 
necessary the three dates.  Clockless servers or reponses with no
expires or L-M-date are dealt with cleanly and insulated from 
rogue proxies.  Servers can decide (on a per response basis if they
wish) whether including the dates is worthwhile.

Just to clean things up a little I would then change the definition
of entity-digest to

            entity-digest =
                    <"> KD (H(A1), unquoted nonce-value ":"
                         transaction-info ":" H(entity-body)) <">
                                       ; format is <"> *LHEX <">

            transaction-info       =
                Method ":"
                digest-uri-value ":"
                media-type ":"   ; Content-Type, see section 3.7 of [2]
                content-coding ":" ; Content-Encoding, see 3.5 of [2]
                *DIGIT ":"         ; HTTP response status code
                *DIGIT ":"         ; entity-length, see ??
                date ":"            ; contents of origin HTTP date header
                last-modified ":" ; last modified date, see 10.25 of [2]
                expires              ; expiration date; see 10.19 of [2]

            date              = rfc1123-date  ; see section 3.3.1 of[2]
            last-modified     = rfc1123-date  ; see section 3.3.1 of [2]
            expires           = rfc1123-date

Then the last five parts of the pre-digested transaction-info is precisely
the content of dheaders.

It would be really good to reach consensus on this and get it 
behind us.

John Franks
Received on Sunday, 21 December 1997 15:06:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:17 UTC