Re: [whatwg] deprecating <keygen>

On Wed, 2 Sep 2015, henry.story@bblfish.net wrote:
> >
> > 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.

That's debatable (see foolip's e-mail), but more to the point, it's 
irrelevant. We're not trying to reflect consensus here. We're trying to 
reflect reality. That's why the spec still has <keygen>, but why it warns 
that browsers are planning on dropping it.


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

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?


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

Again, the point of the spec here is just to reflect reality; if browser 
vendors say they want to drop something, then we have to reflect that, 
even if they don't plan on replacing it with anything. Otherwise, our spec 
is just rather dry science fiction.

Having said that, it's my understanding that there are replacement APIs 
being developed. I'm not personally familiar with that work so I can't 
comment on it. Should the authors of a cryptography specification that 
browser vendors want to implement be interested in publishing their work 
through the WHATWG, I'm sure that could be arranged, and at that point 
this list would make for a very relevant place to discuss those 
technologies.


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

Asymetric key cryptography forms the basis of the entire Web's security 
system. It's pretty much the only possible way to have solid security in 
an environment where you don't trust the carrier. I doubt it's going 
anywhere anytime soon, unless we suddenly get a supply of securely- 
sharable one-time-pads...

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


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

I certainly encourage people to follow such a pattern, but when they 
don't, we can't just ignore reality.

I encourage you to read our FAQ. The WHATWG has a much more pragmatic 
approach than other standards organisations you may be more familiar with.

   https://whatwg.org/faq

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

Received on Thursday, 3 September 2015 18:21:28 UTC