> The pkcs12 export command seems to want both the certificate and the > private key to be able to create a certificate containing the private > key which the key owner can use to verify signatures and decrypt mail > signed and encrypted using his public key.
Decrypting mail requires the private key. The certificate is not needed for this purpose. The PKCS12 format provides the ability to include a collection of keys and certificates and provides a way to encrypt them. > I want to protect the certificate which contains the private key, not > the other certificate which I create that contains only the public key. There is no reason a certificate should ever contain a private key. You may have a file that contains both a certificate and a private key. In that case, the private key should definitely be protected. There is no special reason to protect the certificate as well. > The terminology is not clear (the client programs Thunderbird, Mozilla > mail, Outlook, etc. right or wrong manage private keys as certificates) > I'm not trying to split hairs or rebel against the "standard model" > just trying to understand how to protect the certificate containing the > private key from use other than by the key owner. If there is no such > thing as a certificate which contains the private key, There is not. You most likely mean an entry or file that contains both a certificate and a private key. > then I have two > questions: how do I protect the private key (which the email clients > need to be imported as a "certificate") How do you protect the private key *where*? If you mean how do you convince your client program to store the private key in an encrypted form so that a password is needed to use it, you are asking in the wrong place. That's a client operation question. > and why does the pkcs12 command > want a certificate to be specified along with the private key when > using the export command to create a cert/private suitable for use in > verifying signatures and decrypting mail? You can create PKCS12 files that contain just keys, just certificates, or a mix of both. Normally only the keys, if any, are encrypted. I believe the PKCS12 standard allows you to encrypt the certificates as well, but nobody does so and it wouldn't surprise me if some programs barfed on it. Without a certificate, you don't know what the private key is used for or who it belongs to. So most programs require a certificate before they will do much of anything with a private key. Theoretically, you could decrypt mail without a certificate. Normally, *verifying* a signature is a pure certificate operation. You don't normally have someone else's private key when you verify their signature, you only have their certificate. With just a private key, you could theoretically verify the signature, but you wouldn't know whose signature it was (since the certificate binds the key to its identity). Some of the things you are asking about are theoretically possible but they just are not usually done because there is normally no reason to or the results would be hard to understand or use. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
