Below is my answer to one of the core designers behind HTML5 and their decision to not support digital signatures in HTML5.
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 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. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
