- From: Eduardo Robles Elvira <edulix@agoravoting.com>
- Date: Tue, 22 Jul 2014 11:41:19 +0200
- To: Daniel Roesler <diafygi@gmail.com>
- Cc: public-webappsec@w3.org
Hello Daniel: Sure, that's possible. It's called TLS :-P Seriously, that's what TLS was invented for. I would expect that the normal usage of hashed subresources never change. If you link to http://example.com/jquery-1.5.1.min.js and you need to use a newer version, you can put it in another URL and link to it. subresource integrity doesn't seem to be targeted for dynamic subresources. Regards, On Mon, Jul 21, 2014 at 4:26 AM, Daniel Roesler <diafygi@gmail.com> wrote: > Howdy all, > > I'm trying to figure out how I can validate an included remote > javascript file (i.e. subresource) and still allow that file to be > updated by the trusted remote party? > > I know the spec currently just allows you to set a hash of the > expected resource. However, when the trusted remote party updates > their resource, it breaks the integrity and I have to go and update my > site with the new hash (a pain for me). > > To solve this pain point, would it be possible to use signatures as > the method for validating integrity? That way, I could just include > the public key for the remote party in the integrity attribute and > have the browser check some sort of signature sent with the resource > from the remote party. > > Obviously, this would require some sort of cooperation from the remote > party (a Signature header, maybe?), but I would be okay with that > since they are trusted. > > Is there a way to do this in this specification or another specification? > > Thanks! > Daniel > >
Received on Tuesday, 22 July 2014 09:42:16 UTC