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.

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