[whatwg] Signatures

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'