A certain user of NSS 3.9.x had a secmod.db file that pointed to an old built-ins module, nssckbi, from NSS 3.3.9. He found that the certs in nssckbi could be seen (listed) but had no trust, and trust could not be set on them. The solution was to alter the customer's secmod.db file to point to the newer 3.9.x copy of nssckbi. But the issue here is that we apparently have a break in our backwards binary compatibility story, and we don't yet know where that break occured. It might have occurred on the trunk sometime between NSS 3.3 and NSS 3.9.x, or it might have occurred on the NSS 3.3 branch sometime between NSS 3.3.2 and NSS 3.3.x (whatever is the latest release on that branch). I think we need to know where (in what release, on what branch) the break occured, so that we can at least know for ourselves what releases of nssckbi are compatible with each release of the rest of NSS. When we find it, the version number in this bug should be changed to match it. I've asked Neil to determine if the break occurred on the trunk or on the branch. I've suggested that he test nssckbi from the NSS 3.3 release (on ftp.mozilla.org) against a recent NSS build. If they work together then the break is most likely on the NSS 3.3 branch (or one of the branches derived from that branch). If they don't then I think the break is mostly likely on the trunk somewhere between NSS 3.3 and now.
Setting to P2 per group discussion today. Of particular concern is to ensure that the problem does not recurr. We must test that 3.10 NSS works with 3.9.5 nssckbi before shipping 3.10. If there is a solution that would make 3.10 work with 3.3.x version of nssckbi. that would be desirable, but is not necessarily a release stopper for 3.10. Bob, any ideas about this bug?
Ah Yes. We've mantained 'forward' compatibility, but not backward compatibility. That is nssckbi from old releases may not work on newer ones, but newer nssckbi's will work on older NSS releases. That change that broke 3.3 nssckbi's was the need for the Trust object to contain the issuer/serial number of the cert. Before this we needed to calculate the hash for every cert in the chain to look up the trust object. Now we just have to create the hash when we find a trust entry to verify that the trust entry matches the cert. (change 1.14 to certdata.txt checked in Nov 2001) bob
Running the current (NSS3.10) modutil and certutil against versions from the mozilla ftp site the behavior described here does not occur in NSS3.4.1 but does occur with NSS3.3.2
We need to get together and decide (and then state for the record somewhere) the policy regarding compatibility of various versions of libNSS3 and nssckbi. There seem to be two (or more) views being held by various individuals, and IMO they can't all be right. Here are some of them (in no particular order): View 1. nssckbi is no different from the other shared libraries in NSS with respect to cross-version compatibility. We claim that one must run NSS, SMIME, SSL and SOFTOKN shared libs from the very same release. We make no claims that libSSL from one release works with (say) libNSS from another release. nssckbi is no different, and must be run from the same release as the rest of the NSS libs. (This view seems to be held by some folks at Sun.) View 2. nssckbi is a PKCS11 module. NSS supports compatibility with PKCS11 modules in the PKCS11 v 2.x family. It was a stated goal at the time of the design of NSSCKBI that NSS be able to use zero, one or more "root certs" modules, and that they do NOT have to be tightly coupled to the version of libNSS. IOW backwards compatibility and compatibility with third party root cert modules (which would naturally NOT be released in sync with NSS) was a stated goal. Having been found compatible with libNSS3 in any one release of NSS 3.x, any root certs module should remain compatible with all later NSS 3.x releases. It should be the responsibility of NSS to ensure that compatibility with older root cert modules that were once compatible with earlier NSS 3.x releases. By one of these views, the very act of registering in secmod.db an nssckbi module from a different directory than the one containing the current version of NSS is an error on the part of the software registering that module because any future upgrade of NSS libraries will render that module (which is in another directory) incompatible. Also, by this view, it would be reasonable for NSS to test the version number in the nssckbi module for version EQUALITY, and reject it if not equal. With this view, it makes sense to always have the nssckbi library in the same directory as the rest of NSS, regardless of the path registered in secmod.db, and in fact it makes sense for nssckbi to be linked to NSS (as softoken now is). This does not force NSS to *USE* nssckbi, but it would avoid all problems with getting the pathname of an incompatible nssckbi registered in secmod.db. By the other of those views, any incompatibility between a newer libNSS and an older nssckbi (that was valid with a previous NSS 3.x release) constitutes a backward compatibility failure of libNSS, and should be fixed as an NSS bug. Each of those two views seems self consistent, and inconsistent with the other. There may exist other views that are also self consistent and inconsistent with either of those. At the present time, it appears that when registering nssckbi in secmod.db the ONLY library name that makes sense is a plain file name with no path component (neither an absolute nor relative path), and rely on a library search path to find the libraty. Any name that includes a path component will result in a failure if NSS is ever updated and the new NSS is stored in a different directory than the original. This is making NSS appear unworkable to the developers of the products tht use it.
Re: comment 4, Here is my view : Until such point that nssckbi uses only standard PKCS#11 type and extensions, and no vendor-specific extensions, like trust objects, it cannot be considered a standard PKCS#11 module, and thus should only be paired with libnss from the same source tree.