- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 24 Apr 2015 12:14:29 +0200
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: "fumugami@gmail.com" <fumugami@gmail.com>, public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYhKEiCAOc38T4-=uX961-+8rTcW-yuhCLTsC8Wwp3U==Kw@mail.gmail.com>
On 24 April 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. > Yes, it was a bootstrap. Also provides passwordless login and strong PKI, and is available in all browsers. > > >> 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. > Having used certificates in the browser daily for the past few years, there has been an evolution and regular updates. I dont think it's prioritized tho. The main issue I've found with certs is multiple requests from chrome on android using a low spec phone is quite a difficult UX. > > The "industry" have rather settled on the FIDO Alliance stuff. > Facebook have implemented WebID (not with TLS), and google have said they would offer FOAF, but have not yet. > > 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 think that's always been the case, it just took some a while to realize that decoupling identity and authentication was a good idea. > > Anders > > > > >> Do I need to subscribe to receive responses? I don’t know how exactly >> mailing lists work. >> > > >
Received on Friday, 24 April 2015 10:15:02 UTC