Re: Digest, trailers and buffering was: Re: Updating Digest header RFC3230 using "selected representation"

Hi Rob,

thanks for your feedback! I try to reply per-point.


0- Digest use cases
> Rob: If the message is small, it's also likely that TLS is good enough in that case
> Lucas: Digest allows for integrity protection of the object over multiple hops and, importantly, at rest.
Lucas is right. Digest is mainly used to provide  a basic form of
non-repudiation of origin.

1- send a digest header with the "payload checksum"
2- send a signature protected http message where the signature covers
the digest header;
3- store the message, digest and signature.

See https://github.com/httpwg/http-extensions/blame/master/draft-ietf-httpbis-digest-headers.md#L129
See https://github.com/httpwg/http-extensions/blame/master/draft-ietf-httpbis-digest-headers.md#L686-L690

1- about HTTP/1.1 trailers.
> One issue that prevented the adoption of this header and related ones (e.g. Content-MD5) was that
> HTTP/1.1 trailers had a lot of interoperability problems
> Sending the digest as a trailer reduces costs for the sender, whether it's an upload or download. .

If you mean https://tools.ietf.org/html/rfc7230#section-4.4, they
apply to transfer coded messages, so iiuc
the only reasonable way to send Digest in a trailer was if the message
was transfer-coded from the
beginning by the Origin-Server. Do you agree?

2- about huge payload
> This made it expensive for large files, or impossible to use for message bodies that couldn't be pre-calculated.
I stubbed a reply in the section "Server resource exhaustion for
calculating Digest on huge representation-data"
of  https://github.com/httpwg/http-extensions/issues/852#issuecomment-514541274
You can comment there!

Suggestion and clarifications hints are very welcome!

Your comments are very interesting
and appreciated!

Thanks Rob,
R:
--

Received on Wednesday, 24 July 2019 09:06:34 UTC