At 10:55 PM 11/8/1999 +0000, Ben Laurie wrote:
What I couldn't see was how to fish the key out thru the SSL APIs.
>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?
>
>> >"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.