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