Relationship to Digest header

[LPardue]

The Digest header is defined in RFC 3230. It allows client or server to attach metadata that carries an integrity hash for a request or response body.

The IETF HTTP WG has adopted a draft that updates RFC 3230. This uses more modern terms and will attempt to address some edge cases and gaps. See https://tools.ietf.org/html/draft-ietf-httpbis-digest-headers-00.

There is overlap between Digest and SRI, and an issue has been raised on us to consider their relationship httpwg/http-extensions#868.

Despite overlap, the use cases, operating models and domains do have some differences. So I'm trying to figure out the right amount of information to document, and where.

I'm opening a ticket here for visibility and to promote input or discussion on either ticket.

[LPardue]

Looping back to this, I added a discussion section to draft 01 of Digest Headers

https://tools.ietf.org/html/draft-ietf-httpbis-digest-headers-01#section-8

[mikewest]

One more tangentially-related concept to take into consideration is https://github.com/mikewest/signature-based-sri, which would allow conceptual validation of provenance as opposed to content. The description in that explainer is fairly similar to the Digest header, insofar as it's an assertion from the server whose validation can take place client-side, though it requires a bit more information than Digest would provide.

I am still hopeful that we'll someday rework this into something based on top of Signed Exchanges' signature mechanism (as @jyasskin sketched out in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#name-subresource-integrity). Thus far that hasn't been high-priority-enough to put effort towards, but I still think it's an interesting idea. :)

[LPardue]

hey @mikewest thanks for sharing. It is very relevant to the broader consideration of using Digest in tandem with signatures (Yasskin or Cavage). cc'ing @ioggstream (co-author) who has more hands-on experience with hashes and signatures.

There was some discussion in different sessions at IETF 106 about the applicability of HTTP Signatures to different domains, with one suggestion that such work would be well placed in HTTPbis WG. I can see this have been mentioned before (mnot's comment on an issue in 2017, mikewest/signature-based-sri#5 (comment))

Specific to SRI vs Digest, there are differences in how the hash is calculated. For example, in SRI the hash is applied to the identity encoding but Digest applies it to the encoded representation. The design of signature applied to integrity should accommodate such differences, or at least describe some of the challenges of one over the other.

[ioggstream]

@mikewest re-reading https://github.com/w3c/webappsec-subresource-integrity/blob/master/index.bs#L353 it is not clear to me whether integrity is always computed on the unencoded data or if a user agend can make a different decision (eg. request a content-coded resource and check against it). by definition, "representation data" takes encoding into account.

WRT: httpwg/http-extensions#1354

[annevk]

It's after content encodings have been removed. We need to update this algorithm so Fetch just hands it bytes directly. All SRI should do is take the metadata, bytes, and response's type and return true/false. I might write a PR for that as I'm updating the Fetch side of this.

[LPardue]

By popular demand, we added and section of text comparing SRI and Digest, and subsequently removed it. Its probably interesting material but not really RFC worthy. I think we can close this ticket now.

[annevk]

Fetch and SRI have also been updated, so I guess all is in order then.