Re: U2F and keygen

On 7/21/14 1:00 PM, henry.story@bblfish.net wrote:
> 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.

He or She or It clicks a button and something they don't totally 
understands happens. This thing (not totally understood) has profound 
impact on their identity and ability to calibrate the vulnerability 
online (aka. privacy).

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

Sorry, but you are looking at this issue from a very narrow perspective 
that doesn't scale in reality.

>
> 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's that supposed to mean? I don't want to kick-off of permathread, 
so I'll do my best to let that comment sit in its current ambiguous state.

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

The number of steps isn't the issue.

Understanding what you are doing is paramount when dealing with identity 
and privacy. Don't let any machine perform tasks on your behalf that you 
don't understand.


> And it usually is a lot more complicated.

Again, so you think, from you perspective. IMHO., you position doesn't 
scale in reality. It hasn't done so to date.

Here's what I know will work. More interop of existing implications that 
collectively improve said implementations. This will ultimately 
encourage more implementations across broad end-user and developer 
profiles.

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

See my comments above. Its one thing to have an opinion, its another 
thing to bake those opinions into a spec, where adoption is the prime goal.


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


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