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

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

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 20 Nov 2012 10:25:35 -0800
Message-ID: <CACvaWvaL0XfVeP--D1G4eSCQZgtBO83pJNiiPpH=G+s4kXLm5A@mail.gmail.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Cc: (wrong string) „…™ <hollobit@etri.re.kr>, public-webcrypto@w3.org, Harry Halpin <hhalpin@w3.org>
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

[1] http://www.mozilla.org/projects/security/components/signed-scripts.html
Received on Tuesday, 20 November 2012 18:26:03 UTC

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