I think this is an artificial problem that arises only for ISC since we're out of the delegation loop (except where we can authenticate registries and receive trust anchors from them).
if other non-delegators run dlv services, they will have the same issues. and if you are a delegator, why play dlv as you can directly sign?
Do you imagine that, if IANA/ICANN/USDOT/someone were told to implement a policy to sign the root, that they would have trouble identifying the owners of the TLD's reliably?
how they validated that the keys they sign are correct would be an issue, for sure. but we have some idea of the iana's relationship with the tld zone holders, though, like many things, that could certainly be improved. the isc web page now says Before it is accepted into the dlv.isc.org zone, ISC will perform checks to ensure the keys are being used in the requested zone, that the persons making the request are who they claim to be and that they are authorised by the domain holder to request the inclusion of the keys in the zone. This check will require an in-person meeting with authorised ISC staff to verify documentation. so, there will be strange travel costs incurred, but we have no idea what actual checks will be done. when charles mussisi flies from kampala to redwood city, will he be expected to have brougt the zone key with him on cdrom or something, and you'll check his passport against the iana cctld registry and then accept the key? and, when the iana redelates the UG zone, how will you know this and stop handing out a bogus key?
If so, wouldn't this problem already exist today in the information already present in the root zone?
yep. and iana goes through some non-trivial exercises to validate that they are delegating 'correctly' as defined by 1591 and other documents. and those of us in the tld game are aware of them in some detail, irrespective of our opinion of them. luckily, they do not require people to pay airlines. all i am asking is that isc publish *how* it will validate the correctness of the zone trust keys they sign and provide under their proposed dlv service. e.g., how do you propose to check that the cctld, e.g. NG or UG, for which your proposed dlv service might yield a key is indeed the real NG or UG zone key? randy