RE: comments on draft

david's comments are all very sensible for one thinking in either of two older traditions: the original CA tradition of the 1986/88 authentication framework, and the post-2000 PKI-interpretation of CAs. However, webid is not limited to either of those traditions. webid validation does not presume that the validator is a certificate-using system (to use a phrase from the PKI world).
 
For example, a conforming system may not bother verifying the signature on a client cert. A conforming system may ignore a criticial extension that it does not recognize. PKIX rules on what RDN components are mandatory in subject names do not hold, for conformance. in short, webid is not a certificate using system. If one uses an https PGP ciphersuite and one presents a PGP certificate type to the webid validation code, an extended system is entirely proper and consistent with the model to use it to establish the user had control of the key performing client authn. If one presents no cert (s) from the user from the the wire, again this is entirely appropriate. it is entirely appropriate for the server endpoint to discover its own cert token (that authenticates the keys used to do client authn for the ssl ciphersuite). Nothing (in the spec) says that client authn MUST be performed using RSA signatures (on the cert verify message). In this spec, it is quite appropriate to consider the SAN in a signed DH cert; one without signature key usages.
 
 
If there is a required issuer name, remember that nothing requires that it be controlled by any one large CA in the sky. There can be a million such CAs all asserting that their subjekct name is that value (and that they are one of the issuers, citing that name). David may have misunderstood this signal. The rest of the name was intended to signal that- since the rest of the name says to a human: I am NOT A CA.
 
Its inappropriate in THIS spec to suggest particular normative models of authorization. The spec should merely say that semantic web technologies are required (e.g. foaf groups, foaf accounts, foaf openid) - since they are consistent with the validation theory underlying webid.
 concerning "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?" we should ask for evidence of the opposite. After 20 years of doing this, the number of people doing cert-based authentication to websites on the internet is very small. This is becuase in general cert-based auth works poorly, due to the presence of SSL firewalls that bridge security domains (and cannot project cert authentication forward, due to the nature of the SSL3+ handshake design) This is all relevant to webid though, as it also speaks to webid adoptability.
 

> Date: Fri, 16 Dec 2011 09:55:24 -0500
> From: kidehen@openlinksw.com
> To: public-xg-webid@w3.org
> Subject: 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
> 
> 
> 
> 
> 
>