Jonas Smedegaard <d...@jones.dk> writes: > Quoting Russ Allbery (2013-05-16 17:42:20) >> Jonas Smedegaard <d...@jones.dk> writes:
>>> This seems similar as WebID: In principle ties to HTTPS - and >>> therefore the CA cartel - is only optional (other URIs than http ones >>> suffice). In reality alternatives to HTTP(S) is work in progress. > First of all: Thanks for your quite easy to follow > explanation/reasoning! Thanks -- I just hope I'm not projecting false confidence when I don't actually know what I'm talking about! :) This should all come with the caveat that while I've worked on authentication systems for some years, I've only done a cursory evaluation of WebID, and there may be solutions to the weaknesses that I was glimpsing. >> Changing the protocol doesn't help you get away from the CA >> dependency. The reason why there's a CA dependency is not because it >> happens to use the HTTPS protocol. It's because you have to >> authenticate the provider of identity data (the other end of the URI, >> whatever it may be) or you're vulnerable to having the attacker >> intercept your query and supply whatever data they want. There's no >> way around that. > I believe that with WebID I can get rid of the CA *cartel* while still > reliably using TLS: By using a server cert from same key material as a > PGP key, I can (contrary to a self-signed cert) verify that the cert is > not being handed by a man in the middle (e.g. using Monkeysphere). Sure, but if you have control over the server certificate and are tying the server certificate to the user certificate via some mechanism like Monkeysphere, why do the whole indirection dance through a URI at all? At that point, you have all the tools you need to just validate the user certificate directly, at which point you can just put all the metadata directly in the user's public certificate and be done with it. No third party metadata provider is required. The reason for the WebID indirection, as I understand it, is that the server who is trying to authenticate the user has no way of validating the authenticity of the presented public certificate. Therefore, the web server reads a URI out of the metadata of the certificate and retrieves that URI, confirming that the resource at that URI includes certificate data that matches the presented certificate. This operation verifies the binding between the URI and the certificate and allows the server to then trust that certificate as valid authentication for the user identified by that URI *provided that* the server can verify the URI endpoint certificate. The point is to shift the trust point to the URI endpoint validation instead of the user validation under the assumption that you have some existing mechanism to validate URI endpoints. If introduce Monkeysphere to do the URI endpoint verification, it seems to me like you could just as easily introduce Monkeysphere to do the user certificate verification directly, thus removing the need to introduce a third party metadata provider. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo8azu1k....@windlord.stanford.edu
