(Also (because everyone loves bikeshedding!), it might be helpful for y'all to have an opinion on the Identity-Digest header name that this proposal depends upon: https://github.com/LPardue/draft-pardue-http-identity-digest/issues/10.) We landed on something.

Having spent a little time discussing a few issues with Mike on his issue tracker, I'm starting to think that this probably needed to be marked as an early review rather than a final review. There are a couple of pretty fundamental issues that still need resolution. In particular, https://github.com/WICG/signature-based-sri/issues/45, https://github.com/WICG/signature-based-sri/issues/44, https://github.com/WICG/signature-based-sri/issues/38, and (I can't find the number) a very serious question about whether the signature needs to cover the (current) request URL.

Should this spend a little more time in the shop before we review it like it's done?

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", not "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!

This is just an incremental question and does not represent the views of the entire TAG:

Is there a need for something like signed manifests - listing expected hashes of resources - that can be looked up?

@csarven:

Is there a need for something like signed manifests - listing expected hashes of resources - that can be looked up?

There's a proposal from Meta and Mozilla pushing in something like that direction (Web Application Integrity Consistency and Transparency (WAICT)) that we discussed in WebAppSec last week. It also vaguely reminds me of Web Bundles Integrity Block proposal.

These proposals seem quite complimentary to the HTTP Message Signature-based mechanism described here, and well-worth exploring.

Complementary, perhaps, though the two approaches address fundamentally different goals. Signing provides a second layer of provenance on top of what you get from obtaining content using HTTPS, but it cannot provide integrity in the sense that the application is guaranteed to have a fixed shape. If you care about things like whether you got the same app as everyone else, signing cannot help.

Where signing helps is cases where the provenance of content is not closely tied to its delivery. Like when you use an intermediary (a CDN or static file host) to deliver high-impact content, or just because your own delivery pipeline is not something you want to trust. In those cases, you might want to provide an additional layer of protection in case of mistakes or attacks.

After discussion with @jyasskin, we concluded that the proposal is headed in a constructive direction, but it is more appropriate for @mikewest to continue to chase down some of the outstanding issues in the design before we get into a review.

These issues all trace to the same question: what might be done about the potential for the content substitution from within the set of resources that are signed with the same key. There are a bunch of questions about signing the current URL somehow (which interacts poorly with redirects) or maybe signing a nonce instead (which creates a tighter coupling between linking content and linked content, which might reintroduce the exact for operational problems that this approach is intended to avoid). These seem like a significant-enough set of problems to work through that the ultimate solution might need some significant changes.

With that in mind, we're deferring this one and will ask that you come back once things are more mature. Either open a new issue (mentioning this one) or reopen this one, as you best see fit when that happens.

Thanks for your thoughts. My expectation is that we'll land on initial answers quickly, and hopefully get feedback on their deployability from developers who experiment with the system. I'll bring that feedback back to y'all as it comes.

One thing, though, before deferring this for another day: I was hoping for some higher-level guidance on WICG/signature-based-sri#38. It's a somewhat long thread, but the last two messages (from https://github.com/WICG/signature-based-sri/issues/38#issuecomment-2576937213) reasonably sum up the context. This kind of design question seems generic-enough that it would be helpful for us to come up with a principle we can apply. @martinthomson and I touched on this in WICG/signature-based-sri#44, but I think it would benefit from a little more attention. I'll leave this closed, but I'd appreciate continuing the conversation elsewhere. :)

One possible principle on handling unknown parameters might be that it's often important to include a "critical" list, of parameters that the client must understand: https://github.com/w3ctag/design-principles/issues/560. There might also be other extensibility principles that we could identify, but I think they're likely to be of the form "consider these aspects when making the tradeoff", and won't just give an answer for the signature-based-sri case.

I'd invite y'all to take another look at the spec, as I intend to begin breaking it into PRs against SRI for review. https://wicg.github.io/signature-based-sri/#security-substitution describes the set of issues we discussed earlier in the year, along with potential mitigations. For the moment, key segregation is enough for developers who have experimented with the feature, and there hasn't been substantial interest in requiring signed redirects by default.

I intend to define a redirect-signing profile, and allow site developers to opt-into it via an option on the integrity declaration, but I think that will be a separate extension to SRI, and I'll open a distinct review for it in the future.

Thanks!