Re: Regarding WebID Certificate in TLS

On 24 April 2015 at 07:09, fumugami@gmail.com <fumugami@gmail.com> wrote:

> Hello,
>
> I’m just an individual interested in the idea of a decentralized identity
> like WebID.
>

Welcome!


>
> I want to enquire you about the reason that led you to use an X.509
> certificate in TLS authentication..
>
> 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.
>
> 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.
>

This may be of interest to you:

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

Is it along the same lines?


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

Yes, in the last 5+ years this has been the case.  I've been building apps
for webid+tls, but it's really hard to find even a dozen active users.  By
far the most used deployment of WebID is with facebook authentication.


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