On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote:

>I don't see why not - the technical details actually matter. Since the
>servers will all share a socket, on any normal architecture, they'll all
>have access to everyone's private keys. So, what is gained by having
>separate certs?

I responded in private email:

> With a POLA architecture, perhaps on a capability OS (dream, dream),
> they might not share access to the private keys.  However, given current
> software, I grant your point.

Ben responded that I should post my comments to the list.

There are two scenarios I see as being viable for separating the private
keys with a security barrier.  One is the single machine case alluded to
above.  Here the private keys would be in separate security domains, and
the common part of the web server, which listens on the socket, would
read the initial data on the TCP connection, select the correct security
domain, and "pass" the connection to that domain. While the common part
could continue to examine all the data, those data would be encrypted,
so the it would have the same access as any other untrusted node in the

The other scenario involves a network switch which performs the function
of the common code of the web server.  It uses network address
translation to forward the connection's packets to the back-end computer
with the correct private key.  Here the keys are protected by being kept
on separate computers.

Both approaches allow a web hosting ISP to protect its customers from
each other.  This mutual protection is much the same requirement as
existed in the time-sharing systems KeyKOS was designed to support.

Cheers - Bill

Bill Frantz        | gets() remains as a monument | Periwinkle 
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to