Re: [whatwg] Signatures in HTML5
Ian, Anyway I thank you for your careful consideration and encouragement of another activities. Basically web signature must be implemented by browser venders because of an example of XKMS's fail that Anders indicated. So we have to consider how to do is cost effective and I think form processing with classical Netscape's crypto.signText or MS's CertEnroll. Broweser vendor's cost will be cheap rather than Anders's WASP or other methods. I couldn't find proper position to treat this issue. Also W3C don't give an opportunity to join as individual. (We must make another WHATWG like activity? It's kidding.) I want for browser vendors to be interested in this issue becasue many Asian and European government made own CA and want to do now. The solution depends on only old and security risky Plugin method such as Java and ActiveX. If anyone knows good positions or opinion to discuss this issue, please let me know. Channy - http://www.linkedin.com/in/channy Daum Developers Network Affiliates http://dna.daum.net On Sat, Mar 21, 2009 at 7:54 AM, Ian Hickson i...@hixie.ch wrote: On Thu, Jul 31, 2008 at 10:21 AM, Ian Hickson i...@hixie.ch wrote: Over the years a number of e-mails have been sent to the list about signatures and other public key cryptography topics, most of which are quoted below. For a number of reasons, not least of which my lack of expertise in the area, the size of the HTML5 spec today, and the low level of demand for these features, I have decided to not cover this topic in HTML5, and instead rely on other groups to define these features. Since I wrote the above, a couple of people have reiterated their desire for HTML5 to address this issue. I would like to encourage people interested in this to approach the W3C or IETF and develop this as an independent technology. The expertise required for this is not the same as the expertise required for other features in HTML5, and it would be a mistake for such sensitive technology to not be written by experts in the signature and security field. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Signatures in HTML5
Andres, Thanks for your long effort in this issue. I know there is many issues of more secure solution and specification for financial transactions. But, it has been processed most of bank transaction and cyber trading in web browser form. So new protocol and new specification is not good solution in actual problem. In real world, financial transactions are already the part of web especially HTML. HTML5 is born because of HTML's innovative usage. If HTML 5 solves actual problems with browser vendors, it can be done. New spec is very expensive for actual problem of many bank and e-government sites as well as browser vendors. Your job is also nessasary if bank or government want more secure solution rather than HTML form method. Channy On Thu, Jul 31, 2008 at 2:41 PM, Anders Rundgren [EMAIL PROTECTED]wrote: Hi Ian, I think this decision is OK because a useful signature facility should IMO not be limited to HTML. It is also more like an application than a set of language constructs, at least in my head. Anyway, FWIW, I intend to continue my Web Signature Crusade in a new forum called Information Card Foundation which is dealing with another highly browser-related security addition that there indeed is a great need for: Getting rid of the plague known as passwords. Actually there are other things that also needs to be done and that is the creation of a standard facility for provisioning cryptographic keys trough the use of a browser. Current schemes (including Mozilla's generateCRMFrequest and Microsoft's CertEnroll) are all over the map as well as lacking many vital features. Such an effort is also in an advanced state in case anyone on the distribution list is interested. Sincerely Anders Rundgren - Original Message - From: Ian Hickson [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED]; Michael(tm) Smith [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alexey Feldgendler [EMAIL PROTECTED] Cc: whatwg [EMAIL PROTECTED] Sent: Thursday, July 31, 2008 03:21 Subject: Signatures Over the years a number of e-mails have been sent to the list about signatures and other public key cryptography topics, most of which are quoted below. For a number of reasons, not least of which my lack of expertise in the area, the size of the HTML5 spec today, and the low level of demand for these features, I have decided to not cover this topic in HTML5, and instead rely on other groups to define these features. I include a representative sampling of the e-mails sent to the WHATWG on the topic below, so that if anyone wishes to work on this topic, they can use this feedback. I encourage people interested in this topic to approach the IETF, where work on these issues has historically taken place. On Sun, 29 Oct 2006, Anders Rundgren wrote: It is equally interesting that W3C intends to start a new browser authentication WG but have excluded digital signatures and key provisioning from the charter in spite of the fact that about 10M people today have to use proprietary browser-plugins in order to get their work done. Maybe an answer to that is that this is only happening in the EU which in this particular space is roughly 5 years ahead of the US government and financial industry. On Mon, 30 Oct 2006, Michael(tm) Smith wrote: The use of proprietary mechanisms (mostly ActiveX controls) for digital signatures is common in Korean sites as well, including Korean government sites. On Mon, 30 Oct 2006, Anders Rundgren wrote: That's right. They sure are proprietary; I was not even able to get the Korean e-goverment signature spec since it is secret! On Tue, 31 Oct 2006, Channy Yun wrote: Korean mechanism is same with general pki's. Its structure has been followed by pki standards and browser user-interface for certificates. The different things has own 128bit cryptography algorithm so called SEED and adds digital signature for messages to be legal authorizing. This spec is not secret and gives in http://www.rootca.or.kr/maine.jsp On Mon, 30 Oct 2006, Anders Rundgren wrote: I may have been careless but I could not find the spec of the activeX control (or similar) that is what I refer to as the proprietary solution. I may also have confused Korea with Hongkong who definitely claimed that their scheme requires an NDA. The same goes for the Australian scheme which is not public. BTW, the Swedish and Norwegian government's signature systems are also secret since they are developed by banks. On Wed, 1 Nov 2006, Channy Yun wrote: As you said, we may not get sufficient informations to standardize digital signature. But, in case of Korea, I'll sufficiently give them. The spec. and interface are almost standardized by governmental rules to all vendors. In Korea, the own cryptic algorithm has been encouraged, so vendors couldn't use browser-implemented things such as DES. This is first reason to use
Re: [whatwg] Signatures
Thanks for your follow up about long silence issue. In my understanding, the implementation guide of browsers is most important part of HTML5. As you know, web browsers have offered the authentication of client certificate over SSL per web site. It is widely used by many companies and universities based on VeriSign products or private CA such as MIT. It's more secure than traditional id and password system. It's surely part of user experience of web browser based on PKI technology. In addition, as following requirement has been widely used in European and Asian country with national PKI system for financial transactions. All of them are required of plugin based tool such as active x and java applet. Why do that? Because there is no function in browsers to handle them. The national PKI system has own certificate issuing process to citizen with face-to-face meeting. And it requires to submit ones client certificate for e-government and financial transaction with digital signature per each signature. submit ones client certificate is traditional SSL authentication and digital signature is new requirement. In fact, ActiveX and Java plugin are needed for digital signature. But, digital signature is not new one for web browsers. We already knew and experienced it by Netscape's crypto.signText() and Microsoft CAPICOM dll. If digital signature was required in old browser with cryto.signText, the browser prompted windows that get password of client certificate. After authentication, it returned encrypted message signed by client certificate. If we can submit returned encrypted message in form via SSL, the technical requirement is sufficient for all national PKI system. Especially, Camellia (Japanese and European official cryptographic algorithm) already implemented in Open SSL for web browsers. Most of them is ready. I just wanted to make implementation guide of digital signature in HTML5. If form has signed attribute, web browsers must prompt same window of crypto.signText action and encrypt form data with digital signature, and return it into signedmessage hidden value. If signed form is submitted to server via SSL, web server can decrypt form data signed by client certificate and check validation and insured transaction by each country's law. It's very simple process and actually these are now processed by many country. At last, there is no function and guideline of digital signature in web browser, they cannot help using ActiveX and Java plugin. I think HTML5 must be actual solution in actual problem like this. New standards such as IETF or W3C XSIG are not good solution for real problem right now. Please add sign attribute in form and guide to add digital signature function as like crypto.signText action in HTML 5. If others want to make spec. of more secure than browser based digital signature in HTML5, it can go to IETF or other body. Please reconsider that. Channy On Thu, Jul 31, 2008 at 7:19 PM, Channy Yun [EMAIL PROTECTED] wrote: Thanks for your follow up about long silence issue. In my understanding, the implementation guide of browsers is most important part of HTML5. As you know, web browsers have offered the authentication of client certificate over SSL per web site. It is widely used by many companies and universities based on VeriSign products or private CA such as MIT. It's more secure than traditional id and password system. It's surely part of user experience of web browser based on PKI technology. In addition, as following requirement has been widely used in European and Asian country with national PKI system for financial transactions. All of them are required of plugin based tool such as active x and java applet. Why do that? Because there is no function in browsers to handle them. The national PKI system has own certificate issuing process to citizen with face-to-face meeting. And it requires to submit ones client certificate for e-government and financial transaction with digital signature per each signature. submit ones client certificate is traditional SSL authentication and digital signature is new requirement. In fact, ActiveX and Java plugin are needed for digital signature. But, digital signature is not new one for web browsers. We already knew and experienced it by Netscape's crypto.signText() and Microsoft CAPICOM dll. If digital signature was required in old browser with cryto.signText, the browser prompted windows that get password of client certificate. After authentication, it returned encrypted message signed by client certificate. If we can submit returned encrypted message in form via SSL, the technical requirement is sufficient for all national PKI system. Especially, Camellia (Japanese and European official cryptographic algorithm) already implemented in Open SSL for web browsers. Most of them is ready. I just wanted to make implementation guide of digital signature in HTML5. If form has signed attribute, web browsers
Re: [whatwg] Lack of standard for digital signatures [was Joe Clark's Criticisms of the WHATWG and HTML 5]
Anders, As you said, we may not get sufficient informations to standardize digital signature. But, in case of Korea, I'll sufficiently give them. The spec. and interface are almost standardized by governmental rules to all vendors. In Korea, the own cryptic algorithm has been encouraged, so vendors couldn't use browser-implemented things such as DES. This is first reason to use activex controls. Second is for digital signature. Legally, all data must be signed by user's key. When the money is sent, it needs to know who sends the money. So activex control has almost same user interface with browser's certificate manager. When an user enters an internet banking site, activex are embedded. User's data by action go to activex control and are encrypted by SEED and signed by user's key. Encrypted and signed data gives hidden form in web page again. When an user submit it, the data were transferred to web server. The server-side application decrypts and verifies the data and proceeds proper actions. Web server transfers the web page by requested actions. First thing is not standardized. National algorithm such as SEED or Camella is problems between browser vendor and its governments. Second can be done such as (re)issue and revocation of personal certificates, the digital signature such as old crypto.sign.Text(). As following is one of this efforts. http://middleware.internet2.edu/pki06/proceedings/rundgren-websigning.ppt Channy On 10/31/06, Anders Rundgren [EMAIL PROTECTED] wrote: The use of proprietary mechanisms (mostly ActiveX controls) for digital signatures is common in Korean sites as well, including Korean government sites. That's right. They sure are proprietary; I was not even able to get the Korean e-goverment signature spec since it is secret! Korean mechanism is same with general pki's. Its structure has been followed by pki standards and browser user-interface for certificates. The different things has own 128bit cryptography algorithm so called SEED and adds digital signature for messages to be legal authorizing. This spec is not secret and gives in http://www.rootca.or.kr/maine.jsp Dear Channy, I may have been careless but I could not find the spec of the activeX control (or similar) that is what I refer to as the proprietary solution. I may also have confused Korea with Hongkong who definitely claimed that their scheme requires an NDA. The same goes for the Australian scheme which is not public. BTW, the Swedish and Norwegian government's signature systems are also secret since they are developed by banks. Anders
Re: [whatwg] Lack of standard for digital signatures [was Joe Clark's Criticisms of the WHATWG and HTML 5]
On 10/30/06, Anders Rundgren [EMAIL PROTECTED] wrote: Michael(tm) Smith wrote: It is equally interesting that W3C intends to start a new browser authentication WG but have excluded digital signatures and key provisioning from the charter in spite of the fact that about 10M people today have to use proprietary browser-plugins in order to get their work done. Maybe an answer to that is that this is only happening in the EU which in this particular space is roughly 5 years ahead of the US government and financial industry. The use of proprietary mechanisms (mostly ActiveX controls) for digital signatures is common in Korean sites as well, including Korean government sites. That's right. They sure are proprietary; I was not even able to get the Korean e-goverment signature spec since it is secret! Anders Rundgren Korean mechanism is same with general pki's. Its structure has been followed by pki standards and browser user-interface for certificates. The different things has own 128bit cryptography algorithm so called SEED and adds digital signature for messages to be legal authorizing. This spec is not secret and gives in http://www.rootca.or.kr/maine.jsp Channy
[whatwg] Wrong sample code in 4.9.1 of Web Application 1.0 spec
Dear WHATWG,
As you know, Bon Echo Alpha3 starts to support client-side session and
persistent storage in Web Application 1.0 spec made by WHATWG. But, as
following sample code of 4.9.1 doesn't work in Bon Echo Alpha 3.
p
You have viewed this page
span id=countan untold number of/span
time(s).
/p
script
var storage = globalStorage['example.com'];
if (!storage.pageLoadCount)
storage.pageLoadCount = 0;
storage.pageLoadCount += 1;
document.getElementById('count').textContent = storage.pageLoadCount;
/script
Only one line must be fixed.
-storage.pageLoadCount += 1;
+storage.pageLoadCount = parseInt(storage.pageLoadCount) + 1;
It alway retruns string so it must be parsed to number.
I am not sure whether there is bug from spec or firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=340072
http://channy.creation.net/work/firefox/domstorage/
Channy
-
Seokchan Yun, Mozilla Korean Community
http://www.creation.net
[whatwg] W3C's Rich Web Client Activity and Web Application W/G
Dear whatwg folks, At last W3C announced a charter of Web Application W/G and Rich Web Client Activity Proposal. As you know, this activitiy will be started in September, 2005. According to charter, they included standardzation of all RIA technology (XUL, XAML, MXML, XBL and APIs) and combination with server programming (ECMAScript including Ajax, C#, Ruby etc.) And this working group consists of Format Task Force, API Task Force and Common deliverables. They have a plan of Ajax standardization with DOM w/g. How about this action? I wonder whatwg's action to this activity. Channy Mozilla Korean Community http://www.mozilla.or.kr
