Bill Frantz
Mon, 08 Nov 1999 15:21:48 -0800

At 10:55 PM 11/8/1999 +0000, Ben Laurie wrote:
>Bill Frantz wrote:
>> In the E protocol, you start with the hash of the public key of the vat you
>> want to connect to.  The handshake passes the public key, and the receipent
>> checks the hash to ensure that it is talking to the right vat.
>> What I couldn't see at the time was how to perform this validation,
>> particularly with a commercial SSL.  (See below)
>OK, but it is, in fact, trivial, since the whole purpose of a cert is to
>convey the public key. I presume you now do see that?

What I couldn't see was how to fish the key out thru the SSL APIs.  :)
>> >"Client Server vs. Peer to Peer" - it seems to me this is meaningless.
>> >Each peer acts as a client when it initiates a connection and a server
>> >what it receives one. SSL is used in the obvious way in each case.
>> In the EC Habitats beta, which used the immediate predesesor to the E
>> datacomm protocol, we had major problems with both sides trying to connect
>> at the same time.  To ensure the correct ordering of messages, we need to
>> end up with only one connection.  While I am far from an SSL expert, I
>> don't know anything in SSL that deals with this situation.  There is a fair
>> amount of hair in the E connection setup protocol to handle just this
>> situation.
>There's nothing in SSL to deal with this situation, since its out of
>scope. I don't see why higher layers couldn't deal with it, though.
>BTW, what about "highest hash is the server" as a simple way to ensure
>the connections are one-way?

That is what the datacomm connection protocol ends up doing.  Before the
connection is completed, and therefor used, it detects that an incoming
connection is from a vat it is trying to connect to.  In some cases it is
obvious which connection to flush.  In others, the hash is used to delegate
one of the vats as the one to select the connection to keep.  I still get a
headache thinking about the problem.

I think in SSL, the receiving (server) end, needs to decide to keep or
reject a connection before the creating (client) end sends any Pluribus
messages over it.