FW: SRI and signatures

Some interesting work going on in the WebApp Security group around extending CSP (content security policies) and SRI (sub-resource integrity) with signatures.  (IMO) This would be quite helpful for us for both WP and PWP to make users feel safer about having scripts in their content.

Leonard

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wednesday, November 29, 2017 at 2:29 AM
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Subject: SRI and signatures
Resent-From: <public-webappsec@w3.org>
Resent-Date: Wednesday, November 29, 2017 at 2:24 AM

Hi everyone!

I wanted to take a moment to summarize the current state and next steps of signature support in SRI and open it all up for discussion. This is a follow up to the TPAC discussion.

The idea is more fully detailed in Mike's excellent write up<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikewest%2Fsignature-based-sri&data=02%7C01%7Clrosenth%40adobe.com%7Ce9b66e593e0646584fe308d5371401f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636475481430043422&sdata=AcjpWrVHQDN8P5tia%2BjMOZGtWsR1VdK8QgYLhR8nRk4%3D&reserved=0> but the essential idea is to allow a page to say "check that the resource being loaded is signed by $public-key" and the response to the resource request contains a header that contains the signature on the resource. Current proposal only uses Ed25519.

Currently, there is an implementation in Chrome behind a flag (although, Chrome team is looking into making this an origin trial<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGoogleChrome%2FOriginTrials&data=02%7C01%7Clrosenth%40adobe.com%7Ce9b66e593e0646584fe308d5371401f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636475481430043422&sdata=PQXyrK7Lvn%2Bo2pIQ5XkSmcYg9nA7xyEgEVqex%2BzlQwk%3D&reserved=0>). Chrome's currently looking for web applications instead of experimenting with this and seeing how painful/hard it is. Are there implementors (both browsers and CDNs/websites) interested in trying this out and giving feedback? The current writeup also has a bunch of issues<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikewest%2Fsignature-based-sri%2Fissues&data=02%7C01%7Clrosenth%40adobe.com%7Ce9b66e593e0646584fe308d5371401f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636475481430043422&sdata=hebJ3rhy7PycUyM5qkv2n5FX5FRMdNQ%2BwnShiS%2FmfdU%3D&reserved=0> filed against it; probably the most thriving discussion is on whether the signatures should include the URI path<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikewest%2Fsignature-based-sri%2Fissues%2F5&data=02%7C01%7Clrosenth%40adobe.com%7Ce9b66e593e0646584fe308d5371401f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636475481430043422&sdata=elhY6ZW8J98%2Brhyp9a4vrHte6J3DWmLBJqPG9M%2FuFLQ%3D&reserved=0>.

A second aspect that at least me and Artur are particularly excited about is being able to combine this with CSP. Being able to say "all code running on this page must be signed by $key" is a pretty awesome primitive. The writeup already has some ideas like whitelisting a public key in CSP (similar to how you can whitelist hashes). Feedback on this idea (and other ideas about this in the spec) would be great! Additionally, to make full deployment a reality, inline script support would be pretty critical. It is not clear how to handle inline scripts since SRI currently only talks about remote loads. I would love feedback/thoughts on this! (Github Issue<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikewest%2Fsignature-based-sri%2Fissues%2F10&data=02%7C01%7Clrosenth%40adobe.com%7Ce9b66e593e0646584fe308d5371401f2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636475481430043422&sdata=kTDqEEfbxMfGJJ0SgwcMZYhXw%2Fs51kLLsTybo%2BG7RiQ%3D&reserved=0>)

Happy to discuss more here or on the Github issue; with a slight preference for latter to keep different threads more easily separate. I would really love more input/feedback from the community!


cheers
Dev