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

Re: more minor Digest Auth editorial comments

From: Paul Leach <paulle@microsoft.com>
Date: Thu, 29 Feb 96 09:34:44 PST
To: http-wg-request%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: red-16-msg960229172739MTP[01.52.00]000000b1-121968
Roy says:
]
] >    <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
]
] That won't work.  HTTP header fields of the same name can be appended
] together, and header fields of different names can be reordered, by
] any HTTP recipient without changing the semantics of the message.
] The only way to digest the header fields is to first encapsulate them
] using something like WRAPPED or MOSS.

Is there something wrong with saying that if authentication is desired, 
then the digest
must be computed by the recipient before such transformations are made? 
 After that, it can do what it wishes, reordering, etc. wise.

In order to authenticate, _some_ canonical form is needed, but _any_ 
one will work; some are less convenient than others.  I chose the one 
in the proposal because it seemed like the least work for both sender 
and receiver.  Note: <header-digest> is a hop-by-hop authentication 
mechanism, so the issue of proxies wanting to do the transformations 
you describe is not present.  If it were, I'd agree with you that it 
was an unreasonable burden on the proxy to remember exactly how the 
origin-server sent the headers and resend them to clients unmodified.

Paul
Received on Thursday, 29 February 1996 09:31:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC