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. It contains the same issuer and subject, which look correct to the user but the public key is that one of the forger. The user could find out if he could remember the thumbprint or the signature of the good certificate, but honestly which normal user would do this? The validation function would of course find out about this fake, when checking the signature of the certificate. But the validation function just returned after finding out that revocation information are not available.

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