Re: WebID-ISSUE-20: Portable and Hosted Certificates [WebID Spec]

On 1 Feb 2011, at 11:18, WebID Incubator Group Issue Tracker wrote:

> The WebID protocol currently requires the use of X.509v3 certificates, those certificates need to be stored on the client side and sent as part of the TLS authentication process.
> However, provision is made in the Transport Layer Security (TLS) Extensions RFC [1] for certificates to be passed by URL, rather than value, by using the "Client Certificate URLs" feature [2].
> It should be noted that this feature is already standardized and covers most of the WebID protocol in a well defined manner, indeed it has almost all the key elements of "WebID".
> [1]
> [2]

Thanks for pointing this out. It is useful to know and think about.

The point of passing the certificates by value as defined in TLS security extensions RFC is (it seems) not to bypass the Certificate Chain, and so to allow us to decouple from CAs and create a web of trust instead of a hierarchy of trust, but just to enable small devices, or devices with very low bandwidth, to start the connection. So as far as that goes this does not cover the most important aspect of WebID.

Now could it be used by WebID? Well potentially yes, at different levels.

 1. As far as the above is a way of getting a certificate indirectly and semantically equivalent to getting them directly, there is no issue. The only thing it does is add one more HTTP connection - preferably https connection I suppose if the hash of the certificate is not sent along by the client - to get that certificate. 

 Question: It would be interesting to see how many client and server libraries support this extension out of the box, how many don't, and so on.

 Hypothesis: My guess is that it is not very widely deployed because, it requires a very good synchronisation between the client and the server where the full certificate is deployed, which in the case of CAs just adds one more level of complexity to the protocol without a huge added benefit.

2. It is possible that this RFC extension could even be developed in a more WebIDish manner.
   The RFC specifies that each url_and_hash_list, point to a document whose optional hash hashes the "application/pkix-cert" representation. But the RFC cannot determine that that be the only format returned. Potentially as developed by ISSUE-6 "Using ASN.1 formats for WebID description", but going the other way around, one could think of what we call a Profile Document to be such a certificate, whatever format it be in (assuming that one develop the semantics for certificates clearly) [1]

 Issue: So could one think of those URLs as WebIDs? Not quite, because there is no requirement in the RFC that the certificate be tied in the required way to the identity of the Agent. It is the publishing of the WebID at the WebID profile location that allows us to bypass  the CA as far as the authentication of the reference of the WebID goes, as described in the FAQ "How does Secure Authentication Work with FOAF+SSL?" [2] This is easy to see, by a simple thought experiment: imagine that Chuck [3] wishes to pretend he is Bob. All he would need to do is place his self signed certificate at any location with the WebID of Bob, and presto he would be logged in as Bob. So extra constraints would have to be added: The publication URL and the SAN need to be linked in the right way.

 Issue: what advantages would this bring? It could reduce bandwidth used between client and server which may be a good thing, especially for large sites such as Google. On the other hand it does come with a TCP set up cost, as the client has to first ask for a "client_certificate_url" in the extended client hello. It is also unlikely to be widely deployed in browsers.

   So an interesting thought which will require change to the spec, in the form at the minimum of a note, but possibly more extensive.

[1] that the application/pkix-cert representation is used there should serve as input to ISSUE-6.

Social Web Architect

Received on Tuesday, 1 February 2011 11:41:22 UTC