Re: comments on draft

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