Re: Using client certificates for signing

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

Received on Thursday, 25 February 2016 00:08:05 UTC