W3C home > Mailing lists > Public > public-web-security@w3.org > December 2013

Re: Signed Javascript

From: Fregly, Andrew <afregly@verisign.com>
Date: Wed, 18 Dec 2013 15:33:13 +0000
To: Harry Halpin <hhalpin@w3.org>, "Hill, Brad" <bhill@paypal.com>, "Richard Barnes" <rbarnes@bbn.com>
CC: "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <CED72A92.12361%afregly@verisign.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:20 UTC