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

Re: keygen and client-certificates document available

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 4 Dec 2015 10:08:11 +0100
To: Martin Thomson <martin.thomson@gmail.com>, Travis Leithead <travis.leithead@microsoft.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <566157FB.6000105@gmail.com>
On 2015-12-04 09:47, Martin Thomson wrote:
> On 1 December 2015 at 09:21, Travis Leithead
> <travis.leithead@microsoft.com> wrote:
>> Keygen and client certificates document:
>> http://w3ctag.github.io/client-certificates/
>
> Does the TAG have consensus that <keygen> (and friends) is worth
> replacing?  It seems like there are plenty of approaches that can
> support similar use cases, some of which have considerably more
> momentum (see Fido for instance).  Is anyone signed up to do work on
> this?

Since Microsoft have already removed their counterpart to <keygen> from
Edge, this question seems fairly relevant :-)


> The document is unclear on what recommendation it makes regarding
> <keygen>-and-co right now.  I could infer from all the activity that
> the subtext is a plea to retain the busted feature until a replacement
> is ready, but that's not clear to me from reading the document.  I
> think that's a very important part of the statement.  If the TAG has
> consensus on this point, I'd like to hear that.

The only clear consensus is removing this feature, not updating it.


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

What you and the TAG (indirectly) are saying is that it is perfectly OK if an IdP
like Google asks the user "'acme.com' is requesting authentication do you agree?",
but totally wrong if coming from a built-in browser UI like a certificate selector.


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

Anders
Received on Friday, 4 December 2015 09:08:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 December 2015 09:08:47 UTC