RE: browser change; little, nothing or a lot?

Dane is just this:
 
Instead of trusting a certification authority to have made
   this association correctly, the user might instead trust the
   authoritative DNS server for the domain name to make that
   association.

 
What Hoffman is arguing (and Hoffman is an interesting engineer with superb, Henry-class, writing skills, with a background you might want to research) is that browsers and multi-site https libraries shoud ONLY use the DNS for authority resolution. Its not said as obliquely as I say it here: rather than cert-based mechanisms that place DNS only on the same level as any other name resolver (eg. XRI, wins, structured ontology names, netbios, or even ldap), this architectural element of https being "naming resolver independent" should be consigned to history.
 
>From my perspective, as someone who held the power of the patent in my hands for a year and got to set the very mindset of those around me who were mostly clueless on the politics of asymmetric key management (certs), what I chose to do was NOT know better than civil society. I those chose to put into the hands of folks the instruments to choose their own trust management instruments - knowing these would surely evolve and change, and need to address several communities with apparently opposite goals. The mantra was: "open systems". I was higihly influenced by a notion common in the windows world, called the moniker; that may be worth understanding as a concept. It helps reduce trust<->naming relations to something practical, and not introduce too much DEPENDENCY.
 
 
 
 
 
 
 
 


From: henry.story@bblfish.net
Date: Sat, 12 Feb 2011 11:08:47 +0100
CC: home_pw@msn.com
To: public-xg-webid@w3.org
Subject: Re: browser change; little, nothing or a lot?





On 12 Feb 2011, at 10:45, Henry Story wrote:




On 12 Feb 2011, at 02:24, peter williams wrote:






Define a new cert-type like PGP did (hello extension..)


   Could be useful, but clearly independent of the UI issue. There would be a big format war to decide there, and it's not clear what the advantage is going to be, apart from reduction of bugs due to ASN.1 parsing problems. So here I think there needs to be a lot more work done finding the benefits. My guess is that this should be done after wide deployment of WebID, because then the advantages of what should go into such a certificate will be a lot more obvious.

Much more important than cert-type in my view will be implementation of the results of the IETF keyassure group in the browser. 


See their first draft:
http://tools.ietf.org/html/draft-ietf-dane-protocol-04


That will make it much easier to deploy https on the server, and have a lot of other security advantages, that will be obvious to browser vendors quite apart from the needs of WebID.


Henry