dotgnu-auth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Auth]Authorization Certificates


From: Richard Kay
Subject: Re: [Auth]Authorization Certificates
Date: Thu, 19 Jul 2001 15:55:05 -0400
User-agent: Mutt/1.3.15i

I think the reason the WoT breaks down in a very large group (VLG)
depends on the relative flexibily of meaning behind the 
assertion that A has signed B's (AsigB) key. We must assume that a 
VLG includes very few encryption experts, so
the AsigB relation within a flexible WoT will mean very
different things to different people within the VLG.

My understanding of the likely requirements for PKI for
most likely earlier, initially higher value-added networked 
authentication and privacy applications are that maximum flexibility
may be much less important than semantic simplicity.

For an on-line trading example, let's suppose Bob wants to know
whether it makes sense to accept Alice's on line order,
and Alice presents herself as having an identity of
address@hidden . Bob can then fairly easily estimate a probability figure
between 0 and 1 that the public key Alice claims
to be hers is in fact hers if:

1. Bob has a known level of trust in F's public key and the way F uses it.
2. E.F's public key is signed by F, 
3. D.E.F's public key is signed by E.F and
4. Alice's key is signed by D.E.F .

This may give Bob a measure of confidence in Alice's identity, but 
doesn't tell him whether she has money in her account. 
Depending upon Bob's confidence of C's public key use and
whether he has any previous knowledge of B.C might give
Bob a better measure of confidence in the credentials of address@hidden 
which is an ID whose probability Bob can compute with a smaller
margin for error. Of course Alice might want and acquire both 
identities for different purposes. 

Further checks, e.g.
through Alice's bank may be needed in relation to the 
specific application-dependent trust issue. However the
above simple checks are likely to be application independent
for the purpose of computing a probability that Alice is who she 
says she is, which is a requirement common to very many applications.

Trying to do this without any trusted top-level domain keys 
seems inherently much more difficult within a large group. 

There is, however, nothing preventing anyone creating another 
domain name system independently of the current DNS with as many top-level
domains as whichever organisation establishes the most
trusted TLD registry wants to register.

Of course the problem with this is that my trusted TLD keys
might be different from someone else's and Bob may trust some TLD's
more than others. But, this is only a problem if there is an 
arbitrary and artificial limit on the number of TLDs,
to the extent it becomes difficult or impossible to register
new TLDs. 

I also think that if the registry of TLDs becomes a fully open 
community-based and non-profit foundation, this model has some commercial 
viability. Providing a TLD within this proposed network which
establishes a good reputation with its users
will attract registration fees and domain lookup servicing 
from the next layer down. Registering end users (A registers
Alice) also suggests a decentralised annual subscription 
service model.

I would propose the Free Software Foundation as a suitable
lead organisation for providing a registry of TLD PKI/DNS2 
domain names.  Of course the best TLD names will be
more valuable, and if free software developers are to be
attracted to this model then TLD registrations should be 
available on a preferential basis to those who have 
existing copyright on free software. Lower registration
fees and costs are also suggested for those already well-known
within the free software development community, so the
best names are likely to go to those who establish their
credentials the soonest and can do so most cheaply, perhaps
based on a more distributed trust metric.

I have thought about this application of a more advanced DNS 
partly for the purpose of combining network entity
naming and PKI. This is for the purpose of networking
community currencies as for this application, to become fully
developed, I don't yet understand any alternative models as well.
Maybe there's something about fully decentralised PKI with no
common TLD registry, e.g. based on fully decentralised allocation 
of long and random network entity IDs unlikely to cause collisions 
in a fully decentralised network which I havn't fully grasped. 
However, if Werner's posting is right maybe my intuitive 
understanding of this is in fact correct.

I guess this might have implications for the next generation Internet
DNS as well, as there is no particular reason that newer
services to replace old ones (e.g. spam-free mail) should
be bound to the older and less capable DNS.

I'm also well aware that many other models are possible, whereby
identity and key naming and trust are all established by different channels,
but these do seem more complicated and abstract, and therefore error prone, 
more difficult to implement reliably and slow.

Richard Kay
address@hidden
http://copsewood.net/


On Thu, Jul 19, 2001 at 09:19:13AM +0200, Werner Koch wrote:
> On Tue, 17 Jul 2001 15:22:00 +0200, Norbert Sendetzky said:
> 
> > That's the way PGP/GPG does!
> > It's secure, already there and has been proven over a long period of time.
> 
> The WoT does only work in a group with similar interests and won't
> work for large scale business like selling stuff over the web.  It
> relies on mutual trust which is nothing you can expect in a group of
> merchandiser.  The WoT has a lot of flaws which inhibits its use in a
> large network.
> 
> -- 
> Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
> g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
> Privacy Solutions                                        -- Augustinus
> 
> _______________________________________________
> Auth mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/auth


reply via email to

[Prev in Thread] Current Thread [Next in Thread]