W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > January 2013

Re: Prioritization of secondary features

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 31 Jan 2013 15:56:44 +0100
Message-ID: <510A862C.3090808@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: mountie.lee@gmail.com, public-webcrypto-comments@w3.org, Anders Rundgren <anders.rundgren@telia.com>
On 01/31/2013 03:50 PM, Ryan Sleevi wrote:
>
> Harry,
>
> I believe you are misinformed. Both Chrome and Firefox support it, as 
> does WebKit proper (including iOS, I believe), and we do see usage of 
> it for large sites.
>
Re keygen, I believe Microsoft said they will never support it and 
development on it has ceased, with nobody looking to extend it. Thus, I 
wouldn't recommend it to developers.

It's supported in some browsers and used by some sites, and HTML5 need 
to have it specified in order to try to make browsers behave 
interoperably with those existing sites. In fact, as noted by Mike 
Smith: the HTML5 spec requires browsers to support the keygen element 
but does not require them to fully implement it. What that means is, 
browsers are required to treat it as a known element and provide the 
HTMLKeygenElement interface, but they are not required to implement any 
key particular types/signature algorithms. Of course if the browser 
doesn't implement any key types/signature algorithms for keygen at all, 
that amounts to not really implementing any end-user behavior for it, 
and the keygen element is not going to have any effect in that browser. 
That's the exactly the case for Internet Explorer. The basic parts of 
keygen (sans the actual crypto part) need to be supported because keygen 
has some different parsing behavior that must be hard-coded into HTML 
parsers, and has some other effects in the DOM, and some effects on the 
form-submission model.


> For example, the act of buying a cert via StartSSL will have the user 
> generate a key via key gen for the user cert to access the control 
> panel. For browsers that don't support keygen (such as IE), they use 
> browser specific solutions like XEnroll.
>
> So I am not sure where you are getting your information. There are 
> solutions in the space now, both the standardized and the 
> nonstandardized stink, and there is no good browser interoperability.
>
> However, none of that is a reason this WG should take on an item if 
> the vendors are not involved or interested in a replacement. It would 
> just end up another unimplemented standard.
>

Precisely. Now, if there is desire by MS to implement keygen and 
everyone else wants to extend it, I'm sure W3C would be interested. 
Right now its effectively legacy IMHO, as you sate there is "no good 
browser interoperability".


> On Jan 31, 2013 4:44 AM, "Harry Halpin" <hhalpin@w3.org 
> <mailto:hhalpin@w3.org>> wrote:
>
>     On 01/31/2013 08:37 AM, Anders Rundgren wrote:
>
>         Hi Mountie & list,
>
>         http://lists.w3.org/Archives/Public/public-webcrypto/2013Jan/0081.html
>
>         I agree that this is important.
>
>         I believe though that the individual items would gain by
>         slightly more "meat" including a connection to use-cases.
>
>         Multiple key containers: Although key-containers is my
>         favorite subject there's actually a virtual *ocean* dividing
>         *using* keys and *enrolling* keys unless we are continuing on
>         the path which has [rightfully] been shunned by the market
>         such as W3C's <keygen>:
>
>         http://www.w3.org/TR/html-markup/keygen.html
>
>
>     The obsession with keygen strikes me as odd. It's a legacy feature
>     that W3C has never endorsed and best practice is to ignore, as
>     many browsers plan never to support. Its included in HTML5 as a
>     legacy feature. I think I stated that to you before, Anders, as
>     well as others.
>
>     Thanks for reminder though, I'll email HTML5 and make sure that
>     this page points that out as its obvious its still causing confusion.
>
>         Disrespecting the fact that the Web Crypto WG doesn't seem to
>         enjoy this topic, I'm 100% sure that the Google wallet doesn't
>         use anything like <keygen>, CMP or similar PKIX-related
>         protocols.  Presumably for a reason...
>
>         Thanx
>         Anders
>
>
>
>
Received on Thursday, 31 January 2013 14:56:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2013 14:56:54 GMT