Signature-Based Integrity.

[mikewest]

Guten TAG!

I'm requesting a TAG review of Signature-Based Integrity.

TL;DR: It would be nice if web developers could verify the provenance of resources they depend upon, establishing
a technical foundations upon which they can build confidence in the integrity of their supply chain. SRI offers brittle, content-based integrity mechanisms today which can (in theory) but do not (in practice) enable this capability. This proposal explores an alternative that builds upon existing integrity checks (e.g. <script integrity> and HTTP Message Signatures to give developers an additional option when deciding how to protect their sites from unexpected injection.

In short, developers will include the following on their site:

<script src="https://amazing.example/widget.js"
        crossorigin="anonymous"
        integrity="ed25519-[base64-encoded public key]"></script>

Servers will deliver resources signed with the asserted key:

HTTP/1.1 200 OK
Accept-Ranges: none
Vary: Accept-Encoding
Content-Type: text/javascript; charset=UTF-8
Access-Control-Allow-Origin: *
Identity-Digest: sha-512=:[base64-encoded digest of the response body]:
Signature-Input: sig1=("identity-digest";sf); keyid="[base64-encoded public key]"; tag="sri"
Signature: sig1=:[base64-encoded result of Ed25519([response metadata], [private key])]:

• Explainer¹: https://github.com/WICG/signature-based-sri
• Specification: https://wicg.github.io/signature-based-sri/ (Monkey-patching SRI, HTML, and Fetch)
• User research: None.
• Security and Privacy self-review²: https://github.com/WICG/signature-based-sri/blob/main/questionnaire.md
• GitHub repo: https://github.com/WICG/signature-based-sri
• Primary contacts:
  • Mike West (@mikewest), Google
• Organization/project driving the design: Google
• Multi-stakeholder feedback³:
  • Chromium comments: 👍
  • Mozilla comments: Signature-based Integrity mozilla/standards-positions#1139
  • WebKit comments: Signature-based Integrity WebKit/standards-positions#434
  • Google, Shopify, C

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WebAppSec & WHATWG
• Existing major pieces of multi-implementer review or discussion of this design: Nothing that isn't represented in the GitHub Issues. I've presented to WebAppSec thrice
• Major unresolved issues with or opposition to this design: None that I know of.
• This work is being funded by: Google.

I'd highlight a few comment threads that might be helpful for y'all to weigh in on specifically:

1. Reject or ignore unknown signature metadata parameters? WICG/signature-based-sri#38 discusses forward-compatibility and evolution of the specified components and parameters, with different folks taking different lessons from experience with CSP, etc. Your thoughts would be appreciated.
2. The bottom half of Inline scripts, CSP, and SRI WICG/signature-based-sri#10 discusses the applicability of this model to inline scripts, where the dependency on HTTP Message Signatures doesn't really fit. [Update, 2025-02-06] I ended up turning this into https://mikewest.github.io/inline-integrity/, which I'll present to WebAppSec this month, and come back to y'all if there's enough interest to justify the work.

Thanks for your time!

[mikewest]

(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: LPardue/draft-pardue-http-identity-digest#10.) We landed on something.

[martinthomson]

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, WICG/signature-based-sri#45, WICG/signature-based-sri#44, WICG/signature-based-sri#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?

[mikewest]

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 Redirect behavior? WICG/signature-based-sri#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 Reject or ignore unknown signature metadata parameters? WICG/signature-based-sri#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!

[csarven]

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?

[mikewest]

@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.

[martinthomson]

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.

[martinthomson]

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.

[mikewest]

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 WICG/signature-based-sri#38 (comment)) 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. :)

[jyasskin]

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: w3ctag/design-principles#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.