This is a potential security issue, you are being redirected to https://csrc.nist.gov
NIST/Information Technology Laboratory responds to industry and user needs for objective, neutral tests for information technology. ITL recognizes such tests as the enabling tools that help companies produce the next generation of products and services. It is a goal of the NIST PKI Program to develop such tests to help companies produce interoperable PKI components.
NIST worked with CygnaCom Solutions and BAE Systems to develop a suite of tests that will enable developers and validation laboratories to determine a PKI client application's conformance to the path processing rules as specified in X.509. As additional tests are developed, NIST will make the information necessary to perform the tests (e.g., descriptions of each test, the expected results of the test, and any certificates and certificate revocation lists necessary to perform the test) available on-line for both review and for use in testing applications.
The Public Key Interoperability Test Suite (PKITS) is a comprehensive X.509 path validation test suite that was developed by NIST in conjunction with BAE Systems and NSA. The PKITS path validation test suite is designed to cover most of the features specified in X.509 and RFC 3280.
Both test descriptions and test data are available for the PKITS path validation test suite:
PKITS supersedes an earlier path validation test suite, Conformance Testing of Relying Party Client Certificate Path Processing Logic. PKITS incorporates all of the tests from the earlier test suite, but also includes tests for many features that were not covered by the earlier test suite.
The path discovery test suite consists of a set of sample PKI architectures. In each PKI architecture one CA is designated as the trust anchor and several end-entity certificates have been issued. Each test involves either locating all of the intermediate certificates and CRLs needed to validate an end-entity certificate or determining that no valid certification path exists.
Both test descriptions and test data are available for the path discovery test suite:
The initial draft of the test suite contains three PKI architectures. The three PKI architectures are all very similar, the main difference being the method by which intermediate certificates and CRLs may be located. In one architecture, the certificates include LDAP URIs that indicate where certificates and CRLs may be found. In another architecture, the certificates include HTTP URIs that indicate where certificates and CRLs may be found. In the third architecture, the certificates do not include any information indicating where certificates and CRLS may be found, but the certificates and CRLs may be obtained from smime2.nist.gov using LDAP as specified in RFC 2587.
Each of the PKI architectures is designed to test a path discovery and validation module's abilities to perform path discovery at two different levels of complexity. At the Rudimentary level, all end-entity certificates are issued by CAs that are hierarchically subordinate to the trust anchor CA. At the Basic level, end-entity certificates are issued by CAs that are connected to the trust anchor CA by a mesh PKI architecture. Path discovery and validation modules that are capable of discovering and validating all of the certification paths at the Rudimentary and Basic levels within the Directory based PKI architecture should be capable of discovering certification paths within the Federal PKI as it is currently constructed.
The path discovery test suite is intended for use with path discovery and validation modules whose path validation capabilities have already been successfully tested using PKITS. The Rudimentary path discovery tests require a path validation module that implements the basic path validation functionality along with support for a few certificate extensions (key usage, basic constraints, and certificate policies). The Basic path discovery tests additionally require the path validation module to support processing name constraints for the directoryName name form, the policyMappings extension, the inhibitPolicyMapping field of the policyConstraints extension, and certificatePolicies extensions that assert the anyPolicy OID.