Re: Web ID as passwordless authentication for debian web services
[ Cc'ing Daniel to help kill my misconceptions, as need be ]
Quoting Russ Allbery (2013-05-16 17:42:20)
> Jonas Smedegaard <dr@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
Reply to: