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

Regarding WebID Certificate in TLS

From: <fumugami@gmail.com>
Date: Fri, 24 Apr 2015 07:09:27 +0200
Message-ID: <CAC1+qv+NJPLSXgKpqEQGoQKGujG0tP8kFx3zWuRhTMz6pPqJhw@mail.gmail.com>
To: public-webid@w3.org
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.

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

Do I need to subscribe to receive responses? I don’t know how exactly
mailing lists work.
Received on Friday, 24 April 2015 07:20:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 24 April 2015 07:20:19 UTC