- From: Channy Yun <channy@creation.net>
- Date: Thu, 31 Jul 2008 20:33:13 +0900
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 <channy at creation.net> 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 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 10:21 AM, Ian Hickson <ian at 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. >> >> 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 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 >> >> On Wed, 1 Nov 2006, Channy Yun wrote: >> > >> > As I said in other thread, I think digital signature must be >> > standardized for secure and legal assurance of form data and I respect >> > your issuing and great jobs. But, we can simply think this issue in >> > range of this group. Most of forms directly go to web server via >> > urlencoded. If some indicators are given, browsers can execute signing >> > process. >> > >> > For example, >> > >> > <form name="sendmoney" action="/send.cgi" signed="signed"> >> > <input type="text" name="dollars" value="3.00"> >> > <input type="text" name="account" values="1234567890"> >> > <input type="submt" value="Sending Money!"> >> > </form> >> > >> > When an user clicks submit button, the dialog box will be opened for >> > selecting the private certificates to be signed. Server can understand >> > form data and attached signatures signed by browser via SSL. >> > >> > Or it can be applied each forms. >> > >> > <input type="text" name="dollars" value="3.00" signed="signed"> >> > >> > Anyway it is browser's the function of digital signature such as >> > sign.Text() function. This idea make possible to handle easily them via >> > form. >> >> On Tue, 31 Oct 2006, Anders Rundgren wrote: >> > >> > May I try to explain how I look on web-forms and digital signatures? >> > >> > Most people indeed come up with schemes like the one you described >> > because it seems so obvious. >> > >> > I work with a different concept which is not really form-oriented, but >> > rather view-oriented. This is borrowed from what most e-commerce sites >> > use today. First you create an order using arbitrary web methods >> > including <form>. Then you typically input credit card data etc. >> > Eventually you are faced with a consolidate/aggregated purchase >> > transaction request which typically is just an HTML page with *static* >> > information plus an "OK" button. When you hit OK, you do not send the >> > HTML page, only an acknowledge of the request you had on the screen. >> > Now, how does this map into digital signatures? The basic difference >> > with respect to the OK button is that the returned result contains a >> > signature over the view. The actual (internal) transaction data is >> > typically not signed since it is >> > >> > - already is known in advance by the server otherwise >> > it wouldn't have been able to create a view to the user. >> > >> > - may not have any visual representation at all. >> > >> > What's more, the service also does its own calculation of message >> > digests of the transaction request view and is thus able to immediately >> > verify not only the signatures validity but that the user actually had >> > the proper content in his/her browser. The signature is subsequently >> > stored close to the real transaction record for supporting unlikely (but >> > possible), future dispute resolutions. >> > >> > There is an inherent problem with your suggested form: >> > >> > <form name="sendmoney" action="/send.cgi" signed="signed"> >> > <input type="text" name="dollars" value="3.00"> >> > <input type="text" name="account" values="1234567890"> >> > <input type="submt" value="Sending Money!"></form> >> > >> > because in a real-world case it would probably read: >> > >> > <form name="sendmoney" action="/send.cgi" signed="signed"> >> > <input type="text" name="dollars"> >> > <input type="text" name="account"> >> > <input type="submt" value="Sending Money!"></form> >> > >> > which means that you sign data that has not first passed a server's >> > validation. Although XForms can do validation, I doubt XForms are >> > suitable for anything but simple applications. Server-based validation >> > can also cope with transactional issues that XF can't like bookings. >> > >> > Also I wonder what you meant should be sent to the server. The signed >> > attributes only? I think this is a half-baked idea since the rest of >> > the document may contain important data that could affect the user's >> > decision to sign th data. The "fine print" for example :-) If you sign >> > a house contract you don't sign the sales value but a lot of text and >> > conditions. Digital signatures should IMHO afhere to this notion. >> > >> > In case there would be embedded objects like CSS or IMG in the HTML page >> > holding the <form> they should also in some way be signed? Now we have >> > a brand new format: Signed HTML. WASP does not need any specific signed >> > HTML because its method is a bit like S/MIME although in XML. >> > >> > In addition to that there are some cryptographic stuff that needs to be >> > addressed which makes the rather innocent "signed" attribute grow quite >> > a bit. If you look on the WASP CertificateFilter it is a good example >> > of how complex it can be to sign. >> > >> > We also need an attachment feature. It is a bit unclear how that could >> > be met with a <form> based approach unless all input is done in a single >> > form which would be very constraining. >> > >> > To not be stuck with HTML but also allow MS office, PDF Open Document we >> > also need some other mechanism. >> > >> > This is at least how WASP was conceived >> > >> > In case you have an example of a Korean HTML signature, I would be happy >> > to get a copy. >> >> On Wed, 1 Nov 2006, Alexey Feldgendler wrote: >> > >> > What benefit does this provide over simply using HTTPS with a >> > client-side certificate? >> >> On Wed, 1 Nov 2006, Channy Yun wrote: >> > >> > Using HTTPS with a client-side certificate doesn't support digital >> > signature.The digital signature is same with the signing or stamp of >> > contract in real world. Many governments encourage to add digital >> > signature to transactional data (form data). It legally assures data and >> > transactions signed(added digital signature) by user's certificates. >> >> On Wed, 1 Nov 2006, Alexey Feldgendler wrote: >> > >> > The purpose of a digital signature is to certify that the data submitted >> > by the client were not forged by an attacker. HTTPS with a client-side >> > certificate ensures the same. >> >> On Thu, 2 Nov 2006, Anders Rundgren wrote: >> > >> > Digital signatures is as you say just a variation of authentication. >> > The things that the DS people wants to add are: >> > >> > - A "process" that differs from authentication from the user's point of >> > view >> > >> > - A persistent trace of the authenticated operation. This is what the >> > signature adds to the picture. HTTPS with client-side certificates have >> > no connection to content data since it occurs at the transport level. >> > Digital signatures are created at the application-level in the schemes >> > that Channy and I talk about. >> > >> > But it is a fact that strong authentication is an alternative to digital >> > signatures but some of use are trying to change that, not only for legal >> > reasons but for making a difference between "login" and "accept". >> >> [...] >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080731/1cc737a3/attachment.htm>
Received on Thursday, 31 July 2008 04:33:13 UTC