Re: [whatwg] deprecating <keygen>

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.


> yes, what is needed therefore is a place where discussions making 
> explicit the reasons for this ( and other ) decision can be made, so 
> that the larger community of users of the technologies the browser 
> vendors are implementing can have a voice, and also like in any open 
> source project to have a lot of different eyes help work through the 
> tangle of complexity in this field.

If you have specific proposals for changes to the WHATWG specifications, 
then this mailing list would absolutely be a fine place for that.


> > 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.
> 
> What would be discussed here? As I see your point is that the WHATWG 
> only publishes what has been implemented already.

I encourage you to read our FAQ, which covers such matters in detail:

   https://whatwg.org/faq

Does that answer your question?


> yes, but it is not because the JS crypto API has methods to do 
> asymmetric key cryptography, that it is useable in the way needed for 
> authentication etc... The problem is that the JS crypto API have not 
> developed a way to store the prive key in the browser without the JS 
> from the same origin getting access to it. That is what is missing is a 
> certain category of security guarantees, which involve User Interface 
> elements.

I encourage you to bring such concerns up with the group(s) developing 
those APIs. As far as I'm aware, none of the WHATWG specs include JS 
crypto APIs. (And given that there are already groups working on such 
technologies, we wouldn't want to start a new spec for those technologies 
unless the browser vendors indicated that they weren't interested in the 
existing specs and wanted a new one.)


> From the discussions on the blink list it was clear that Ryan Sleevi 
> thinks that it is a good enough answer for the security of private keys 
> that they be place in HTML5 web storage. A lot of the decision to remove 
> keygen and other features depend on mistaken - or if I give him the 
> benefit of the doubt, at best undocumented assumptions - of this sort.

I recommend bringing this up with Ryan.

The only change that has been made to the WHATWG HTML spec is adding a 
note to the effect that the feature is likely to be removed. This is just 
a statement of fact, reflecting intents stated by browser vendors. It's 
not a value judgement and it's not a technical or normative change.

If you would like to discuss a technical change to the WHATWG HTML spec, 
then that would definitely be something that this list would be appricate 
for. To argue against the change that _has_ been made, though, you'd have 
to show that it wasn't accurate, which would presumably first mean 
convincing the browser vendors not to deprecate the feature in question.

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

Received on Thursday, 3 September 2015 19:45:17 UTC