Certificate Path Validation

Current situation

OOo validates certificates using either NSS (Linux, Solaris, Mac, etc) functionality or platform specific functionality (Windows). The documentation of the respective validation function does not state clearly what standard they implement or to what extend a standard is supported. The currently (OOo 3.2) used validation function of NSS is said to support partly RFC 3280.

Mission

OOo will strive to follow RFC 3280 and the newer RFC 5280. Other certificates, certificate extensions and other validation schemes as the one mentioned in those standards will not be implemented. This does not hinder other parties to provide a different solution for OOo.

To do

• Use NSS validation function which complies with RFC 3280, including
  • revocation checking via OCSP (using AIA extension) and CRLs (using CRL distribution points and locally cached CRLs)
  • certificate fetching (using AIA extension)
• Proper handling of policies
• Proper handling of key usage

Validation status

The certificate path building and validation can fail for a lot of reasons. Validation functions (NSS, Windows CAPI) usually offer error codes indicating a reason for a failure. However, they are lacking to document clearly how their implementations proceed when encountering an error. It is not unusual that an algorithm just returns when encountering an error. Or in case of multiple certification paths for a given end certificate, an algorithm may only return the error of the last checked paths. In other words, the returned error may be only one of many others and not necessarily the most severe. And it is unclear, if all other aspects of the certificate path validation are OK, except the one indicated by the returned error.

Presenting the error codes to users may mislead them. Examples:

1. The certificate has expired. The user may think that it is still OK, because it has only expired a couple of days ago. In this case the certificate can already be revoked, because the private key leaked to the public. But the user does not get this important information, because the validation function did not check revocation information. This can have two reasons:

• the validation stopped right after finding out that the certificate has expired,
• revocation information must not be provided for expired certificates

2. No revocation information available. Again the user thinks that the certificate is OK, because it was OK recently and the user is aware that there is no internet connection available at moment. He concludes correctly that the missing internet connection is the reason for this error. However this time, the user received a forged certificate. The public key was exchanged by a public key of the forger, which then signed the message with the corresponding private key. The validation function would of course notice this fraud, when checking the signature of the certificate. Unfortunately this check comes after revocation checking and the function just returned after finding out that revocation information is not available.

In order to prevent these misinterpretations, OOo reports a certificate as either valid or invalid.

Logging

To obtain more information about the possible cause of a failure, one can set the environment variable XMLSECURITY_TRACE=1 (OOo 3.3)(this is in fact a bootstrap variable). This will cause that additional information is written to stderr.

On Windows (as of Vista) one can use the event viewer to get more information about the validation procedure. An article about it can be found here [1].