- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 3 Sep 2015 18:21:00 +0000 (UTC)
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>, Philip Jägenstedt <philipj@opera.com>
- Cc: WHATWG <whatwg@whatwg.org>
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