- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 4 Feb 2011 10:32:04 +0100
- To: Akbar Hossain <mail@akbarhossain.com>
- Cc: WebID XG <public-xg-webid@w3.org>
On 4 Feb 2011, at 09:38, Akbar Hossain wrote: > Yes. I have been playing with dns (bind) doing pretty much this. > > Going back to a blog by Dan and an idea around a dyndns service and the http://fingerprint.example.com idea that the other Dan mentions.(The protocol http is not relevant in this dns zone lookup.) You need to help me out with the Dan's here. I am lost :-) Are you thinking of Dan Brickley and Dan Kaminsky? > > Essentially you should be able to register with a dns service. Publish your public key and ip and sign it. What the server does is perhaps sign that entry too but not sure its necessary.(A set of such servers could create a network etc closed or otherwise.) Yes, that is essentially what the DNSSEC server does. It signs the entries in DNS. It's a hierarchy that goes all the way up to the US, which can be problematic, but is not really that problematic in the end. If one wanted to trust a DNSSEC server without going all the way through the top hierarchy, then one would just have to add that DNS server to one's list of trusted roots. That is what has been happening up till last year, before the root was signed. The danger is that one might end up with a naming clash in that case. DNS is hierarchical now, and so DNSSEC does not make that any worse. In any case the same idea can work with any secure DNS solution. It's just that my guess is that DNSSEC is going to get a big push now. Dan Kaminsky in his blog points out an interesting issue of Zooko Triangle which is that it is impossible to have all three of the following properties in a naming system • Secure: Only the actual owner of the name is found. • Decentralized: There is no “single point of failure” that everyone trusts to provide naming services • Human Readable: The name is such that humans can read it. http://dankaminsky.com/2011/01/05/djb-ccc/#zooko Now I really need to read up on this. > > Also been thinking if the server signs the zones its akin to signing all the keys I know if the dns was on my personal domain etc. > > Sorry not got anything clean enough to share right now but using something like IAN would seem to help with discovering a dns server setup like a keyserver. yes, I did not get to how this helps with ISSUE-2. A DNS is a name, and one can place the DNS in the Issuer Alternative Name (IAN) of a client certificate using the object type dNSName in the draft-saint-andré [1]. This is how a server would know to look up the public key in DSN. Btw, to put things in temporal order, the server would have created his Certificate Authority (CA), signature enabled, certificate with that domain placed in the SAN of the server certificate. ( So I am not yet sure what that name names. An agent of some sort presumably? Is it always a server? ) What would be possible then is to also complement this with another SAN for the server certificate, which could point to a server profile, where the server is described in more detail - RDF is just a lot more flexible than what can be put in DNS. So the server could then be described as being an entity that is owned by some organisation. Perhaps <#s1> a :Server; dns:name "google.com"; dns:ownedBy <http://nasdaq.com/GOOG#co> . That helps tie DNS records into much richer RDF linked data records. So that could tie in with ISSUE-1: "Multiple URI entries in SAN Extensions" Ok, should be getting ready... Henry [1] http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14 Social Web Architect http://bblfish.net/
Received on Friday, 4 February 2011 09:32:43 UTC