Steven T. Hatton wrote: > If I understand correctly, one main purpose of NSS is to provide a > standard 'wrapper' around different implementations of security tokens > and security services, so the programmer using the services can write to > one abstract interface which will provide all the services from the > underlying token implementation. JSS is inturn, a wrapper around NSS > which provides the Java programmer with the same functionality NSS > provides to the C programmer. > > I am aware of things such as JSSE and OpenSSL which provide much of the > functionality I am looking for. The problem I ran into was that of > incompatible certificate/key-store formats. In particular, I wanted to > have one cert issued per box which would provide for SSL/PKI related > services for all servers running on the box. In order to use JSSE I was > required to export the keys and certificates and store them in a > different format. This, to me is a non-starter. Anything which > required the same data to be stored in different locations, and or > different formats - with the exception of caching and backup purposes - > is inherently evil. > > What I want is the ability to the following: > > ftp -a ftp.mozilla.org/<where the latest JSS is> > tar xvfz latest-jss.tar.gz > pkgadd -d latest-jss //or rpm -i latest-jss > > /* hack a bunch of java code that uses JSS > create and install one set of key3.db, cert7.db and secmod.db files > for all my aplications on a given box. > */ > > run my code. > > The ease of installation is extremely important. Am I off target in > what I am wanting?
I don't quite understand what you want. Do you want your JSSE-based and OpenSSL-based applications to be able to use your centrally installed key3.db, cert7.db, and secmod.db files too? How can NSS or a standard wrapper of security services that you envisioned enable you to do that? If you've converted your apps to use NSS, why is the incompatible certificate/key-store formats used by JSSE and OpenSSL an issue? Wan-Teh
