W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: more minor Digest Auth editorial comments

From: Paul Leach <paulle@microsoft.com>
Date: Wed, 28 Feb 96 17:19:46 PST
To: john@math.nwu.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: red-16-msg960229011351MTP[01.52.00]000000b1-121199
On Wed, 28 Feb 1996, John wrote:
]
] Great.  But try to do it quickly.  I would like to get version 03 of this
] document submitted.

Here's a proposal for a replacement for the description of 
Degest-MessageDigest:

HTTP/1.1 200 OK
Digest-MessageDigest:
              message="<message-digest>",
              header="<header-digest>",
              response="<response-digest>",
              nextnonce="<nextnonce>"

   The Digest-MessageDigest header indicates that the server
   wants to communicate some information regarding the
   successful authentication (such as a message digest or a
   new nonce to be used for the next transaction).

   <message-digest> is a keyed digest of the entity in the response.
   It is computed as

      <message-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" +
          H(<entity-body>) + ":" + <date>)

   where A1, N, A2, and <entity-body> are the same as in the algorithm given
   above for <message-digest> in the Authorization header, and <date>
   is the value of the Date header in the message containing this header.
   (In the case of caches, this will be the Date in the original
   response from the origin-server that contained this <entity-body>.)
   This allows the client to verify that the body of the response has
   not been changed en-route, and the freshness of the response
   (i.e., the client can know the time that the origin server server
   sent the response, thus preventing caches from claiming responses
   are newer than they actually are).
   The server would probably only send this when it has the document
   and can compute it.  The server would probably not bother generating
   this header for CGI output.

   <header-digest> is a keyed digest over the entity headers (as defined by
   HTTP -- e.g., as of HTTP/1.1, Content-Type and other Content-* headers,
   Last-Modified, Expires, etc.) It is computed as

      <header-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" +
          h1 + ":" + h2 + ... + ":" hn + ":" + <date>)

   where A1, N, A2, and <date> are the same as in the algorithm given
   above for <message-digest>, and h1 to hn are the entity headers
   in the response, in the order sent by the origin-server and in
   the origin-server's case, including, for each header, the header
   name, the colon, the value of the header with its original LWS,
   and the trailing CRLF. Similarly to the <message-digest>, this
   allows the client to verify that the entity headers have not
   been changed en-route.

   <response-digest> is a keyed digest over all headers in the
   response other than the entity headers. It is computed as

      <response-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" +
          h1 + ":" + h2 + ... + ":" hn + ":" + <date>)

   where A1, N, A2, and <date> are the same as in the algorithm given
   above for <message-digest>, and h1 to hn are the other headers
   in the response, in the order sent by the server and in
   the server's case, including, for each header, the header
   name, the colon, the value of the header with its original LWS,
   and the trailing CRLF. (In this case, the server could be
   the origin server or a proxy.)  Similarly to the <message-digest>,
   this allows the client to verify that the response headers have
   not been changed en-route.

   <nextnonce> is the nonce the server wishes the client to use for
   the next authentication response.  All fields are optional.  In
   particular the server may send the Digest-MessageDigest header
   with only the nextnonce=<nextnonce> field as a means of
   implementing one-time nonces.  If the nextnonce field is present
   the client is strongly encouraged to use it for the next
   WWW-Authenticate header.  Failure of the client to do so may
   result in a request to re-authenticate from the server with
   the "stale=TRUE."
Received on Wednesday, 28 February 1996 17:16:58 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:47 EDT