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 13:28:59 2006
> 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
> 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?