[whatwg] window.cipher HTML crypto API draft spec
Jungshik Shin (신정식, 申政湜)
jungshik at google.com
Tue May 24 14:13:26 PDT 2011
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
2011/5/24 Ian Fette (イアンフェッティ) <ifette at google.com>
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
Web Sigining in Action
Re: Web Sigining in Action
JS crypto? (and ensuing thread)
Re: Hash functions (and ensuing thread)
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.
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
2011/5/24 David Dahl <ddahl at mozilla.com>
> ----- Original Message -----
> From: "Jungshik Shin (신정식, 申政湜)" <jungshik at google.com>
> To: "Ian Fette" <ifette at google.com>
> Cc: "David Dahl" <ddahl at mozilla.com>, "WHATWG Proposals" <
> whatwg at lists.whatwg.org>, channy at 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
> it's not sufficient yet to replace various browser-plugins/add-ons used
> 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 <form>, etc.
> > I also wonder what David's proposal has to do with another Mozilla effort
> the area : https://wiki.mozilla.org/Labs/Secret
> The "Secret" project seems to have fizzled out, never getting past the
> brainstorming phase. That being said a lot of the functionality of my
> implementation stems from the Weave (now Sync) project at Mozilla, which
> presumably may have been some of the underpinnings of the "Secret" project -
> at least in theory.
More information about the whatwg