W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: Korean Banking Use-case now an election issue!

From: Richard L. Barnes <rbarnes@bbn.com>
Date: Tue, 20 Nov 2012 13:27:26 -0500
Cc: (wrong string) „…™ <hollobit@etri.re.kr>, public-webcrypto@w3.org, Harry Halpin <hhalpin@w3.org>
Message-Id: <768E5B95-E827-474D-A28D-BCE718494761@bbn.com>
To: Ryan Sleevi <sleevi@google.com>

On Nov 20, 2012, at 1:25 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Tue, Nov 20, 2012 at 9:39 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
>> So ignoring the UI part, the requirements would be something like:
>> 1. Access to crypto primitives
>> 2. Access to smart cards
>> 3. Signed JS
>> My impression of scoping is that (1) is definitely this WG, (2) might be, partly, and (3) is currently out of scope.
>> On (3): It seems that this was the major point of contention at the F2F.  IIRC, Mountie gave the impression that he thought that verifying signed JS should be in scope of this WG.  EKR's position was that if this group is about a JS crypto api, then verifying signed JS must be out of scope, since the JS doing the verification would need to be signed/verified, creating a circular dependency.
>> I tend to agree with EKR on this point, but the question of how to do signed JS seems worth solving nonetheless.  It seems like it can be addressed in part using things from WebSec/WebAppSec, namely HSTS (using TLS as the "signature").  If that's not sufficient (and I would wonder why not), then it seems like you would need to have the browser do some verification, e.g., by doing S/MIME over HTTP[S].
> I strongly oppose adding signed JS to this groups work, for the many
> reasons raised during the face to face, both in terms of the web
> security model, and in terms of the threat model that was presented
> that Signed JS was supposed to defend against.
> While academically appealing, I do not believe there has been an
> actual demonstrated need for it (eg: there have been no reasonable
> threat model that any of the proposed semantics would defend against).
> Attempts to introduce signed script in the past [1] have continually
> shown the evolving nature of the threats require a comprehensive
> re-thinking of the JS VMs and execution model, a position I'm
> categorically able to say this group should not be involved in, given
> how unfamiliar things such as "Same Origin Policy" have been for
> members.
> [1] http://www.mozilla.org/projects/security/components/signed-scripts.html

Indeed, I was trying to make the argument that signed JS is outside the scope of this group's work.  So if work is to be done on it, it needs to happen elsewhere.  Sorry if that wasn't clear.

Received on Tuesday, 20 November 2012 18:28:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC