At 13:31 22/07/2005, Francois Menard wrote:
IETF-ers,
What is the latest state-of-the-art thinking at the IETF about a
distributed multiple-root systems for name discovery based on end-to-end
peer-to-peer PKI-based trust discovery and trust chain management &
properties/capabilities exchange (I can sign you, you can sign me, I can
do 4096 bits but you'll only parse 2048, etc.)
Is it permissible to think that this could be an alternative to the DNS at
some point in time in the future or does the DNS needs to remain as it is?
Dear François,
I suggest first you read http://www.icann.org/icp/icp-3.htm. As you may
recall the IANA function, name and number space management have been
contracted by the USG to ICANN and the USG recently published a position on
the root system, etc. You will find some useful links on the political
aspects under http://nicso.org/iana.htm. ICANN has an obligation of
insurring the stability of the DNS. The Part-5 of ICP-3 gives you
fundamental elements.
I asked several time that the IETF get involved in the requested test-bed
and I just proposed ccTLD and national communities to build on the
experience of the dot-root test bed we ran for two years according these
rules. Some temporary elements could be found in a study we published on a
paying basis (to cover our costs) in French. This study resulted in
multiple propositions and efforts.
From this I would not advise to consider multiple-root at all. There is
only one real root file: the description of the existing TLD forest. But
you can have multiple visions of that forest. And ways to build your root
file. This actually results in a root-matrix rather than in a file. The way
you use and conceive that matrix gives you various possible visions of the
internet.
Let consider your .travel. If New.net .travel and ICANN .travel are
orthogonal we have an absurdity. No one can know who is name.travel. But if
New.net and ICANN .travel are two versions of the same reality there is no
conflicts. There only can be names which will not resolve or different
_desired_ resolutions. There is no objection that air-france.travel
resolves to two different sites if this is the decision of air-france.
So, there is no fuzzy concept of "trust", but a deliberate choice by the
user to use a root where .travel is upported by ICANN and one where it is
spported by New.net. Like when you visit Paris you can purchase two
different Guides.
Where "trust" can be considered it is in the building of the root itself,
but not exactly as you conceive it. It is absurd to have ICANN building the
root file with delays which may be of months. It would be far better that
the root is build from the data published by the TLD Managers: everyone
could build his root and _mutually_ correct in case of failure or attack.
The problem is the trust you can have in this data as reflecting the
decision of the TLD Manager. There is no major problem in having sites
published by the TLD Manager where he displays his data: the data must be
the same of 2/3 of them for being acceptable. However we need a public
declaration procedure to know what are these sites. This can be achieved by
a system of Trust as you refer. But a mutual system involving Govs, large
gTLDs, etc.
ICANN could then lead the system. But its role would not be to accept a
delegation,. It would only be to make sure it is the origin of the new list
is the same as the one who published it first.
Such a system exists today we do not notice, it is the name of countries.
Except about the recent conflict about "Macedonia" it works well.
What you could do to is to use another class than "IN" at least initially.
jfc
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf