Re: WebID-RSA. Re: google proposing to deprecate KEYGEN

> On Aug 4, 2015, at 5:18 AM, Henry Story <henry.story@co-operating.systems> wrote:
> 
>> 
>> On 4 Aug 2015, at 09:05, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>> 
>> On 2015-08-04 08:12, Henry Story wrote:
>>> 
>>>> On 31 Jul 2015, at 17:25, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>>> 
>>>> On 2015-07-31 15:47, Andrei Sambra wrote:
>>>>> I’ve already started work (this spring) on an alternative auth
>>>>> protocol based on WebID, which uses the new WebCrypto API. You can read about it here [0].
>>>> 
>>>> Pardon my ignorance but I don't understand how WebID-RSA works since
>>>> WebCrypto is SOP-crippled.  That you can generate a key on the fly
>>>> is true but exactly what does that buy?
>>> 
>>> What does SOP-cripled mean?
>> 
>> HTTPS CCA (Client Certificate Authentication) allows you to share a certificate
>> with any number of sites (domains).  This is huge drawback according to the folks
>> working with core Web security- and privacy-technology in W3C.
>> 
>> WebCrypto as well as FIDO/U2F only allows the domain who generated a particular
>> key to "see" it following SOP (Same Origin Policy).
>> 
>> If you need to generate a new key for each site you are visiting, I don't see how you
>> could maintain the binding to a particular WebID without running something like an e-mail
>> verification round-trip which IMO would make such a system much less attractive.
> 
> yes, that indeed seeems to be the situation. As you pointed out in another e-mail
> this does not help increase the security and privacy of the web because all it does is
> allow the emergence of cerntralised Identity Services such as Facebook
> or Google+ that replace this feature with a distributed authentication service
> allowing the centralised provider to track all that the user is doing.
> 
> Now for server to server communication WebID-RSA poses no problems, just as it poses no
> problems to WebID-TLS that keygen and the x509 certificate mime types are removed from the browsers.
> 
> But in the client side though the question to Andrei with WebID-RSA are:
> 
> 1) How does the browser store the key? (I suppose in the browser local storage)

These are really important questions. Until W3C or FIDO come up with a standard API around accessing the secure element on smart cards, the solution is to use localStorage. There are several ways this can be done:

a) Client-side apps use a shared library loaded from a secure origin, which acts like a keychain. This solution, however, involves centralizing the service into a handful of keychain providers (maybe).

b) Users run their own keychain app on top of their LDP server, and link to the app from their WebID profiles. Then using an app for the first time simply involves disclosing the user’s WebID. (the app can then use localStorage to store the WebID value for subsequent usage)


> 2) How does the browser use that key to authenticate to another domain, since SOP restrictions are in place?

This is the million $$ question. My current answer is to have the app request a bearer token from the keychain app. Here is a tentative workflow, the user went through the a) and b) steps above:

a) App requires authentication to access a protected resource on ServerA. (ServerA responded with a 401 and a nonce N)
b) App requests a signature over N from keychain app, using cross-window messaging with postMessage [0].
c) Keychain app signs N and passes it back to App using postMessage.
d) App retries the request by sending the signed credential.


There’s also an improvement that can be made to the workflow. For instance, the keychain app may display a message asking the user to validate the request for a signature coming from App. The keychain app should then cache these requests (both locally in localStorage and on the user’s LDP server for sync purposes across the user’s devices/browsers).

—Andrei

[0] https://w3c.github.io/webmessaging/

> 
> Also on the document I read:
> 
> [[
> One important advantage of WebID-RSA over WebID-TLS is that keys can be generated on the fly to sign and encrypt data. The way client certificate management is currently implemented in browsers, it does not offer the means to access keys inside certificates, for purposes other than authentication.
> ]]
> 
> But given that there is no chrome support for WebID-RSA how does the user know that the
> JS is indeed signing what it tells the user it is signing? The JS has full access to the private key so can sign whatever it wants.
> 
> The major security problem of same origin policy is that same origin policy is very broad and difficult to supervise. Any JS served by the origin needs to be verified and understood. This opens up a whole set of security problems for SoLiD concerning the upload of JS on the origin, which I don't think have been considered yet.
> 
> Henry
> 
> 
> 
>> 
>> Anders
>> 
>>> 
>>> 
>>>> 
>>>> Anders
>>>> 
>>>>> 
>>>>> It’s currently implemented in gold [1], one of the SoLiD servers.
>>>>> 
>>>>> —Andrei
>>>>> 
>>>>> [0] https://github.com/linkeddata/SoLiD#webid-rsa
>>>>> [1] https://github.com/linkeddata/gold
>>>>> 
>>>>>> On Jul 31, 2015, at 8:51 AM, Cory Sabol <cssabol@uncg.edu <mailto:cssabol@uncg.edu>> wrote:
>>>>>> 
>>>>>> It would be interesting to conduct some work on that. WebID with some alternative crypto APIs.
>>>>>> 
>>>>>> On Fri, Jul 31, 2015 at 6:42 AM, Andreas Kuckartz <a.kuckartz@ping.de <mailto:a.kuckartz@ping.de>> wrote:
>>>>>> 
>>>>>>   Kingsley Idehen wrote:
>>>>>>> Keygen doesn't define existence of WebID-TLS. It just offered a
>>>>>>> perceived convenience.
>>>>>> 
>>>>>>   Can WebID-TLS be based on the Web Cryptography API instead?
>>>>>> 
>>>>>>   What would be the advantages and disadvantages?
>>>>>> 
>>>>>>   Cheers,
>>>>>>   Andreas
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Regards,
>>>>>> 
>>>>>> -Cory Sabol
>>>>>> cssabol@uncg.edu <mailto:cssabol@uncg.edu>