This document provides details on the cryptographic material that the participants will have to deal with while conducting the plugtest and also on the trust frameworks specified for this plugtest.

Cryptographic material

ETSI will supply to plugtest participants with the required cryptographic material for conducting all the tests.

This material will consist in:

  1. P12 files containing private keys and their corresponding certificates for generating and verifying test cases signatures.

  2. Certificate files containing the CA certificates up to a trust anchor represented by the root CA (Root_CA_OK). These certificates will be published in the LDAP server (details for accessing to the LDAP server may be found in the Online PKI services details page) and in the HTTP server deployed in the plugtest portal.

  3. CRLs issued by the CAs operating in the plugtest trust frameworks. These CRLs will be re-issued several times during the plugtest with a certain periodicity, so that all of them are up to date. The CRLs will be published in the LDAP server and in the HTTP server deployed in the plugtest portal.

  4. The certificate for the Time-stamping server issued by Root_CA_OK. As above, this material will be published in the the LDAP server and in the HTTP server deployed in the plugtest portal.

Trust frameworks

ETSI has defined two trust frameworks for this plugtest, each one having a different Root CA.

Within each trust framework different scenarios are defined. ETSI will define groups of test cases (for instance a group defining different test cases for XAdES-A signatures) for each scenario.

Participants will use the cryptographic material in a certain scenario (as per ETSI indications) for generating (and/or verifying) the signatures corresponding to this group. In consequence each scenario will incorporate a set of cryptographic items that the participants will use while working with one of the aforementioned groups of test cases.

The two trust frameworks have been defined as detailed below:

  1. First trust framework. Root_CA_OK as Root CA. This framework will be used for conducting all the tests on XAdES v1.3.2. For this trust framework, two different scenarios have been defined:

    1. Scenario SCOK. Participants will use its cryptographic material for both generating and verifying the signatures corresponding to the generation and cross-verification test cases. In this scenario all the certificates managed during the generation and verification of the signature, including the end-entities certificates issued by the CA deployed in the portal to the participants, are valid.

    2. Scenario SC1. Participants will use its cryptographic material only for verifying signatures pre-generated by ETSI corresponding to the only-verification tests cases. In this scenario, ETSI will include a pre-generated signing certificate, which by the time the plugtest will start will be revoked, and also a pre-generated signing certificate, which by the time the plugtest will start will be expired. The CA issuing both certificates (Level_B_CA_OK) will issue the CRLs including references to the revoked certificate. This CA will also generate OCSP responses reporting on the status of these certificates whenever it is requested by the participants. ETSI will generate one XAdES signature using the revoked certificate and another one using the expired certificate. This scenario is intended to check implementations behaviour when verifying not valid signatures, which will be provided by the ETSI portal.

  2. Second trust framework. Root_CA_2OK as Root CA. This framework will be used for conducting the tests on new features introduced by XAdES v1.4.1, namelly and unsigned properties. Only one scenario has been defined for this framework, consisting in one Root CA (Root_CA_2OK) which issues certificate for a TSA (TSA2), which issues the time-stamp tokens for the signatures generated. This scenario does not provides end user certificates and participants will use signing certificates in the the first trust framework, which results in certificates and validation material coming from different trust frameworks appearing within the same AdES signature.