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

Hi.
for Signed JS part.
I know it is currently out of scope in WG.

HSTS can not be the answer. because it can not verify code integrity.
in ActiveX case, a reviewer review the code and not allowed to change after
code signing.
my concern is how can we verify the javascript code (this is not binary
code) that is actually loaded service provider itself.

script-nonce in WebAppSec CSP 1.1 is good idea.
but I think it has weakness in phishing with proxy of criminal.
how browser identify nonce value is from original or criminal?
I will try to discuss in WebAppSec WG

regards
mountie.

On Wed, Nov 21, 2012 at 2: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].
>
>
>
> On Nov 20, 2012, at 12:20 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
> > For something that allows arbitrary native code execution, it seems
> rather hard to classify things as "features" other than "it runs whatever I
> want"
> >
> > FWIW, my experience is heavy use of CryptoAPI/CNG, WinScard, and custom
> UI. This is then wrapped in a *partially* code signed bundle with a sig by
> one or more trusted authorities. Invocation occurs via BHOs or via direct
> instantiation of the plugin.
> >
> > On Nov 20, 2012 9:13 AM, "Richard L. Barnes" <rbarnes@bbn.com> wrote:
> > Jonathan,
> >
> > Can you clarify what ActiveX features are being used by Korean banks?
> >
> > --Richard
> >
> >
> >
> > On Nov 18, 2012, at 11:40 PM, 전종홍 <hollobit@etri.re.kr> wrote:
> >
> > > Hi, Harry and Web crypto fans.
> > >
> > > Right. ActiveX Replacement(based on HTML5 and Web API) is the one of
> hot issues in Korea.
> > >
> > > It would be good if we will have the F2F meeting in Korea.
> > >
> > > Best Regards,
> > >
> > > --- Jonathan Jeon
> > >
> > > -----Original Message-----
> > > From: Harry Halpin [mailto:hhalpin@w3.org]
> > > Sent: Thursday, November 15, 2012 10:43 PM
> > > To: public-webcrypto@w3.org
> > > Subject: Korean Banking Use-case now an election issue!
> > >
> > >
> > > May the requirement for the ActiveX plug-in for e-Commerce be
> abolished?
> > > See news article (and great video at end!)
> > >
> > > Or do the candidates want to revise the idea? Perhaps after election
> would be a good idea to have that WebCrypto WG f2f meeting in Korea!
> > >
> > >    cheers,
> > >       harry
> > >
> > > [1]
> > >
> http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to-end-outdated-encryption-standard/
> > >
> > >
> > >
> >
> >
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World