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