RE: comments on draft

There should be no statement that the DNS is trusted, in any particular way. DNS is not a part of semweb trust model. Not all URIs use authority concepts tied to DNS. And, webid URIs are NOT tied to http URIs (as Kingley has demonstrated effectively, and  as Im working with now sip URIs).
 
http class webid should be required to work with IP adresses in the authority fields. There must not be any assumption that the validation agent has connectivity to a DNS server (or that said DNS server has zones managed by IANA and its delegates). There must be no assumption that a conforming validation agent has any particular means of establishing whether a zone is authoritive or "official" (or not).
 
If the VA does use zones from a DNS resolver, it is entitled to use a locally-administered zone - which it says google.com is mapped to IP address X ( even though laws may have required the _official_ zone administrator to have blacklisted that google.com named RR).
 
The test will be whether the web can route AROUND DNS and routing blocks. For example, if some govt agency forces some zone authority to blacklist  piratebay.org, a test of a conforming VA will be that one can still get the profile from piratebay from a locally administered zone (despite the DNS-based blacklisting). Similarly, if the IP address is being blocked by the ISP doing the routing (acting as a layer 3 blacklisting agency), again, the test of the VA is that one can tunnel over the ISP.
 
Now, I dont believe that any of these edge cases have much to do with the real work use case, but they forcing function on the design. They establish the dependency and the resiliency of the security model. If a given implementation cannot SHOW that it can be used to circumvent the official choke points, you know that it has built in dependency assumptions abou "officially managed" and sanctioned web.  Typically, one analyzes security standards to see how the regulated "public infrastructure" dependencies have been inserted (by vendors and government types); and often they are subtle. Folks perhaps remember how mandatory key escrow was being inserted into PKI standards in the 2000 era; and how the standard text was being manipulated by the editors to express the mandatory to implement (but not enforce) rule. Folks who o bjected to the standard being edited that way tended to get blacklisted (1950s communist/gay style).
 

 

> From: henry.story@bblfish.net
> Date: Fri, 16 Dec 2011 16:08:45 +0100
> CC: public-xg-webid@w3.org
> To: d.w.chadwick@kent.ac.uk
> Subject: Re: comments on draft
> 
> Thanks a lot David for this detailed feedback. This is very helpful to the editors.
> 
> On 16 Dec 2011, at 14:49, David Chadwick wrote:
> 
> > Comments on WebID 1.0 (Draft 6 Dec 2011)
> > David Chadwick, 13 Dec. 11
> > 1. We need a section called Trust Model which summarises the trust that is needed in the system. See Appendix 1 for suggested text.
> 
> thanks, that is very useful to know.
> 
> > 2. We need to add definitions of Identification Agent, TLS Agent and WebID Verifier to section 1.2
> 
> - "Identification Agent" needs to be removed I think and replaced by "Client" and perhaps "Subject" at one point.
> This was the old terminology I found made the document very difficult to read before. And I must have forgotten to remove it 
> everywhere
> - "TLS Agent" is used as a synonym for "TLS Service".
> Question: should I use TLS Agent, TLS Service, or have both? 
> - "WebID Verifier" is defined as synonym of "Verification Agent" in the definitions. I found it useful for a few terms to have
> Synonyms, so that the language did not become too wooden.
> 
> > 3. Subject definition contains a couple of errors: princiap -> principal, and lisibility is not an English word, use readability instead.
> 
> Thanks! Easy fix.
> 
> > 4. Why does Key Chain Agent have this name it does? Specifically, why is Chain in the name as its functionality does not seem to involve building or verifying certificate chains. Wouldn’t Key Ring Agent or Key Store Agent of simply Key Agent be better?
> 
> No idea which would be better. In this case I just chose the first one that came to mind. Keychain, probably came to mind because the Apple tool that stores all keys is called the Keychain.app . There the image is clearly of a chain of keys people could have in their pockets, not the chain of certificates.
> 
> But I had not thought of the TLS association of key chain with certificate chains. So given that we are speaking to TLS people here one of those other terms may be better. A bit difficult to tell. We'll try to work that out.
> 
> 
> > 5. The definition of Guard is not quite correct. Suggest change to “..and decide if it needs to be authorised by looking at the access control rules. If the client needs to be authorised, it can first request identification and authentication and use the WebID Verifier to compete the identity checks. Finally it checks the access control rules to either grant or deny access.”
> 
> yes, that reads better. In fact that is what I wanted to write :-)
> 
> > 6. The Issue about the Issuer of certificates. We definitely do not want O=FOAF+SSL… to be the only certificate issuer. Besides being a bottleneck to performance and a single point of failure, it also represents a choke point that has ultimate control over who can have certificates. This is very undesirable. Furthermore it is not needed from a trust perspective, since the issuer does not need to be trusted (see Trust Model) and can be anyone. Finally if a way is needed of signalling WebID certificates as being different to other X.509 certificates, then we should define a new critical extension, say “FOAF+SSL” which means that relying parties must either understand this extension or reject the certificate (which is probably the behaviour you desire. If not, make the extension non-critical).
> 
> yes this is one of those issues that is still open ISSUE 59
> http://www.w3.org/2005/Incubator/webid/track/issues/59
> 
> Neither critical nor non critical extensions in X509 are really helpful here as the only way a server can have an effect on the client is by sending a certificate_authorities list of Distinguished Names when requesting a client certificate.
> 
> But you are quite right:
> 1. We should not give the impression that there is a DN that is central
> 2. The way to have a standard DN was to have the the O=FOAF+SSL CA be an open CA, with a publicly known private key so that everybody
> can mint certificates with it.
> This is something the feasibility of which we should explore in detail next. 
> 
> 
> > 7. 3.2.5 Authz. We could add an example, based on roles or group memberships, which would show the flexibility and power of the system. Suggested text is “For example, suppose a service wishes to grant access to its resources to only those WebID users who can prove membership of a specific group or role e.g. only to users who Bob says are members of the WebID experts group. The service would first need to know the WebID of Bob, and also the URL of the page where Bob stores this information e.g. https://bob.example/webIDexperts. Then the service would read this page, which contains an RDF description of the members of the group e.g. <rdf:Description rdf:about="https://bob.example/webIDexperts">
> > <member> “https://mary.example/profile#me”</member>
> > <member> “https://joe.example/me”</member>
> > <membershipList> “https://acme.co.uk/employees”</membershipList>
> > </rdf:Description>
> > ISSUE. We should be able to nest groups of users, recursively. The last entry is an incorrect attempt to do this (since we need to specify both the WebID of the list owner and the page where the list is described).
> 
> yes, I agree that a few non controversial examples would be useful. (Currently though section 
> 3.2.4.3 Authorization is a bit too deeply nested to be able to put much in there...)
> 
> > 8. Page 15 first line. Why do you assert that “People don’t feel comfortable authenticating to a web site on the basis of a certificate alone…..” Where is your evidence for this? Can you reference a research paper that presents this?
> 
> Ok, so that is badly expressed. 
> What I meant is that if you go to a web site and the browser first asks you for a certificate before you even can see the page then you are breaking the expectations that people have built up over the past 20 years, namely that you go to a site look around and then login if you want to. If you go to a site and are asked for your identity before you can see the page then you don't know really WHO you are identifying to. Robots will know, because they read the certificate, but humans don't do that, so the experience is for the human that he is being asked first for authentication.
> 
> I don't think we need a research paper to show this. But clearly this has to be explained in mode detail.
> 
> 
> 
> > 9. Minor editorials.
> 
> (just a minor detail on your notes below: our spec is not numbered by page numbers, it would be easier to refer to paragraph numbers.)
> 
> > a. p5. WebID defn “Agent as the controller” -> “Agent who is the controller” and “the document” -> “this document”.
> 
> ok
> 
> > b. p9. can or not -> can or cannot
> 
> ok
> 
> > c. p11 (it ->(if
> 
> thanks
> 
> > d. p13 step 2. If the client needs authentication and authorisation.
> 
> ok
> 
> > e. p14 a claimed WebIDs
> 
> ah yes, the s is too much
> 
> > f. p16 an https WebID -> an http WebID
> 
> I think this is correct. but perhaps instead of writing HTTP one should write https:// webid ...
> 
> 
> > 
> > Appendix 1. WebID Trust Model.
> > Assumptions: There is a server somewhere on the Internet that contains a web page identified by a Web ID URL. This web page contains a public key and the Web ID URL. The trust model for Web ID is as follows:
> > 1. The DNS is trusted to correctly resolve a WebID URL into the correct IP address for the server hosting the WebID URL.
> > 2. The Internet routing infrastructure is trusted to correctly route messages to destination IP addresses.
> 
> Though the above 2 are mitigated by the use of server side Certificate Authorities as the WebID should be an TLS based resource.
> Is there a way of adding that in?
> 
> > 3. A server hosting a WebID URL is trusted to only allow the subject holding the private key corresponding to the public key published at this URL to modify the contents of this page, but not to modify the referent component of the WebID URL published on this page i.e. the WebID URL minus the trailing fragment.
> > 4. This server is further trusted to ensure that the subject’s public key certificate containing the public key published at this URL contains this WebID URL in its subjectAltName extension (Q. is this the whole WebID URL or the referent part only?). Note. The server is effectively acting as a Certification Authority, verifying that the public key and the subjectAltName belong to the subject who “owns” the page at this URL.
> 
> I am not sure it is required that the server have done that. What if someone makes their own public key and puts in a profile on an Apache Server?
> 
> > 5. A Key Store is trusted to not divulge the private keys that it holds to anyone other than the key store owner i.e. the subject of the corresponding public key certificates.
> 
> yes
> 
> > 6. Subjects are not inherently trusted, and are assumed to be capable of inserting any WebID URLs into any WebID certificates. Subjects may also divulge their private keys to someone else without a relying party being able to determine that this is the case. Note. It is outside the scope of the WebID specification how a relying party determines whether a subject is trusted or not
> 
> yes, neither is what is written in the profile document to be trusted per se. 
> 
> > 7. A certificate verifier has trust in the cryptographic components to correctly verify certificate chains mathematically. However, none of the issuers of the certificates in a WebID Certificate chain need to be trusted. If a WebID Certificate is not self-signed, then the certificate chain will have to be verified up to either a self-signed certificate to ensure that no contents of any of the certificates in the chain have been tampered with, or a trusted certification authority.
> 
> I am not sure this needs to be done. If the Certificate chain has been tampered with, that just invalidates any claims that one could have
> deduced had they not been invalidated. It does not invalidate the WebID Verification that was just done.
> 
> > 8. The outcome of the WebID trust model is that a relying party can trust that the client is identified by the WebID and does possess the private key corresponding to the public key in the WebID certificate.
> 
> indeed.
> 
> Ok, I'll leave others to comment too, and then I'll integrate as much as stands up to the spec.
> 
> Thanks a lot for your help,
> 
> 
> Henry
> 
> 
> 
> > 
> > -- 
> > 
> > *****************************************************************
> > 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/
> 
> 
 		 	   		  

Received on Friday, 16 December 2011 20:15:40 UTC