Cryptography and Site Security: Please critique my security idea

[Robert Paris <rpjava () hotmail com>]

My company is going to have an application that houses and shares
internal documents through an extranet. There has been a concern by
the network administrators that even with a firewall, someone might
get direct access to the server (housing these documents) whether
through hacking or otherwise. If they did, they'd have access to all
the documents. So I came up with the following solution, which I'd
like some critique on:

1. A symmetric (secret) key ( Key "A" ) is created
2. All files to be managed are encrypted with key "A"
3. Each user is assigned an asymmetric (public-private key pair) 
   key ( Key "B" )
   a. The user is assigned this key pair, but NOT given the key. We
      house the key internally.
4. Key "A" is encrypted separately for each key "B" ( called 
   file "1" )
5. User is given file "1"
6. The public key for each user's private key is stored on an internal
   server that is inaccessible from the server and vice versa
7. When the app/web server is started up, the application is in a
   "turned off" state. This is because no public keys have loaded.
   There is one page only that is accessible and it is locked to two 
   IPs (both internal). This page allows an authenticated user to 
   upload the public keys in to applciation memory. This must happen 
   after every restart or the site is unusable.
8. The first time a user ever logs in to the site, they must give 
   username, password and upload file "1". This file "1" (after being 
   verified through message digest) is then stored in the user's 
   cookie. After this, they log in with username and password.
9. After user log-in, file "1" is sent to the server, and opened with 
   the proper public key (in memory) and stored in session memory 
   only. During this session, if this user wishes to download a 
   document, this now decrypted key "A" will be used to decrypt the 
   file and send the decrypted stream to the user. The file remains 
   encrypted on the server. As well, the in-memory key "A" is used for
   encryption when they upload a file.
10. All communication is HTTPS, 128.

As well, I am considering putting a lifespan on the private/public key 
pair that is used to encrypt the symmetric key that is stored (encrypted) 
in the user's cookie. What I would do (and I don't have this 100% down) 
is, if the lifespan is past, create a new key once (for that old key) and 
use that new key to encrypt the symmetric key and save that to their 
cookie. So even if they gave the original file to someone (along with 
username and pass), it'd no longer be useful. I'm not 100% sure how to 
make this work correctly or even if it's a good idea.

Please let me know:
1. What are the weaknesses of this architecture?
2. What performance hits will this cause?
3. What are some alternative/better ways to achieve this?

Some major concerns/limitations: 
1. We must use the browser as the thin client and it may be
IE/Netscape or even something else (as long as cookeis and HTTPS 128
are enabled) on windows, linux, unix, mac/osX.

2. Our users will not be willing to do anything more inconvenient than
that one time uploading of the encrypted key. And if possible to do
less, they'd prefer this. Especially since they'd prefer a way to have
it accessible from any computer not just one with the key (although
I'm not sure I think that's the best idea)