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

Hi Kingsley,

On Thu, Aug 8, 2013 at 3:09 PM, Kingsley Idehen <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>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, 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 and 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.

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
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>