Thank you for the reply, David.
It's my mistake to send it without subscribing to the list. To avoid further
splitting the thread, I'm including below my original email here for others
to see (and to be archived).
BTW, while doing so, I'm adding a pointer to a chromium bug with some more
background on PKI and digital signing (in Korea and elsewhere) :
http://crbug.com/73226 (David has already found it and added a comment
there :-)).
Jungshik
2011/5/24 Ian Fette (イアンフェッティ)
I personally find this to be a very interesting and potentially useful
> proposals. One of the problems that we / the web face is a legal requirement
> faced by many Asian banks (esp. Korea) to digitally sign all transactions.
> To meet this requirement, they use ActiveX controls, as the platform doesn't
> really give them the primitives they need. This seems like it should give
> them what they need, but I would be very interested in knowing whether
> there's more that would be needed or whether this would actually suffice.
>
>
The situation in Korea got a bit "better" recently in the sense that some
banks (or government agencies) now have a Firefox extension (with an xpcom
plugin), an npapi plugin, a Safari extension (on Mac OS only), and a Java
applet in addition to ActiveX controls (I can do online banking on Linux and
Mac ! :-)) . Obviously, this 'proliferation' of browser "plugins" is far
from ideal and it'd be great if there's a standard set of API to do what
these 'browser plugins' do.
> It would be good if we can figure out whether this is sufficient for e.g.
> Korean banking requirements, and if not, what else would be necessary. Does
> anyone have contacts with the relevant industry groups?
>
>
Earlier in the thread, JeffH mentioned the following. The first two threads
in his list are relevant to on-line banking/e-commerce/government service
access in Korea and elsewhere.
While that's sorta interesting, there's various use cases that've been
mentioned in various places that the above proposed API doesn't necessarily
address..
Web Sigining in Action
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html
Re: Web Sigining in Action
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0953.html
JS crypto? (and ensuing thread)
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0605.html
Re: Hash functions (and ensuing thread)
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1041.html
It looks like what David proposed seems to be a good start, but I'm afraid
it's not sufficient yet to replace various browser-plugins/add-ons used for
digital sigining and certificate management (as is done in Korea). For
instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
copying to him) has the following proposal.
http://html5.creation.net/webcrypto-api/
It covers the generation of cert request, cert import, smart card event
handling (apparently, in China, smartcards are widely used for on-line
banking) in addition to signing text. 'keygen' (codified in html5) appears
to cover some of needs for cert request and cert issuance, but does not go
all the way (to be useful).
I also wonder what David's proposal has to do with another Mozilla effort in
the area : https://wiki.mozilla.org/Labs/Secret
Jungshik
2011/5/24 David Dahl
>
> - Original Message -
> From: "Jungshik Shin (신정식, 申政湜)"
> To: "Ian Fette"
> Cc: "David Dahl" , "WHATWG Proposals" <
> whatwg@lists.whatwg.org>, cha...@gmail.com
> Sent: Tuesday, May 24, 2011 2:36:01 PM
> Subject: Re: [whatwg] window.cipher HTML crypto API draft spec
>
> Great insight into the situation in Korea, thanks!
>
> > It looks like what David proposed seems to be a good start, but I'm
> afraid
> it's not sufficient yet to replace various browser-plugins/add-ons used
> for
> digital sigining and certificate management (as is done in Korea). For
> instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
> copying to him) has the following proposal.
>
> > http://html5.creation.net/webcrypto-api/
>
> Thank you for the link. I need to read all of these ideas and specs.
>
> > It covers the generation of cert request, cert import, smart card event
> handling (apparently, in China, smartcards are widely used for on-line
> banking) in addition to signing text. 'keygen' (codified in html5) appears
> to cover some of needs for cert request and cert issuance, but does not go
> all the way (to be useful).
>
> yeah, keygen would be so much better as part of an API rather than being
> part of a , etc.
>
> > I also wonder what David's proposal has to do with
