Re: Using client certificates for signing

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".

> The UA may perfectly only offer it for websites configured for this certificate.

How would that configuration be done?

> 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.


Mitar

On Wed, Feb 24, 2016 at 4:07 PM, Ángel González <angel@16bits.net> wrote:
> Crispin Cowan writes:
>> I'm convinced. Those prompts are useless. "Dear user. Would you like
>> to <crypto blah blah blah> Y/N?" is in general a useless prompt.
>> Users only understand in-context prompts like "Would you like to buy
>> <FOO> from <merchant.com> for <$BAR>?" Having the browser ask the
>> user a question about crypto is a guaranteed failure.
>>
>> Perhaps I've misunderstood and you have some way to deliver an in-
>> context prompt. Let's here that. But a generic crypto prompt is not
>> going to happen.
>
> I disagree.
> I concur that a generic “Do you want to sign XYZ?” prompt is annoying
> and pretty useless. Many users will click through it without caring,
> while others will find that not enough detail is provided.
>
> I would draft the question to the user detailing the contents of *what*
> they are signing in a quite user-readable way. For example:
>
> The request to the website https://citizenpetitions.gov can be signed
> with your «Government eID for John Doe»:
>
> Date: 24 February 2016 22:01:00 GMTSignatory: John Doe
> Passport ID: 123456
>
> Petition number: 8010dd3
> Text: Please do not deprecate <keygen tag>!
>
>
>   +---------+  +----------------------------+
>   | Sign it |  | I do not want to sign this |
>   +---------+  +----------------------------+
>
>
>
> Or in a merchant context:
>
> The request to the website https://merchant.shop would be signed with
> your «Government eID for John Doe»:
>
> Date: 24 February 2016 22:01:00 GMTBuyer: J. Doe
> Passport ID: 123456
>
> Product: Weaving the Web by TimBerners-Lee (ISBN 006251587X)
> Tracking id: 714e8662dd77c4
> Cost: 16 USD
> Payment method: VISA card 987654321
> Other: Free shipping
>
>
>   +------+  +----------------------------+
>   | Sign |  | I do not want to sign this |
>   +------+  +----------------------------+
>
>
> Some notes:
>  * The content to be signed is a list of key-value pairs. These would
> be the result of the form filled by the user. It is simply displayed in
> a nicer way here, in order to be understandable by a normal user.
>
>  * I would expect the browser (or the agent performing the signing on
> behalf of the browser) to additionally include a nonce, a timestamp
> field and another with the source URL. Some internal data (such as eID
> serial) may be appended too.
> Automatic insertion of the origin url means that a malicious page which
> obtained a valid signature can't pose as the user to a third party.
>
>  * I embedded into the requests  a couple of opaque identifiers which
> while looking innocent, serve as CSRF protection.
>
> (Whether «Government eID for John Doe» can sign for J. Doe is out of
> scope, but the website will probably relay in some kind of CA system)
>
>
> Thus, I think we are solving the UI problem of authenticating with a
> certificate already installed onto their system.‡ Not that different to
> the kind of «prompts understood by users» that you mentioned, actually.
>
>
>
> ‡ This doesn't mean that the whole keyring needs to be exposed. The UA
> may perfectly only offer it for websites configured for this
> certificate.
>
>
>
> A novelty is that a page which supported this should have readable
> field names, while currently they are not exposed to the user. However,
> supporting any new technology requires changes, and this is a minor
> change to do, while providing readability to the user (and if the names
> are meaningless, no matter how valid the signature is, I suspect it
> would be unenforceable anyway).
>
>



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Received on Thursday, 25 February 2016 05:32:36 UTC