Contents

  1. Introduction

  2. Conducting generation of original signatures

  3. Conducting signatures upgrade

  4. Conducting signatures arbitration: verifying upgraded signatures

  5. Generation, upgrade and arbitration for XAdES v141 and CAdES v181

1. Introduction

The present document provides details on how to operate for conducting the signature upgrade and arbitration interoperability tests.

The figure below shows the interactions of three participans for conducting this kind of tests:

2. Conducting generation of original signatures

First of all, PARTICIPANT-A will generate a signature according to a certain test case. The way that this participant has to conduct such a generation is documented in conducting plugtests: cross-verification tests; generating signatures.

3. Conducting signatures upgrade

The current section provides details on how PARTICIPANT-B should operate for upgrading the original signature generated by PARTICIPANT-A and upload it to the Plugtest portal.

The figure below shows how PARTICIPANT-B takes the original signature generated by PARTICIPANT-A stored in the file XAdES-BES.SCOK/PARTICIPANT-A/Signature-X-BES-1.xml and how PARTICIPANT-B upgrades it to a more complex form (XAdES-A according to test case XAdES-A-1) and stores it in the file XAdES-A.SCOK/ PARTICIPANT-B/Signature-X-A-1~X-BES-1+PARTICIPANT-A.xml (steps 1 to 3). Steps 4 to 5 show how PARTICIPANT-B generates a zip file with this signature and proceeds to upload it to the plugtest portal

For CAdES interoperability tests participants, the structure of the folders would be the same as the one shown in the figure, but folder names would start with "CAdES" instead "XAdES" and file names would include "C" instead "X". Now, for CAdES interoperability test, PARTICIPANT-B takes the signature generated by PARTICIPANT-A stored in the file CAdES-BES.SCOK/PARTICIPANT-A/Signature-C-BES-1.xml, upgrades it and stores the upgraded in the file CAdES-A.SCOK/ PARTICIPANT-B/Signature-C-A-1~C-BES-1+PARTICIPANT-A.p7 (steps 1 to 3).

Below follows the rules for managing the upgraded signatures.

  1. Each participant will generate a new file for each upgraded signature. The contents of this file will be the upgraded signature.

  2. Below follow the rules for selecting the folder where each upgraded signature MUST be placed:

    1. The first level of the destination folder is identified by the form of the upgraded signature. In the case of the previous figure, the upgraded signature is a XAdES-A, and in consequence the first level of the destination folder will be XAdES-A.SCOK.

    2. The second level of the destination folder will be the folder corresponding to the participant that has generated the upgraded the signature. In the case of the previous figure, as PARTICIPANT-B has generated the upgraded signature, the second level of the destination folder is PARTICIPANT-B.

      Example: participant PARTICIPANT-B has generated a XAdES-A upgraded signature. The destination folder for such signature isXAdES-A.SCOK/PARTICIPANT-B.

  3. The upgraded signature file name will be Signature-[UPGRADED-SIGNATURE-CODE]~[ORIGINAL-SIGNATURE-CODE]+[GENERATOR-PARTICIPANT].xml where :

    1. [UPGRADED-SIGNATURE-CODE] stands for the code of the test case file that specifies the contents of the resulting upgraded signature (X-A-1 in the example of the figure, as the upgraded signature has to be built according to what is specified in test case file X-A-1.xml).

    2. ~ indicates that the signature is an upgraded signature of some other signature.

    3. [ORIGINAL-SIGNATURE-CODE] stands for the code of the test case file that specifies the contents of the original signature (X-BES-1 in the example of the figure, as the original signature has to be built according to what is specified in test case file X-BES-1.xml).

    4. [GENERATOR-PARTICIPANT] stands for the code of the participant that has generated the original signature (PARTICIPANT-A in the example of the figure above.

    Example: in the former case, where participant PARTICIPANT-B has upgraded the signature present in file {X,C}AdES-BES.SCOK/PARTICIPANT-A/Signature-{X,C}-BES-1.xml, the file name for the upgraded signature would be Signature-{X,C}-A-1~{X,C}-BES-1+PARTICIPANT-A.xml and this file would be stored in the folder {X,C}AdES-A.SCOK/PARTICIPANT-B as mentioned before.

4. Conducting signatures arbitration: verifying upgraded signatures

This section provides details on how PARTICIPANT-C should conduct for acting as an arbitrator for the signature upgrade and arbitration.

The figure below shows how PARTICIPANT-C takes the upgraded signature as generated by PARTICIPANT-B stored in the file XAdES-A.SCOK/PARTICIPANT-B/Signature-X-A-1~X-BES-1+PARTICIPANT-A.xml and how PARTICIPANT-C verifies it, generates a verification report and stores it in the file XAdES-A.SCOK/ PARTICIPANT-C/Verification_of_PARTICIPANT-B_Signature-X-A-1~X-BES-1+PARTICIPANT-A.xml (steps 1 to 3). Steps 4 to 5 show how PARTICIPANT-C generates a zip file with this report and proceeds to upload it to the plugtest portal

For CAdES interoperability tests participants, the structure of the folders would be the same as the one shown in the figure, but folder names would start with "CAdES" instead "XAdES" and file names would include "C" instead "X". Now, for CAdES interoperability test, PARTICIPANT-C takes the upgraded signature generated by PARTICIPANT-B stored in the file CAdES-BES.SCOK/PARTICIPANT-B/Signature-C-A-1~C-BES-1+PARTICIPANT-A.xml, verifies it and stores the verification report in the file CAdES-A.SCOK/ PARTICIPANT-C/Verification_of_PARTICIPANT-B_Signature-C-A-1~C-BES-1+PARTICIPANT-A.xml (steps 1 to 3).

Below follows the rules for managing the upgraded signatures verification reports.

  1. Each participant will generate one verification report for each upgraded signature.

  2. Below follow the rules for selecting the folder where the verification report MUST be placed:

    1. The first level of the destination folder is identified by the form of the upgraded signature. In the case of the previous figure, the upgraded signature is a XAdES-A, and in consequence the first level of the destination folder will be XAdES-A.SCOK.

    2. The second level of the destination folder will be the folder corresponding to the participant that has generated the verification report. In the case of the previous figure, as PARTICIPANT-C has generated the verification report, the second level of the destination folder is PARTICIPANT-B.

      Example: participant PARTICIPANT-C has generated the verification report of the upgraded signature. The destination folder for such signature isXAdES-A.SCOK/PARTICIPANT-C.

  3. The verification report file name will be Verification_of_[UPGRADE-PARTICIPANT]_Signature-[UPGRADED-SIGNATURE-CODE]~[ORIGINAL-SIGNATURE-CODE]+[GENERATOR-PARTICIPANT].xml where:

    1. Verification_of_ indicates that the file contains a verification report.

    2. [UPGRADE-PARTICIPANT] indicates the participant that has generated the signature that has been verified (in this case the participant that has generated the upgraded signature: PARTICIPANT-B).

    3. [UPGRADED-SIGNATURE-CODE]~[ORIGINAL-SIGNATURE-CODE]+[GENERATOR-PARTICIPANT].xml is the notation for upgraded signatures as explained in the previous section.

    Example: in the former case, where participant PARTICIPANT-C has verified the signature upgraded by PARTICIPANT-B, the verification report would be stored in file Verification_of_PARTICIPANT-B_Signature-X-A-1~X-BES-1+PARTICIPANT-A.xml and this file would be stored in the folder XAdES-A.SCOK/PARTICIPANT-C as mentioned before.

5. Generation, upgrade and arbitration for XAdES v141 and CAdES v181

Upgrade and arbitration test cases managing XAdES v141 or CAdES v181 will be conducted in a similar way as for XAdES v132 and CAdES 174. The only consideration that has to be made is that the codes of the signatures will now become:

  1. X141-... instead X- for XAdES v141.

  2. C181-... instead C- for CAdES v181.

Examples:
  1. For XAdES:
    1. PARTICIPANT-A generates a XAdES v141 original signature according to test case X141-BES-1.xml. The signature is stored in file Signature-X141-BES-1.xml and the file is stored in folder XAdES-BES.SCOK/PARTICIPANT-A.

    2. PARTICIPANT-B takes the XAdES v141 original signature, verifies it and upgrades it to a signature that is specified in test case X141-A-1.xml. The resulting upgraded signature is stored in file Signature-X141-A-1~X141-BES-1+PARTICIPANT-A.xml and the file is stored in folder XAdES- A.SCOK/PARTICIPANT-B.

    3. PARTICIPANT-C verifies the resulting upgraded signature. The verification report is stored in file Verification_of_PARTICIPANT- B_Signature-X141-A-1~X141-BES-1+PARTICIPANT-A.xml and the file is stored in folder XAdES-A.SCOK/PARTICIPANT-C.

  2. For CAdES:

    3. As mentioned in the generation and cross-verification tests page, so far three test cases for CAdES v181 have been identified, which were already specified for the last plugtest (CAdES-A-7, CAdES-A-8 and CAdES-A-9) and as they were already used in past CAdES plugtest, no new test cases identifiers have been defined for them. Should new specific test cases for CAdES v1.8.1 were generated during the plugtest, then the rules for the files naming would be as indicated below:

    1. PARTICIPANT-A generates a CAdES v181 original signature according to test case C181-BES-1.xml. The signature is stored in file Signature-C181-BES-1.xml and the file is stored in folder CAdES-BES.SCOK/PARTICIPANT-A.

    2. PARTICIPANT-B takes the CAdES v181 original signature, verifies it and upgrades it to a signature that is specified in test case C181-A-1.xml. The resulting upgraded signature is stored in file Signature-C181-A-1~C181-BES-1+PARTICIPANT-A.xml and the file is stored in folder CAdES-A.SCOK/PARTICIPANT-B.

    3. PARTICIPANT-C verifies the resulting upgraded signature. The verification report is stored in file Verification_of_PARTICIPANT-B_Signature-C181-A-1~C181-BES-1+PARTICIPANT-A.xml and the file is stored in folder CAdES-A.SCOK/PARTICIPANT-C.