Re: WebID-ISSUE-45 (pgp-comparison): Compare WebId with PGP/GnuPG Web of Trust [research]

On 23 Feb 2011, at 13:33, Reto Bachmann-Gmuer wrote:

> 
> On Wed, Feb 23, 2011 at 12:28 PM, Henry Story <henry.story@bblfish.net> wrote: 
>> we should address this chicken and egg problem.
> 
> I am not sure if the chicken and egg problem has found a solution yet. There are claims going both ways :-) And we can continue enjoying eggs in the meantime.
> 
> The PGP-Wot approach is key-signing parties. I think the approach of WebId should be growing trust with increasing interaction over increasingly secure channels, without requiring a document to be shown (which the usual form of identity proof at key-signing parties) as what matters is not your passport of your DNA but your social identity within the networks in the physical world and on the web.

Agree. 

> 
> 
>> There seems to be a misunderstanding: As often no more security than the one offered by email authentication is needed it is a feature of WebId to offer something at this level. WebId works also with insecure profile documents which roughly offers the same security as email verification (email can be more and maybe even less secure but that's not the point).
> 
> yes, WebID over unprotected connection is not secure. We leave it there to get things going. But when seriously discussing WebID we should be assuming TLS on both sides.
> I disagree. We should discuss different levels of security and how higher security can evolve. As the fact that email-verification is so widespread shows, that this low degree of security is often regarded as safe enough for the purpose at hand.

agree. 

But just one should be careful not to confuse different levels then when speaking of how secure something is. It is very easy to attack WebID over http - as it is e-mail verification.

> 
> 
>> Here I'm referring to the transitive trust features PGP WOT bases on (not to anything relating to emails). The discussion on signing (parts of) profile documents could allow transitive trust features. In the example in http://www.w3.org/wiki/File:X509CertsAndSocialGraph.jpg you may trust jane because you know Bruno and Bruno knows Jane but this doesn't give you a reason to believe that XYZ is in fact the public key of Jane.
>> The trust relation the image describes may be important for assigning rights to Jane, the trust path I'm talking about (and which is implemented pretty well in PGP) is necessary for authentication.
> 
> If he links to Jane referentially, and you get those keys that way, then why would you not have *a* reason to believe that is her key? 
> The fact that Bruno points to https://jane.name/#j is Irrelevant for the association between <https://jane.name/#j> and XYZ. To trust this association I have to trust the holder and the signer of the server certificate for jane.name.

As said before you have to trust many thing besides that.

Yes, jane.name:443 the server could have a WebID too, then you could calculate a measure of trust given your beliefs and your knowledge of her network. If jane chooses to use jane.name as her provider then you don't necessarily need to have an idea of how you evaluate the provider too. It is also partly her responsibility to choose a good provider. 

>  
> You may worry that she puts it on an untrusted host? Well then what of a PGP owner who puts his private key on a virus infected computer? Again there is no absolute. One has to look for coherence.
> Right, the incoherence is showing the lack of security of CA-based traditional PKI and offer an improvement for client certs while relying solely on the traditional PKI for the trust into the WebId-Key association.

That is not an incoherence. We are trying to bootstrap something by using existing infrastructure, of which  PKI is a useful working one. As you can see getting anything going is incredibly slow and tedious process. PKI is not that bad, and we are not attacking it on all fronts. It is not useless. When the web was getting going most people had little understanding of network security, even the security people will tell you that they did not. One just improves things over time.

The issue with client certificates in PKI is that they are very difficult to make, because they require too much verification by entities that are not able to give that verification, and the cost of it would be too high. The cost makes is also then tied to the complexity of dealing with private keys that were made for one occasion. As a result it is hardly used, and password security reigns.

  That is why you have to be careful: too much security is the enemy of security. And in security you don't need a lot to loose.

Once the principle of WebID gets going it should be easy to add new webs of trust, such as finding if you trust the hoster of an identity.

But we agree I think given your point at the beginning of this e-mail on building various levels of security. Perhaps one should call those _aspects_ of security.

>  
> The danger of trying to go for military grade security, is that it ends up costing a fortune, and is rarely used - like military grade secure computers. So if we can build something that enables that without requiring that, then one can get adoption and build use cases of increasing security needs. 
> 
> We are talking about building a technologies that support various degrees of security. Supporting the same level of security as PGP doesn't seem an exaggerated requirement to me. As you correctly describe, there is no absolute security, but there is a level of which we can realistically believe that it can assure private and secure communication even under conditions that would otherwise be a serious threat to freedom of communication.
> 
> With WebId the degree of trust that the communication partner is who is claim to be should be solely a function of the of trust (both in their honesty and technical security) into the referring parties under condition that:
> - you are in full control of the signals you receive and that you emit 

There is no full control. Do you control the software of your OS? Have you read all its code? Do you know the hardware? Do you know the hosters of your hardware? 

> - you are able to keep some secret key safe

That is also not an absolute. It depends on the above already, and if you live in a country with a lot of guns around, and people willing to attack you in your home, on the street, to extract your private keys. It also depends on the police and political institutions you are in.

> - you're able to correctly apply encryption algorithm
> - the applied encryption algorithms are safe

And those are unknowns if you push a lot too far. To know the encryption algorithms are safe, you would need to study mathematics very very widely. And the institutions where you can do that are probably military backed institutions - after all they are really interested in the subject.

> 
> I think we shouldn't try to cover situations where the attacker can invisibly walk through walls and play around with what's in our minds.

You don't need to have attackers walk through walls to see that guaranteeing the security of your hardware and OS is itself very difficult.

Why do I bring that up? Well because you bring up the issue of trusting the hoster of jane.name earlier on.

I would go the other way. A WebID identifies an agent. It does not need to identity a physical person. So think of http://jane.name/#i as the agent that is both partly the physical person and also somewhat the hoster - since she trusts it enough to do be identified through it. Now if she hosts her own files, then you have no flack.

But yes, in a further trust network you would need to take into account who makes the statements, and who serves them. But it all depends on your needs. If you want to allow someone to post comments on your blog, or invite people to your party, or many other things, then all of that can be part of the background assumptions.

Henry

> 
> Reto

Social Web Architect
http://bblfish.net/