wrt joao damas' DLV talk on wednesday

Tue Jun 13 22:16:50 UTC 2006

> therefore registrars (like alice's... remember alice? this is a song about
> alice) have no place to go with registrant KSK data at this time.  this in
> turn keeps most registrars from bothering to collect or store this "useless"
> data.  ISC proposes to accept this KSK data (in the form of DLV RRs) via
> authenticated automated processes whereby "lots of keys" can be sent to us
> by interested/participating registrars.  we do not have a good way of knowing
> whether somebody is or isn't the registrant for bankofamerica.com, but we
> think that bank of america's registrar does have a way of authenticating the
> registrant.  and we know how to authenticate bankofamerica.com's registrar.
> so there IS a more scalable, untouched-by-human-hands, trust path available.

thanks for actual technalia.

( first, i suspect much of the confusion could come from your
thinking that the place up on skyline is *the* alice's restaurant.
it isn't.  the real one was in stockbridge, mass, and rather
short-lived.  so you can see why one might wonder about isc's
validation methods.  :-)

i think if you amplified on and detailed the above, and went into
how re-delegation and key changes would handled, it would go a long
way to clarifying the isc dlv registry's security process.

you're also welcome to use some of the cctlds and other zones i
manage as outlying/strange examples.  e.g. NG, which i could sign,
but neither ng nor i have an established relationship to isc.  and
then i hope to get rid of it soon (been working with the in-country
folk for five years on this, and the illumination at the end of the
tunnel might be a light as opposed to a train!), and how it would
be rolled would be of interest.  and say psg.com, registered
through retsiger, who we might assume, for sake of example, will
not play.

randy