Using CID in HTML SRI (Subresource Integrity attributes)

[lidel]

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match. – https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

<script
  src="https://example.com/sw.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

This is a placeholder issue with the current state of things.

In my mind there are three "stages" of SRI support we could think of, and only first one can be done without internal support from browser engines and standards bodies.

• 🟢 (A) Existing SRIs could be turned to CIDs and payload could be trustlessly fetched and verified from IPFS, e.g. trustless gateway, when possible, instead of https:// src:

  <script src="https://example.com/sw.js" integrity="sha256-UTe33acZ78PiBp03/u/vVxeFkmS2rOt9qv3HukgejCg=" crossorigin="anonymous"></script>

  sha256-UTe33acZ78PiBp03/u/vVxeFkmS2rOt9qv3HukgejCg= → bafy.. (with raw codec)

• 🟠 (B) Extend integrity attribute to support CIDs as-is.

  <script src="https://example.com/sw.js" integrity="cid-bafy..." crossorigin="anonymous"></script>

  • As long the referenced asset fits in a single raw block, and the CID describes that block alone, with raw codec.
  • Things that need to be implemented by browser here is multibase, cid, and multihash.
    • Likely that cid needs to be registered at IANA at https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml, as browser specs
    • Unsure if this could be done in userland.
  • 🟠 (C) Things bigger than 2MiB run into Large Blocks problem. Supporting bigger assets require browser to also understand and implement dag-pb and UnixFS, and, have access to intermediate blocks with minimal metadata necessary for verifying the root CID does match the DAG.
    • If the asset was fetched trustlessly, browser already has these blocks. If it was fetched indeserialized form, additional blocks need to be fetched somehow to facilitate verification.

Ref.

• https://www.srihash.org
• https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
• • More context on Block Size limit and Supporting Large Blocks