W3C home > Mailing lists > Public > public-webid@w3.org > April 2015

Re: Regarding WebID Certificate in TLS

From: <henry.story@bblfish.net>
Date: Fri, 24 Apr 2015 11:31:10 +0200
Cc: fumugami@gmail.com
Message-Id: <7BC35892-51FC-4AA7-9D15-2AF857B1DE8F@bblfish.net>
To: public-webid <public-webid@w3.org>

> On 24 Apr 2015, at 09:39, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> On 2015-04-24 07:09, fumugami@gmail.com wrote:
>> Hello,
>> 
>> I’m just an individual interested in the idea of a decentralized identity like WebID.
>> 
>> I want to enquire you about the reason that led you to use an X.509 certificate in TLS authentication..
> 
> I guess the reason is because this mechanism is already in place.
> 
>> 
>> X.509 certificates are part of the Directory system. It is a system used widely in centralized, hierarchical environments, where entities are named by their hierarchical Distinguished Names. The X.509 certificate is a signed verification that a certain public key belong to the given entity identified by a Distinguished Name. This claim is verified by an entity with higher priviledges, which is trusted.
>> 
>> Now, when you send an X.509 certificate, the client or server has a list of trusted CAs and it verifies that the chain of signatures on the received certificate is valid. This is done LOCALLY, without contacting anyone. The only place a remote resource is fetched is to get a CRL that can invalidate a given certificate, but that list is also signed by the CA and then verified locally by the client/server.
> 
> That's the traditional use of X.509 certificates.  There are many applications that rely on self-signed certificates like point-to-point connections between two boxes using TLS.
> 
> 
>> 
>> In WebID you are proposing a decentralized system, where the entity is authenticated by sending a CLAIM of their identity, which the server then veririfies by contacting a REMOTE resource. This is completely different from what X.509 certificates are designed for. It would be better and wiser to do it like this:
>> 
>> 1. In order to support WebID, the server sends a CertificateRequest with a webid(TBD) ClientCertificateType value. The "certificate_authorities" list is empty or ingored.
>> 
>> 2. The client sends something like this as the Certificate message:
>> 
>> struct {
>> uint8 version; /* In case the definition changes later */
>> opaque webid<1...65535>; /* The WebID identity URI */
>> } WebIDClaim;

yes, the client could send webid instead of the certificate, and another similar protocol could then be built. But

 * it would require changing most TLS clients, and so there would be little gained
 * it would require the server receiving the WebID to then fetch all the public keys from the WebID profile document, and then it would have to guess which one of the public keys was going to be used 
 
Currently we already have public key identification of the user after the TLS handshake which means the server can already  serve some content to the thus identified user. The WebID step is just one additional identity verification step.

The spec should probably try to bring this out more clearly.

But in any case a similar idea could be used for a different authentication scheme that uses the newly enabled crytography in the browser. See:

https://github.com/linkeddata/SoLiD#webid-rsa


>> 
>> 3. The server, upon receiving the above, fetches the associated public key from the Profile Document using the URI in WebIDClaim.webid.
>> 
>> 4. The client sends a ClientKeyExchange with the pre-master secret encrypted with its WebID private key.
>> 
>> 5. The server decrypts the pre-master secret with the fetched public key. This key is claimed to be the client's. If the public key is incorrect, this will result in an incorrect master secret and the handshake will fail.
>> 
>> 6. If the handshake succeeds, the WebID is verified and the client authenticated.
> 
> You are proposing changes in the TLS protocol.  That's a very big task and there must be extremely good reasons for trying that.

Not only that but you are still making a request to the remote server, so you have not gained anything.

> 
> 
>> 
>> This would make the handshake message smaller, and allow implementations to separate WebID code from X.509 code. The server's WebID verification process is a process of verifying an unknown claim. It relies completely on the trueness of the Profile Document and that it is fetched correctly and from the right source. There is no certificate. Nothing is certified prior to receiving the identity claim.
>> 
>> Anyway, I think the major obstacle in adoption of a decentralized solution is that most people are used to be governed by some kind of single government and the idea of a decentralized system brings anarchy and chaos to mind.
> 
> The purpose of WebID is not replacing eID-like systems.
> 
> WebID-TLS is fine on a conceptual level, however it is built on platform that essentially haven't been updated the last 20 years and it has been rejected by all major service providers as far as I can tell.
> 
> The "industry" have rather settled on the FIDO Alliance stuff.
> 
> Note that WebID nowadays are "marketed" without the TLS since the conveners claim that it is the WebID data structure that is the core.

I don't think Anders Rundgren has ever implemented WebID, LDP, Web Access Control or any  of the other things that constitute the working stack for which we are building this, so you can safely ignore his rants on these topics. He has his own protocol that he wishes to sell to people and he seems to think that by hanging out on mailing lists and spamming them he can accomplish this.

Otherwise I agree with the points he made previous to his rant.

> 
> Anders
> 
> 
>> 
>> Do I need to subscribe to receive responses? I don’t know how exactly mailing lists work.
> 
> 

Social Web Architect
http://bblfish.net/
Received on Friday, 24 April 2015 09:31:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 24 April 2015 09:31:41 UTC