Re: [whatwg/fetch] Handle `Unencoded-Digest` assertions. (PR #1867)

@mikewest commented on this pull request.

Thanks, @annevk. I made the easy changes, and left some comments about some others. :)

> +algorithms, and whose values are <a data-lt="structured field byte sequence">byte sequences</a>
+represent a digest of the response produced via the specified algorithm. [[!UNENCODED-DIGEST]]
+
+
+<div algorithm>
+<p>To <dfn export>verify `<code>Unencoded-Digest</code>` assertions</dfn>, given a
+<a>byte sequence</a> <var>bytes</var> and a <a for=/>header list</a> <var>list</var>, run these
+steps:
+
+<ol>
+ <li><p>Let <var>header</var> be the result of
+ <a for="header list" lt="get a structured field value">getting</a> the
+ `<a http-header><code>Unencoded-Digest</code></a>` header as a "<code>dictionary</code>" from
+ <var>list</var>.
+
+ <li><p>If <var>header</var> is null, then return <b>verified</b>.

Booleans require reading the algorithm name carefully, so I find it clearer to name the output in some way. We do this already in at least one place in Fetch (https://fetch.spec.whatwg.org/#cross-origin-resource-policy-check), and I'd prefer that we do that more often.

I could put up a PR against Infra that attempted to generalize this pattern (define some set of values (**Success** and **Failure**, **Allowed** and **Blocked**?) that can be returned from algorithms, and use them in the algorithm linked above?) if you'd be interested in that. We might find more values over time, but the things I can easily remember from CSP and SRI would fall into one of those categories...

> +
+ <li>
+  <p><a for="list">For each</a> <var>alg</var> → <var>digest</var> of <var>header</var>:
+
+  <ol>
+   <li>
+    <p>Switch on <var>alg</var>:
+
+    <dl class=switch>
+     <dt>"<code>sha-256</code>"
+     <dd>
+      <ol>
+       <li><p>Let <var>body digest</var> be the result of executing the SHA-256 algorithm on
+       <var>bytes</var>. [[!FIPS-180-4]]
+
+       <li><p>If <var>body digest</var> matches <var>digest</var>, <a for="iteration">continue</a>.

"is" is accurate.

I thought about folding this into SRI as well. That might make more sense. My feeling is that this header is more closely tied to the fetching mechanism, as it's a server's declaration of the intended response body's content, but I suppose that's true for the signature mechanism as well that would come in a subsequent PR, and that probably doesn't fit into Fetch terribly cleanly. Hrm.

@mozfreddyb might have an opinion here?

> +  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string, or if
+  <var>internalResponse</var>'s <a for="response">header list</a> <a for="header list">contains</a>
+  `<a http-header><code>Unencoded-Digest</code></a>`, then:

The way this is currently defined would apply the check to responses regardless of a page's integrity assertions. It's based on a server's assertions, not on integrity metadata associated with the request. That layering makes the SRI checks quite straightforward (similar conceptually to CSP's layering on top of SRI), as the algorithms can assume that the `unencoded-digest` header will be enforced, so they only need to concern themselves with signature verification.

This layering also gives servers the same ability as clients to make binding assertions about responses. Philosophically, I find that appealing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1867#pullrequestreview-3481377961
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1867/review/3481377961@github.com>