Mike West

As @martinthomson points out, we're talking about two things above: 1. Can we sign redirects generally? That seems straightforward, as we've described: sign `@status` and `location` in the same way...

I've thought about this a bit on and off over the last few days, and my current take is that it's reasonable to be strict about the provenance checks that...

Shifting this to the future: https://wicg.github.io/signature-based-sri/#security-redirection spells out the current approach and the options we might want to explore later on, but current deployment experience suggests both that key segregation...

I'm not sure what you mean by "solve them in the standard". The developers I've talked to about this have fairly universally been uninterested in locking down redirects, preferring instead...

We can require anything we like, so long as it's shippable. My recollection is that developers deploying signatures didn't strongly object to requiring signed redirects, but also saw it as...

@annevk: I hope that https://wicg.github.io/signature-based-sri/#security-substitution provides some context for the risks we're discussing. In short, an attacker who controls a server's responses (but does not possess the signing key) can...

> With `@path` referring to the final hop, wouldn't you be protected against that still? How can redirects thwart that? Signing `@path;req` ensures that an attacker could not replace `good.js`...

Signing `@path;req` ensures that the response you're getting is a response the server intends to deliver for the current request. Signing redirects ensures that when the server changes the request...

> Well, Jeffrey's suggestion would side-step the need for redirects to be signed as the page and final resource agree on a stable identifier that's also signed. Deployment-wise that seems...

> I don't think that addresses the concern. The attacks you described involve substitution of resources of the same type. Indeed. The robustness of key segregation depends entirely on the...