Scalable Distributed Security with Bearer Certificates

[Mark S. Miller]

Thanks Frank, this sounds wonderful.  Two issues:


At 08:39 AM 2/10/99 , Frank O'Dwyer wrote:
>... To begin with this will only provide
>datagram communication (although the underlying comms will be TCP),
>... However a stream protocol could in principle be built atop this.

E requires such a stream protocol.  Post handshake, we run an SSL-like
secure data pipe on top of it.  See "Pluribus Protocol: Data Comm Layer" at
http://www.erights.org/elib/index.html


>Also the
>functionality could be wrapped in a SOCKS or plug-gw style proxy,
>avoiding the need to modify applications (but requiring some way of
>advertising and learning of mix participants). 

The essential step of capability computation, and therefore the central
problem for a secure protocol for E to solve, is the three party handoff,
explained in http://www.erights.org/elib/elibmanual.pdf

In order for your mix to appear to be a compatible socket library, I take
it that Alice would know Bob and Carol by what appear to Alice to be Bob
and Carol's TCP/IP addresses?  In you system, how would Alice introduce Bob
to Carol?  If Alice tells Bob the alleged TCP/IP address by which Alice
knows Carol, can Bob contact Carol by using this address?  Don't worry
about authenticating that it actually is Carol once the contact is made --
we got that one covered.  I'm concerned about routing.

If, pre-introduction, none of the three parties could determine the
location of the other two, would this still be true post-introduction?  How
does your system find a Bob-Carol route?  And what if Firewalls are in the
way?  (E doesn't yet route through Firewalls, but see
http://www.erights.org/to-be-sorted/DataCommThruFirewalls.html for a plan
to handle the bad cases.)


Is your open source license compatible with Mozilla?  Most are, including
LGPL, but GPL is not.


If it works out, it would be truly superbly wonderful to have a working mix
underneath Pluribus.

	Cheers,
	--MarkM