- From: Crispin Cowan <crispin@microsoft.com>
- Date: Mon, 7 Mar 2016 07:46:09 +0000
- To: Mitar <mmitar@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
There are 2 problems with this: 1. You are asking the user to pick a cert. Don't do that, users don't understand certs. 2. The cert is not unique to the asking web site. If you allow certs to be valid for more than one origin, you are inviting phishing attacks. -----Original Message----- From: Mitar [mailto:mmitar@gmail.com] Sent: Sunday, March 6, 2016 1:25 PM To: public-webappsec@w3.org Subject: Alternative proposal for the form signing using client-certificate Hi! I got a lot of great feedback in my initial question about lack of access to client-certificate in browsers. Based on that I came up with a proposal which I think addresses all concerns raised in the previous discussion. Here it is: - let's introduce <input type="signature" name="sig"> form element, available only on HTTPS websites - if this form element is present inside a form, on POST submission browser prompts the user to select the client-certificate using trusted UI - it combines form payload with URL requesting the signature, and site SSL certificate fingerprint, and signs this combined data (maybe we can also automatically include timestamp and some nonce, or some other extra metadata) - stores the result (with added metadata) into the "sig" form field in some format - submits the form Certificate never leaves the browser. Signature cannot be reused elsewhere, it is clear for which webapp it is. But signature can be verified by the 3rd party and it can be legally bound. This is a low risk form element, but high utility in countries where client certificates are provided by the government. This form element cannot really be misused. We might even not prompt the user to select a client certificate if there is only one available. If webapp gets a signature of without user consent or if the user is tricked, such signature does not help the webapp in any way. The verifier would detect the URL (or even SSL fingerprint) mismatch, the same how we detect these days SSL certificate mismatch. So the whole point is that we embedded into signatures enough information so that verifiers can do informed validation of the signature. They have the rules what is a valid signature. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Received on Monday, 7 March 2016 07:46:42 UTC