Re: more minor Digest Auth editorial comments

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