Re: future of Identity on the Web

On 25 Oct 2011, at 22:20, Edward O'Connor wrote:

> Hi Henry,
> 
> Harry wrote:
>>> WebID was not viewed as very convincing by the vast majority of
>>> attendees at the workshop and there were serious security concerns
>>> raised by Brad Hill.
> 
> And you replied:
>> you keep saying that Harry, but I don't think I know of these security
>> concerns.
> 
> In [1] you cite Brad's primary concern, though I can't find his original
> email. You quote him as saying
> 
>> Primarily, I believe that interrupting the TLS handshake as part of
>> the protocol is a complete non-starter for a variety of reasons.
> 
> …and I think this objection of his still stands.

Thanks for pursuing Ted.  As I said before I don't think it stands at all. But clearly more explanation is needed.

So let me put forward the following: the TLS handshake does not get interrupted at all. Let us be clear about what Brad Hill meant

> 
> The quick summary of my concerns is that:
> 
> 1. The existing install base of TLS terminators cannot support the protocol
> 2. TLS terminators must communicate WebID context to apps
> 3. Performance and scalability is terrible relative to server-auth-only TLS
> 4. A major denial-of-service attack surface is introduced by the protocol

So all TLS terminators need to do is verify that the client did in fact own the private key of the public key sent in the certificate. Once they have done this they are done. The next stage happens at a different layer. At that point you can say that the terminator has just proven that the identity of the user is the user with that public key: i.e. the following

_:X a foaf:Agent;
    cert:key :pubKeySent .

Where X is known by description as "The agent at the end of that connection".

The checking of the WebID can then be done, that is the substitution of that local handle _:X with the URL that is claimed in the certificate. But this does not need to be done by the connector at all!!

So

1. TLS terminators can support the protocol
2. TLS terminators don't need to know anything about WebID. They can just be dumbed down.

Next with 

3. Performance and scalability is terrible relative to server-auth-only TLS

There is only one connection to the WEbID server and that can be cashed, so there is a bit of a cost on the first connection. But even normal TLS is supposed to do something like verification of the certificate on a revocation list. Other requests can use information from the cache as long as the cache is felt to be valid, which is no different from checking revocation lists.

But if you really feel this is a serious issue for large providers, then we can help you out, without any trouble at all. We were just waiting for people with such issues to talk up a bit, because I don't want to make the protocol more complex without reason. It is simple: We just need to use an Issuer WebID. So let's say Apple issues a number of certificates, they can issue each of them with a webid of

<https://apple.com/id#AAPL>

Then any server that finds the public key of AAPL, won't need to check the profile of the user: it will just need to verify that AAPL signed it. Of course it could then do another check on the WebID to get the latest information from there, but perhaps you are right - that could be done in a different thread between two connections.

Does that help? Is that something you would like us to add to the spec?

Henry


> 
> 
> HTH,
> Ted
> 
> 1. http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0127.html
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 25 October 2011 21:05:10 UTC