Re: WebID-ISSUE-19: x509v3 Independence and TLS Extensions [WebID Spec]

On 1 Feb 2011, at 19:26, Peter Williams wrote:

> on issue 19. SRP doesnt have much support because of patent licensing issues . But, its example does show the relevance of the extensibility point called the ClientHello - which contrasts with cert-based extensibility points. Rmeember, the client hello data is ultimately authenticated by the handshake, providing state machines are built correctly. it can be confidential, by the usual double handshake trick.

Good to know.

>  
> cert fields of choice: Extended policy fields and various SAN fields are well supported in browsers dialogs. But, is this that relevant?

Well it is something. It has been around for a while. This is not a minor issue. Browsers take a very long time to be updated (the half life is perhaps 5 years). And they need to be updated in large enough numbers for new features to be useable. 

Also browser vendors need to be convinced of the usefulness of a feature. They tend to do that when they see a lot of users or money. After all every new feature is a maintenance issue. So the point is one needs an opening to get things started, and in a big enough way that one can then get big adoption changes on the ground.

> We are working with the machine-centric web, which cannot depend on human visualizations for semantic communication. The dialogs are MOSTLY there for legal reasons - that the legal design parameters (never discussed here) are not effective without certain dislosure properties. This introduces identified a "legal issue" therefore.

Yes, but it is there. It is easy to understand and can get developers going. I find it useful for example, when I have a few certs and I put a bad DN in there, I sometimes can't distinguish them. So the SAN helps.

> We need to characterize how webid protocol is different to classical https, where the the older tie in to legal protocols enforced via the certs policy fields that bind rules to a protocol exchange are not even in scope, in this field. If there are to be legal tieins, then semweb work is needed - to do better than the cert dialog.

Of course one has to do better but "A journey of a thousand miles begins with a single step" as Lao-tzu says. So you need two things: to know where you want to go - though one should leave that quite open - and the first thing one can do.

In my view the most important browser improvements are currently to do with login/logout issues, and making it easy for the user to see what identity he has on a web site. That is what ISSUE 14 is about http://www.w3.org/2005/Incubator/webid/track/issues/14

The second biggest improvement to our security is going to be DNSSEC, and the ability to publish keys for servers there. That is big because it makes deploying SSL server side a lot easier, a point Dan Kaminsky has made in great detail in numberous of his talks.

All we need is SAN and perhaps IANs to get the linked data piece. It's the linked data piece that people have to understand, not certificates so much :-)


> This suggests there exists a legal issue topic - mostly agreeing that webid protocol does not do enable the kind of legal rules projection that classical https does project (becuase of its integration with human-readable dialog boxes)

yes, quite possibly there will be a legal story. But I think those will be beyond the scope of this group at present.

> legacy issue:
>  
> > In any case my guess is that few (if any) browsers currently implement this, so that need to specify the X.509 version and how to deal with multiple SANs. Dealing with Multiple SANs is going to be a lot easier to specify and work with, than getting browser vendors to add extensions to their TLS layers.
> 
>  
> Not sure I agree. IETF is regularly designing ClientHello extensions, and they keep rolling out to all as browser folks exploit the extensiblity point. There are quite a few of them now.... 

Is there a list of these extensions somewhere and how they are implemented in each browser? That would help get some idea of what the steps after the first few steps can be.

> 
> But the main point is: how much does the web relaly want to carry forward the (ancient world) of certs and ASN.1? Is this the time to make a break?

There is no point making a break for love of breaks. One has to understand the value of
a change and the cost of it, in terms of implementation and in terms of convincing people, which can itself be huge. Of course I am sure many people would be on the side of removing ASN.1. I bet you Dan Kaminsky would.

>  
> Again, the main decision point is: should this protocol work with older fielded browsers, or not?

Yes it should.

> If so, we are stuck with legacy, and we will still have ASN.1 cert 10 years from now - yet more deeply inserted into the crud of the web. It just gets harder and harder to eliminate.

No, because of the flexibility of the design. We just care about the proof that the client has access to a private key, and then tying that proof to a confirming URI. You can change the format of ASN.1 to XML-DSIG, it won't make a big difference. A few client libraries will need to be updated that's all. 

>  
> My gut is : be bold. Dont fall into the legacy trap. unlike the FOAF+SSL team, the W3C has the infuence to overcome issues like; with its relationship management skills. Browser versions (delivered 12 months time, from now) happen regularly. In windows, its even an OS dll update... not a browser update!

Well I propose a multi step approach. Finish the spec as it is now, as step 1. 
In parallel start exploring ideas of longer term changes, as we have been doing this last week by exploring the very rich extension space in TLS.

But watch out: there is a huge amount of research in this space on the semantic web angle

   http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/

Working through those ideas is going to take a lot of time. 




>  
>  
>  
>  

Social Web Architect
http://bblfish.net/

Received on Wednesday, 2 February 2011 10:43:00 UTC