Public Key Infrastructure Testing PKI

X.509 Path Validation Test Suite

Version 1.07
enabling tools for PKI client software developers

This page contains conformance tests for relying parties that validate X.509 certification paths.  Each test consists of a set of X.509 certificates and CRLs.  The tests are fully described in the Conformance Testing of Relying Party Client Certificate Path Processing Logic document.  The goal for the first release of these tests was to address the X.509 features used in the DoD Class 3 PKI.  While this test suite remains available for use, it has been superseded by the Public Key Interoperability Test Suite (PKITS), which provides for more comprehensive testing of the features of X.509.

The tests cover X.509 version 3 certificates and X.509 Version 2 CRLs.  The tests cover the commonly used fields and extensions with the following caveats:

• Serial number is always positive in these tests.
• Distinguished names only use PrintableString in attributes whose value is of type DirectoryString (e.g., o=, ou=, or cn=).
• Unique identifiers never appear in these certificates.
• All certificates are signed with RSA PKCS #1 v1.5 and SHA-1.
• At a minimum, implementations must support basic constraints and key usage.  If these extensions are not supported, the implementation will not be able to process any of the tests.
• These tests also address certificate policies and policy constraints.  Tests for policyConstraints address only the requireExplicitPolicy field.
• Expected test results assume that the implementation requires certificate status information and processes CRLs.

The tests are provided in two different formats:

• as a compressed tar file (tgz file).  This file may be opened using tar.  To use tar, the command "tar -zxvf  <filename>" will decompress and untar the file.  This will create a folder called "X509tests", which will in turn contain 76 folders called "testX" where X is "1" through "76".
• as a zip file.  This will create a folder called "X509tests", which will in turn contain 76 folders called "testX" where X is "1" through "76".

In both cases, each folder contains all the certificates and CRLs required to perform one of the tests, as well as the end-entity private key.  The tests are ordered in the same way as they are ordered in the document that describes the tests.  In cases where the API for the path validation routines is not exposed, the private key may be used with applications to implement these tests.  Each folder contains five types of files:

• Files with a "crt" extension contain certificates.
• Files with a "crl" extension contain CRLs.
• Files with a "p12" extension are encoded according to PKCS #12 and contain encrypted versions of the end-entity private keys (the password for each .p12 file is "password").  In addition, each .p12 files contains a CertBag and a CRLBag that together include all of the relevant certificates and CRLs for the test.
• Files with a "p7m" extension contain signed S/MIME messages (i.e., CMS) that may be useful in testing the path validation capabilities of S/MIME clients.  Each .p7m contains a message that was signed using the end-entity's private key.  As with the .p12 files, the .p7m files also include all of the certificates and CRLs for the test.
• Files with a "crtx" contain private keys.  The syntax of the these files is according to the PrivateKeyInfo data structure in PKCS #8, where the OCTET STRING for privateKey contains a DER encoded RSAPrivateKey from PKCS #1.

The certificates and CRLs necessary to perform the tests can also be retrieved using LDAP.  The directory is on the machine seclab7.ncsl.nist.gov and can be accessed using port 389.  The schema specified in RFC 2587 was used to place the certificates and CRL in the directory.

Notes: The trust anchor and CRL are included in each test.  However, the same trust anchor and CRL are used for every test.  It may be more convenient to establish the trust anchor and then perform the tests.

The certificates and CRLs are signed with the same Certification Authority (CA) using the same private key.  Thus, the issuer Distinguished Name (DN) in the certificate and the issuer DN in the CRL will always match.  Furthermore, there is no need to develop a certification path for validating signatures on the CRL.  In fact, the same public key used to validate the signature on a certificate MUST be used to validate the signature on the CRL.

The X.509 2000 policy processing rules are assumed. 

No test data has changed between versions 1.06 and 1.07 of this test suite.  All of the tests and expected test results are the same.  The only changes in version 1.07 are minor corrections in the documentation.