[ Cc'ing Daniel to help kill my misconceptions, as need be ] 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! > 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). > In theory, you could use the PGP web of trust instead, but bear in > mind that the security model of WebID is based on validating the URI > endpoint rather than the user. URI end points generally don't have > PGP keys, nor are they generally part of the PGP web of trust, so > there's a bit of a bootstrapping problem there. Generally today servers use cartel-issued certs, that is correct. But what relevancy does that have to the ability to do different? Each webmaster is free to trust cartels for their server certs, but I don't see how that stops other webmasters to choose not to trust cartels and instead create "PGP-linked" certs instead. > To a large extent, the practical effect of WebID is that it's a way of > substituting one authentication system for another. The problem that > it's trying to solve is that user key distribution and key > verification is hard, so it allows the user to bind their key to a URI > and the server to verify that the URI and the key are bound by > retrieving the URI. In essence, this moves the authentication problem > from user authentication to URI endpoint authentication, under the > theory that we already know how to validate URI endpoints and that > such validation is an easier problem. If you don't agree with the > assertion that we already know how to validate URI endpoints (which is > the source of the objections to trusting the CA cartel), WebID looks > to me like it basically falls apart from a security standpoint. Thanks for distilling the essential weak part. Both for further discussion, and as help for the drivers of WebID to refine their documentation (they are following this thread). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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/20130516174931.29499.3...@bastian.jones.dk