- From: Stéphane Corlosquet <scorlosquet@gmail.com>
- Date: Fri, 11 Jan 2013 16:38:32 -0500
- To: WebID <public-webid@w3.org>
- Message-ID: <CAGR+nnF1pV-0q40aj1BFGDFTQtBJDR7BZGfY_BG4Q0n9cnw3bg@mail.gmail.com>
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. 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! 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. 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. 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? What else am I missing on any of these stages? Is it a bad idea to use such delegated service? -- Steph. [1] http://www.w3.org/wiki/WebID/Authentication_Delegation
Received on Friday, 11 January 2013 21:39:00 UTC