Original Issue Produced by: Chris Harding, The Open Group
1 Introduction
2 Explanatory Notes
2.1 Functionality Addressed by Tests
2.2 Test Objectives
2.3 Judging Test Results
2.4 CATS Directory Information Tree (DIT) and Content
3 The Certificates
4 The Tests
4.1 Secure Web Connection
4.1.1 Successful https Connection
4.1.2 Expired Server Certificate
4.1.3 Revoked Certificate
4.2 Secure Web Transaction
4.2.1 Successful Transaction
4.2.2 Revoked Certificate
4.3 E-Mail Transaction
4.3.1 Successful Transaction
4.3.2 Revoked Certificate
5 Acknowledgements
6 Author's Address
7 Bibliography
This document defines a Certificate Authority Test suite for use by any individual, organization, or group. The purpose of this document is to provide the information required for testers to prepare for and perform tests which are designed to gauge interoperability between certificate generation products.
The document should be read in conjunction with the description of the Basic LDAPv3 Interoperability Test Suit (BLITS). BLITS contains some tests which test inter-operation of Certificate Generation products with each other and with Directory products. In addition, many of the CATS tests can be performed by obtaining certificates from a Directory rather than configuring them in to the web clients etc. that are used in the tests. The greatest value of the CATS tests to Certificate Generation product vendors is to perform them and the relevant BLITS tests in conjunction with Directory product vendors.
This document may be copied in whole or in part for use in other documents if acknowledgement of the source is provided in those documents.
The tests cover
The tests are designed to be performed in a multi-vendor environment, permitting certificate generation implementers to verify basic interoperability with each others' products.
Specific success criteria for each test are indicated along with the description of how to perform each test. If the criteria are not met for a given test, it is deemed to have failed.
The tests in this test suite do not require use of directories. However, the CATS DIT is important because X.509 certificate subject fields contain Directory distinguished names. Also, the tests are designed such that they can be carried out by products that retrieve the certificates from directories instead of having them installed manually. Furthermore, there are tests in the Basic LDAPv3 Interoperability Test Suite (BLITS) that require the CATS test data to be stored in the LDAP servers being tested.
The CATS DIT an extension of the BLITS DIT and is available in the same forms as the BLITS DIT.
Note that the BLITS tests that involve certificates also use these subtrees. Additional entries in them, not used in CATS, are defined for BLITS. The DIT described in this section of the CATS definition covers what is needed for the BLITS certificate tests as well as for the CATS tests, and Section 3 of the CATS definition covers the certificates needed for the BLITS certificate tests as well as those needed for the CATS tests. (This is so that the certificate definitions needed by both test suites are listed in one place, for the convenience of people testing certificate generator products, and because some certificates are used in both sets of tests.)
References to DNs found in the text of this document are described in terms of X.500-style naming.
The user attribute and object class sub-sets used in this suite are those used in BLITS.
Where the CATS test data is stored in LDAP servers, access controls should be set up on each LDAP server in such a way that users binding anonymously can read and search all the data.
Figure 2-1: CATS Directory Information Tree (DIT)
Figure 2-1 shows the subtree of the BLITS DIT used for the tests in CATS. Its root is ou=CAs, o=imc, c=us.
The CATS tests enable up to 10 certificate generator products to be tested. For each product, there are two CAs that issue certificates generated by that product. For product <n> (n = 1 through 10) these CAs are CA<n> and BadCA<n>. (The BadCAs are used in testing CRLs). There are thus 20 CAs: CA1 through CA10 and BadCA1 through BadCA10. Their DNs are ou=CA1, ou=CAs, o=imc, c=us through ou=CA10, ou=CAs, o=imc, c=us and ou=BadCA1, ou=CAs, o=imc, c=us through ou=BadCA10, ou=CAs, o=imc, c=us.
The subtrees below the CA entries are all similar to each other. The subtrees below the BadCA entries are all similar to each other but are different in detail from those below the regular CA entries.
Each CA subtree and each BadCA subtree contains:
Each CA or BadCA entry is of auxiliary object class certificationAuthority and contains a cACertificate attribute which is a self-signed certificate for its public key. Each CA entry also contains a certificateRevocationList attribute which is a CRL that lists all of the certificates issued under its public key for BadCAs. (See RFC 2256.)
The Crosscerts branch under the CA entry for CA<n> contains an entry for each CA and an entry for each BadCA. These entries are of auxiliary object class certificationAuthority. The entry for CA<m> (or BadCA<m>) in the Crosscerts branch for CA<n> contains a cACertificate attribute which is a certificate for the public key of CA<m> (or BadCA<m>) signed using the private key of CA<n>.
The Orgs branch under the CA<n> entry contains the organizations, hosts (computers) and people used in the tests.
Each person is of auxiliary object class strongAuthenticationUser and has a userCertificate attribute whose values are certificates signed using the CA<n> public key. They include a certificate containing the person's DN in the subject field and in some cases containing the person's e-mail address in the alternate subject extension field.
Each host is of object class device and auxiliary object class strongAuthenticationUser and has a userCertificate attribute having a value that is a certificate signed using the CA<n> public key and containing the host's DNS address in the alternate subject extension field.
This section describes the certificates to be generated by the Certificate Generator vendors participating in the tests.
In the test descriptions, the participants are referred to as Vendor<a> and Vendor<b>. At different times, the same Vendor<n> can be Vendor<a> or Vendor<b>. Each Vendor<n> must generate the certificates shown in the table below. They will be made available to other participants in the tests in subdirectory certs<n> of the main directory where test information is stored. The name of the file containing each certificate is given in the table.
In addition to the certificates, the CRL for CA<n> will be made available in file ca_crl in the certs<n> subdirectory.
| Certificate Name | Filename | Certificate Description |
|---|---|---|
| CA<n> Root Certificate | ca_root | A self-signed X.509 v3 certificate whose private key will be used to sign other certificates. The subject field must contain the DN ou=CA<n>, ou=CAs, o=imc, c=us. The time interval for which the certificate is valid must include the date of the tests. |
| BadCA<n> Root Certificate | badca_root | A self-signed X.509 v3 certificate whose private key will be used to sign other certificates. The subject field must contain the DN ou=BadCA<n>, ou=CAs, o=imc, c=us. The time interval for which the certificate is valid must include the date of the tests. |
| CA<n> Valid Widget Server Certificate | valid_widget_server | An X.509 v3 certificate signed using the CA<n> Root Certificate private key. The subject field must be blank. The alternate subject field must contain the DNS address widgets<n>.dc.opengroup.org. The time interval for which the certificate is valid must include the date of the tests. |
| BadCA<n> Widget Server Certificate | badca_widget_server | An X.509 v3 certificate signed using the BadCA<n> Root Certificate private key. The subject field must be blank. The alternate subject field must contain the DNS address widgets<n>.dc.opengroup.org. The time interval for which the certificate is valid must include the date of the tests. |
| Expired Widget Server Certificate | expired_widget_server | An X.509 v3 certificate signed using the CA<n> Root Certificate private key. The subject field must be blank. The alternate subject field must contain the DNS address widgets<n>.dc.opengroup.org. The time interval for which the certificate is valid must NOT include the date of the tests. |
| Cross-Certificates for CA<m> | crosscert-ca<m> | There is one of these for each CA<m>. It is an X.509 v3 certificate signed using the CA<n> Root Certificate private key and validating the CA<m> Root Certificate public key. The subject field must contain the DN ou=CA<m>, ou=CAs, o=imc, c=us. The time interval for which the certificate is valid must include the date of the tests. |
| Cross-Certificates for BadCA<m> | crosscert-badca<m> | There is
one of these for each BadCA<m>. It is an X.509 v3 certificate
signed using the CA<n> Root Certificate private key and validating the
BadCA<m> Root Certificate public key.
The subject field must contain the DN
ou=BadCA<m>, ou=CAs, o=imc, c=us. The
time interval for which the certificate is valid must include
the date of the tests.
These certificates appear in the CRL for CA<n>. |
| CA<n> Frank Bristow Certificate | ca_frank_bristow | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Frank Bristow, ou=People, ou=Gigantic<n>, ou=orgs, ou=CA<n>, ou=CAs, o=IMC, c=US. The Alternate Subject field must contain the e-mail address frank-bristow@gigantig<n>.dc.opengroup.org. The time interval for which the certificate is valid must include the date of the tests. |
| BadCA<n> Frank Bristow Certificate | badca_frank_bristow | An X.509 v3 user certificate signed using the BadCA<n> Root Certificate private key. The subject field must contain the DN cn=Frank Bristow, ou=People, ou=Gigantic<n>, ou=orgs, ou=BadCA<n>, ou=CAs, o=IMC, c=US. The Alternate Subject field must contain the e-mail address frank-bristow@gigantig<n>.dc.opengroup.org. The time interval for which the certificate is valid must include the date of the tests. |
| Pablo Picasso Certificate | pablo_picasso | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Pablo Picasso, ou=TLS, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| John Constable Certificate | john_constable | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=John Constable, ou=TLS, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must NOT include the date of the tests. |
| William Turner Certificates | william_ca<m>_turner | There is one of these for each CA<m>. It is an X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=William CA<n> Turner, ou=TLS, ou=CA<m>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| Georges Braque Certificates | georges_badca<m>_braque | There is one of these for each CA<m>. It is an X.509 v3 user certificate signed using the BadCA<n> Root Certificate private key. The subject field must contain the DN cn=Georges CA<n> Braque, ou=TLS, ou=CA<m>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| Basil Brush Current Certificate | basil_brush_current | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Basil Brush, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| Basil Brush Expired Certificate | basil_brush_expired | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Basil Brush, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must NOT include the date of the tests. |
| Charles Fox Certificate | charles_fox | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Charles Fox, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. |
| Lawrence Lamb Certificate | lawrence_lamb | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Lawrence Lamb, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. |
| Richard Bird Certificate | richard_bird | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Richard Bird, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. |
| Michael Fish Current Certificate | michael_fish_current | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Michael Fish, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| Michael Fish Expired Certificate | michael_fish_expired | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Michael Fish, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must NOT include the date of the tests. |
| Tony Hart Current Certificate | tony_hart_current | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Tony Hart, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| Tony Hart Expired Certificate | tony_hart_expired | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Tony Hart, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must NOT include the date of the tests. |
| Quintain Hogg Certificate | quintain_hogg | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=Quintain Hogg, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. |
| John Prescott Current Certificate | john_prescott_current | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=John Prescott, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must include the date of the tests. |
| John Prescott Expired Certificate | john_prescott_expired | An X.509 v3 user certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN cn=John Prescott, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. The time interval for which the certificate is valid must NOT include the date of the tests. |
| Swallow Bank Certificate | swallow_bank | An X.509 v3 certificate signed using the CA<n> Root Certificate private key. The subject field must contain the DN ou=Swallow Bank, ou=Certificates, ou=CA<n>, ou=CAs, o=IMC, c=US. |
In addition to the tests described in this document, the tests in BLITS sections 3.3.11, 3.3.15.1.3 and 3.3.15.2.3 test interoperation of certificates generated by different products. (They do so in conjunction with LDAP clients and servers.)
| Purpose | Make a secure connection to a web server. |
| Vendor <a> Configuration | Web server at https://www.widgets<a>.dc.opengroup.org configured to provide the CA<a> Valid Widget Server Certificate when responding to incoming https connections. |
| Vendor <b> Configuration | Web browser configured to require https servers to be validated by a certificate chain ending with the CA<b> Root Certificate. The browser should have the CA<b> Cross-Certificate for CA<a> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Procedure | Vendor <b> attempts to browse http://www.widgets<a>.dc.opengroup.org/ |
| Expected Results | The test is successful if the http://www.widgets<a>.dc.opengroup.org home page is displayed. |
| Purpose | Check that a secure connection can not be made to to a web server whose certificate has expired. |
| Vendor <a> Configuration | Web server at https://www.widgets<a>.dc.opengroup.org configured to provide the CA<a> Expired Widget Server Certificate when responding to incoming https connections. |
| Vendor <b> Configuration | Web browser configured to require https servers to be validated by a certificate chain ending with the CA<b> Root Certificate. The browser should have the CA<b> Cross-Certificate for CA<a> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Procedure | Vendor <b> attempts to browse http://www.widgets<a>.dc.opengroup.org/ |
| Expected Results | The test is successful if there is an authentication error and the http://www.widgets<a>.dc.opengroup.org home page is not displayed. |
| Purpose | Check that a secure connection can not be made to to a web server when there is a revoked certificate in the certificate path. |
| Vendor <a> Configuration | Web server at https://www.widgets<a>.dc.opengroup.org configured to provide the BadCA<a> Widget Server Certificate when responding to incoming https connections. |
| Vendor <b> Configuration | Web browser configured to require https servers to be validated by a certificate chain ending with the CA<b> Root Certificate. The browser should have the CA<b> Cross-Certificate for BadCA<a> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Procedure | Vendor <b> attempts to browse http://www.widgets<a>.dc.opengroup.org/ |
| Expected Results | The test is successful if there is an authentication error and the http://www.widgets<a>.dc.opengroup.org home page is not displayed. |
| Purpose | Make a successful secure web transaction. |
| Vendor <a> Configuration | Web transaction server configured to require transaction clients to be validated by a certificate chain ending with the CA<a> Root Certificate. The server should have the CA<a> Cross-Certificate for CA<b> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Vendor <b> Configuration | Web transaction client configured to provide the CA<b> Frank Bristow Certificate. |
| Procedure | Vendor <b> attempts a secure transaction on the Vendor <a> server. |
| Expected Results | The test is successful if the transaction succeeds. |
| Purpose | Check that a successful secure web transaction can not be made when there is a revoked certificate in the certificate path. |
| Vendor <a> Configuration | Web transaction server configured to require transaction clients to be validated by a certificate chain ending with the CA<a> Root Certificate. The server should have the CA<a> Cross-Certificate for BadCA<b> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Vendor <b> Configuration | Web transaction client configured to provide the BadCA<b> Frank Bristow Certificate. |
| Procedure | Vendor <b> attempts a secure transaction on the Vendor <a> server. |
| Expected Results | The test is successful if the transaction fails with an authentication error. |
| Purpose | Make a successful e-mail transaction. |
| Vendor <a> Configuration | E-Mail client receiving mail sent to widgets<a>.dc.opengroup.org and configured to require received S-MIME messages to be validated by a certificate chain ending with the CA<a> Root Certificate. The client should have the CA<a> Cross-Certificate for CA<b> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Vendor <b> Configuration | E-Mail client configured to send messages from gigantic<b>.dc.opengroup.org and to secure S-MIME messages using the CA<b> Frank Bristow Certificate. |
| Procedure | Vendor <b> sends an S-MIME message to per-svensson@widgets<a>.dc.opengroup.org. |
| Expected Results | The test is successful if the message is validated by the Vendor <a> mail client. |
| Purpose | Check that an S-MIME message is flagged as invalid when there is a revoked certificate in the certificate path. |
| Vendor <a> Configuration | E-Mail client receiving mail sent to widgets<a>.dc.opengroup.org and configured to require received S-MIME messages to be validated by a certificate chain ending with the CA<a> Root Certificate. The client should have the CA<a> Cross-Certificate for CA<b> loaded. (Alternatively, it could be configured to search a Directory for this certificate). |
| Vendor <b> Configuration | E-Mail client configured to send messages from gigantic<b>.dc.opengroup.org and to secure S-MIME messages using the BadCA<b> Frank Bristow Certificate. |
| Procedure | Vendor <b> sends an S-MIME message to per-svensson@widgets<a>.dc.opengroup.org. |
| Expected Results | The test is successful if the Vendor mail client flags the message as invalid. |
Chris Harding
The Open Group
Apex Plaza
Forbury Road
Reading, Berks. RG1 1AX
UK
E-Mail: c.harding@opengroup.org
Voice: +44 118 9508311 X 2262
FAX: +44 118 9500110