Re: [w3ctag/design-reviews] Signature-Based Integrity. (Issue #1041)

mikewest left a comment (w3ctag/design-reviews#1041)

I appreciate y'all's feedback and engagement however you'd like to label it, and the questions you've raised are quite helpful! The two questions I think are most pressing are:

1. Should we apply a public key constraint only to the response we get at the end of a redirect chain, or to each hop along the way? It seems reasonable to define a signature mechanism for redirects, so I'll do that in any event; it's simply unclear to me whether we should require developers to care about that in every case, or make it somehow optional. This is https://github.com/WICG/signature-based-sri/issues/45.

2. How do we best support evolution of this standard in the future? The current draft ignores signature/signature-input members it doesn't understand, requiring developers to attach multiple signatures to cover a breadth of client versions. An alternative would be to accept unknown aspects of signatures, and sign them as best we can. Each approach has some benefits and drawbacks. This is https://github.com/WICG/signature-based-sri/issues/38.

The question of covering the current request URL seems like it was answered: `@path` represents the request's "[current URL](https://fetch.spec.whatwg.org/#concept-request-current-url)", not "[URL](https://fetch.spec.whatwg.org/#concept-request-url)". It sounds like you're suggesting that we might want to require developers to sign `@path` along with `unencoded-digest`? That seems like it would introduce deployment brittleness (the signing infrastructure would have to the URL from which the resource will be served) that doesn't seem justified as a requirement. I don't think there's an issue on that topic specifically, so if we should discuss it, I'll file another. :)

---

In parallel with continuing the conversation on those issues, my plan at the moment is:

1. To run an origin trial with Chromium's current implementation to get some feedback from developers about what I think we generally agree upon as the feature's core (sign `unencoded-digest`, punt on ~everything else). That should give us some insight into deployability of signatures generally, as that infrastructure will require testing at scale.

2. To ask WebAppSec to spin up an update to SRI that will include this problem space, which hopefully provides a broader forum to hammer out the specifics (along with other bug fixes from the last ~decade already present in the ED).

Does that sound reasonable to y'all?

Thanks again for your time and attention!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1041#issuecomment-2664784193
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1041/2664784193@github.com>