RE: Turning every Web Server into a CA

I get to play the role some many played when arguing against evil X.509 (vs the liberating vision of PGP)
 
So: that evil X.509 is all hierarchial. The evil hierarchy. Hierachy evil. The DNS is hierarchical. Its unPGP.
 
X.509 ties keys to names that have to be be registered. names are evil; handles are good. DNS names are evil and registered. You even have to pay for them; an internet tax.
 
X.509 ties you to that evil, horrid, layer 7 directory, or as SUN used to say , any directory is evil, hierarchical, and passe (compared to the network or XML). The DNS is becoming a layer 7 directory.
 
Well that was fun rant (I got to play the PGP role, finally). Now lets do some infrastructure engineering.
 
It means the end of the PGP era - because access to keys are tied to a major infrastructure owned by others (not your file system, and your presence at conferences). Well, to be honest, I never cared for the PGP key management thesis to start with. But lots of other did (not that the arguments were very coherent outside the palpable "human emancipation" resonance).
 
Whatever X.500/ldap directory wanted to do originally by being a trusted directory (and I just spent 20 years NOT doing what the X.500 1988 spec said to do about exploiuting "trusted directory agents"), trusted DNS [agents] does tne same. So there is really nothing to object to. We would be doing the original X.500 trusted resolver "in essence" - its just morphed a bit on the wire, so now the only name choice is a domain-name. All the IETF's own argument for certs/PKIX go out the door, as PKIX is all about not using ANY directory type thing (because NONE of them can be trusted, in an crypto-engineering sense). PKIX is a theory about the security "control"-plane (ensuring transec info leakage is controlled, by controlling the infrastructure dependencies and ensuring no infrastructure => no impact).
 
but, going with the keyed-DNS does fit into the "general renewal" theme going on with the selling of the internet : IPv6 addresses, Ipv6 router/proxy discovery on the LAN, router as last mile DNS resolver, signed zones, signed RR. So, we would be "in vogue" by making the web;s client/server logon fit with ongoings. Its "big", and we want to be part of big social movements, tuning them for webbiness.
 
Can anyone operate such a DNS overlay, and avoid "the wikileaks switch-off" issue? Yes - so long as one's followers (which may need to be a twitter-size peering group) can point their personally administered DNS servers/resolvers at each other, cutting out those managed by the ** cybercommand or its proxies. This is technically quite easy, being PGP-ish even: one leverages the public infrastructure (while its turned on) to distribute the endpoints of the local/leaf routers, and (just like X.500/DEC taught) one caches the bridge across the naming hierarchy, in what used to be called a cross-cert. Now its called a cross-DNS link, perhaps. (patent alert, since this is "original thinking" in US patent land, Im sorry to say)
 
We should all know here that we can create vpns (remmeber DTLS is part of our charter). a VPN is a private overlay. Each of on this list could be part of a common one, operating per-list. Dont think "remote terminal access" to work computers using metaphors from 1960 tymshare ; think "routing overlays" in the frame-relay sense (ask anyone with a CCNA what that is, if you dont know). Thats what BBN wanted for IPsec initially (that never really got realised, until DTLS did what IPsec was supposed to do). ANyone got their "own" internet, by overlaying on the shared packet transfer. IPsec was to have been a "VPN generator" infrastucture, including personal VPNs that we might term "follower-VPNs" to be webby/facebooky/twittery.
 
(hmm, even a built in nod to crypto-history there: "turingery" (bletchley),.... to "twittery")
 
 
Of course, peering the DNS server in home wifi router with cross-DNS links doesnt work if the internet packet transfer or inter-area routing is switched off by "the hierarchy" (the ISP hierachy doing interarea and inter-ISP switching, that is), but then we have bigger problems socially at that point anyways than me and my little key fob, shared with my 4 followers. We WILL need to do some archive cleaning, that makes "hiearchy is good". 
 
It IS a big picture thing. We are not fiddling around with minor tools, trying to get happiness out of the dregs of extensibility that the cert-folks left for us (a side-effeect of the cryptowars, to be fair)
 
Its a general trend that is new; moving beyond legacy cert formats, legacy limited APIs from NSA/FBI crypto-war era, legacy trust points based on self-signed X.
 
So, as a TONE - I like it. 
 
Still need to define the webbiness in/on it, but that is why we exist. Its why I worked so hard to put "DTLS" in the charter - an invite "to think big" and out of the box. And, that in general is going to mean "being in vogue" with the work of others.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


----------------------------------------
> From: henry.story@bblfish.net
> Date: Fri, 4 Feb 2011 10:32:04 +0100
> CC: public-xg-webid@w3.org
> To: mail@akbarhossain.com
> Subject: Re: Turning every Web Server into a CA
>
>
> 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 .
>
>
> 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 13:28:02 UTC