Re: U2F and keygen

On 21 Jul 2014, at 18:51, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 7/21/14 11:50 AM, henry.story@bblfish.net wrote:
>> On 21 Jul 2014, at 15:53, Kingsley Idehen<kidehen@openlinksw.com>  wrote:
>> 
>>> >On 7/21/14 9:22 AM,henry.story@bblfish.net  wrote:
>>>> >>On 21 Jul 2014, at 04:45, Kingsley Idehen<kidehen@openlinksw.com>   wrote:
>>>> >>
>>>>>> >>> >On 7/20/14 12:42 PM,henry.story@bblfish.net   wrote:
>>>>>>>>>> >>>>> >>>Why it that?  Microsoft doesn't care and neither does Apple (for iOS).
>>>>>>>> >>>> >>I don't care that microsoft does not care since I can work around it
>>>>>>>> >>>> >>using ActiveX.
>>>>>> >>> >
>>>>>> >>> >Do care i.e, please don't recommend ActiveX circa. 2014.
>>>>>> >>> >
>>>>>> >>> >IE doesn't have a problem. You don't need to do anything for IE to work properly with WebID-TLS.
>>>> >>Does IE now support keygen?
>>>> >>
>>> >
>>> >No it doesn't, never will, and rightly so (IMO).
>> It has an activeX component that is pretty secure and does the same thing, which can be called from JS.
>> 
>>> >
>>> >Keygen isn't a critical WebID-* related application feature or part of the spec, so I've never really understood the relevance you give to this questionable feature, in regards to Web-scale privacy and identity. When a Windows user wants to generate an identity card for themselves they use the Windows keystore (via its in-built UI) or the native OS API. The same applies to Mac OS X via keychain.
>>> >
>>> >Generating identity credentials that aren't understood by an end-user might look like a convenience, but it actually a potential point of vulnerability and identity compromise. That's why Microsoft doesn't support <keygen/> .
>> That's why you think they don't support keygen. See below for why I don't think that's a correct assumption.
>> 
>>> >
>>> >WebID and WebID-TLS experience in IE:
>>> >
>>> >1. User or 3rd party Native App generates Identity Card (an x.509 cert) that includes WebID in SAN -- Identity purveyor
>>> >2. User selects Identity Card when prompted by TLS CCA
>>> >3. User Identity Claims are authenticated by a protected resource server using authentication protocols e.g., WebID-TLS
>>> >    -- and is capable of repeating this using different WebIDs without restarting IE by simply using the "New Session" feature of IE.
>>> >
>>> >WebID and WebID-TLS experience in Safari:
>>> >
>>> >1. User or 3rd party Native App generates Identity Card (an x.509 cert) that includes WebID in SAN -- Identity purveyor
>>> >2. User selects Identity Card when prompted by TLS CCA
>>> >3. User Identity Claims are authenticated by a protected resource server using authentication protocols e.g., WebID-TLS
>>> >    -- and is capable of repeating this using different WebIDs without restarting Safari since Mac OS X will end idle TLS sessions after a short timeout (only minus is that in my version of Mac OS X 10.6 the timeout isn't configurable, I expect that to change).
>>> >
>>> >WebID and WebID-TLS experience in Firefox, which has its own keystore (rather than using what the host OS provides, more securely):
>>> >
>>> >1. User or 3rd party Native App (some use <keygen/> for this) generates Identity Card (an x.509 cert) that includes WebID in SAN -- Identity purveyor
>>> >2. User selects Identity Card when prompted by TLS CCA
>>> >3. User Identity Claims are authenticated by a protected resource server using authentication protocols e.g., WebID-TLS
>>> >    -- and is capable of repeating this using different WebIDs without restarting Firefox if the protected resource server leverages Javascript.
>> For all of the above I can reduce this to one action.
>> 
>> 1. User goes to his home page in his browser and clicks a "create certificate" button.
>> 
> 
> No you can, for any user and browser combination. Thus, you can achieve the goal in a manner that doesn't generate confusion and inertia.

There's no confusion at all for the end user.  In whatever browser he is in he just clicks a button.

For the Web site developer there is no more confusion that in any other JS library such
as Facebook's React framework. The differences between browsers dealt with by the library.

This is what Bruno Harbulot one of the people who discovered WebID-TLS with me in 2008 
wrote up quite a few years ago.

> 
> What you can do is produce a pkcs#12 file for a user. Then you have an artifact that can be opened (using natural OS provided flow) across any modern operating system (desktop, tablet, palm-top, phone).

If you count the number of operatons the user has to do in that scenario you'll find it is always more than the keygen
solution. And it usually is a lot more complicated. 

Still it is a fallback solution. But why use a fallback solution when you don't need to?

> 
> Links:
> 
> [1] http://youid.openlinksw.com -- demonstrates what I am saying, an Web Service edition with HTML front-end is working its way through our internal QA process.
> 
> -- 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog 1: http://kidehen.blogspot.com
> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> Twitter Profile: https://twitter.com/kidehen
> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Social Web Architect
http://bblfish.net/

Received on Monday, 21 July 2014 17:00:51 UTC