Pluribus

Bill Frantz frantz@communities.com
Mon, 08 Nov 1999 14:21:18 -0800


At 06:29 PM 11/6/1999 +0000, Ben Laurie wrote:
>"Mark S. Miller" wrote:
>> 
>> At 04:34 AM 11/6/99 , Ben Laurie wrote:
>> >Following on from these comments, something I've been wondering for a
>> >while is why not just use TLS?
>> 
>> I believe the short answer is "wrong handshake".  The longer answer is
Bill's
>> http://www.erights.org/to-be-sorted/SSLvsEComm.html
>I don't understand why "we will need to add certificate checking that
>ensures that the distinguished name is indeed the hash of the public
>key" is necessary at all. Who cares what the DN is if you have the key
>in your hand?

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)


>"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.


>BTW, why does the page only mention commercial SSL implementations, and
>not any of the free ones?

We required Java implementations (for historic reasons which are less
compelling in the open source system we have now than they were in the
closed source, commercial environment that existed when the decision was
made and that document was written.)