--- Christopher Cain <[EMAIL PROTECTED]> wrote:
>
> In short, it is currently a needless exposure, and
> certs are much more
> important than most other resources. If I paid good
> money for a real
> cert signed by a CA, I would especially have a
> comprehensive security
> scheme in place to protect it. Leaving the password
> sitting around would
> be about the last thing I would possibly do. If your
> box is compromised,
> then your cert store is also unquestionably
> compromised. If your store
> is compromised, than every cert and private key in
> that store is
> worthless. That could potentially be catastrophic in
> a business
> environment, and would leave you open to all kinds
> nasty things. If
> someone gets ahold of your cert, bad, bad, BAD
> things can happen. Just
> ask Microsoft =)
>
> And if you should be cracked, and someone
> masqaurades as you to do bad
> things, that is a lawsuit you will not win because
> you did not have take
> resonable precautions against it. I realize that
> this is all a bit of
> Chicken Little-ism, but my point is that SSL
> implementation is a serious
> business. And I can choose to lock down the rest of
> the stuff you
> mention with a custom solution. I have no such
> option with the SSL
> implemention (short of hacking the code, which we
> can't reasonably
> expect people to have to do).
>
One of the possible custom solutons is to encrypt the
other information with your public key, then use the
private key to decrypt the other sensitive
information. Since the info is signed with the public
key, any developer could encrypt information that
could only be retrieved by the system. That way, the
solution would scale.
Anyway, if you implement the "prompt for key on
reboot" it could always be a configurable option, so
if someone didn't feel that level of security was
necessary, they wouldn't have to use it.
Jim
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
