W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2015

Re: [whatwg] deprecating <keygen>

From: <henry.story@bblfish.net>
Date: Thu, 3 Sep 2015 22:25:47 +0200
Message-Id: <63921DE8-2BD0-4ECB-B5F8-6E1D7050708F@bblfish.net>
To: Ian Hickson <ian@hixie.ch>
Cc: WHATWG <whatwg@whatwg.org>, Philip J├Ągenstedt <philipj@opera.com>

> On 3 Sep 2015, at 21:44, Ian Hickson <ian@hixie.ch> wrote:
> 
> On Thu, 3 Sep 2015, henry.story@bblfish.net wrote:
>>>>> 
>>>>> and the other major implementation has never supported [<keygen>].
>>>> 
>>>> You mean IE? IE has always had something that did the same:
>>>> 
>>>> https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
>>>> 
>>>> It is not idea, and it is easy to use both.
>>> 
>>> I'm not really sure what you're trying to argue here. Are you saying 
>>> we should specify this API? Are other browsers planning on 
>>> implementing it?
>> 
>> What I am saying is that all desktop browsers have implemented that 
>> functionality in one way or another for 15 years. So that it is 
>> misleaading to make it look like it is only a minority that has been 
>> using it.
> 
> If you consider <keygen> and IE's Certificate Enrollment API to be 
> equivalent, then I wouldn't worry about the deprecation warning regarding 
> <keygen>. I would fully expect a similar feature to be supported by the 
> <keygen>-supporting browsers long before <keygen> itself is removed. One 
> might even hope that such a feature would be one developed in a standards 
> environment with input from security expects and with with input from all 
> vendors, and that it might therefore be more secure than <keygen> and 
> actually implemented by all vendors, which would certainly be an 
> improvement over the current situation.

Its a bit optimistic especially in the security area to think that if you remove
a security component it is going to magically re-appear. 

Anyway, let's leave that discussion to the TAG.

Still I think I'll chime in with Melvin and the point I made earlier
that it would be good to have more details on what the security issues
with keygen are. At the minimum it may be worth explaining this in the
WHATWG spec.

As I wrote in the previous mail in response to your point:

>> 
>> The post foolip pointed to points out that <keygen> is actually rather 
>> insecure (e.g. using MD5). One could argue that _keeping_ <keygen> is 
>> actually more harmful to asymetric-key cryptography than removing it...
> 
> It can't be more insecure than storing the key in HTML5 web storage.
> All keygen allows the browser to do is to sending the public key ( hopefully 
> over TLS ) to the server which can then send you back a certificate. Since 
> the private key does not leave the user agent there is not much that can go 
> wrong. After all it is a Public Key that then in any case will be published! T
> hats the whole point of asymetric key cryptography! :-)

So yes, what is the attack vector here?

Henry



Social Web Architect
http://bblfish.net/
Received on Thursday, 3 September 2015 20:26:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:35 UTC