RE: WebID in Browsers conf feedback

 david chadwicks repeat of comments from unknown parties is of the same essence as the Paypal comment. They are both stuck in the https conception of a decade ago, not seeing how https/ssl can evolve to do what is *already* being done with IPsec and client certs.
 
Both criticisms have the same structure: that server farms based on load-balancing, failover, HA, .... architectures CANNOT adopt webid - BECUASE of the need to follow a reference. Any reference.
 
In a UCI world (where anyone can make up any crap), obviously who in a Paypal-grade of corporate entity wants to be seen publicly to be following a ref to irc://childporn.com, just because its presented in a cert ref from an nonymous party seeking to identity (and disrupt)? David's comment about someone's argument was that by IMPOSING trusted intermediaries (known as CAs), paypal's of the world are protected - as the CA has vetted the refs, up front.
 
Of course, this is the anti-thesis of the webid movement. The whole claim basis of webid as an argument is that the sematic web has a "reputation" trust model built in. And, one uses that, rather than imposing CAs as qualifying-introducers.
 
SO, the defense has to address the objection, expressed in its own terms. And that real objection is (ignoring the suggestion to go back to CAs) that webid needs to be able to qualify WHICH refs a consumer follows, before it follows them.
 
Its like saying: given a webid claim from a client cert newly presented, one needs to consult the semantic web as a trust model to find out whether or not the reference itself is something one wants to follow, before following it and evaluating the *content* of the triple store similarly against the semantic web and its trust model (now applied to triples, vs mere refs). One has to consider the provenance (hint) of the ref that is.
 
Now, knowing Henry argument style, he would probably say: this is architecturally already dealt with, because we are are assuming that those URI refs have domain-names, registered in DNS (as managed by or rooted by US firms, in whom we globally trust). Thus the DNS is the Reputation-source about the refs, since its the reputation source about their domain-names - and the notion of "authority" built into the URI concept. Webid is thus formalizing that the DNS (signed zone) is the authority of that namespace of URIs. DNS decides it the authority component of the webid resolves, or NOT. Its a security authority for refs, that is.
 
Now, we have got rid of CAs (and replaced them with more scalable signed DN zones!).
 
Little or none of this is talked about in the spec. Similarly, the control model of centralized/de-centralized implications of DNS and signed azones is not explored. It doesnt say how de-centralized zone signing is to be achieved (allowing for walled-garded DNS servers, with their own signed zone key management, ....)
 
 
 
 
 
 
 
 
> Date: Sun, 12 Jun 2011 12:31:46 -0400
> From: hhalpin@w3.org
> To: public-xg-webid@w3.org
> Subject: Re: WebID in Browsers conf feedback
> 
> The W3C released a blog post as well:
> 
> http://www.w3.org/QA/2011/06/workshop_tackles_the_hard_prob.html
> 
> 
> Also, we will produce a final report within a week or two.
> 
> As regards WebID, I think David Chadwick's summary is good, as is Brad 
> Hill (Paypal)'s summary of the security issues that need to be addressed.
> 
> cheers,
> harry
> 
> 
> On 06/12/2011 09:12 AM, Henry Story wrote:
> > Here is some feedback from the WebId in Browser conf.
> >
> > Henry
> >
> > On 26 May 2011, at 14:00, David Chadwick wrote:
> >
> >> Hi Henry
> >>
> >> I got some good feedback from people at the workshop, which you should consider in a revision of the protocol.
> >>
> >> 1. You should not interrupt an SSL/TLS session midway (to fetch anything, either a remote page and/or the remote server's cert).
> >> The solution to this would be either
> >> a) get the browser to issue self signed certs for the user (the best solution), or
> >> b) get the browser to send the user's server signed cert plus the server's cert which has been signed by a known root CA during the TLS handshake. In this way the receiving server can validate the signature chain without having to make a call out. However this would still mean modifications to the SSL software similar to that used by proxy certificates in their chain validation (since the signing servers' cert is flagged as an end user cert and not a CA cert, so it isnt allowed to issue certificates to end users. Consequently standard X.509 cert chain processing software will fail.)
> >>
> >> 2. it is not a good idea to ask a server to go and fetch any remote page (in this case the user's web id page) since an attacking user can point the server to poisoned pages that can contain any arbitrary code to be executed by the fetching server.
> >>
> >> I am not sure what the solution to this is Internet scale, since the whole process hinges on user's being able to point to arbitrary web id pages. For small scale use you can have white lists of known trusted servers and only allow user's to store their web id pages on these trusted servers.
> >>
> >> 3. Some people questioned how usable the PGP type web of trust would be, and whether it would scale to Internet proportions. One comment was I would not want the semantic web crawling to be more than two links deep as I cannot trust anything further removed from me than that. I think that in order to establish links between people at Internet scale you need around 7 links in order to connect most people together.
> >>
> >> Hope these comments are useful
> >>
> >> regards
> >>
> >> David
> >>
> >>
> >> *****************************************************************
> >> David W. Chadwick, BSc PhD
> >> Professor of Information Systems Security
> >> School of Computing, University of Kent, Canterbury, CT2 7NF
> >> Skype Name: davidwchadwick
> >> Tel: +44 1227 82 3221
> >> Fax +44 1227 762 811
> >> Mobile: +44 77 96 44 7184
> >> Email: D.W.Chadwick@kent.ac.uk
> >> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> >> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
> >> Entrust key validation string: MLJ9-DU5T-HV8J
> >> PGP Key ID is 0xBC238DE5
> >>
> >> *****************************************************************
> > Social Web Architect
> > http://bblfish.net/
> >
> >
> 
>