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

Re: Regarding WebID Certificate in TLS

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Fri, 24 Apr 2015 12:14:29 +0200
Message-ID: <CAKaEYhKEiCAOc38T4-=uX961-+8rTcW-yuhCLTsC8Wwp3U==Kw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: "fumugami@gmail.com" <fumugami@gmail.com>, public-webid <public-webid@w3.org>
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

This archive was generated by hypermail 2.3.1 : Friday, 24 April 2015 10:15:03 UTC