[6341] in cryptography@c2.net mail archive
RE: starting up servers that need access to secrets
daemon@ATHENA.MIT.EDU (Salz, Rich)
Thu Jan 6 12:55:37 2000
Message-ID: <AAD0807E1794D311A54000A0C99609B90B24C6@macertco-srv1.ma.certco.com>
From: "Salz, Rich" <SalzR@CertCo.com>
To: "'Matthew Hamrick'" <mhamrick@inprise.com>,
Crypto Mailing List <cryptography@c2.net>
Date: Thu, 6 Jan 2000 11:40:39 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
>From: Matthew Hamrick [mailto:mhamrick@inprise.com]
[General crypto token intro deleted]
>2) Configuring your web server to use the coprocessor
It's not very hard -- start with apache and openssl (www.apache.org and
www.openssl.org). In OpenSSL there's a struct containing function pointers
for the RSA operations -- directing that to crypto hardware isn't that hard.
>You'll probably not want to trust that your private key to a device
>that can potentially fail, and is designed to not allow attackers to
>read the private key should they have physical posession of the
>coprocessor.
[interesting sharing solution omitted]
Many devices (e.g., the FIP140-1 Level 3 Chrysalis LunaCA-3 device,
www.chrysalis-its.org) have the ability to export/import keypairs; 3DES
seems to be a common encryption method to protect the private key. Cf.
PKCS#12.
I believe it would be better if browsers didn't trust web server certs, but
could
easily be taught to trust any web server cert under a given CA. (We're not
there yet, but it seems to be in the near-term future.) That would
eliminate the need to clone signing keys, just certify peers under the same
CA. Many "closed" PKI's use this approach (cf, www.identrus.org), it's
kinda what x.509 is all about.
/r$
