Intent to Prototype: Signature-based Integrity

[Chromestatus]

Contact emails

mk...@chromium.org

Explainer

https://github.com/WICG/signature-based-sri

Specification

https://wicg.github.io/signature-based-sri

Summary

This feature provides web developers with a mechanism to verify the provenance of resources they depend upon, creating a technical foundation for trust in a site's dependencies. In short: servers can sign responses with a Ed25519 key pair, and web developers can require the user agent to verify the signature using a specific public key. This offers a helpful addition to URL-based checks offered by Content Security Policy on the one hand, and Subresource Integrity's content-based checks on the other.

Blink component

Blink>SecurityFeature

Motivation

To protect themselves from code injection, developers can restrict themselves to loading script from certain URLs and certain `<script>` elements (through Content Security Policy), and to loading script whose content is well-known (through Subresource Integrity). These satisfy a large number of use case, but fail to satisfy others (particularly supply chain integrity for dynamic resources). Signatures reasonably address this hole, nicely complementing the existing mechanisms.

Initial public proposal

https://github.com/w3c/webappsec/issues/449

Search tags

sri, signature, ed25519, integrity, provenance

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1139)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/434)

Web developers: No signals Shopify (@yoavweiss) has expressed positive initial impressions, as have folks at Cloudflare.

Other signals:

Ergonomics

The hash functions we currently support for SRI generally are not conducive to streaming responses. This is arguably fine for scripts and stylesheets (as those are executed atomically, requiring the entire body), but it cannot work for other resource types (images, video, etc). It's likely we'll want to extend the set of hash functions in the future (though we'd do that for SRI, CSP, and this mechanism in one fell swoop).

Security

The feature aims to plug a security hole in the platform's status quo ante: it is impossible to deploy content-based integrity checks for dynamic resources, and URL-based checks are too broad to provide meaningful security protections. We continue to require CORS-based opt-in for integrity checks on responses to ensure that we're not leaking data unintentionally between origins.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/subresource-integrity/identity-digest?label=experimental&label=master&aligned https://wpt.fyi/results/subresource-integrity/signatures?label=experimental&label=master&aligned

Flag name on about://flags

signature-based-sri

Finch feature name

SignatureBasedIntegrity

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/375224898

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5032324620877824?gate=5176565124825088

This intent message was generated by Chrome Platform Status.