On Sat, 8 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA) wrote:
Opera is already downloading root certificates from a digitally signed online
repository using a secure connection, and the download is done in a fashion
that the user will NOT be asked about certificates concerning that download.
A dynamic download of the TLD structure information would be done in a
similar manner, without user interaction.
So in this case, Opera is creating and maintaining a list, and offering it
to their clients. Other software, including non-browser software, will
have to do the same. The problem is that if TLD's do not implement a
universal dicovery method, any fancy protocol will come to "someone is making
a list somewhere and you need to know this person and trust them". It also
scales poorly. See the non-standard scheme of naming the whois sides, and
software like 'jwhois' with a 32kb config file maintainer by "someone
somewhere",
that requires updating all the time. We might as well stick sub-tld information
in /etc/jwhois.conf while we're at it - we don't need a new protocol for that.
That's why to me it would make more sense to have something like "tld.nic.<TLD>"
with information, either in DNS records that can be signed, or via some https
method with an SSL cer).
In any case: Google, Microsoft and Mozilla are ALL, right now, deploying
browsers using Mozilla's PublicSuffix database, and two of them have been
doing so for more than 6 months.
So what will a new protocol add to this? The database will be required anyway,
because one does not know where to find this information for a random TLD.
IMO, an even better approximation to what our applications need for various
automatic security features, would be a list of registry-like domains
provided by the TLD regisitries.
And probably the only common zone all Registry's reserved for themselves and
was not allowed to be users by Registrants is 'nic.TLD'.
If there are better approximations the DNSOp WG and other interested parties
are encouraged to come forward with them.
the real problem is not the method of presenting or transfering the information,
the problem is finding it. Section 2 of this draft starts with:
The client retrieves the domain list for the Top Level Domain
"tld" from the vendor specified URI
https://tld-structure.example.com/tld/domainlist .
However, before that comes another unlisted step:
The client retrieves the meta information on where to
find the list of "TLD Structure" servers for each TLD from
some to be pre-determined location.
That's the problem not addressed in draft-pettersen-subtld-structure-04.txt
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
