NSS libPKIX Brainstorming

Integrating libPKIX functionality is an important task for the future of NSS.

Open Questions

The following questions need to be discussed/answered before libPKIX can be used in production.

• 1. NSS has several functions that take a leaf cert, and construct and return a cert chain for that leaf cert, without verifying it. These functions operate on the assumption (valid before the advent of cross-certified CAs) that for each cert, there is only one chain leading to a root. These functions construct as much of the chain and they can, and stop when they come to a root or to a CA whose issuer cannot be found. They succeed even if the constructed chain stops short of a root CA, and even if it stops short of a trusted CA cert. In other words, they succeed even if they cannot verify the chain they produce.

NSS typically uses such a function when constructing a chain for a "user cert" (a cert for which the local user has the private key). The functions assume (IIRC) that user certs are valid unless expired.

In the PKIX world of cross certified (bridge) CAs, where it may be possible to construct multiple cert chains that lead to multiple roots, we may instead want to construct chains that lead to a trusted root. That is something that libPKIX can do.

• 2. There is a function that takes a list of Issuer names (names of CA cert Subjects) and finds a user cert whose chain leads up to one of the CAs named in the list of Issuer names. In effect, we treat the list of issuer names as a list of trusted roots, and find a user cert whose chain leads up to one of them. This is done by SSL clients to build a cert chain with which to respond to a server's cert request. Today NSS does this without validating the cert chain as we construct it, and we don't handle bridge CAs (cross certified CAs) that may have more than one issuer. We will need to handle those in the world of PKIX.

• 3. NSS has functions that find a user cert that is believed to be valid for a purpose, e.g. find a user cert valid for email signing. Today, the algorithm assumes that all unexpired user certs are valid, and so it merely filters user certs based on cert extensions (such as Key Usage, Extended Key Usage, Netscape Cert type) to find the first cert valid for the purpose. We may want a version of these functions that chooses a cert that is verifiably valid against one of our trusted roots.

The next step is to find all the functions in each of these categories, so that we can examine their signatures to see what arguments they are already taking, which will tell us what information the callers already possess.

The next step after that will be to look at all the callers of those functions, to see if they will have access to additional information (such as policy info) with which to construct a chain or choose a cert.

Performance Comparison

• Comparison was made between NSS current certificate verification (CERT_VerifyCertificate) and libPKIX (PKIX_BuildChain) functions with the following conditions:
  • Machine: amd 2 core opteron with Linux 2.6.16
  • Chain contains three certificate. Leaf cert -> enterm CA -> trusted CA installed into the certificate db.
  • if lib ckbi is installed then nss will try to find a proper trust anchor among 106 trusted CA certs.
  • caches are primed with prior cert chain verification.
  • measurement is taken for 1000 tries.
• Results:
  • (with lib ckbi is installed)
    • libpkix: 720 microsec | nss code: 980 microsec
  • (without lib ckbi is installed)
    • libpkix: 540 microsec | nss code: 840 microsec
  • Certificate traversal time for 106 certs with ckbi installed is around 2600 microseconds.

Identified Tasks

• The libPKIX development branch contains changes to existing NSS source files. These have not yet landed on NSS trunk. TODO:
  • File a tracker bug to land the diff
  • The existing NSS functions that are now exported (in order to be accessible by libPKIX) must have their names changed to follow the style.
  • Review the patch and check it in.
  • Alexei and Nelson working on this?

• Ensure consistency of verification decisions across all existing and new certificate verification functions, in particular:
  • add new verification function(s) that offer libPKIX parameters in its API
  • keep all existing verification API, but change their implementation to call libPKIX functions
  • Alexei has already been working on this and might be close already. The code currently lives in test programs.
  • Tracker bug?