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

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

From: Mountie Lee <mountie.lee@mw2.or.kr>
Date: Wed, 21 Nov 2012 14:06:45 +0900
Message-ID: <CAE-+aYJsaosGdJ3ENS-v9K_UvUuWy+dmszFDkWRuzu7jcR7kKQ@mail.gmail.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Cc: 전종홍 <hollobit@etri.re.kr>, Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Hi.
let me list up the required features in Korean Banks.

1. identity user
- digital certificate is normally used to identify user
- the certificate is issued by strong user verification mechanism with Face
to Face
- WebCrypto API need to touch certificate issues now.

2. authenticate user
- verify user who has valid ownership of private key associated digital
certificate.
- private key is stored at local folder, USB Storage or Smartcard.
- PKCS#11 can be used for accessing smartcard.

3. identify service provider
- ActiveX Transmission encryption over HTTP is co-exist with SSL.
- EV-SSL can be good replacement.

4. verify application integrity of service provider
- normally activeX code sign verification mechanisms is used.
- Korean members are now discussing about script nonce (
https://dvcs.w3.org/hg/**content-security-policy/raw-**
file/tip/csp-specification.**dev.html#script-nonce--**experimental<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-nonce--experimental>)
and Signed WebApp with XMLDSIG(http://www.w3.org/TR/widgets-digsig/)
- javascript is now part of important infrastructure. we can not trust
browser sandbox security itself (we know iPhone jailbreak case)
- CSP in WebAppSec WG mentioned "defense-in-depth".
- if possible and even if it can not be the perfect solution, we need to
add more security layer.
- I think WebAppSec WG did not deeply consider using cryptography
technology in user agent level.

5. Encrypt Transmission Data
- current SSL/TLS is NOT enough.
- SSL session is established out side of browser sandbox. means the data is
stored somewhere of user environment before entering SSL turnnel
- Korean Banking need End to End encryption. encrypt data inside of sandbox
with public/certificate of service provider.
- I think with current API spec, it can be implemented.

6. Non-Repudiation
- the most important feature.
- digital signature can be answer.
- to be non-repudiable, we need additional discussions about certificate
(certificate enrollment, keyStorage location, interfacing with P11 enabled
smartcard)

7. etc.
- API need to access X509 certificate extensions
- API need to handle encoding specific text in X509 extensions.

On Wed, Nov 21, 2012 at 2:12 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

Received on Wednesday, 21 November 2012 05:07:30 UTC

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