browser vendors and CAs agreeing on high-assurance certificat es

[Ben Laurie]

Bill Frantz wrote:
> On 12/24/05, ben at algroup.co.uk (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
> path.
> 
> 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.

This would defeat the reason people share IP addresses, which is so they
can share a single machine to reduce costs. Of course, a capability OS
would permit this whilst separating keys, as you said.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com