To:
Randy Bush <randy@psg.com>
Cc:
"Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, dnssec@cafax.se
From:
Derek Atkins <warlord@MIT.EDU>
Date:
05 Sep 2001 11:23:04 -0400
In-Reply-To:
Randy Bush's message of "Wed, 05 Sep 2001 07:46:40 -0700"
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
Randy Bush <randy@psg.com> writes:
> > 1. I would strongly prefer to have all the random
> > keys that are *not* part of the DNS
> > infrastructure end up in a single place.
>
> i too. outside the dns. why not put them in the aim member directory? why
> always the dns?
Because in the end you wind up having to mirror the exact structure of
the DNS. You need locator records to tell you what server maintains
the record. You need delegation points to refer requests for
sub-trees. You need security records to maintain the integrity of the
server and delegation records. And then you need the key/certificate
storage records. In the end, you've just recreated DNS.
So why not _USE_ DNS? The only argument that I've seen to _not_ use
DNS for application keys is that keying information would greatly
increase the size of the zone databases.
I've got a solution to that: nothing states that you can't delegate
keys to another subdomain and host it on different servers. One
approach (albeit very gross) would be to have a subdomain for keys.
Then use CNAME records from special 'key-names' in the top-level zone
pointing into the 'keys' subdomain:
_ssh._key.host.site.domain. CNAME _ssh._key.host._keys.site.domain.
Then you can have your "_keys.site.domain" zone hosted on alternate
servers so you don't "hose" your main servers with extra key data. I
suppose an alternate solution would be a KEYX record, where you have
an (authenticated) URL pointing to the key storage location:
_ssh._key.host.site.domain. KEYX http://keys.site.domain/host/ssh
But then how do you authenticate the retreival from the key-storage
location? Sure, I suppose you could use https or ldaps, but that
implies that you've already got a CA up and running already. This
leads to a huge chicken-and-egg problem where you need a CA in order
to run a CA, but you can't run a CA until you have one. Or something
like that :)
> randy
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available