286663 - backwards compatibility failure: NSS 3.3.9 nssckbi with 3.9.x NSS

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 2

[Robert Relyea]

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

Comment 3

[Neil Williams]

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

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 5

[Julien Pierre]

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.