W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: Using client certificates for signing

From: Ángel González <angel@16bits.net>
Date: Fri, 26 Feb 2016 00:20:41 +0100
Message-ID: <1456442441.11456.8.camel@16bits.net>
To: Mitar <mmitar@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Mitar wrote:
> Hi!
> I am glad we agree. Because I do a prompt like: "Site X would like
> you
> to sign a form. Y/N [more]" and if you would click more you would see
> the form content being submitted. Key/value pairs as you describe.
> So it seems the question is only if we display data automatically, or
> do the users have to click "more".

I'd favor being explicit about what you are signing. After all, if you
are legally signing it, it would be important, doesn't it?

I don't think the UA could make the decision. Specially since eg.
javascript could have changed the field values just before submit.

(I'm sure most people don't read most paper contracts before signing
either, but that's no excuse for not expecting them to do so)

> > 
> > The UA may perfectly only offer it for websites configured for this
> > certificate.
> How would that configuration be done?

I was thinking in a list in your certificate window, where you could
input either exact domains or wildcards (eg. *.gov.$CC)

The aim is to counter the problem of “any website could query your
identity”, as you need to manually empower them to do so.

> > A novelty is that a page which supported this should have readable
> > field names, while currently they are not exposed to the user.
> We could also make it so that any fields which start with _ are not
> part of the signed content, are not displayed to the user, but they
> are still send with the form. Or, we could have a field <signature
> for="field1-name field2-name"> and only those fields would be
> displayed and signed.

I'm not convinced about the use cases of partially signing some fields.
But I'm open to such variants.

Received on Thursday, 25 February 2016 23:21:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC