Re: [whatwg] deprecating <keygen>

> On 1 Sep 2015, at 19:56, Ian Hickson <ian@hixie.ch> wrote:
> 
> On Tue, 1 Sep 2015, henry.story@bblfish.net wrote:
>> 
>> As the WhatWG only recenly moved to Github members here may not have 
>> noticed that <keygen> has been deprecated.
>> 
>> I opened https://github.com/whatwg/html/issues/67 to give space for the 
>> discussion. It is a pitty that this was closed so quickly ( within an 
>> hour ) without giving members and the public ( the users of the web ) 
>> time to comment nor for their voice to be heard.
>> 
>> This is a complex issue that involves many different levels of 
>> expertise, and it should not be handled so lightly.
> 
> The spec just reflects implementations. The majority of implementations of 
> <keygen> (by usage) have said they want to drop it,

There was a lot of pushback on those lists against dropping it, and no
clear arguments have been made for dropping keygen there.

> and the other major  implementation has never supported it.

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.

> The element was originally (and for 
> many years) purely a mostly-undocumented proprietary extension;

Adopted by most browsers. ( With IE having a similar feature just
done differently )

> at the 
> time it was invented, the HTML spec was edited by the W3C and the W3C did 
> not add it (they only ended up speccing it in their most recent HTML spec 
> because they forked the WHATWG's spec which did define it -- indeed, even 
> then, it was something that W3C HTML working group members argued should 
> not have been included). It was only added to the WHATWG spec because one 
> of the browser vendors said they could not remove support for it due to 
> usage by enterprise customers; that browser vendor is now amongst one of 
> the ones wanting to drop it.

To replace it with what? That is the problem that needs discussing and not partially
across twenty lists where the issues are only ever half addressed. 

> As far as I can tell, therefore, things here are working exactly as one 
> should expect.

Indeed: they seem to be working as one would expect where one thinking that forces
that don't like asymetric key cryptography to be widely deployed were trying to
remove that capability as far as possible. The manner of doing this - by secret 
evidence, and pointers to closed non deployed standards - seems to be very much
the way of doing of organisations that like to keep things secret and closed.

> 
> It's worth noting that <keygen> is a pretty terrible API. I recommend 
> approaching the groups writing new cryptography APIs, explaining your use 
> cases, and making sure they are supported in up-and-coming, more widely 
> supported, more secure, and more well-thought-out APIs.

The case has been made that things should go the other way around: the problems
should be brought up, and then improvements or replacements found. When those are
found and are satisfactory ( as evaluated against a wider set of values that take
the whole web security into account ) then one moves forward.



> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Social Web Architect
http://bblfish.net/

Received on Wednesday, 2 September 2015 11:01:24 UTC