Alternative proposal for the form signing using client-certificate


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.



Received on Sunday, 6 March 2016 21:25:46 UTC