[Freedombox-discuss] FOAF developers taking FreedomBox into their equation

[Henry Story]

On 11 Mar 2011, at 05:38, Daniel Kahn Gillmor wrote:

> On 03/10/2011 08:44 PM, Jonas Smedegaard wrote:
>> If e.g. Verisign is untrusted, then remove Verisign root certificates
>> from your system and any website using that CA will no longer be
>> trusted.  This should be true also for WebID.
> 
> The problem with this approach is a nasty social problem, rooted in the
> single-issuer specification of X.509 certificates:
> 
> http://lair.fifthhorseman.net/~dkg/tls-centralization/

I think the PGP in TLS is an interesting idea. One could have a server certificate signed by one, two or more CAs, by friends, and so on. I think it is certainly worth developing this idea in the freedom box, even if it seems to me a lot of the picture still needs to be filled in.

It seems very compatible with WebID.

Perhaps you can help us get the PGP folks to specify a WebID field one can place in the PGP key, so that one can move from PGP certs to referential information about the subject of the cert.

> 
> In short: there is a system of perverse incentives that force people to
> keep "trusting" the untrustworthy middlemen.  We need to change that.
> 
>> Might be that the user runs IE8 with horrible settings, but the
>> FreedomBox wanting to verify a claimed WebID does not, so that should
>> not matter to us, I believe.
> 
> You're missing the step of what i called the "backhaul link" earlier.
> If the fb is verifying a claimed webid by visiting its stored URI, then
> it needs to verify that its pubkey matches the pubkey served by that
> URI.  But to verify that it is legitimately reaching the URI, the FB
> needs to validate the certificate of the web server hosting the FOAF
> file.  This leads to either:
> 
> (a) infinite recursion, in the case where the web server's cert itself
> contains a WebID-style URI, or

I did argue that the equivalent of a WebID for a web service is the host:port pair for which there is even a type in the X509 cert spec. Indeed such a service ID can be placed in the Subject Alternative Name (SAN) field of the certificate. So you would place that in the SAN and the lookup then would be to DNS. If you can trust DNS there is then no infinite recursion. Which is where your next point fits in

> 
> (b) some other certificate verification method, which Henry Story
> points out is the standard X.509 cartel today, and may move to
> DANE-style DNSSEC-backed key publication.  

But you are right: other methods to verify that you are accessing the correct machine can be added. The more proofs you have the better, and that is a core part of the PGP philosophy. So you could increase your trust by having the TLS server

  - serve a PGP certificate signed by multiple CAs
  - have that PGP certificate also appear in DNSsec 
     (though here the DANE group is a bit obtuse, they seem to only want X509, so one will have to start another RFC)
  - put the same public key in an X509 cert that you place in DNS
  - other methods? Perhaps the PGP cert can contain a WebID and that of its signers too, so that it is easy to find them.

> I don't think either of these methods is acceptable, so that leaves us with:

Why? It seems to be core part of PGP philosophy to allow one to increase the numbers of ways of gaining trust.


> (c) sort out a better, decentralized certificate verification method.
> But if we're going to do that, then we've begged the question.  We might
> as well use this hypothetical better certificate verification method
> directly on the client-side certs in the first place.

It seems to me that once you have the servers clearly identified you have jumped of the main hurdle: you can then take it that the representations they serve are correct. Especially in the case of freedom boxes which are single user (or close) end points.

 You can then use the network effects of the web. Btw if you want to measure the power of the network effect of the web think of the following: the current web has grown with an insecure DNS system, mostly without end to end security, and where there is security with a pretty limited trust system.

> I'm sorry i'm not offering a specific solution right now.  I would be
> happy if someone else came up with one, or if i got the time to work on
> the approaches that i think are promising.
> 
> 	--dkg
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss

Social Web Architect
http://bblfish.net/