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!