Re: Simple WebID, WebID+TLS Protocol, and ACL Dogfood Demo

On 8/8/13 12:53 PM, Andrei Sambra wrote:
> Hi Kingsley,
>
> On Thu, Aug 8, 2013 at 3:09 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 8/8/13 7:22 AM, Andrei Sambra wrote:
>>     On Wed, Aug 7, 2013 at 7:34 PM, Nick Jennings
>>     <nick@silverbucket.net <mailto:nick@silverbucket.net>> wrote:
>>
>>         Hi Kingsley,
>>
>>          Thanks for the links. Trying out the first link
>>         (http://youid.openlinksw.com/) now, some notes:
>>         2. With firefox, after filling out the form, I get a download
>>         dialogue for the cert instead of it installing into the
>>         browser. So I saved, then went into preferences and "import"
>>         ... which was successful with "Successfully restored your
>>         security certificate(s) and private key(s)". Previously, with
>>         my-profile.eu <http://my-profile.eu>, this was automatically
>>         installed into the browser (I was using Chrome then). Though
>>         I guess it's better to have it export/save by default so you
>>         can install the same cert on any number of browsers without
>>         hassle. Still, it creates more steps and could be confusing
>>         for new users.
>>
>>
>>     Downloading the cert means that it was generated on the server
>>     side, thus the server has knowledge of your private key -> BAD.
>>     Using the HTML5 <KEYGEN> element is always preferred in this
>>     case, which is currently the case for my-profile.eu
>>     <http://my-profile.eu> and rww.io <http://rww.io>.
>     Re., what you assume is BAD:
>
>     You have a tradeoff, store to pkcs#12 or to browser.
>
>     We default to saving pkcs#12 while <keygen/> is an option too.
>     Remember, privacy is about *self-calibration* of one's
>     vulnerabilities, so we prefer to provide options to app/service
>     users rather than mandating a single option.
>
>
> I agree that you may have your use-cases in which you are not able to 
> use a browser, say for an agent that is part of some application. 
> However, users are issued certificates through browsers, exposing the 
> private key to the server poses security (and privacy) risks. Worst 
> case scenario, users should be educated to what the 
> advantages/disadvantages are when choosing one option over the other.
>
>
>     Remember, WebID+TLS is not basic PKI meaning: we have a composite
>     of items that challenge compromise feasibility:
>
>     1. keypairs
>     2. agent identity
>     3. entity relationship semantics.
>
>     Take any of the items above out of the composite and the WebID+TLS
>     authentication challenge fails. In the context of Webby-PKI (which
>     is what  WebID+TLS is about), the private key doesn't have the
>     *pivotal role* it had re. basic PKI.
>
>
> Please allow me to disagree. The private key *has* a pivotal role, 
> even if it is outside the context of classic PKI. It is what makes 
> authentication possible in crypto-based systems, which is the case for 
> WebID-TLS. Otherwise, you would have a system in which anyone can 
> assume the identity of a particular user/agent.

To be clearer, my point is that a composite means: it's all three of the 
items I listed above or nothing. There isn't a single pivotal component.

As a result of the reality above, we've opted to do the following:

1. provide native OS generators for Certificates that bear WebIDs -- of 
course, we also encourage folks to use the native generators (where such 
exist) if they are happy doing this by hand

2. provide a Web based generator -- but in the spirit of "letting the 
user calibrate their vulnerability" we offer the option to take the 
pkcs#12 or <keygen/> routes (there's a drop-down for pkcs#12 or keygen).


pkcs#12 files are an important option, even when generated by a server 
which you may actually own/control i.e., we don't really envisage a 
world in which an HTML based server isn't actually controlled by the 
end-user. Our models for service deployment are as follows:

1. Hosted Personal Data Spaces -- these are communal
2. Self-hosted Personal Data Spaces -- there run in cloud spaces (e.g. 
Amazon EC2) owned by the user
3. Enterprise Data Spaces -- conventional enterprise setup.


I hope that clears up why we see pkcs#12 as an important part of the 
certificate generation workflow.


Kingsley

>
> Andrei
>
>
>     Also note, pkcs#12 files (re. YouID) are actually generated on the
>     mobile device (iPhone for now with Android arriving any second).
>     It is no different to generating a certificate using Keychain on
>     Mac OS X [1].
>
>
>     Links:
>
>     1. http://bit.ly/SuMWP4 -- creating an X.509 certificate bearing a
>     WebID (HTTP URI that denotes an Agent) using Mac OS X Keycain
>     (which Apple forgot to port ot iOS) .
>
>     -- 
>
>     Regards,
>
>     Kingsley Idehen 
>     Founder & CEO
>     OpenLink Software
>     Company Web:http://www.openlinksw.com
>     Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile:https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen