19 September 2015

Editor:

Juan Carlos Cruellas, UPC cruellas@ac.upc.edu

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 (there will be two different root CAs, namely: RootCAOK and RootCAOK2). 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 servers issued by different CAs. As above, this material will be published in the the LDAP server and in the HTTP server deployed in the plugtest portal.

Trust Frameworks and Scenarios

ETSI has defined a number of trust frameworks, within which different scenarios are defined. ETSI has defined groups of test cases (for instance a group defining different test cases for XAdES baseline signatures compliant with level B) for each scenario (they will be grouped within the folder XAdES-B-B).

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.

There are two trust frameworks: the one whose root CA is RootCAOK and the other whose root CA is RootCAOK2. These two trust frameworks support three scenarios, which are detailed below:

  1. Scenario SCOK. This scenario will include the first root CA (RootCAOK), one intermediate CA (LevelACAOK), one final CA, which issues certificates for end-entities (LevelBCAOK), and a Time Stamp Authority (TSA1), certified by RootCAOK. Participants will use its cryptographic material for both generating and verifying the signatures corresponding to the generation and cross-verification.In this scenario there are 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, that are valid. CAs within this scenario issuing certificates will issue the CRLs including references to the revoked certificate. CAs within this scenario will also generate OCSP responses reporting on the status of these certificates whenever it is requested by the participants. This scenario is intended to check implementations behavior when verifying signatures that will be provided by the other participants.

  2. Scenario SCOK2. This scenario is formed by the second root CA RootCAOK2 and a Time Stamp Authority (TSA3) certified by RootCAOK2, which issues correct time-stamp tokens. This scenario allows that signatures generated following the specifications of certain test cases, incorporate time-stamp tokens coming from two correct and different TSAs (namely TSA1 certified by RootCAOK, and TSA3 certified by RootCAOK2). This has impact on the contents of XAdES properties carrying validation material of time-stamp tokens.

  3. Scenario SCUN. This scenario will include the following services:

    1. RootCAOK, LevelACAOK, and LevelBCAOK.

    2. A CA, issuing certificates to end entities, whose certificate shall be revoked by the time the plugtest will start (LevelBCARev, certified by LevelACAOK).

    3. A Time Stamp Authority, certified by LevelBCARev(TSA2).

    4. A Time Stamp Authority, certified by RootCAOK, whose certificate shall be revoked by the time the plugtest will start (TSA_Rev).

    5. A Time Stamp Authority, certified by RootCAOK, whose certificate shall be expired by the time the plugtest will start (TSA_Exp).

    Participants will use its cryptographic material for verifying signatures pre-generated by ETSI corresponding to the only-verification test cases. Furthermore, in this scenario there are the certificates managed during the verification of the signature, including:

    1. One pre-generated signing certificate, issued by LevelBCAOK, which by the time the plugtest will start will be revoked.

    2. One pre-generated signing certificate, issued by LevelBCAOK, which by the time the plugtest will start will be expired.

      3. CAs within this scenario issuing the certificates will issue the CRLs including references to the revoked certificate. CAs within this scenario will also generate OCSP responses reporting on the status of these certificates whenever it is requested by the participants. ETSI will pre-generate one XAdES signature using the revoked certificate and another one using the expired certificate. This scenario is intended to check implementations behavior when verifying not valid signatures.