[974] in WWW Security List Archive
Re: CA heirarchy vs Web of Trust
daemon@ATHENA.MIT.EDU (Milton Anderson)
Mon Oct 2 17:08:27 1995
Date: Mon, 2 Oct 1995 13:26:10 -0400
From: milton@thumper.bellcore.com (Milton Anderson)
To: www-security@ns2.rutgers.edu
In-Reply-To: Mail from 'William.Soley@eng.sun.com (William Soley)'
dated: Mon, 02 Oct 1995 09:03:25 AM PDT
Errors-To: owner-www-security@ns2.rutgers.edu
The problem is deeper than web of trust versus CA heirarchy. To be
actually useful for commerce, the certificate chain should contain
the context within which the key can be trusted for some transactions.
Certificates that just link names to keys are not useful.
For example, even if there were a CA heirarchy and I trust that your DN
goes with your key, I still don't know whether to do business with
you. To ascertain that, I need to use your DN to query Equifax, TRW,
D&B, the BBB, etc. to find out whether to trust you. If I have to do
that, then I may as well find out your public key from them, and just
eliminate the use of certificates. Once I do one transaction with
you, I have your public key and some information about your
trustworthiness in my local records, so I don't need to get the
certificate chain a second time.
On the other hand, if your certificate were signed by one of the
credit or busness bureaus, and if it contains sufficient info about
your reputation with them, then I would be able to decide whether to
do business without the directory lookup, and the certificates would be
useful for dealing with first time customers.
Milton Anderson
milton@bellcore.com
# From: "John Hemming CEO MarketNet" <JohnHemming@mkn.co.uk>
# Which is, of course, the key debate between a web of trust and
# a CA heirarchy. We are stuck without the facility in Netscape 2.0,
# because we are not commercially linked to RSA. At the end of the
# day it is up to the end user to determine who to trust and not the
# client software implementor. That, I think, is the correct position.
#
# The client program should clearly indicate, however, who signed
# the certificate and the Domain Name. This is still not much
# commercial use as it gives almost no information about the organisation
# offering services through the server.
#
#
#
