19 March 2014

Editor:

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

Contents

  1. Introduction

  2. Conducting generation of ASiC containers

  3. Conducting verification of ASiC containers

1. Introduction

The present document provides details on how to operate for conducting the generation and cross-verification interoperability tests.

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

2. Conducting generation of ASiC containers

The current section provides details on how the participants must proceed for generating ASiC containers as specified in the generation and cross-verification interoperability tests.

Once the participants have extracted all the information present in the package in their computers, they may opt for generating ASiC containers aligned with the specifications of the testcase document.

These ASiC containers MUST be placed in the right folder with the right name.

Below follow the rules for choosing the right folder:

  1. Check the ASiC Form, what it wants to be tested, and whether the container must have signatures or/and time-stamp tokens: this will provide the first part of the upper level folder name.

  2. Check the Scenario whose cryptographic material the participant has used: this will provide the second part of the upper level folder name. Example: if a participant has generated an ASiC-S container, with some XAdES signatures inside, but not time-stamp andusing the cryptographic material of scenario SCOK, then the first level folder is ASiC-S_CSSC_X.SCOK

  3. Look within the former folder for a sub-folder whose name is equal to the participant's acronym: that will be the final destination of the generated ASiC container. Example, if the participant that generated the ASiC-S container using the cryptographic material within SCOK scenario had as acronym PARTICIPANT-1, the participant would put the generated ASiC container within the sub-folder PARTICIPANT-1 of the folder ASiC-S_CSSC_X.SCOK, as shown in the figure below.

As for the file name, it MUST follow the following pattern: Container-{TESTDEFINITION_FILE_NAME}.{EXTENSION}, where {TESTDEFINITION_FILE_NAME} stands for file name in TestDefinitions folder that specifies the actual test case. If the former participant PARTICIPANT-1 has generated the ASiC container corresponding to the test case specified in the ASiC-S_CSSC_X-1.xml file within TestDefinitions folder, then the part corresponding to the file name (without extension) would be Container-ASiC-S_CSSC_X.

As for {EXTENSION}, ETSI TS 102 918 RECOMMENDS that ASiC-S containers have the extension ".asics" (or ".scsW in operating systems and/or filesystems not allowing more than 3 characters file extensions). Additionally it also RECOMMENDS that ASiC-E containers have the extension ".asice" (or ".sce" in operating systems and/or filesystems not allowing more than 3 characters file extensions). In consequence the complete file name in the former example would be: Container-ASiC-S_CSSC_X.asics.

The figure below how participant PARTICIPANT-1 generates the ASiC container correponding to test case code ASiC-S_CSSC_X-1: an ASIC-S container, generated with cryptographic material in scenario SCOK, which is stored in Container-ASiC-S_CSSC_X.asics file within folder ASiC-S_CSSC_X.SCOK/PARTICIPANT-1.

A plain text description of the test cases may be found in the test case documents for ASiC containers; a XML encoded descrption of the same test case may be found in the ASiC-S_CSSC_X-1.xml file within TestDefinitions folder. PARTICIPANT-1 then generates the ASiC-S container and stores it in the file ASiC-S_CSSC_X.SCOK/PARTICIPANT-1/Container-ASiC-S_CSSC_X-1.asics (steps 1 to 4). It also shows how the participant MUST proceed for uploading these ASiC containers to the portal for allowing the rest of participants to verify them (steps 5 to 6).

NOTE: Participants tools do not need to be able to process the contents of the files within TestDefinitions folder, but the names of these files represent the test cases codes, which contribute in building the names of the files where the generatedd ASiC containers MUST be stored.

The figure below shows a participant generating ASiC containers and uploading them to the portal.

Participants are kindly requested to stick to these rules: the portal incorporates mechanisms that explore these folders and generate certain web pages briefing the current status of the interoperability plugtest on the fly.

Once the participants have generated their ASiC containers, they may proceed to upload their results to the portal. For doing that the participant MUST:

  1. Generate a zip file containing the newly generated ASiC containers. The structure of the zip file MUST be the same as in the initial package for ASiC containers, i.e. it must contain ASIC-* directories. For the correct structure, please refer to the orientation presentation and to the figure above, where the blue rectangle shows what folders must be zipped and uploaded.

  2. Upload it to the plugtest using the ASiC containers upload page.

Participants may upload these packages at any time using the upload page. Participants may repeteadly upload these packages througouth the plugtest event. The portal will ensure consistency of the uploaded material.

The rest of participants may, after that, download these packages and proceed to verify these ASiC containers for checking interoperability of their tools.

3. Conducting verification of ASiC containers

The present document provides details on how the participants must proceed when they verify ASiC containers generated by other participants (or ETSI), in order to report to the rest of the participants about the verification result.

The portal will keep an up-to-date package (the download package henceforth) containing all the generated ASiC containrs and verification reports uploaded by all the participants ready for download at the download pages for XAdES containers.

Participants may download the latest version of the download package at any time.

Participants may then proceed to verify the ASiC containers present in that package and generate the corresponding reports for these verifications.

Below follows the rules for generating such reports

  1. Each participant will generate a report file for each verified ASiC container.

  2. The report file will be a xml file with the following minimum contents:

    <Verified></Verified>

    if the result of the verification of the ASiC container is "verified"

    <Failed></Failed>

    if the result of the verification of the ASiC container is NOT "verified"

    During past plugtests on XAdES, it was agreed to also allow for a VerifiedWithWarning result that may be mapped to Verified for the final reports. The portal can handle the following values, but please stick to use Verified and Failed whenever possible. 
    <Verified />                -> lime
<VerifiedWithWarning />     -> green
<Failed />                  -> red
<Incomplete />              -> gray
<NotApplicable />           -> yellow
    Further it was suggeted to include the following elements as the first two children of the document element to allow for better consistency checks between verification report and ASiC container. 
    <VerifiedAt>2011-12-07T17:00:00Z</VerifiedAt>
  according to http://www.w3.org/TR/xmlschema-2/#dateTime
<Hash>01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F:10:11:12:13:14</Hash>
  with SHA-1 of the raw document with hex encoding and : as separator

  3. Participants may add any further contents to this file as long as the resulting file is a well formed xml file.

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

    1. Verification report and verified ASiC container have the same upper level folder.

    2. The sub-folder within the former upper level folder aforementioned will be the one whose name matches the acronym assigned to the participant that has verified the ASiC container.

      Example: participant PARTICIPANT-2 has verified the ASiC container stored in file ASiC-S_CSSC_X.SCOK/PARTICIPANT-1/Container-ASiC-S_CSSC_X-1.asics. The destination folder of the report that PARTICIPANT-2 has to generate is the folder ASiC-S_CSSC_X.SCOK/PARTICIPANT-2.

  5. The verification report file name will be Verification_of_[PARTICIPANT]_[ASiC-CODE].xml where [PARTICIPANT] stands for the acronym of the participant that generated the ASiC container whose verification is reported and [ASiCE-CODE] stands for the name of the file that contains the ASiC container that has been verified.

    Example: in the former case, where participant PARTICIPANT-2 has verified ASiC container stored in file ASiC-S_CSSC_X.SCOK/PARTICIPANT-1/Container-ASiC-S_CSSC_X-1.asics, the file name for the verification report would be Verification_of_PARTICIPANT-1_Container-ASiC-S_CSSC_X-1.xml and this file would be stored in the folder ASiC-S_CSSC_X.SCOK/PARTICIPANT-2 as mentioned before.

  6. These rules also apply to the verification reports on ASiC containers corresponding to only-verification test cases. The names of these verification reports will have the following structure: Verification_of_ETSI_[ASiC-CODE].xml, and the folder where they have to be placed is selected following the same rules as in the generation and cross-verification test cases.

The figure below shows how PARTICIPANT-2 takes the ASiC container generated by PARTICIPANT-1 stored in the file ASiC-S_CSSC_X.SCOK/PARTICIPANT-1/Container-ASiC-S_CSSC_X-1.asics, verifies it, generates the verification report and stores it in the file ASiC-S_CSSC_X.SCOK/PARTICIPANT-2/Verification_of_PARTICIPANT-1_Container-ASiC-S_CSSC_X-1.xml (steps 1 to 3). Steps 4 to 5 show how PARTICIPANT-2 generates a zip file with these reports and proceeds to upload it to the plugtest portal.

After the verification participants may upload their verification reports in the same way as they upload their ASiC containers, namely generating a zip whose content is shown in the figure above with the blue rectangle (for the correct structure, please refer to the orientation presentation) and using the ASiC upload page.

Participants may at any time proceed to download the package for getting new ASiC containers of the rest of the participants, to verify them and to upload the corresponding verification reports.