[Top] [All Lists]

Re: Chain of Trusted Forwarders

2005-05-30 12:26:05

At 11:12 PM 5/29/2005 -0400, Robert A. Rosenberg wrote:
At 12:07 -0400 on 05/29/2005, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

Congrats.  You've re-invented the PGP Web Of Trust, although usually people
don't bother doing the extra step of running credit and police records.  The
fact is that the PGP Public Keyserver system has only several million e-mail
addresses in it, and only some 100K (last I checked) in the "well connected
set" (meaning keys that *have* done this sort of thing enough to be
identifiable to anybody else in the set).

That number is dropping fast due to the new PGP Key server code that drops any signature from a uploaded key if it is not already on the server. IOW: If A has had his/her key signed by B, C, and D, these signatures will get stripped off when stored on the server unless B, C, and D has uploaded their keys to the Server. To get an accurate key onto the server, A must reload his/her key again after B, C, and D (who must also reupload so the copies signed by the others is the "official" copy that is stored.

The difference between the "chain of trust" you are talking about and email authentication is DNS. When a sender puts its public key, or any other authentication information in its own section of the DNS hierarchy, we don't need further authentication of that information. We assume the folks who delegate DNS zones, starting with the registrars of the top-level-domains, are competent and honest. ( Yes, I know about Melbourne IT's mishandling of The exception proves the rule. Hopefully, Melbourne and a bunch of other registrars have fixed their procedures.)

The security requirements needed to thwart spammers are luckily much less than needed to guard nuclear weapons data, or we would not be able to rely on DNS.

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

<Prev in Thread] Current Thread [Next in Thread>