337799 - Need tool to import OpenSSL private key files

Status: NEW

(NSS :: Tools, enhancement, P4)

Description

[Nelson Bolyard (seldom reads bugmail)]

NSS needs a way to be able to import a PKCS8 file (an OpenSSL .pvk file).

OpenSSL commonly produces certs and private keys in separate files, with 
the private key being unencrypted (a PKCS#8 file).  NSS can import a 
separate cert file, but has no way to import a separate private key file.  

OpenSSL can take a cert file and private key file and make a PKCS12 file 
from them.  Today, for users who have those two types of files, the only
way for them to import them into NSS is to use OpenSSL to make a PKCS12 
file from them and then import the PKCS12 file into NSS.  So, today it is
unfortunately common to need to direct users to use OpenSSL first to make
a PKCS12 file, before they can use NSS-based products.  This reinforces
the perception that OpenSSL is more complete and a better product.  

We could either
a) add the ability to importa raw private key back into certutil, or 
b) add the ability to combine a cert and private key into a PKCS12 file
using pk12util.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Above I mistakenly identified OpenSSL PKCS8 files as .pvk files.
I should have called them PEM files.
.pvk files are a Microsoft Windows file format.  
I will file a separate bug about the ability to import .pvk files.

Comment 2

[Robert Relyea]

PK11_ImportEncryptedPrivateKeyInfo() will do this, we just need to add code to pk12util or certutil to call it. (well there is some code to convert the base 64 to epki, but that should be relatively simple as well. pk12 uses pkcs8 under the covers anyway).

bob

Comment 3

[Elio Maldonado]

PK11_ImportEncryptedPrivateKeyInfo takes a SECItem *publicValue argument which one would have to extract from the certificate assuming that the certificate is being imported at the same time as, or earlier than I guess, the private key. Would certutil need to support importing a private key without the cert or vice-versa?

Comment 4

[Elio Maldonado]

An alternative to using PK11_ImportEncryptedPrivateKeyInfo would be to use the PEM module that was released downstream as an NSS patch in fedora 8/9 once it gets accepted upstream.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

The PEM module has not been offered upstream.  There is no NSS bug that says
"Here's a new PKCS11 module that we'd like NSS to take upstream".

Today, the approved method for "importing" OpenSSL PEM files is for the user
to make a PKCS#12 file from the PEM files for the private key and the cert,
and then import the PKCS#12 file.  That was VERY deliberate on the part of 
the NSS team.  OpenSSL's PEM files for private keys are not always encrypted,
and leaving private keys lying around in files unencrypted is VERY VERY POOR
crypto practice.  NSS does not with to encourage it, which is the main reason
that NSS does not import such files directly.  

Remember, NSS is about security, not fun-and-games playing with PEM files.

Comment 6

[Wan-Teh Chang]

The NSS bug for Red Hat's PEM module is bug 402712.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I'm happy to learn that the PKCS11 module *has* been offered upstream!
I wonder why there's been no discussion of this. (?) 

Comment 8

[Elio Maldonado]

The last comment on bug 402712 was 2007-11-09 but there was some extra work and the patch did not become available in fedora until very recently, after NSS_3_12 was included in fedora I am not mistaken.

Comment 9

[Andrew Cagney]

As the author of nss-pem points out, it's largest user, curl is giving up on NSS:
https://curl.se/mail/lib-2022-01/0120.html
W.r.t. the nss-pem code base, it was written in the era of RSA, so is unfortunately showing its age.