NSS libPKIX Brainstorming

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

The LibPKIX API Overview

PKIX is split into two layers:

• an independent layer that has main control over cert chain building and verification. It implements algorithm compatible with one described in RFC 3280(6.2 Extending Path Validation).
• a portability layer that supports multiple cert stores (local pkcs11, and remote ldap, http), and OCSP cert validation. This layer does most of it’s work by delegating operations to the underlying crypto platform. It also implements a number of platform-dependent cert chain checkers.

Main functions:

• PKIX_BuildChain: the function attempts to build and validate a certificate chain according to the ProcessingParams using an RFC 3280-compliant validation algorithm. If successful, this function returns NULL(PKIX_Error*) and stores the build result at "pResult", which holds the built certificate chain, as well as additional information, such as the policy tree and the target's public key. If unsuccessful, an Error is returned.

• PKIX_ValidateChain: the function attempts to validate the certificate chian that has been set in the PKIX_ValidateParams pointed to by "params" using an RFC 3280-compliant algorithm. If successful, this function returns NULL and stores the PKIX_ValidateResult at "pResult", which holds additional information, such as the policy tree and the target's public key.

Main structures:

• PKIX_ProcessingParams: are parameters used when validating or building a chain of certificates. Using the parameters, the caller can specify several things, including the various inputs to the PKIX chain validation algorithm (such as trust anchors, initial policies, etc), any customized functionality, such as CertChainCheckers, RevocationCheckers, CertStores(PK11, LDAP, HTTP), CertSelectors(selects certs based on name constrain extension), ResourceLimits(controls work time, chain depth, max number of used certs and crls), and whether revocation checking should be disabled.

• PKIX_BuildResults: represents the result of a PKIX_BuildChain call. It consists of a ValidateResult object, as well as the built and validated certificate chain.

• PKIX_ValidateResults: represents the result of a PKIX_ValidateChain call. It consists of the valid policy tree and public key resulting from validation, as well as the trust anchor used for this chain.

Integration Approach

To be expanded

Integration In Details

To be expanded

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.

• 4. One of the parameters of the validation process that libPKIX produces is a validated policy tree. I'm wondering if there is going to be a use of a policy tree in the browser.

One of the application that I can think of is to use the tree in the UI, to show user why this particular policy and it's modifier was picked. If there is no use of it, we can limit API to return only the set of valid policy oids of he leaf certificate. Please not, that policy tree is not available if build/validation process failed.

Features

• Ensure that our new code can handle the (client auth) case, where the trust information relevant to the cert path construction (on the client side) is different from the locally stored trust information (in the client).

The libPKIX relies on caller to supply trust anchor information for a particular chain validation. The new API to libPKIX will provide a call back functionality that should be used by caller to supply arbitrary trust anchors.

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:
  • Tracker bug to land the diff: bug 358785
  • 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 is working on this item. Work in progress.

• Get initial figures for libPKIX performance.
  • Compare chain building and validation performance of old NSS API with new libPKIX API.
    • This task is done(see results in "LibPKIX performance section).
  • Get performance numbers for the building and validation of a chain that includes certs with policy extensions and cross-certification.
    • Work in progress... Looking for such cert chain.

• Ensure consistency of verification decisions across all existing and new certificate verification functions, in particular:
  • add new verification function(s) that offers libPKIX parameters in its API.
    • The internals of the implementation of the function are written. Finalizing API design. For more information see bug 294531
  • keep all existing verification API, but change their implementation to call libPKIX functions
    • I will start working on it after new API is finalized.

• NSS internal libraries such as libSSL and libSMIME that utilize NSS chain building and validation features will need to be modified in order to leverage new functionalities provided by libPKIX. These changes are related to propagating policy parameters for certificate chain building/validation API from user application to NSS libraries and back. There are also open questions regarding changes in chain building process(See "Open Questions" 1-3) answers to that will result in NSS libraries modifications.

• After all of above items are done, we will not be able to say that libPKIX NSS is fully integrated in NSS. There are number of features that PKIX/NSS/NSPR still lacks. Here is the list of bugs: pkix bug list
  • Bugs/features need to be reviewed and the target release should be assign for the ones that will hold 3.12 release.
  • Fix bugs that have 3.12 as the target release.