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

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.
 
cert fields of choice: Extended policy fields and various SAN fields are well supported in browsers dialogs. But, is this that relevant? 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. 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.
 
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)
 
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.... 

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?
 
Again, the main decision point is: should this protocol work with older fielded browsers, or not? 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.
 
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!