LSB 4.0: The Cryptography Strategy

The coming of the next version of the Linux Standard Base will bring a lot of interesting new features, one of which will be the addition of a cryptographic library that independent software vendors will be able to utilize for their applications.

There are several crypto solutions out there that the Linux Standard Base could incorporate into LSB 4.0. One clear criterion for such a solution is that the library include Secure Sockets Layer (SSL) capability. Which leaves a few good candidates. The big one, of course, is OpenSSL, a highly popular library that is widely used by so many applications.

But OpenSSL has one big concern that poses a problem for standardization: as it has been developed over time, OpenSSL has not maintained full backwards compatibility with its earlier versions. Application vendors have dealt with this ABI compatibility issue in the past by simply picking a version and basically trying to stick with it. For inclusion in a standard, however, OpenSSL's strategy is a big problem.

Faced with this obstacle, the LSB team opted to go with another, more original implementation of SSL--Mozilla's Network Security Services (NSS)--as the included crypto solution in LSB 4.0.

Originally known as Netscape Security Services, NSS is actually the first software implementation of SSL, and is composed of a client and server-side solution that includes more toolsets than just crypto and SSL. According to Robert Relyea, a developer at Red Hat and the NSS team, NSS includes several command-line tools that enable such things as encryption of private keys and certificate generation.

Since NSS implements SSL for clients and servers, it shows up in a variety of applications, Relyea explained. Mozilla uses it for its popular client projects such as Firefox and Thunderbird, and of course it's still being used in the Netscape browsers. Red Hat uses NSS for its Directory Server and Certificate System. And NSS shows up in OpenOffice.org, Evolution, and Gaim. Clearly, this is no Johhny-come-lately to the crypto scene.

Even though NSS may not be as widely used as OpenSSL, it has a big advantage over OpenSSL as far as the LSB is concerned: the developers of NSS have always made it a priority to keep binary compatibility with all versions of NSS. Relyea related that he personally was aware of many instances of applications that were written for NSS 3.2 that could be run with no problems on machines that had NSS 3.11, a much newer version.

NSS is currently maintained by Red Hat and Sun, as the NSS components, originally part of Netscape, were picked up by Red Hat's acquisition of the Red Hat Certificate System from AOL (the eventual owner of Netscape) in 2005. Sun's 1999 iPlanet alliance with Netscape has enabled the company to remain in touch with NSS development. The fact that two large open source players are still maintaining and developing NSS is also a big plus for its inclusion in the LSB.

License compatibility was also a small concern for inclusion of OpenSSL. It is possible, for instance, to use OpenSSL crypto libraries in NSS, but OpenSSL's dual licenses (the OpenSSL and SSLeay Licenses) have attribution requirements that are incompatible with the GPL and other licenses. By contrast, the NSS is tri-licensed under the Mozilla Public License, the GPL, and the Lesser GPL, which offers more licensing flexibility for software vendors.

Relyea emphasized that the differences between NSS and OpenSSL are more than just in terms of binary compatibility. He described OpenSSL as being "like assembler language programming for cryptography." NSS, he added, "is more of a higher-level form of cryptography."

The transition of NSS into the LSB is not without some hurdles, however. In order for it to work within the LSB, NSS will also have to come with Netscape Portable Runtime (NSPR). According to Wan-Teh Chang, a computer programmer at Google and an NSPR developer, NSPR is a platform abstraction library that NSS uses as a platform abstraction layer rather than developing its own. Viewed this way, NSPR is an internal dependency of NSS.

Chang added "But NSS also uses some NSPR types in its API. And the SSL library in NSS is implemented in a layered I/O model--SSL is a layer on top of the TCP layer. NSS uses some NSPR functions to set up this stack of I/O layers."

Right now, the NSS and NSPR teams are working to get the libraries ready for inclusion in LSB 4.0. "Even though LSB 4.0's primary interest is in NSS, we have to document some NSPR functions so that people can use the SSL functions (and some certificate functions) in NSS successfully," Chang explained.

The work should be worth it, though, when NSS is included with the LSB. The availability of a strong set of cryptography tools will enable application developers to build their security-enabled apps towards a standard that will greatly enhance that application's portability to other Linux distributions. No longer will they have build separate security solutions within their application for each Linux distro they want to deploy the application.