Re: Regarding WebID Certificate in TLS

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;
>
> 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.


>
> 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.

Anders


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

Received on Friday, 24 April 2015 07:40:37 UTC