Re: Web Sigining in Action

2009-03-29 Thread timeless
On Thu, Mar 26, 2009 at 8:49 PM, Channy Yun cha...@gmail.com wrote:
 Japan made own cryptographic algorithm called Camella with Nokia pushing it
 to all browsers.

Funny, I work for Nokia, on a web browser. And I don't recall being
told to care about Camella.

I also don't recall Nokia having a significant presence in Japan.

There are groups trying to get their pet crypto systems into Gecko,
but Camella isn't one that i can find. By contrast, South Korea's SEED
was added to NSS by
https://bugzilla.mozilla.org/show_bug.cgi?id=453234 (there's another
bug about exposing it in PSM, but...).

That said, this group generally doesn't want API definitions, and
every group with which I'm involved where people start w/ API
definitions suffers because it's an awful starting point.

What input is there and what output is actually needed?

form
input id=author
textarea id=message
input type=submit
input id=signature
/form

Supposing you had a very simple form of this kind. Do you ever want to
sign more than one field? i.e. do you need to be able to sign the set
{author}+{message}? Or do you only need to be able to sign {message}.

I'm hoping you only need a signature on {message}.

Is there a *good* reason to allow JavaScript access to signature apis?

if we had:
form signedfield=message
input id=author
textarea id=message
input type=submit
/form

and the browser automatically asked the user to select a key and sign
the message when the user clicked submit, would that be sufficient?

Personally, given how important my signature is, I don't really like
the idea of providing scriptable access to a signing API.

It seems like I'd want to be able to review what I'm signing.

Note that the fact that a bank wants to be able to scramble random
words together is not a good reason to provide a scriptable signing
API, nor is the fact that a bank today will be evil and use a Java
Applet or an ActiveX control.



Re: Web Sigining in Action

2009-03-29 Thread Channy Yun
On Sun, Mar 29, 2009 at 4:41 PM, timeless timel...@gmail.com wrote:

 On Thu, Mar 26, 2009 at 8:49 PM, Channy Yun cha...@gmail.com wrote:
  Japan made own cryptographic algorithm called Camella with Nokia pushing
 it
  to all browsers.

 Funny, I work for Nokia, on a web browser. And I don't recall being
 told to care about Camella.

 I also don't recall Nokia having a significant presence in Japan.

 There are groups trying to get their pet crypto systems into Gecko,
 but Camella isn't one that i can find. By contrast, South Korea's SEED
 was added to NSS by
 https://bugzilla.mozilla.org/show_bug.cgi?id=453234 (there's another
 bug about exposing it in PSM, but...).


Oh. I'm very sorry for my confusion between NTT and Nokia. Camellia was made
by European and Japan joint project made by NTT (
http://en.wikipedia.org/wiki/Camellia_%28cipher%29) and

About adding in Gecko, please refer to as following bugs.
https://bugzilla.mozilla.org/show_bug.cgi?id=361025
https://bugzilla.mozilla.org/show_bug.cgi?id=382292
https://bugzilla.mozilla.org/show_bug.cgi?id=382223

Channy


Re: Web Sigining in Action

2009-03-29 Thread timeless
On Thu, Mar 26, 2009 at 8:49 PM, Channy Yun cha...@gmail.com wrote:
 Japan made own cryptographic algorithm called Camella with Nokia pushing

On Sun, Mar 29, 2009 at 11:16 AM, Channy Yun cha...@gmail.com wrote:
 Oh. I'm very sorry for my confusion between NTT and Nokia. Camellia was made
 by European and Japan joint project made by NTT
 (http://en.wikipedia.org/wiki/Camellia_%28cipher%29) and

Please note that spelling counts. You wrote Camella in your earlier
comment, not Camellia.



Re: Web Sigining in Action

2009-03-26 Thread Channy Yun
Dear Marcos Caceres,

Thanks for your kind reply. Sorry my delay.

 Ian recommended us to continue this discussion in Webapps W/G[6]. Andres
 also has tried another effort to solve issue[7].
 

 can you please send us a better summary.


As you know, most of certificate service consist of three steps: 1. Issuing
of personal certificate 2. Authentication and validation per each
certificate 3. Digital signing for valid text or document.

I meant this full process was lack in web browser right now, anyway many
private or public CAs have did it in web browser. It means they couldn't
help using plug-in method for missing link. I know some of european
government also used plugins (http://www.openoces.org/index.html) as well as
Verisign's private CA service. Actually all of plugins had same functions
and cost in duplicated. In case of Korea, there are over 40 same function
Active X plugin per each CA or PKI companies. If there is good spec. for web
browser, it can be implemented soon.

All browser already had certificate storage that issued personal
certificates can be managed and own PKI library (open source or not) that
validates certificate and does digital signing. Actually   there were
issuing certificate in web browser such as such as text-signing
functions in web browser such as crypto.signText() and Microsoft
capicom.dll.

So I suggested form-based signing such as form signed=signined in HTML5
spec. If web browser count this form, it can be proceeded choosing
certificate, signing text and send to server. Ian thought there are many
apps based consideration not for only HTML spec. He recommended for me to
suggest it in this w/g.




  Rebuilding of Web Signing Profile
  Maybe this long history was recognized by leading people of this group. I
 don’t convince whether the activity of web signing profile was made by this
 purpose or not. But, it seems to integrate with Widget’s digital signature
 and there is no action further.
 

 I dont understand. can you please make your comments against the
 current editor's draft of our spec?


I don't blame for your current widget:digital signature and just wondered
whether web signing profile is limited widget area or not. I still thank
you and member's job for developing current spec and it'll be useful
trust-building among widget vendors, providers and users.

So my suggestion is complete another about your current job and want for w/g
member to consider for future job.


 So I want for you to consider this issue in this working group with new
 baseline and for to browser vendors to join this issue quickly before many
 countries commit a fault as like Korea. Brower’s functions as like
 crypto.signText or IE’s CAPICOM dll were deprecated in right now. So it is
 essential making new standard and implementation them.
 

 I'm not sure what you wan us to do.


Mine is very simple: Finding simple job in web browser to support full
process of digital signing. In view of webapps, all of functions have better
be declared by Javascript interface. It may be similar with old IE's capicom
method http://msdn.microsoft.com/en-us/library/aa388154%28VS.85%29.aspx or
http://docs.sun.com/source/816-6152-10/sgntxt.htm.

Simple scheme is as followng fuctions:

1. issuing and validation of personal certificate
auth.ceritificate.issue()
auth.certificate.revoke()
auth.certificate.validate() for OCSP protocol.

2. digital signing.
auth.certificate.open()
auth.certificate.validate()
auth.signText()
auth.signXML()
auth.send() - xmlhttprequest.send()
auth.close()

e.x. resultString = auth.signText(stringToSign, caOption, [caNameString1,
[caNameString2, . . . ]])

Channy


Re: Web Sigining in Action

2009-03-26 Thread Channy Yun
Dear all,

I agreed Andres said that it is unclear where a certain issue belong apps or
not. I means everyone didn't care about this while many industrial vendors
have made tireless same plugins in web space. Although Anders indicated
there were less certificate applications, there are 14 million users in
Korea and many countries have considered public CA area in web browser.
Japan made own cryptographic algorithm called Camella with Nokia pushing it
to all browsers. It means Japan is interested in offering public CA to all
citizen. European I said.

For several years, innovation from web browsers changed world. It's time to
action not to only thinking and I believe that html5 and webapps w/g can do
this. Frankly speaking, my suggestion is very old, but it's cost-effective
for existing vendors both web browser and plugin based CAs.

Thanks,

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

Daum Developers Network  Affiliates
http://dna.daum.net



On Wed, Mar 25, 2009 at 7:00 AM, Anders Rundgren
anders.rundg...@telia.comwrote:

 I think a problem is that it is unclear where a certain issue belong.

 IMO all of the stuff I wrote about belong to the app-area but some people
 think it is about security only.

 XML protocols in browsers is an app, at least as I see it.

 Anders

 - Original Message -
 From: Marcos Caceres marc...@opera.com
 To: Anders Rundgren anders.rundg...@telia.com
 Cc: channy cha...@gmail.com; WebApps HG public-webapps@w3.org;
 Jungshik Shin
 jungs...@google.com; Gen Kanai g...@mozilla.com; Ian Hickson
 i...@hixie.ch; Thomas
 Roessler t...@w3.org
 Sent: Tuesday, March 24, 2009 22:24
 Subject: Re: Web Sigining in Action


 On Tue, Mar 24, 2009 at 9:37 PM, Anders Rundgren
 anders.rundg...@telia.com wrote:
  Hi Everybody,
  There are simply TONS of issues related to usage of certificates in
  conjunction with a browser. If you want, you can take a peek at the
  current thread client certficates unusable? in mozilla-dev :-)
 
  I personally find it annoying that there are maybe some 100M USB
  memory sticks in circulation that could have been a wonderful container
  for keys but unfortunately it never happened. Well, a few US compaines
  tried to create proprietary solutions with SanDisk but (of course) they
  all failed. Who want to *pay* for a card driver? It is really
  something that you would like the OS to have from the beginning!
 
  What does this have to do with Web Signing you may wonder? Well, IMO we
 need
  to take this in a step-wise fashion and if we can't even get the
 keyring´right, it seems
  that the rest will be of secondary interest. That doesn't say I'm not
 interested in
  Web Signing, I have just put it on the back-burner in favor of key
 storage and
  execution.
 
  The absence of a useful keygen standard is a disaster. Will the
 browser-
  vendors be able to address this issue? I don't expect that.
 
  Regarding Web Signing a large groups of banks have turned to MSFT to get
  this solved. I think they are overly optimistic about MSFT's capability
 and
  interest in this area but it is a good thing that they are trying at
 least :-)
 
  Based on 13 years of experience with eID, I believe most of the web
 standards
  in this are will not come from standardization forums because they have
 proved
  to good for really general purpose stuff, but much less successful for
 applications
  like Web Sign and keygen. A scheme like my current KeyGen2 would not
  take less than 3 years to standardize and the result would probably be
 not be
  very useful anyway. Why? Because there are too many choices and people
  cannot work under such premisses. Whatever keygen or WebSign we will
  get, it will most certainly be an open source effort rather than a
 standard.
 
  What W3C could/should standardize is a way to get XML protocols running
  in a browser and leave the content parts to other groups. IETF's KEYPROV
  will fail as hard as XKMS did if we ignore the browser connection all the
 time.

 I see. thanks for the history. However, what, if anything, should our
 working group do? I don't see anything that is in scope or anything
 directed at any one of our specifications. If we are screwing
 something up somewhere, then please be clear as to where and we will
 do our best to fix it.

 Kind regards,
 Marcos


 --
 Marcos Caceres
 http://datadriven.com.au




Re: Web Sigining in Action

2009-03-24 Thread Anders Rundgren
I think a problem is that it is unclear where a certain issue belong.

IMO all of the stuff I wrote about belong to the app-area but some people
think it is about security only.

XML protocols in browsers is an app, at least as I see it.

Anders

- Original Message - 
From: Marcos Caceres marc...@opera.com
To: Anders Rundgren anders.rundg...@telia.com
Cc: channy cha...@gmail.com; WebApps HG public-webapps@w3.org; 
Jungshik Shin 
jungs...@google.com; Gen Kanai g...@mozilla.com; Ian Hickson 
i...@hixie.ch; Thomas 
Roessler t...@w3.org
Sent: Tuesday, March 24, 2009 22:24
Subject: Re: Web Sigining in Action


On Tue, Mar 24, 2009 at 9:37 PM, Anders Rundgren
anders.rundg...@telia.com wrote:
 Hi Everybody,
 There are simply TONS of issues related to usage of certificates in
 conjunction with a browser. If you want, you can take a peek at the
 current thread client certficates unusable? in mozilla-dev :-)

 I personally find it annoying that there are maybe some 100M USB
 memory sticks in circulation that could have been a wonderful container
 for keys but unfortunately it never happened. Well, a few US compaines
 tried to create proprietary solutions with SanDisk but (of course) they
 all failed. Who want to *pay* for a card driver? It is really
 something that you would like the OS to have from the beginning!

 What does this have to do with Web Signing you may wonder? Well, IMO we need
 to take this in a step-wise fashion and if we can't even get the 
 keyring´right, it seems
 that the rest will be of secondary interest. That doesn't say I'm not 
 interested in
 Web Signing, I have just put it on the back-burner in favor of key storage 
 and
 execution.

 The absence of a useful keygen standard is a disaster. Will the browser-
 vendors be able to address this issue? I don't expect that.

 Regarding Web Signing a large groups of banks have turned to MSFT to get
 this solved. I think they are overly optimistic about MSFT's capability and
 interest in this area but it is a good thing that they are trying at least :-)

 Based on 13 years of experience with eID, I believe most of the web 
 standards
 in this are will not come from standardization forums because they have proved
 to good for really general purpose stuff, but much less successful for 
 applications
 like Web Sign and keygen. A scheme like my current KeyGen2 would not
 take less than 3 years to standardize and the result would probably be not be
 very useful anyway. Why? Because there are too many choices and people
 cannot work under such premisses. Whatever keygen or WebSign we will
 get, it will most certainly be an open source effort rather than a standard.

 What W3C could/should standardize is a way to get XML protocols running
 in a browser and leave the content parts to other groups. IETF's KEYPROV
 will fail as hard as XKMS did if we ignore the browser connection all the 
 time.

I see. thanks for the history. However, what, if anything, should our
working group do? I don't see anything that is in scope or anything
directed at any one of our specifications. If we are screwing
something up somewhere, then please be clear as to where and we will
do our best to fix it.

Kind regards,
Marcos


-- 
Marcos Caceres
http://datadriven.com.au 




Web Sigining in Action

2009-03-22 Thread Channy Yun
Dear Webapps W/G members,

This is Channy Yun, one of web standards evangelists in Korea. I'm so glad
to introduce myself in this working group. I want to get advice from you
about as following my issue. Please don't hesitate to write your thought.

*Motivation*
As someone knows, Korea's browser monoculture has prevented tech innovations
and user's choice [1]. It was caused by wrong implementation of digital
signature by Korean govenment's the law and national PKI system. Its
technique has been based on browser plugin as like Active X and Java applet,
so it also made many security problems on user's PC. Nowadays 15 million
personal certificates were issued and they are used in e-banking, trading
and governmental sites to valid user and transaction in Korea.

Similarly some of European countries also had national PKI system including
Denmark [2], Spain and etc. Denmark's system was opensourced [3], but it is
also based on browser plugins. It were dominated by VeriSign most of
commercial market as like private CA service with issuing personal
certificate and transaction with digital signature.

Many countries want to national CA and offer their service to citizen with
assurance by law[4]. So I thought it needed browser-based web signing model
by bad example of Korea.

*History*
I and some people suggested this issue to WHATWG because it was solved by
browser vendors. Anders Rundgren also did own model of WASP - signing data
in browser sessions[5] and I did adding digital signature in form
processing in HTML5.

As following is history of this issue.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-September/thread.html#7246
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-October/thread.html#7573
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-November/thread.html#7592
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015513.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/thread.html#15522
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/thread.html#18919

Ian recommended us to continue this discussion in Webapps W/G[6]. Andres
also has tried another effort to solve issue[7].

*Rebuilding of Web Signing Profile*
Maybe this long history was recognized by leading people of this group. I
don’t convince whether the activity of web signing profile was made by this
purpose or not. But, it seems to integrate with Widget’s digital signature
and there is no action further.

As you know, the technology situation was very changed in time raising this
issue. Ajax was born and there are many web applications based on open
standards and Web APIs.

So I want for you to consider this issue in this working group with new
baseline and for to browser vendors to join this issue quickly before many
countries commit a fault as like Korea. Brower’s functions as like
crypto.signText or IE’s CAPICOM dll were deprecated in right now. So it is
essential making new standard and implementation them.

*
Reference*
--
[1] http://www.kanai.net/weblog/archive/2007/01/26/00h53m55s
[2] http://www.virk.dk/digital_signatur
[3] http://www.openoces.org/index.html
[4] https://wiki.mozilla.org/CA:Schedule
[5] http://webpki.org/
[6]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018935.html
[7] https://informationcard.net/wiki/index.php/Browser_Integration_WG


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

Daum Developers Network  Affiliates
http://dna.daum.net