457923 - NSS has no tool to import an unverifiable PKCS#7 cert package

Status: RESOLVED WONTFIX

(NSS :: Tools, defect, P5)

Description

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 1

[Julien Pierre]

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 ?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.