Re: Signed Javascript

If an intermediate solution is widely adopted, such as using hashes for
the time being, what is the predicted magnitude of updating legacy code
when a "final" solution is defined and adoption of that begins?

-----Original Message-----
From: Harry Halpin <hhalpin@w3.org>
Date: Tuesday, December 17, 2013 5:23 PM
To: "Hill, Brad" <bhill@paypal.com>, Richard Barnes <rbarnes@bbn.com>
Cc: "public-web-security@w3.org" <public-web-security@w3.org>
Subject: Re: Signed Javascript
Resent-From: <public-web-security@w3.org>
Resent-Date: Tuesday, December 17, 2013 5:23 PM

>We're appointing Editors on the new sub-resource integrity spec on
>today's WebAppSec call, and I expect we'll have a strawman available soon
>in the new year.
>
>For the moment we plan to simply provide a way to identify a remote
>resource of any type by hash.  To deal with upgrade/fragility issues, a
>mismatch will cause some policy-defined response which, in addition to
>failure to load, might include a fallback to an alternate https resource
>or simply generation of a CSP-style report. (presuming we can find an
>acceptable position on cross-domain information leakage with such, such
>as requiring a Access-Control-Allow-Origin header)
>
>We have deliberately avoided for now the idea of "signing" because the
>questions of identity and authenticity are indeed so thorny.  My feeling
>is to take this one step at a time.  If we get traction with hashes, we
>can think about signatures after.

Received on Wednesday, 18 December 2013 15:35:09 UTC