NSS needs a tool that can import all the certs from a PKCS#7 certificate package, whether or not they validate against a trusted root, and regardless of their KU and EKUs. It used to have this ability, but presently does not. NSS shared libraries contain code that can do this, but no tool calls them in such a way that they will do it. The fix for bug 193367 has left NSS without any tool to import a chain of certificates from a PKCS#7 certificate package (a "signedData" message) when that cert chain does not chain to an already known and trusted CA. Consequently, if a user receives a PKCS#7 cert package to install for the purposes of obtaining a new root CA, he cannot import the certs from that package with any NSS tool. This is a functional regression for NSS tools. Here is some analysis to support that conclusion. The functions that are capable of decoding and importing certs from a PKCS7 message include: SEC_ReadPKCS7Certs - not exported from any NSS shared library CERT_DecodeCertPackage - Not used directly by any NSS command CERT_DecodeCertFromPackage - only outputs the FIRST cert in the PKCS7 message. used by certutil -A, and ocspclnt -r SEC_PKCS7VerifySignature used by p7content, which tells it NOT to keep the decoded certs. called by SEC_PKCS12DecoderVerify, which tells it NOT to keep certs SEC_PKCS7VerifyDetachedSignature used by p7verify and signver tools, neither of which tell it to keep the decoded certs. NSS_CMSSignedData_ImportCerts used by cmsutil -k, but only keeps ENCRYPTION certs that chain to trusted root, and the CA certs associated with those encryption certs. I would suggest that we add an option that will do this to certutil or any one of the pkcs7 test programs mentioned above.
Is this a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=209166 , which was marked INVALID ? Or was the reason for marking that bug invalid in https://bugzilla.mozilla.org/show_bug.cgi?id=209166#c4 incorrect ?
In reply to comment 1, no, this is not a duplicate of bug 209166, and the reason for marking that bug invalid was correct. That bug was about libraries, not tools. It was a complaint from a browser user. The problem here is not an NSS shared library bug, but rather is purely an issue with NSS tools. NSS shared libraries have several ways of doing what needs to be done, as documented in comment 0, but the tools do not make use of any of them in a way that will "keep" the certs. It may be that the browser also needs to add a means by which the user can tell it "import all these certs, even if they don't verify". But that is not an issue with NSS shared libs. This bug in not intended to suggest that the fix for bug 193367 was defective in some way. Rather it observes that the only NSS tool capable of importing all the certs in a PKCS7 cert package (cmsutil) was depending on a vulnerability in a function, and when that function's vulnerability was fixed, the tool that was dependent on that behavior stopped working.
You need to log in before you can comment on or make changes to this bug.