Signature-based Integrity

[mikewest]

WebKittens

@annevk @Wilander

Title of the proposal

Signature-based Integrity

URL to the spec

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

URL to the spec's repository

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

TAG Design Review URL

Waiting to get feedback/signal from y'all and our friends at Mozilla

Mozilla standards-positions issue URL

mozilla/standards-positions#1139

WebKit Bugzilla URL

No response

Radar URL

No response

Description

It would be nice if web developers could verify the provenance of resources they depend upon, establishing the technical foundations upon which they can increase confidence in the integrity of their dependencies. We offer 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 signature mechanisms (RFC9421 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); alg="ed25519"; keyid="[base64-encoded public key]"; tag="sri"
Signature: sig1=:[base64-encoded result of Ed25519([response body], [private key])]:

Modulo a few details we're still working out in the draft spec and on GitHub, that's it. Easy peasy. WDYT?

[mikewest]

FYI: I filed a TAG review request in w3ctag/design-reviews#1041. It'd be helpful to get y'all's thoughts on this proposal as input to that discussion. :)

[nmahendru]

Please don't add RSA PKCSv1_5 as an option. Implementations of that have had many, many issues and ECDSA/edDSA are well known and available everywhere and provide more than enough options for implementors in my opinion.

[nmahendru]

Skimming through this https://www.rfc-editor.org/rfc/rfc9421.html#name-creating-the-signature-base :

• what's the proposal on what key will be used to sign and how will the client application know what key to trust ?
• For HMAC(symmetric Key), how will the client get the secret Key ? TLS ? if yes then that is kind of not really making it any better.

[mikewest]

Thanks for the feedback, @nmahendru!

Please don't add RSA PKCSv1_5 as an option. Implementations of that have had many, many issues and ECDSA/edDSA are well known and available everywhere and provide more than enough options for implementors in my opinion.

Sure. I don't see any need to extend beyond Ed25519 at the moment, and that's the only algorithm defined as acceptable in this proposal.

Skimming through this https://www.rfc-editor.org/rfc/rfc9421.html#name-creating-the-signature-base :

• what's the proposal on what key will be used to sign and how will the client application know what key to trust ?
• For HMAC(symmetric Key), how will the client get the secret Key ? TLS ? if yes then that is kind of not really making it any better.

RFC9421 defines a very flexible, generic signature mechanism; this proposal only uses a subset, defined in https://wicg.github.io/signature-based-sri/#profile. It locks the SRI profile to Ed25519, embeds the public key in the keyid parameter of the Signature-Input header, and does not support a symmetric key variant.

[nmahendru]

okie! I think that's good then!

[mikewest]

Great. If y'all have additional feedback, I'd love to hear it. :)

[annevk]

Colleagues and I suggest resolving this as "position: support" one week from now. This is under the assumption that the work will move into a proper Working Group shortly and the remaining minor points of contention in the issues get resolved.

[mikewest]

Thanks, @annevk.

This feature spans across SRI and Fetch, and I'm quite open to feedback about what pieces might live where. Would it be reasonable to put up some concrete patches against those documents to discuss the right division of labor? https://wicg.github.io/signature-based-sri/#monkey-patch-fetch has some things that seem clearly Fetchish, for instance, while I'd appreciate others' thoughts on a home for the algorithms in https://wicg.github.io/signature-based-sri/#server-initiated (Unencoded-Digest in particular).

[annevk]

Yeah that sounds reasonable. I'd be inclined to leave server-specific processing to SRI. While Fetch does contain some of that with CORS, it's probably more easily maintained as part of SRI.