October 2019

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


Contents

  1. Introduction

  2. Conducting generation of AdES signatures/ASiC containers

  3. Conducting validation of AdES signatures/ASiC containers and generating validation reports

    3.1 Rules for conducting validation

    3.2 Validation report formats

      3.2.1 Validation report conformant to ETSI Draft TS 119 102-2 v1.2.2

      3.2.2 Ad-hoc validation report format

  4. Proposed naming conventions for new AdES signatures/ASiC containers



1. Introduction

The present document provides details on how to operate for conducting the positive interoperability tests.

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

2. Conducting generation of AdES signatures/ASiC containers

The current section provides details on how the participants must proceed for generating AdES signatures/ASiC containers. Essentially, participants should:

  1. Extract all the information present in the downloaded package in their computers.

  2. Generate the AdES signatures/ASiC containers that they consider worth to generate. For new AdES signatures/ASiC containers, it is recommended that participants try to follow the naming convention specified in 4. Proposed naming conventions for new AdES signatures/ASiC containers section, at the end of this document.

  3. Upload the generated file to the portal using the Upload new signature page available at the portal.

Once a participant will have uploaded an AdES signature/ASiC container though, and regardless the name that the participant has given to the file, the portal will change the name of the file to something like: "Signature-[Y]-[PARTICIPANT]-1.xml", where [PARTICIPANT] is the acronym of the participant, and the [Y] shall be:

The reason for doing this is that a part of the AdES signatures/ASiC containers to be managed in the plugtest have been delivered by participants without following any naming convention, and the tools deployed in the portal for updating the interoperability matrixes work on well-established file names patterns. The portal though, will provide the mapping between the original names given by the participants and the names assigned by the portal, so that participants may at any time check this mapping.

The figure below shows how participant AT_ID2 generates a XAdES signature purportedly valid and conformant to XAdES Baseline Profile B-conformance level, which happens to be the first one. Following the naming conventions recommended in 4. Proposed naming conventions for new AdES signatures/ASiC containers section, participant AT_ID2 decides to give the name "AT_ID2-X-B-B-V-1.xml" name to the generated file:

The figure clearly shows that participant AT_ID2 has generated and uploaded the file named "AT_ID2-X-B-B-V-1.xml". It also shows that the portal gives to this file the new name "Signature-X-AT_ID2-8.xml". Finally, it also shows that the portal keeps record of the mapping between names "AT_ID2-X-B-B-V-1.xml" and "Signature-X-AT_ID2-8.xml", placed within the folder ESIG-X/AT_ID2, so that participant AT_ID2 is aware that file "Signature-X-AT_ID2-8.xml" contains the signature that the participant placed in file "AT_ID2-X-B-B-V-1.xml".

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

Warning: each time an AdES signature/ASiC container is reloaded, the portal will delete all the validation reports on the signature/container.

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



3. Conducting validation of AdES signatures/ASiC containers and generating validation reports

3.1 Rules for conducting validation

The present section provides details on how the participants must proceed when they validate the AdES signatures/ASiC containers generated by other participants, in order to report to the rest of the participants about the validation result.

The portal will keep up-to-date the download package containing all the generated AdES signatures, ASiC containers, and verification reports uploaded by all the participants ready for download at the download page.

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

Participants may then proceed to validate any AdES signatures/ASiC containers present in that package, generate the corresponding validation reports, include the validation reports in their folders, zip them, and upload the zip file using the mechanisms in Upload Verification page.

The validation reports shall be named and placed in their corresponding folders following the rules indicated below:

  1. Rules for selecting the folder where each verification report MUST be placed:

    1. The sub-folder of the validation report and the sub-folder of the validated AdES signature/ASiC container shall have the same parent folder.

    2. The validation report shall be placed in the sub-folder (of the aforementioned parent folder) owned by the participant that has generated it.

    Example: participant CY-ID1 has validated a XAdES signature stored in folder "ESIG-X/AT_ID2/". Participant CY-ID1 will then include the corresponding validation report in folder: "ESIG-X/CY-ID1/"

  2. Naming the validation report file: the validation report file name will be Verification_of_[GENERATOR-PARTICIPANT]_[SIGNATURE-CONTAINER-NAME].xml where [GENERATOR-PARTICIPANT] stands for the acronym of the participant that generated the AdES signature/ASiC package whose validation is reported and [SIGNATURE-CONTAINER-NAME] stands for the name of the file that contains the AdES signature/ASiC packag that has been validated.

    Example: in the former case, where participant CY-ID1 has validated a XAdES signature stored in file "ESIG-X/AT_ID2/Signature-X-AT_ID2-8.xml", the file name for the verification report would be Verification_of_AT_ID2_Signature-X-AT_ID2-8.xml and this file would be stored in the folder "ESIG-X/CY-ID1/" as explained above.

The figure below shows precisely how participant CY-ID1 takes the XAdES signature whose generation by AT_ID2 has been shown in the figure above (that the portal has stored in the file "ESIG-X/AT_ID2/Signature-X-AT_ID2-8.xml") (step 1), validates it (step 2), generates the validation report and stores it in the file ESIG-X/CY-ID1/Verification_of_AT_ID2_Signature-X-AT_ID2-8.xml" (step 3). Steps 4 to 5 show how participant CY-ID1 generates a zip file with all the validation reports generated and proceeds to upload it to the plugtest portal.

After the validation, participants may upload their validation reports in the same way as they upload their AdES signatures/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 Upload Verification page.

WARNING: the portal will ignore any signature and/or ASiC container present in the zipped folders structure when uploaded using the the Upload Verification page, i.e., these signatures and/or ASiC containers will not be added to the download package. Participants are strongly recommended not to include any signature or ASiC container in the zip container of validation reports.

Participants may at any time proceed to download the package for getting new AdES signatures/ASiC containers of the rest of the participants, to validate them and to upload the corresponding validation reports.

3.2 Validation report formats

The following formats for validation reports are admitted by the portal at this plugtest event:

  1. A validation report conformant to ETSI Draft TS 119 102-2 v1.2.2: Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report.

  2. An ad-hoc validation report as the one used in former plug tests.
3.2.1 Validation report conformant to ETSI Draft TS 119 102-2 v1.2.2

Those participants able to generate validation reports conformant to ETSI Draft TS 119 102-2 v1.2.2: Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report are kindly asked to upload them to the plugtest portal.

The portal shall process the value of the ValidationReport/SignatureValidationReport/SignatureValidationStatus/MainIndication element and shall present the information as follows:

Below follows the color codes for the different results corresponding to this format:

"urn:etsi:019102:mainindication:total-passed"   -> lime


"urn:etsi:019102:mainindication:total-failed"   -> red


"urn:etsi:019102:mainindication:indeterminate"  -> yellow
3.2.2 Ad-hoc validation report format

Those participants that are not able to generate validation reports conformant to ETSI Draft TS 119 102-2 v1.2.2: Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report are kindly asked to generate reports matching the following rules for an ad-hoc format already used in previous plugtests:

  1. The validation report shall be a XML document.

  2. Its root element shall be one of the following elements:

  3. The reports should contain the following two children (please note that this is not mandatory, but convenient):

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

The validation report results page provides a detailed list of possible sub-indications for VALID, INVALID, INDETERMINATE, ERROR, and REUPLOAD results, as well as their semantics.

Below follows the color codes for the different results corresponding to this ad-hoc format:

<VALID />                -> lime


<INVALID />                  -> red


<ERROR />              -> gray


<INDETERMINATE />           -> yellow

4. Naming conventions for new AdES signatures/ASiC containers

This section provides details of the proposal for naming the files containing the AdES signatures/ASic containers generated by participants during this plugtest. Its contents are the same as the contents of Annex I of the document circulated to the EUMS before the start of the start of the plugtes.

The names of the files containing the signatures or ASiC containers should be created chaining the following strings:

  1. 2 characters defining the iso country code of the Member State followed by an underscore character ‘_’

  2. The acronym of the participant followed by a hyphen character ‘-’

  3. A sequence of characters [XXX] indicating the type of signature or the container followed by a hyphen character ‘-’. The sequence of characters should be selected as indicated afterwards in this section.

  4. The optional string "EN-" indicating that the signature/container is compliant against one of the ETSI ENs that specifies the signature/container formats (ETSI EN 319 122, ETSI EN 319 132, ETSI EN 319 142, and ETSI EN 319 162). Absence of this string indicates that the signature/container is compliant with the ETSI TS that specifies the signature/container formats (ETSI TS 103 171, ETSI TS 103 172, ETSI TS 103 173, and ETSI TS 103 174)

  5. The "B" character, indicating "Baseline signature/container", followed by a hyphen character ‘-’

  6. a string defining the Baseline level to which the signature/container is claiming conformance. This value will take one of the following values:

  7. A hyphen character ‘-’

  8. A character defining the validity of the signing certificate whose value can be one the following:

  9. A hyphen character ‘-’

  10. An increasing number, starting from 1, numbering different signatures/containers generated for every Baseline level

  11. A sequence of characters [YYY], which will depend of the type of signature / container generated.


The sequence of characters [XXX] shall be:

  1. the character ‘C’ for files containing CAdES signatures

  2. the character ‘P’ for files containing PAdES signatures

  3. the character ‘X’ for files containing XAdES signatures

  4. A sequence of three characters for ASiC containers, as indicated below:


The sequence of characters [YYY] shall be one of the sequences indicated below:

  1. ".p7m" for files containing attached CAdES signatures.

  2. ".p7m.zip" for files containing one detached CAdES signature. In this case the zip file shall contain the detached CAdES signature and the file whose content is the data object signed by the aforementioned CAdES signature.

  3. ".pdf" for files containing PAdES signatures.

  4. "xml" for files containing XAdES signatures.

  5. ".xml.zip" for files containing one detached XAdES signature. In this case the zip file shall contain the detached XAdES signature and one or more additional files. Each file shall contain one of the detached signed data objects. For each of these files, the XAdES signature shall contain a ds:Reference element whose URI attribute shall have as value the local name of the file.

  6. ".asics" for files containing simple ASiC containers.

  7. ".asice" for files containing extended ASiC containers.


Some examples are shown below:

  1. The name "IT_P1-C-B-B-V-1.p7m" would identify the first CAdES signature; this signature claims conformance to B-B level as specified in ETSI TS 103 173, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  2. The name "IT_P1-C-EN-B-B-V-2.p7m" would identify the second CAdES signature; this signature claims conformance to B-B level as specified in ETSI EN 319 122, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  3. The name "IT_P1-P-B-B-V-1.pdf" would identify the first PAdES signature; it claims conformance to B-B level as specified in ETSI TS 103 172, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  4. The name "IT_P1-P-EN-B-B-V-2.pdf" would identify the second PAdES signature; it claims conformance to B-B level as specified in ETSI EN 319 142, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  5. The name "IT_P1-X-B-B-V-1.xml" would identify the first XAdES signature; it claims conformance to B-B level as specified in ETSI TS 103 171, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  6. The name "IT_P1-X-EN-B-B-V-2.xml" would identify the second XAdES signature; it claims conformance to B-B level as specified in ETSI 319 132, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  7. The name "IT_P1-ASC-B-B-V-1.asics" would identify the first ASiC simple container with CAdES signature; this container claims conformance to B-B level as specified in ETSI TS 103 174, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  8. The name "IT_P1-AEX-B-B-V-2.asice" would identify the second ASiC extended container with XAdES signatures; this container claims conformance to B-B level as specified in ETSI TS 103 174, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.

  9. The name "IT_P1-AEX-EN-B-B-V-3.asice" would identify the third ASiC extended container with XAdES signatures; this container claims conformance to B-B level as specified in ETSI EN 319 162 part 1, and has been generated by the Italian participant whose acronym is P1, using a valid signing certificate.