- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Tue, 31 Oct 2006 21:46:16 +0100
Hi Channy, 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. Anders ----- Original Message ----- From: "Channy Yun" <channy@creation.net> To: "Anders Rundgren" <anders.rundgren at telia.com> Cc: <whatwg at lists.whatwg.org> Sent: Tuesday, October 31, 2006 19:24 Subject: Re: [whatwg] Browser Signature Standards Proposal Anders and all, 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. Channy On 9/3/06, Anders Rundgren <anders.rundgren at telia.com> wrote: > F.Y.I. > > I'm sorry about WASP, I was not aware of your activities when I created > the Web Activated Signature Protocol. > > Background: > http://middleware.internet2.edu/pki06/proceedings/rundgren-websigning.ppt > > Minimal technical description: > http://webpki.org/WASP-tutorial.pdf > > The works: > http://webpki.org/WASP-specifications-2006-08-26.zip > > There is [much] more if somebody is interested. > > Anders Rundgren > > > >
Received on Tuesday, 31 October 2006 12:46:16 UTC