Re: [whatwg] window.cipher HTML crypto API draft spec

Hi, all.

I proposed *Web Crypto API community group* in
http://www.w3.org/community/groups/proposed/
If you're interested in this issue, please join us and let's discuss
together.

I thinks there are various oppotunites around WebCrypto API[1] or
DOMCryptAPI[2] etc.

[1] http://html5.creation.net/webcrypto-api/
[2] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

Channy
---------------------
http://www.linkedin.com/in/channy

* Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr
* Daum Developers Network & Affiliates http://dna.daum.net



2011년 5월 25일 오전 6:13, Jungshik Shin (신정식, 申政湜) <jungshik@google.com>님의 말:

> 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 (イアンフェッティ) <ifette@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
> 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 <ddahl@mozilla.com>
>
>>
>> ----- Original Message -----
>> From: "Jungshik Shin (신정식, 申政湜)" <jungshik@google.com>
>> To: "Ian Fette" <ifette@google.com>
>> Cc: "David Dahl" <ddahl@mozilla.com>, "WHATWG Proposals" <
>> whatwg@lists.whatwg.org>, channy@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 <form>, etc.
>>
>> > I also wonder what David's proposal has to do with another Mozilla
>> effort in
>>  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.
>>
>> Regards,
>>
>> David
>>
>
>