Message-Id: <6.2.1.2.2.20050722171905.04ad7380@pop.online.fr>
Date: Fri, 22 Jul 2005 17:20:07 +0200
To: Francois Menard <francois@menards.ca>, ietf@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: Re: Multiple roots & E2E PKI trust discovery, chain management
 & capabilities exchange
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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=20
>distributed multiple-root systems for name discovery based on end-to-end=
=20
>peer-to-peer PKI-based trust discovery and trust chain management &=20
>properties/capabilities exchange (I can sign you, you can sign me, I can=
=20
>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=20
>some point in time in the future or does the DNS needs to remain as it i=
s?

Dear Fran=E7ois,
I suggest first you read http://www.icann.org/icp/icp-3.htm. As you may=20
recall the IANA function, name and number space management have been=20
contracted by the USG to ICANN and the USG recently published a position =
on=20
the root system, etc. You will find some useful links on the political=20
aspects under http://nicso.org/iana.htm. ICANN has an obligation of=20
insurring the stability of the DNS. The Part-5 of ICP-3 gives you=20
fundamental elements.

I asked several time that the IETF get involved in the requested test-bed=
=20
and I just proposed ccTLD and national communities to build on the=20
experience of the dot-root test bed we ran for two years according these=20
rules. Some temporary elements could be found in a study we published on =
a=20
paying basis (to cover our costs) in French. This study resulted in=20
multiple propositions and efforts.

 From this I would not advise to consider multiple-root at all. There is=20
only one real root file: the description of the existing TLD forest. But=20
you can have multiple visions of that forest. And ways to build your root=
=20
file. This actually results in a root-matrix rather than in a file. The w=
ay=20
you use and conceive that matrix gives you various possible visions of th=
e=20
internet.

Let consider your .travel. If New.net .travel and ICANN .travel are=20
orthogonal we have an absurdity. No one can know who is name.travel. But =
if=20
New.net and ICANN .travel are two versions of the same reality there is n=
o=20
conflicts. There only can be names which will not resolve or different=20
_desired_ resolutions. There is no objection that air-france.travel=20
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=20
user to use a root where .travel is upported by ICANN and one where it is=
=20
spported by New.net. Like when you visit Paris you can purchase two=20
different Guides.

Where "trust" can be considered it is in the building of the root itself,=
=20
but not exactly as you conceive it. It is absurd to have ICANN building t=
he=20
root file with delays which may be of months. It would be far better that=
=20
the root is build from the data published by the TLD Managers: everyone=20
could build his root and _mutually_ correct in case of failure or attack.=
=20
The problem is the trust you can have in this data as reflecting the=20
decision of the TLD Manager. There is no major problem in having sites=20
published by the TLD Manager where he displays his data: the data must be=
=20
the same of 2/3 of them for being acceptable.  However we need a public=20
declaration procedure to know what are these sites. This can be achieved =
by=20
a system of Trust as you refer. But a mutual system involving Govs, large=
=20
gTLDs, etc.

ICANN could then lead the system. But its role would not be to accept a=20
delegation,. It would only be to make sure it is the origin of the new li=
st=20
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.=
=20
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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf