Re: What we were using public key authentication for

On Wed, Mar 23, 2016 at 6:08 PM, Tim Berners-Lee <timbl@w3.org> wrote:

> Virginie
>
> You asked at the AC lunch for me to describe what it was that we had been
> using  public key authentication for.
>
> This is the system we have been using for someone to be able to identify
> themselves as the owner of a web page, like a blog.
>
> - A user of a web browser runs a web app A
> - The web app uses data stored in various different web sites B (Like
> health data, bank data, calendar, etc)
> - The user has a global ID which is an https: URI which points to public
> info about them (or a persona) like their blog
> - The access control on the data stores is set to allow access referring
> to that ID string
> - The user accesses the data from within the webapp by using a private key
> which is stored securely on the device (or hardware gadget)
> - The user’s public key is accessible only though unfakable "browser
> chrome"
> - The cert is NOT signed by anything — it can be self signed. (the trust
> is from the public key being on the web)
> - The public web home page for the user lists the corresponding public key
> publicly
> - The client cert does contain the global ID URL
>
> The essential characteristics of the system which the browser architecture
> seems to fight against:
>
> - The whole point is to be have a public identity (like your W3C or github
> id) which can be to show you are the same person on multiple sites
> - It isn’t just about logging onto different we sites, it is about
> accessing the same data you own on many sites B from many different sites A
> - The signature on the cert is not part of the system, so the keychain
> won’t recognize the cert as “trusted”.  This does NOT use the PKI
>
> We have been doing this using client certs, but the UI was unloved, the
> keygen API weird and had bugs, browsers have had a war against client
> certs.  But the system worked!   Until keygen got turned off in Chrome and
> Firefox  a few days ago.
>
> So can we get this functionality using web crypto in the short term?
>
>
Here's my best guess!


> Suppose we
> 1) generate the keys in a web app using web crypo, store them in ephemal
> strage, and rejenerate them any time the use clears the key storage. Use
> them in a custom HTML form based auth session with the server in which we
> invent our own PK based authentication protocol.
>

One way to prevent keys from destroyed if localStorage is cleared to 'wrap'
long-term private keys with another per-session key and upload long-term
(i.e. exportable) keys to your server and then download those keys from the
server and unwrap when you need them. That long-term keypair could have a
public key that you could then display on your URL w/i a WebID.

The main issue is you'd probably still want a keypair to wrap. To get
per-session key, I'd use as a temporary measure like Secure Remote Password
(SRP) and then upgrade to WebAuthn (FIDO 2.0) when it happens [1]. Another
option is HOBA (no passwords) and it needs recoding in WebCrypto I think [2]


> 2) genearte the keys using math, possibly web cryto with “exportable”
> keys, and download a .pem file to the user’s desktop.  Get the user to
> click on the .pem and go through the process of installing the cert on
> their site. Hope fingers crossed the browsers don’t just block the use of
> client certs at all!
>


What would the self-signed cert get you that a key would not? It seems that
localstorage vs. TLS keystore is the issue, where it's believed TLS
keystore is much more secure? Would be a good thing for a security audit to
investigate, such as iSec partners.



>
> 3) Switch the while thing over to use openID-connect to connect people to
> some password-protected site?
>

OAuth can be used to transfer information (such as data from your
access-control). You would need to have your WebID hdata store be OAuth
enabled as your 'identity provider.'

There's nothing preventing an OAuth provider (MIT CSAIL is also moving from
certs to OpenID Connect) from working with a URI-based identifier (RDF) and
shipping RDF-based data around. In fact, you could do all sorts of fancy
stuff like encrypted the data by storing it in JSON-LD (I think you could
do n3 as well likely if you normalized a bytestring via base64) in a JWT
and signing using a JWS.


>
> If the Fido system will give us all we need by the end of this/next year,
> that will be great, but we need something now we can improvise say using
> web crypto and JS.
>


[1] http://srp.stanford.edu/
[2] https://hoba.ie/



> Best
>
> Tim
>
>
>
>
>