thanks for actual technalia. i've also been warned that this isn't ops-related and told to move elsewhere.
if it was not from the ml committee, tell whoever to foad. they would not know ops if it bit them on the <bleep>.
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. i feel sure that joao said at the podium that he would do that
not really. he misunderstood my question and then waffled off into something directed at sam weiler that i think one needed to be steeped in ivtf <bleep> to understand. no blame. it was as if my question was off the wall, or i had stepped on a sore toe. i am good at both.
it's possible that no trust path can be found for some domains. for example, i cannot imagine who could represent the root zone for the purpose of sending in a key for it. (not that DLV has a way to publish the root key; it doesn't; i'm just using the root as the ideal strange example of this problem.)
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? 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