<128a01c8f3b6$dadf16b0$82c5a8c0@arport2v>
Current votes: None.
This is a multi-part message in MIME format. ------=_NextPart_000_1287_01C8F3C7.9C7A6E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Channy, A reason why I remain quite pessimistic about "Web Signatures" is the = fact that the signature people have never managed (bothered perhaps?) = getting together to find out what they really want and why they want it. = I have personally invested huge amounts of time researching this issue = and have concluded that there are two "diametrically opposed" ways of = supporting web signatures: One is the traditional method primarily pushed by the US government = where a user creates data and then signs it. Applied to on-line banking: The live signed data constitutes that actual = transaction. Adobe have faithfully reproduced this behavior in their = Acrobat signature software which is a 100 Mb download. The other way is based on how the web actually works today including = on-line transactions and work-flow systems. Applied to on-line banking: The static data presented by the service = constitutes a human-adapted view of a transaction request. In this approach a signature is essentially a PKI-augmented version of = the [in]famous OK button like in: http://webpki.org/WASP-tutorial.pdf So why not support both schemes? Because the complexity of the former = approach is 10-100 times that of the latter. However, since the software industry is rather US focused and thus will = likely lean on local (US) requirements, it seems infeasible raising a = credible web signature standards effort at this stage. It is also worth considering that no standards consortium has to date = ever taken on a security standard with browser bindings. XKMS (to take = an example) probably failed on the market due to the fact that it has no = browser linkage like Microsoft's proprietary CertEnroll. Regards Anders Rundgren ----- Original Message -----=20 From: Channy Yun=20 To: Anders Rundgren=20 Cc: Ian Hickson ; Alexey Feldgendler ; whatwg ; Massimiliano Pala ; Bud = P. Bruegger ; Kemp, David P.=20 Sent: Thursday, July 31, 2008 12:33 Subject: Re: 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 finacial transactions. = But, it has been proccessed 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".=20 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 seucure solution in HTML form method. Channy On Thu, Jul 31, 2008 at 2:41 PM, Anders Rundgren = <anders.rundgren@telia.com> 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" <ian@hixie.ch> To: "Anders Rundgren" <anders.rundgren@telia.com>; "Michael(tm) Smith" = <mikes@opera.com>; <channy@creation.net>; "Alexey Feldgendler" <alexey@feldgendler.ru> Cc: "whatwg" <whatwg@whatwg.org> 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 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=3D"sendmoney" action=3D"/send.cgi" signed=3D"signed"> > <input type=3D"text" name=3D"dollars" value=3D"3.00"> > <input type=3D"text" name=3D"account" values=3D"1234567890"> > <input type=3D"submt" value=3D"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=3D"text" name=3D"dollars" value=3D"3.00" = signed=3D"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 = > 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=3D"sendmoney" action=3D"/send.cgi" signed=3D"signed"> > <input type=3D"text" name=3D"dollars" value=3D"3.00"> > <input type=3D"text" name=3D"account" values=3D"1234567890"> > <input type=3D"submt" value=3D"Sending Money!"></form> > > because in a real-world case it would probably read: > > <form name=3D"sendmoney" action=3D"/send.cgi" signed=3D"signed"> > <input type=3D"text" name=3D"dollars"> > <input type=3D"text" name=3D"account"> > <input type=3D"submt" value=3D"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. = `._.-(,_..'--(,_..'`-.;.' ------=_NextPart_000_1287_01C8F3C7.9C7A6E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1611" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Hi Channy,</FONT></DIV> <DIV><FONT face=3DArial size=3D2>A reason why I remain quite pessimistic = about "Web=20 Signatures" is the fact that the signature people have never managed = (bothered=20 perhaps?) getting together to find out what they really want and why = they want=20 it. I have personally invested huge amounts of time = researching this=20 issue and have concluded that there are two "diametrically opposed" ways = of=20 supporting web signatures:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>One is the traditional method primarily = pushed by=20 the US government where a user creates data and then signs = it.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Applied to on-line banking: The = <EM>live signed=20 data constitutes that actual transaction</EM>. Adobe have = faithfully=20 reproduced this behavior in their Acrobat signature software which = is a 100=20 Mb download.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>The other way is based on how the web = actually=20 works today including on-line transactions and work-flow = systems.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Applied to on-line banking: The = <EM>static</EM>=20 data presented by the service constitutes a human-adapted view of a=20 <EM>transaction request</EM>.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>In this approach a signature is = essentially a=20 PKI-augmented version of the [in]famous OK button like in: <A=20 href=3D"http://webpki.org/WASP-tutorial.pdf">http://webpki.org/WASP-tutor= ial.pdf</A></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>So why not support both schemes? = Because the=20 complexity of the former approach is 10-100 times that of the=20 latter.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>However, since the software industry is = rather US=20 focused and thus will likely lean on local (US) requirements, it seems=20 infeasible raising a credible web signature standards effort at this=20 stage.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>It is also worth considering that no = standards=20 consortium has to date <EM>ever</EM> taken on a security standard = with=20 browser bindings. XKMS (to take an example) probably failed on the = market=20 due to the fact that it has no browser linkage like Microsoft's = proprietary=20 CertEnroll.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV style=3D"FONT: 10pt arial">----- Original Message -----=20 <DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20 title=3Dchanny@creation.net href=3D"mailto:channy@creation.net">Channy = Yun</A>=20 </DIV> <DIV><B>To:</B> <A title=3Danders.rundgren@telia.com=20 href=3D"mailto:anders.rundgren@telia.com">Anders Rundgren</A> </DIV> <DIV><B>Cc:</B> <A title=3Dian@hixie.ch href=3D"mailto:ian@hixie.ch">Ian = Hickson</A>=20 ; <A title=3Dalexey@feldgendler.ru = href=3D"mailto:alexey@feldgendler.ru">Alexey=20 Feldgendler</A> ; <A title=3Dwhatwg@whatwg.org=20 href=3D"mailto:whatwg@whatwg.org">whatwg</A> ; <A = title=3Dpala@cs.dartmouth.edu=20 href=3D"mailto:pala@cs.dartmouth.edu">Massimiliano Pala</A> ; <A=20 title=3Dbud@comune.grosseto.it = href=3D"mailto:bud@comune.grosseto.it">Bud P.=20 Bruegger</A> ; <A title=3DDPKemp@missi.ncsc.mil=20 href=3D"mailto:DPKemp@missi.ncsc.mil">Kemp, David P.</A> </DIV> <DIV><B>Sent:</B> Thursday, July 31, 2008 12:33</DIV> <DIV><B>Subject:</B> Re: Signatures in HTML5</DIV></DIV> <DIV><BR></DIV> <DIV dir=3Dltr>Andres,<BR><BR>Thanks for your long effort in this issue. = I know=20 there is many issues of more secure solution and specification for = finacial=20 transactions. But, it has been proccessed most of bank transaction and = cyber=20 trading in web browser "form". So new protocol and new specification is = not good=20 solution in actual problem. In real world, financial transactions are = already=20 the part of web especially "HTML". <BR><BR>HTML5 is born because of = HTML's=20 innovative usage. If HTML 5 solves actual problems with browser vendors, = it can=20 be done. New spec is very expensive for actual problem of many bank and=20 e-government sites as well as browser vendors. Your job is also = nessasary if=20 bank or government want more seucure solution in HTML form=20 method.<BR><BR>Channy<BR><BR> <DIV class=3Dgmail_quote>On Thu, Jul 31, 2008 at 2:41 PM, Anders = Rundgren <SPAN=20 dir=3Dltr><<A=20 href=3D"mailto:anders.rundgren@telia.com">anders.rundgren@telia.com</A>&g= t;</SPAN>=20 wrote:<BR> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: = rgb(204,204,204) 1px solid">Hi=20 Ian,<BR>I think this decision is OK because a useful signature = facility should=20 IMO not be limited to HTML. It is also more like = an<BR>application than=20 a set of language constructs, at least in my head.<BR><BR>Anyway, = FWIW, I=20 intend to continue my "Web Signature Crusade" in a new forum called=20 Information Card Foundation which is dealing<BR>with another highly=20 browser-related security addition that there indeed is a great need = for:=20 Getting rid of the plague known as<BR>passwords.<BR><BR>Actually there = are=20 other things that also needs to be done and that is the creation of a = standard=20 facility for provisioning<BR>cryptographic keys trough the use of a = browser.=20 Current schemes (including Mozilla's generateCRMFrequest and=20 Microsoft's<BR>CertEnroll) are all over the map as well as lacking = many vital=20 features. Such an effort is also in an advanced state in case=20 anyone<BR>on the distribution list is = interested.<BR><BR>Sincerely<BR>Anders=20 Rundgren<BR><BR>----- Original Message -----<BR>From: "Ian Hickson"=20 <ian@hixie.ch><BR>To: "Anders Rundgren" <<A=20 = href=3D"mailto:anders.rundgren@telia.com">anders.rundgren@telia.com</A>&g= t;;=20 "Michael(tm) Smith" <<A=20 href=3D"mailto:mikes@opera.com">mikes@opera.com</A>>; <<A=20 href=3D"mailto:channy@creation.net">channy@creation.net</A>>;=20 "Alexey<BR>Feldgendler" <<A=20 = href=3D"mailto:alexey@feldgendler.ru">alexey@feldgendler.ru</A>><BR>Cc= :=20 "whatwg" <<A=20 href=3D"mailto:whatwg@whatwg.org">whatwg@whatwg.org</A>><BR>Sent: = Thursday,=20 July 31, 2008 03:21<BR>Subject: Signatures<BR><BR><BR><BR>Over the = years a=20 number of e-mails have been sent to the list about<BR>signatures and = other=20 public key cryptography topics, most of which are<BR>quoted = below.<BR><BR>For=20 a number of reasons, not least of which my lack of expertise in = the<BR>area,=20 the size of the HTML5 spec today, and the low level of demand = for<BR>these=20 features, I have decided to not cover this topic in HTML5, = and<BR>instead rely=20 on other groups to define these features.<BR><BR>I include a = representative=20 sampling of the e-mails sent to the WHATWG on<BR>the topic below, so = that if=20 anyone wishes to work on this topic, they can<BR>use this feedback. I=20 encourage people interested in this topic to approach<BR>the IETF, = where work=20 on these issues has historically taken place.<BR><BR>On Sun, 29 Oct = 2006,=20 Anders Rundgren wrote:<BR>><BR>> It is equally interesting that = W3C=20 intends to start a new browser<BR>> authentication WG but have = excluded=20 digital signatures and key<BR>> provisioning from the charter in = spite of=20 the fact that about 10M people<BR>> today have to use proprietary=20 browser-plugins in order to get their work<BR>> done. Maybe = an answer=20 to that is that this is only happening in the EU<BR>> which in this = particular space is roughly 5 years ahead of the US<BR>> government = and=20 financial industry.<BR><BR>On Mon, 30 Oct 2006, Michael(tm) Smith=20 wrote:<BR>><BR>> The use of proprietary mechanisms (mostly = ActiveX=20 controls) for digital<BR>> signatures is common in Korean sites as = well,=20 including Korean<BR>> government sites.<BR><BR>On Mon, 30 Oct 2006, = Anders=20 Rundgren wrote:<BR>><BR>> That's right. They sure are = proprietary; I was=20 not even able to get the<BR>> Korean e-goverment signature spec = since it is=20 "secret"!<BR><BR>On Tue, 31 Oct 2006, Channy Yun = wrote:<BR>><BR>> Korean=20 mechanism is same with general pki's. Its structure has been<BR>> = followed=20 by pki standards and browser user-interface for certificates.<BR>> = The=20 different things has own 128bit cryptography algorithm so = called<BR>> SEED=20 and adds digital signature for messages to be legal = authorizing.<BR>> This=20 spec is not secret and gives in <A = href=3D"http://www.rootca.or.kr/maine.jsp"=20 target=3D_blank>http://www.rootca.or.kr/maine.jsp</A><BR><BR>On Mon, = 30 Oct=20 2006, Anders Rundgren wrote:<BR>><BR>> I may have been careless = but I=20 could not find the spec of the activeX<BR>> control (or similar) = that is=20 what I refer to as the proprietary<BR>> solution.<BR>><BR>> I = may=20 also have confused Korea with Hongkong who definitely claimed = that<BR>>=20 their scheme requires an NDA. The same goes for the Australian=20 scheme<BR>> which is not public.<BR>><BR>> BTW, the Swedish = and=20 Norwegian government's signature systems are also<BR>> secret since = they=20 are developed by banks.<BR><BR>On Wed, 1 Nov 2006, Channy Yun=20 wrote:<BR>><BR>> As you said, we may not get sufficient = informations to=20 standardize<BR>> digital signature. But, in case of Korea, I'll=20 sufficiently give them.<BR>> The spec. and interface are almost=20 standardized by governmental rules to<BR>> all = vendors.<BR>><BR>> In=20 Korea, the own cryptic algorithm has been encouraged, so = vendors<BR>>=20 couldn't use browser-implemented things such as DES. This is = first<BR>>=20 reason to use activex controls.<BR>><BR>> Second is for digital=20 signature. Legally, all data must be signed by<BR>> user's key. = When the=20 money is sent, it needs to know who sends the<BR>> money. So = activex=20 control has almost same user interface with browser's<BR>> = certificate=20 manager.<BR>><BR>> When an user enters an internet banking site, = activex=20 are embedded.<BR>> User's data by action go to activex control and = are=20 encrypted by SEED<BR>> and signed by user's key. Encrypted and = signed data=20 gives hidden form in<BR>> web page again. When an user submit it, = the data=20 were transferred to web<BR>> server. The server-side application = decrypts=20 and verifies the data and<BR>> proceeds proper actions. Web server=20 transfers the web page by requested<BR>> actions.<BR>><BR>> = First=20 thing is not standardized. National algorithm such as SEED or<BR>> = Camella=20 is problems between browser vendor and its governments. Second<BR>> = can be=20 done such as (re)issue and revocation of personal = certificates,<BR>> the=20 digital signature such as old crypto.sign.Text().<BR>><BR>> As = following=20 is one of this efforts.<BR>> <A=20 = href=3D"http://middleware.internet2.edu/pki06/proceedings/rundgren-websig= ning.ppt"=20 = target=3D_blank>http://middleware.internet2.edu/pki06/proceedings/rundgre= n-websigning.ppt</A><BR><BR>On=20 Wed, 1 Nov 2006, Channy Yun wrote:<BR>><BR>> As I said in other = thread,=20 I think digital signature must be<BR>> standardized for secure and = legal=20 assurance of form data and I respect<BR>> your issuing and great = jobs. But,=20 we can simply think this issue in<BR>> range of this group. Most of = forms=20 directly go to web server via<BR>> urlencoded. If some indicators = are=20 given, browsers can execute signing<BR>> process.<BR>><BR>> = For=20 example,<BR>><BR>> <form name=3D"sendmoney" = action=3D"/send.cgi"=20 signed=3D"signed"><BR>> <input type=3D"text" name=3D"dollars" = value=3D"3.00"><BR>> <input type=3D"text" name=3D"account"=20 values=3D"1234567890"><BR>> <input type=3D"submt" = value=3D"Sending=20 Money!"><BR>> </form><BR>><BR>> When an user clicks = submit=20 button, the dialog box will be opened for<BR>> selecting the = private=20 certificates to be signed. Server can understand<BR>> form data and = attached signatures signed by browser via SSL.<BR>><BR>> Or it = can be=20 applied each forms.<BR>><BR>> <input type=3D"text" = name=3D"dollars"=20 value=3D"3.00" signed=3D"signed"><BR>><BR>> Anyway it is = browser's the=20 function of digital signature such as<BR>> sign.Text() function. = This idea=20 make possible to handle easily them via<BR>> form.<BR><BR>On Tue, = 31 Oct=20 2006, Anders Rundgren wrote:<BR>><BR>> May I try to explain how = I look=20 on web-forms and digital signatures?<BR>><BR>> Most people = indeed come=20 up with schemes like the one you described<BR>> because it seems so = obvious.<BR>><BR>> I work with a different concept which is not = really=20 form-oriented, but<BR>> rather view-oriented. This is = borrowed from=20 what most e-commerce sites<BR>> use today. First you create = an order=20 using arbitrary web methods<BR>> including <form>. Then = you=20 typically input credit card data etc.<BR>> Eventually you are faced = with a=20 consolidate/aggregated purchase<BR>> transaction request which = typically is=20 just an HTML page with *static*<BR>> information plus an "OK" = button.=20 When you hit OK, you do not send the<BR>> HTML page, only an=20 acknowledge of the request you had on the screen.<BR>> Now, how = does this=20 map into digital signatures? The basic difference<BR>> with respect = to the=20 OK button is that the returned result contains a<BR>> signature = over the=20 view. The actual (internal) transaction data is<BR>> = typically not=20 signed since it is<BR>><BR>> - already is known in advance by = the server=20 otherwise<BR>> it wouldn't have been able to create a view = to the=20 user.<BR>><BR>> - may not have any visual representation at=20 all.<BR>><BR>> What's more, the service also does its own = calculation of=20 message<BR>> digests of the transaction request view and is thus = able to=20 immediately<BR>> verify not only the signatures validity but that = the user=20 actually had<BR>> the proper content in his/her browser. The=20 signature is subsequently<BR>> stored close to the real transaction = record=20 for supporting unlikely (but<BR>> possible), future dispute=20 resolutions.<BR>><BR>> There is an inherent problem with your = suggested=20 form:<BR>><BR>> <form name=3D"sendmoney" action=3D"/send.cgi" = signed=3D"signed"><BR>> <input type=3D"text" name=3D"dollars" = value=3D"3.00"><BR>> <input type=3D"text" name=3D"account"=20 values=3D"1234567890"><BR>> <input type=3D"submt" = value=3D"Sending=20 Money!"></form><BR>><BR>> because in a real-world case = it would=20 probably read:<BR>><BR>> <form name=3D"sendmoney" = action=3D"/send.cgi"=20 signed=3D"signed"><BR>> <input type=3D"text" = name=3D"dollars"><BR>>=20 <input type=3D"text" name=3D"account"><BR>> <input = type=3D"submt"=20 value=3D"Sending Money!"></form><BR>><BR>> which means = that you=20 sign data that has not first passed a server's<BR>> validation.=20 Although XForms can do validation, I doubt XForms are<BR>> = suitable=20 for anything but simple applications. Server-based validation<BR>> = can also=20 cope with transactional issues that XF can't like = bookings.<BR>><BR>>=20 Also I wonder what you meant should be sent to the server. The = signed<BR>>=20 attributes only? I think this is a half-baked idea since the = rest=20 of<BR>> the document may contain important data that could affect = the=20 user's<BR>> decision to sign th data. The "fine print" for = example=20 :-) If you sign<BR>> a house contract you don't sign the sales = value but a=20 lot of text and<BR>> conditions. Digital signatures should = IMHO=20 afhere to this notion.<BR>><BR>> In case there would be embedded = objects=20 like CSS or IMG in the HTML page<BR>> holding the <form> they = should=20 also in some way be signed? Now we have<BR>> a brand new = format:=20 Signed HTML. WASP does not need any specific signed<BR>> HTML = because its=20 method is a bit like S/MIME although in XML.<BR>><BR>> In = addition to=20 that there are some cryptographic stuff that needs to be<BR>> = addressed=20 which makes the rather innocent "signed" attribute grow quite<BR>> = a bit.=20 If you look on the WASP CertificateFilter it is a good = example<BR>>=20 of how complex it can be to sign.<BR>><BR>> We also need an = attachment=20 feature. It is a bit unclear how that could<BR>> be met with = a=20 <form> based approach unless all input is done in a = single<BR>> form=20 which would be very constraining.<BR>><BR>> To not be stuck with = HTML=20 but also allow MS office, PDF Open Document we<BR>> also need some = other=20 mechanism.<BR>><BR>> This is at least how WASP was=20 conceived<BR>><BR>> In case you have an example of a Korean HTML = signature, I would be happy<BR>> to get a copy.<BR><BR>On Wed, 1 = Nov 2006,=20 Alexey Feldgendler wrote:<BR>><BR>> What benefit does this = provide over=20 simply using HTTPS with a<BR>> client-side certificate?<BR><BR>On = Wed, 1=20 Nov 2006, Channy Yun wrote:<BR>><BR>> Using HTTPS with a = client-side=20 certificate doesn't support digital<BR>> signature.The digital = signature is=20 same with the signing or stamp of<BR>> contract in real world. Many = governments encourage to add digital<BR>> signature to = transactional data=20 (form data). It legally assures data and<BR>> transactions = signed(added=20 digital signature) by user's certificates.<BR><BR>On Wed, 1 Nov 2006, = Alexey=20 Feldgendler wrote:<BR>><BR>> The purpose of a digital signature = is to=20 certify that the data submitted<BR>> by the client were not forged = by an=20 attacker. HTTPS with a client-side<BR>> certificate ensures the=20 same.<BR><BR>On Thu, 2 Nov 2006, Anders Rundgren = wrote:<BR>><BR>>=20 Digital signatures is as you say just a variation of = authentication.<BR>>=20 The things that the DS people wants to add are:<BR>><BR>> - A = "process"=20 that differs from authentication from the user's point of<BR>>=20 view<BR>><BR>> - A persistent trace of the authenticated = operation.=20 This is what the<BR>> signature adds to the picture. = HTTPS with=20 client-side certificates have<BR>> no connection to content data = since it=20 occurs at the transport level.<BR>> Digital signatures are created = at the=20 application-level in the schemes<BR>> that Channy and I talk=20 about.<BR>><BR>> But it is a fact that strong authentication is = an=20 alternative to digital<BR>> signatures but some of use are trying = to change=20 that, not only for legal<BR>> reasons but for making a difference = between=20 "login" and "accept".<BR><BR>[...]<BR><FONT = color=3D#888888><BR>--<BR>Ian=20 Hickson U+1047E = =20 )\._.,--....,'``. =20 fL<BR><A href=3D"http://ln.hixie.ch/"=20 target=3D_blank>http://ln.hixie.ch/</A> U+263A = =20 /, _.. \ = _\=20 ;`._ ,.<BR>Things that are impossible just take longer. =20 = `._.-(,_..'--(,_..'`-.;.'<BR><BR></FONT></BLOCKQUOTE></DIV><BR></DIV></BO= DY></HTML> ------=_NextPart_000_1287_01C8F3C7.9C7A6E90--