Re: Delegated certificate generator

On 11 Jan 2013, at 22:38, Stéphane Corlosquet <scorlosquet@gmail.com> wrote:

> In the same vein as the Authentication Delegation [1], I thought it would be nice to have a similar service to generate a WebID certificate. The same reasons apply, it requires to setup SSL on your server, something that you might not be able to do depending on your hosting. Any web app could then redirect its users to the trusted certificate generator, and provide the basic info to that delegated service such as the WebID URI, the name and email in the URL parameters. I asked Andrei about this and he was kind enough to deploy such service in MyProfile. So if you go to 
> https://my-profile.eu/certgen.php?webid=http%3A//example.com/user/25%23me&name=Johnny&email=johnny%40example.com
> all the necessary info will be filled for you and all you have to do is to click on the "Install certificate" button to get a cert in your browser. Nice work Andrei, thanks.

On the whole I think the user will feel a lot more comfortable if he is able to create the 
WebID directly from the IDP's page. Redirections always has to be a cause for some
Suspicion. Creating forms that can process keygen requests is not that difficult.

Nevertheless in the spirit of being helpful, with the proviso that in security as in love you cannot really give the job to someone else  ( the buck stops somewhere ), here is an idea...

> 
> After this, the user is still left to its own devices though, and she has to know to look in the certificate (using KeyChain maybe) to copy paste the public key info in her profile in the original app providing the WebID profile. Maybe if the original WebID provider location was also passed in the URL, the delegated cert generator could redirect to the original site, and also (very important) provide the public key modulus and exponent as part of the url redirection. The WebID provider could then update the user profile WebID document with this info. This would improve the UX significantly!

It's a bit late in France and it's Friday, but here is an idea off the top of my head...

I think that the key-generation service could create a service that would could create
certificates that would only be visible to the server ( the IDP )  that send the user to it. 
So if 

   http://simple-server.org/keygen

were in LDP terms a collection, in which each remote IDP were able to create its
own sub collection, for example http://simple-server.com/ could create the collection
(LDPC)

   https://foafssl.org/srv/keygen/simple-server

This would on a text/html request show a form such as the one built by Andrei,
which any user could use to create a certificate with some remote WebID. If the
request on this form were to be for example 

  https://foafssl.org/srv/keygen/simple-server&webid=http://simple-server.org/joe%23me

then the form would not need to show the users WebID  and so be more user friendly.

The foafssl.org  service for simple-server could create a keygen form submission to create a public key in the collection with URL

  https://foafssl.org/srv/keygen/simple-server/sdfsdfs

and return Alice her public key. This 'sdfsdfs' resource would only be readable by http://simple-server.org/#me who created the

  https://foafssl.org/srv/keygen/simple-server/

collection.

Ie. Anyone could write to that collection (using POST), but only simple-server 
could read its contents. Then on creation of that  sdfsdfs resource Alice's browser would 
be redirected to 

   https://simple-server.org/keygenclient?cert=https://foafssl.org/srv/keygen/simple-server/sdfsdfs

with as you can see a pointer to the resource containing information about Alice's
public key.

I think this could work, but I wonder if it is not just as much work as to simply do the
keygen parsing locally. Here you have issues of network connectiviy that need to be deal with, issues of DNS poisoning attacks added to it, server up time you need to rely on, etc...



> 
> What I'd like to discuss next is how to secure this delegation service. There are two stages in the process:
> 
> 1. The WebID provider redirects Alice to the delegated certgen service. Obviously it's up to the WebID provider to trust what service it redirects its users. Is there any room for a MITM attack in this stage? Imagine if Chuck who is eavesdropping manages to change the WebID in the certificate being transmitted to Alice's browser (or maybe by sending a completely different certificate). When Alice wants to use her certificate to authenticate on a WebID enabled site, it may not work, or she may get logged in as someone else using a different WebID than the one she intended to use (the WebID that Chuck managed to sneak in the certificate, provided he updates his WebID profile document). But as far as I can tell, there is not way at this point to "steal" Alice WebID and impersonate as Alice somewhere on the WebID enabled Web.

I think the above scenario happening as it is over https would work. The service could even
pint the simple-service with the key and the webid directly to remove the need to pass this
over the client.

> 
> 2. Alice is still on the delegated certgen service, and the service redirects her to the original WebID provider site with the modulus and exponent as part of the URL.

Those are too long. URLs should not exceed 1024 characters, due to proxy and other limitations.

> If the certgen server has been compromised or if Chuck is still successfully eavesdropping, he could intercept this request and change the public key info to one that matches an existing certificate he has on his browser that contains Alice's WebID, and Alice's WebID provider will insert Chuck's certificate public key info into Alice public WebID profile. Alice's WebID will not work, but Chuck will be able to use his certificate to authenticate as Alice on the Web. The redirect probably needs to include the same kind of signature as we already have for the delegated authentication, is that sufficient?

https should be enough I think.

> 
> What else am I missing on any of these stages? Is it a bad idea to use such delegated service?

I think it is an interesting idea, but still it seems to me somewhat complicated and as with any additional complication in security circles, it will lead to new attack surfaces. 

I think OpenSSL can do the trick for key creation, and that compiles for every platform being open source.

> 
> -- 
> Steph.
> 
> [1] http://www.w3.org/wiki/WebID/Authentication_Delegation

A short message from my sponsors: Vive la France!
Social Web Architect
http://bblfish.net/