wrt joao damas' DLV talk on wednesday

Wed Jun 14 15:00:34 UTC 2006

On Tue, 13 Jun 2006, Randy Bush wrote:

<snip>

>
> how about cctlds, which are of great interest to me?  i suspect
> that iana will not play, so how would cctlds play in way in which i
> can bet my bippies?
>
>>> and how it would be rolled would be of interest.
>>
>> key-roll through DLV is no different, from the high level, that
>> key roll through non-DLV.  either way you have to instantiate a
>> new key and get it to your registry somehow (either through your
>> registrar or otherwise) before you start using it.
>
> how do i enroll NG in a way that third parties can reasonably know
> is trustable?  from the policy and process pov, how will we move it
> to a new zone set and server set when i get rid of it?

along these lines - there seem to be a huge number of smallish
tools related to DNSSEC, but I don't find anything that looks
like a package with a couple of tools and scripts that would be
usable by a small ccTLD - recommendations and good written
exercises that step a newbie through the process would be
very useful - any pointers? I've already looked at:

http://www.dnssec-deployment.org./
http://www.dnssec.net/software
http://www.ripe.net/disi/dnssec_howto/
http://www.dnssec-tools.org/

lots of info - but a cheat sheet and some recommendations 
for basic tools are needed to get this deployed and used.

is this the current state-of-the-art?
http://www.dnssec-tools.org/docs/step-by-step-dnssec-tools/sbs-dt.pdf

> similarly, how do i enroll psg.com in a way third parties can
> trust?  how do we handshake in a clearly documented process- and
> key-wise exchange that gives third parties reason to be confident
> in the validity of the key isc hands out for psg.com?
>
> and
>
>> anyone whose registrar won't play, will have to follow the
>> procedure outlined on www.isc.org/ops/dlv/, which involves much
>> manual labour, but can be done.  (see
>> http://www.isc.org/ops/dlv/#how_register in particular.)
>
> says not much about how things will actually be verified.  only
> that isc will vet, i will fly, ...  heck, for an org, it does not
> even state that corp docs of the flavors rirs use for transfers
> will be needed/used.
>
> i suspect that where we may be differing, other than restaurant
> lore, is that you may be saying "the underlying technology is
> documented, and isc are good folk and if we say it's vetted you can
> trust us."  problem is that, though i may want to trust isc (heck,
> i run isc's code!), for a security exercise, i should not.  an
> example of some rigor in policy and process needs to be set.
>
> randy
>

-- 
Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
llynch  @darkwing.uoregon.edu		(541) 346-1774