W3C home > Mailing lists > Public > www-tag@w3.org > December 2015

Re: keygen and client-certificates document available

From: Graham Leggett <minfrin@sharp.fm>
Date: Fri, 4 Dec 2015 13:20:13 +0200
Cc: Travis Leithead <travis.leithead@microsoft.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <E2179EAD-8BC6-40A5-B617-44042CF0933F@sharp.fm>
To: Martin Thomson <martin.thomson@gmail.com>
On 04 Dec 2015, at 10:47 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> I'm disappointed that the TAG thinks that user permission is all that
> is needed to install a cross origin correlator.  I realize that this
> is a highly contentious aspect of <keygen>: very important to some,
> one of the worst aspects to others.  Either way, I don't think that
> there is any question you could sensibly ask a user that would
> convince me that the answer you got constituted informed consent.

“This website wants to use your location, do you allow this?”
“This website wants to use your camera, do you allow this?”
“This website wants you to create a new identity, do you allow this?”

> On a less serious note, I think that the characterization of CryptoKey
> is inaccurate.  An asymmetric Crypto-Key with an unexportable private
> key might be usable for authentication, though other forms are
> definitely unsuitable.  The opt-in protection isn't therefore a
> non-issue.

The opt-in protection breaks keygen completely.

Think of a man-in-the-middle between a browser and a CA. The man-in-the-middle sends poisoned javascript that tells the browser to create a key with no protection, and then allows that key signing request to be forwarded to the CA. The CA issues a certificate against this request in good faith believing the key is secure, when it is not.

There are two kinds of crypto we want to do on the web:

- Crypto that protects the server’s interests. Think copy protection.
- Crypto that protects the client’s interests. Think document signing, non-repudiation, authnz.

There is no way that code that is obtained from a server can be trusted to operate in the interests of the client. The server can _initiate_ a request for the client to do something, but the mechanics of doing this has to be built into the client.

> I also believe that it is possible to generate keys in
> secure storage with the WebCrypto API (Firefox might already if there
> is a suitable device, but I'm not sure).

It is not possible, no, and requests to make it possible have fallen on deaf ears.

Regards,
Graham
—
Received on Friday, 4 December 2015 11:20:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 December 2015 11:20:41 UTC