Re: From whence we came...

[Edward Lewis <lewis@tislabs.com>]

I've finally caught up on this thread, and have a few comments to make.

The one issue that I've learned about from this is the "who do you trust"
issue.  There seems to be a dilemma of, on one hand, placing a lot of
"power" in the hands of a few when it comes to establishing trust, and, on
the other hand, allowing for an unruly number of trust centers.  (This
hasn't come out just right.)

When it comes to the fear that there is an economic monopoly in the trust
business, I think that this needs to be explored further.  Before
criticizing the practice of charging for certificates (perhaps over
charging), think of what it takes to provide the service.  If I am going to
buy something that certifies I am who I am, I want to make sure the
certifier has sufficient physical security, economic stability, and public
reputation of being trustworthy.  I've had the past experience of once
criticizing an operation's budget and then having to turn around and defend
the budget requests.

As much as a monopoly is a threat, too much competion is also dangerous.
It is hard to tell reputable from not without expending a lot of personal
energy.  (Ever try to get someone to remodel a condominium?)

Even if we could determine the optimum number of certication authorities,
how would one design a protocol that made maintaining the number "natural."
Rarely when a protocol leaves trust up to local policy is there a lack of a
de facto set of trust rules followed.  (And the de facto source emerges as
the monoply.)

Of course, a "monopoly" is an social/economic distinction, just as a single
point of failure is an engineering distinction.  (The two do not map 1:1.)
From this observation, it might not be possible to create a protocol that
enforces a non-monopolistic entitiy, but it would be benefical.

Finally - about the unruly comment.  There is a (fuzzy) desire to organize
ISPs during emergencies.  One of the elements of this is the need to share
sensitive information amongst ISPs to help respond.  The difficulty of this
has been determining what constitutes a "real" ISP, and is why I mentioned
this problem.  When there is no clear definition of what it takes to
provide a service, it is hard to design a self-policing mechanism.

As far as the direction of the discussion, I hope we don't get away from
the observation that one-size-fits-all when it comes to key distribution of
applications.  Instead of trying to do this top-down, that is thinking of
distribution mechanisms and how they can be generalized (for keys, certs,
both, via DNS, LDAP, etc.), it might be more constructive to go bottom up.
That is, by understanding the needs of individual applications, we can draw
common elements.  Perhaps some applications are unique and wouldn't benefit
from a generic approach, that shouldn't halt the benefit for other
applications.

(I haven't caught up on other threads, so there may be some
application-specific  discussions happeneing.)

There was also a point about where is this effort leading.  Right now, we
are in the mode of searching for just that.  Now is the time for different
ideas to be trotted out.  As new folks enter the discussion, topics may
reemerge, either to be shot down again or to take on a new meaning as more
is learned.  In the coming months the effort to organize a BoF at the
Minneapolis meetings may begin - if warranted.  That is the time where we
will begin to formulate a direction and charter.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Opinions expressed are property of my evil twin, not my employer.