Re: Prioritization of secondary features

On 01/31/2013 04:25 PM, Anders Rundgren wrote:
> On 2013-01-31 15:56, Harry Halpin wrote:
>> 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.
> Harry, this is not how it actually works: No CA outputs the <keygen> tag for Internet Explorer, they either generate code for Microsoft's completely different solution or display a with page "unsupported browser".  I.e. the "User-Agent" string is our only guide to [some kind of] interoperability.

I wasn't describing how it worked for CAs. I'm describing what the HTML5 
spec meant by "support" of keygen. Like I said, some sites use it. I 
would not encourage it.

>
> BTW, iOS does AFAIK not support <keygen>.   Apple have developed a more elaborate solution for their mobile devices than their competitors.  I would give it an "almost usable" score.  However, for consumers there's nothing.
>
> I'm currently building an entirely proprietary one-of-kind enroll/keystore facility for a large European bank.  Although it sure is good money, I still think it is crap**10.
>
>>
>>> 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.
>>>
> Who could possibly argue with that?
>
> Anders
>
>> 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 15:28:55 UTC