- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 16 Dec 2011 09:55:24 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4EEB5BDC.6020108@openlinksw.com>
On 12/16/11 8:49 AM, 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. > 2. We need to add definitions of Identification Agent, TLS Agent > and WebID Verifier to section 1.2 > 3. Subject definition contains a couple of errors: princiap -> > principal, and lisibility is not an English word, use readability > instead. > 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? > 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.” > 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). > 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). > 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? > 9. Minor editorials. > a. p5. WebID defn “Agent as the controller” -> “Agent who is the > controller” and “the document” -> “this document”. > b. p9. can or not -> can or cannot > c. p11 (it ->(if > d. p13 step 2. If the client needs authentication and authorisation. > e. p14 a claimed WebIDs > f. p16 an https WebID -> an http WebID > David, Some tweaks to your comments. > 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: Web Page leads to confusion, how about a Resource (e.g., a Web Page). > 1. The DNS is trusted to correctly resolve a WebID URL into the > correct IP address for the server hosting the WebID URL. Hosting the Resource. > 2. The Internet routing infrastructure is trusted to correctly > route messages to destination IP addresses. > 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. Global substitution needs to be applied to #3 of the form: s/WebID URL/Resource . > 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?). This server is further trusted to ensure that the Resource it hosts posses the following characteristics: 1. fine-grained structured in the form of an EAV/SPO based directed graph pictorial 2. exposes a Resource owner's WebID (a URI based Handle) and Public Key relation that mirrors the subjectAltName and Public Key relation in the subject's certificate. > 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. s/page/Resource . > 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, but it doesn't have the same pivotal effects re. TLS+WebID due to the "mirrored claims" aspect of the verification protocol. Losing the device hosting your private key isn't fatal. Its only one part of a federated relation. > 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 See comments above. > 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. If the relation mirror is broken i.e., ceases to exist, none of the above will facilitate successful verification. > 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. > Plus the fact that this is mirrored on a server. The local keystore and a server have mirrored claims that are verifiable, via combination of trust logic and cryptography. -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 16 December 2011 14:56:43 UTC