Re: removing keygen from HTML

> On 1 Jun 2016, at 14:10, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> On 2016-05-30 11:40, Chaals McCathie Nevile wrote:
>> Hi folks,
>> 
>> there is an open issue [1] and open call for consensus [2] to remove
>> keygen from HTML. Since the TAG, or its members, appear to have opinions
>> about our spec, we'd be grateful to hear them.
> 
> If you look into the comments I think there are two fairly unrelated
> issues here where removing keygen represents the less important (Microsoft
> never bothered with keygen and iOS doesn't support keygen either).
> 
> So the core issue is rather that the TAG considers using client-certificates
> in an origin-unconstrained (including user consent) fashion is "wrong".

I don't see where you get that from. The Client Certificate document published by 
the TAG here

  http://w3ctag.github.io/client-certificates/

says that inserting a key into an OS keystore should not be done without
user consent, just like a web page should not be able to start the camera
on the computer without user consent, or be able to access the users geo 
location without her consent. All of that is well understood in fact, and
has not stopped browsers giving access to the camero or to geo location 
information on the device.
 
> The problem with this is that this concept already is firmly established and
> in some places in the world indeed working quite good as well.  I don't think I'm
> alone finding it quite handy being able to open any number of "doors" with just one key.
> 

I think the TAG finding does not disagree with that position. Do you have text 
you can point to that goes in that direction?

> 
> Few if any of these deployments rely on keygen, they rather use their
> own take on certificate enrollment.  After the deprecation of browser plugins
> which have had a big impact on the Web ecosystem, quite a bunch of these
> deployments have switched to "Apps".
> 
> What's really missing is a down-to-earth description of how for example
> WebAuthentication could support the multiple door scenario.

I agree with you that the confusion about Single Origin Policy's applicability
to authentication across origins is what has stalled a lot of the work that would
have enabled  client certificates in browsers to be deployed to their full 
capacity.

But to be fair, most of the browsers that have implemented client certificates have 
held to this obvious restriction when dealing with using certificates accross origins. 
The same is true about inserting a certificate into the OS level keystore, though perhaps
a lot of the browsers do not allow the user to easily specify if a certificate should
be only used for one origin or across origins... So improvements can be made.

So I welcome the TAG finding as it makes this obvious point clear.


> 
> Anders
> 
>> 
>> cheers
>> 
>> Chaals
>> 
>> [1] https://github.com/w3c/html/issues/43
>> [2] http://www.w3.org/mid/op.yhs220oos7agh9@widsith.local
>> 
> 
>

Received on Wednesday, 1 June 2016 12:35:22 UTC