North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: wrt joao damas' DLV talk on wednesday
- From: Randy Bush
- Date: Tue Jun 13 18:17:12 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