W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

Re: [Integrity] Signature based subresource integrity?

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 22 Jul 2014 08:45:42 -0700
Message-ID: <CAEeYn8gM2FBBw_FpggDJuk3i9osnzDRuDJjHH7z59=U4NGoakw@mail.gmail.com>
To: Daniel Roesler <diafygi@gmail.com>
Cc: Eduardo Robles Elvira <edulix@agoravoting.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
It's also rather similar to Authenticode, Android package signing, npm
package signing, etc.   It's something that's been done many times
before but without a clear consensus emerging on what exact approach
to take.  It seems likely that there won't be much appetite from the
platform vendors to either adopt someone else's model or invent yet
another one.  And it's significantly more complicated to get this kind
of system correct than just a hash.  e.g. Is code still OK if a
signature verifies, but one of the certificates in the chain has
expired since the signature was made?  Take a look at XAdES
(http://www.w3.org/TR/XAdES/) to see how complex this all gets.

It is very difficult to build the identity metasystem around such a
format.  A hash is simple in identifying "what".  A signature is only
really useful if it identifies "who".  Inventing a new system for
assigning identities to content providers on the Web is another job
I'm not sure anyone wants to sign up for.  We have the web PKI for
TLS, which works reasonably, but I'm not sure anyone's really all that
happy with.  The gains from re-using the same PKI with new
certificates or a trust-on-first-use-model aren't clear - will content
authors understand and apply signatures appropriately in a way that
meaningfully enhances trust?

At the end of the day, this isn't in our current charter for these and
other reasons.  We thought at the very least we would see what kind of
adoption we might see for integrity before thinking about biting off
this much bigger chunk.


On Tue, Jul 22, 2014 at 7:41 AM, Daniel Roesler <diafygi@gmail.com> wrote:
> Thanks for the response. Is there another specification that is
> targeted towards dynamic resources?
> Consider the following example: I trust the creators of webkit.js[1]
> and want to use that library in my website as a resource. However,
> they only distribute the library through a CDN[2], who I do not trust.
> I could re-host the library myself, but that kind of defeats the
> purpose of using a CDN (pre-caching, auto-updating, etc.).
> This is very analogous to Linux package mangers, where often
> developers can't afford host their resource themselves. By signing
> their resource, any repo mirror can host the file and any system can
> safely install the resource from any mirror.
> The biggest use case for something like integrity-through-signing
> would be for FIrefoxOS app developers. Currently, you have to package
> all the resources you need in your app, which leads to a ton of
> duplicated resources on a device. It would be great to have
> dependencies (just like a Linux package manager) so you didn't have to
> package subresources in your app.
> Daniel
> [1] - https://github.com/trevorlinton/webkit.js/tree/master
> [2] - http://cdnjs.com/libraries/webkit.js
> On Tue, Jul 22, 2014 at 2:41 AM, Eduardo Robles Elvira
> <edulix@agoravoting.com> wrote:
>> 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 15:46:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC