|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: wrt joao damas' DLV talk on wednesday
> 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
|