> On 3 Sep 2015, at 20:21, Ian Hickson <i...@hixie.ch> wrote:
> On Wed, 2 Sep 2015, henry.st...@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.

yes, I see.

That is why it seems appropriate that the discussion moved
to the Technical Architecture Group (TAG) which can take a more 
global view of the situation.

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

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.

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

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.

Clearly the  WHATWG does not see itself in the position to be such a forum, 
but is just an executor. 

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

I suppose I have been looking for a forum where discussions about standard
development was taking place, so that reasonable discussion could take place.
I see I was mistaken.

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

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. 

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.

> 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! :-)

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

Fine. But clearly that means that serious discussion needs to happen somewhere
else then.

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

Social Web Architect

Reply via email to