Submitted to the EC on 03/06/2012. COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ICT Policy Support Programme (ICT PSP) e-codex

Transcription

1 Submitted to the EC on 03/06/2012 COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ICT Policy Support Programme (ICT PSP) e-codex e-justice Communication via Online Data Exchange ICT PSP call identifier: CIP-ICT-PSP ICT PSP main Theme identifier: CIP ICT PSP : E-JUSTICE SERVICES Project full title: e-justice Communication via Online Data Exchange Grant agreement n : D 4.2: Concept for Implementation of WP4 Deliverable Id : D 4.2 Deliverable Name : Concept for Implementation of WP4 Status : V 1.0 Dissemination Level : PU Due date of deliverable : Actual submission date : Work Package : WP4 Organisation name of lead partner for this deliverable : Ministry of Justice, Estonia Adrian Klar Rudi Teschner Author(s): Viljar Tina Cyril Murie Lesli Hommik Partner(s) contributing : DE, EE, FR, WP1, WP4, WP5, WP7 Abstract: As part of the e-codex project, this deliverable provides the concept for implementation of WP4. The aim is to provide a description of modules and building blocks to be realised, descriptions of detailed processes and requirements and the mapping of the processes to the functionalities of the solution. This deliverable will be a basis for developing the necessary modules and building blocks in WP4 for e-codex.

2 History Version Date Changes made Modified by First Draft Second draft, comments on the first draft analysed and changes made accordingly Final changes made. Deliverable finalised. Adrian Klar Rudi Teschner Viljar Tina Cyril Murie Adrian Klar Rudi Teschner Viljar Tina Lesli Hommik Adrian Klar Rudi Teschner Viljar Tina 1

3 Table of Contents HISTORY... 1 TABLE OF CONTENTS... 2 LIST OF FIGURES... 5 LIST OF TABLES... 6 LIST OF ABBREVIATIONS AND ACRONYMS... 7 EXECUTIVE SUMMARY INTRODUCTION SCOPE AND OBJECTIVE OF DELIVERABLE WP4 GENERAL OBJECTIVES AND VISION METHODOLOGY OF WORK RELATIONS TO INTERNAL E-CODEX ENVIRONMENT RELATIONS TO EXTERNAL E-CODEX ENVIRONMENT QUALITY MANAGEMENT RISK MANAGEMENT STRUCTURE OF THE DOCUMENT TECHNICAL ENVIRONMENT ARCHITECTURE E-CODEX SERVICE PROVIDER CONNECTOR E-CODEX GATEWAY KEY COMPONENTS TRUST OK-TOKEN ASIC-S CONTAINER DIGITAL SIGNATURE SERVICES SIGNATURE CERTIFICATE FUNCTIONALITIES CONNECTOR GENERAL DESCRIPTION CONNECTOR (OUTGOING) CONNECTOR (INCOMING)

4 3.2 RECIPIENT MANUAL REVALIDATION PROCESSES AND TASKS SUBMISSION OF DOCUMENTS (OPTIONAL) SIGNATURE REVALIDATION SIGNATURE VERIFICATION PRECONDITIONS PROCESS FLOW: SIGNATURE VERIFICATION POST CONDITIONS CREATE THE TRUST OK -TOKEN (PDF & XML) PRECONDITIONS DATA FLOW: CREATION OF THE TRUST OK -TOKEN POST CONDITIONS CREATE CONTENT ARCHIVE PRECONDITIONS DATA FLOW: CREATION OF A CONTENT ARCHIVE PREDEFINED PROCESS: ADD FILE(S) TO ZIP ARCHIVE POST CONDITIONS CREATE AND SIGN AN ASIC-S SIGNATURE CONTAINER PRECONDITIONS DATA FLOW: CREATION OF ASIC-S SIGNATURE CONTAINER POST CONDITIONS CREATE VALIDATION REPORT DESCRIPTION OF MODULES AND BUILDING BLOCKS TO BE REALISED JAVA LIBRARY FOR USAGE WITHIN THE CONNECTOR REQUIREMENTS PACKAGING PUBLIC CLASSES CONFIGURATION SIGNATURE VERIFICATION VERIFICATION AT SENDING SERVICE PROVIDER VERIFICATION AT RECEIVING SERVICE PROVIDER CROSS-BORDER VERIFICATION

5 5.3 SIGNATURE CREATION ON BUSINESS DOCUMENTS SIGNATURE CREATION ON TRUST OK -TOKEN SIGNATURE ON THE PDF VERSION SIGNATURE ON THE XML VERSION VALIDATION REPORT TRUST OK -TOKEN CONTENT STRUCTURE LINK TO THE VALIDATED DOCUMENTS TRANSMISSION OF THE TOKEN I. REFERENCES A. APPENDIX: VALIDATION REPORT STRUCTURE INTRODUCTION USED TYPE VALIDATION REPORT TIME INFORMATION SIGNATURE INFORMATION B. APPENDIX: RESULTS OF THE COMPARISON OF DSS AND PEPPOL

6 List of Figures Figure 1: E-CODEX Architecture Figure 2: ASiC Container Structure Figure 3: Submission of business documents - Sending side Figure 4: Submission of business documents Receiving side Figure 5: Signature Revalidation Figure 6: Basic View on Signature Verification Figure 7: Check Signature Figure 8: Closer view on "Signature Integrity Analysis" Figure 9: Closer view on "Certificate Integrity Analysis" Figure 10: Closer view on "Certificate Authority Analysis" Figure 11: Closer view on Certificate Status Analysis Figure 12: Creation of a Trust Ok -Token Figure 13: Creation of a Content Archive Figure 14: Closer view on the process Add file(s) to ZIP archive Figure 15: Basic Process of ASiC-S signature container creation Figure 16: Closer view on Valid Archive? Figure 17: Closer view on Create signature container Figure 18: Closer view on Create XAdES Signature Figure 19: Closer View on "Create Validation Report Figure 20: Exemplary "Trust OK"-Token Figure 21: Example for ASiC-S structure applied to a nested container file Figure 22: Example for a valid signature container Figure 23: Signature container within the e-codex transport infrastructure

7 List of Tables Table 1: Quality Checklist Table 2: Risks Table 3: Basic View on a XAdES Signature Table 4: Detailed View on the Element "ds:signedinfo" Table 5: Specification of the content archive Table 6: Comparison of DSS and PEPPOL functionality

8 List of Abbreviations and Acronyms Acronym API CA Explanation Application Programming Interface Certification Authority CAdES CMS Advanced Electronic Signatures, published by ETSI as TS CMS CRL DES DG Driver DSS ebms ebxml e-codex ecm EPO ETSI GW ICT ID LTV MS MS-CAPI OCSP OS Cryptographic Message Syntax, see CAdES -Description Certificate Revocation List, see RFC Data Encryption Standard Directorate-General Software allowing computer programs to interact with a hardware device Digital Signature Standard ebxml Messaging Services Electronic Business using XML e-justice Communication via Online Data Exchange e-codex Member European Payment Order European Telecommunications Standards Institute Gateway Information and communication technologies Identity Long Time Validity EU Member State Cryptographic Application Programming Interface Online Certificate Status Protocol, see RFC Operating System PAdES PDF Advanced Electronic Signature, published by ETSI as TS PDF Portable Document Format 7

9 PEPPOL PKCS QC SAML 2.0 SHA SP SSCD STORK Time Mark Token Pan-European Public Procurement Online Public-key cryptography standards Qualified Certificate Security Assertion Markup Language v2.0 Authentication request and response format Secure Hash Algorithm (e-codex) Service Provider Secure Signature Creation Device Secure Identity across borders linked Timestamp alternative defined in XAdES specification Device that an authorised user of computer services is given to ease authentication TSL Trust-Service Status List, published by ETSI as TS TSP VRE WP Trusted Service Provider Validation Report Entry Work Package XAdES XML Advanced Electronic Signatures, published by ETSI as TS XML Extensive Markup Language 8

10 Executive Summary Due to higher mobility and progressing European integration, the number of procedures containing cross-border effects increases. This successively requires more cooperation between the different national judicial systems. In that perspective, the goal of e-codex is to improve cross-border access for citizens and businesses to legal means in Europe and the interoperability between legal authorities by using instruments of the ICT. The ambition of e-codex is to create a pan-european interoperability layer by connecting already existing national systems to allow communication and data exchange based on the development of common technical approaches and standards. The project strongly commits itself to adapt and / or adopt the solutions developed by other interoperability projects like PEPPOL, SPOCS, STORK and DG Market s Digital Signature Services Tool. Whereas the overall scope of the project is bigger, WP4 aims to cover all e-identity related topics: e-identity management for natural and legal roles, mandates and rights as well as user authentication and authorisation Verification and Implementation of e-signatures. The present document is the third deliverable written by WP4 and is based on the results of the analysis performed earlier in deliverables D4.1 and D It gives a detailed description of the e- Signature related processes, functionalities and software modules to be realised and provides the concept for implementation of WP4. Beside the detailed description of processes and building blocks this document describes significant key decisions: the usage of DSS, ASiC and the Trust OK -Token. When comparing the e-codex use cases to the functionalities provided by other interoperability projects, the result was that most of the missing building blocks can be covered by DG Market s DSS Tool - a Java based open source software module that can be used to create, extend and validate XAdES, PAdES and CAdES e-signatures. To overcome one of the biggest issues for WP4 that currently not all European citizens are equipped with an electronic signature tool and that advanced electronic signatures are not yet completely interoperable at European level, the concept of the Trust OK -Token is introduced providing validation information in the document carriers. To realise the Trust OK -Token it has been decided that an e-codex Service Provider delivering trusted documents has to be characterised as an advanced electronic system (see section ). The use of an advanced electronic system within e-codex will thus guarantee that a trusted document is linked to one particular user, that it is created using means the use can maintain under his sole control and that it has not been changed. The Trust OK -Token basically is a confirmation document signed by the Connector. Within the Circle of Trust (see section ) it is used to assure the authenticity of the delivered documents. This deliverable will have a great impact on the further work of WP4 since it will be a basis for the development of e-codex e-signature validation solution and the creation of the Trust OK -Token. 9

11 1 Introduction 1.1 Scope and Objective of Deliverable This deliverable provides the concept for implementation of tasks assigned to WP4. The aim is to provide descriptions of modules and building blocks to be realised, descriptions of detailed processes and requirements and mapping the processes to the functionalities of the solution. This deliverable will be a basis for the development of necessary modules and building blocks in WP4 for e-codex. 1.2 WP4 General Objectives and Vision The overall objective of WP4 is to establish a model for the use of a European e-identity framework for data exchange between e-justice applications and to investigate the use of roles, their attribution to identities and how they can be mapped. WP4 analyses what is covered by existing projects, evaluates national solutions and examines the need for signatures in e-justice applications. WP4 will also deal with standards and implementations to ensure the long-term preservation of electronic signatures. The vision of WP4 is to support pilots by investigating and setting up a solution for e-signature verification in e-codex. 1.3 Methodology of Work The deliverable was drafted by the WP4 authors team which consists of IT-architects and lawyers from Estonia, Germany and France. While writing this deliverable, one workshop was held to discuss open issues and to reach agreements on important issues while other WP4 members were consulted via s. Intensive communication and good cooperation between the authors formed the basis for unity within the work package. 1.4 Relations to Internal e-codex Environment This deliverable is an important step towards the creation of a solution for the validation of e- signatures and the creation of a Trust OK -Token as it provides the specifications for development of these solutions. The deliverable D4.1.1 has been a basis for this deliverable. 1.5 Relations to External e-codex Environment In deliverable D4.2, the modules and building blocks have been described in detail and solutions are specified. This deliverable will have a great impact on the further work of WP4 since it will be a basis for development of the e-codex e-signature validation solution and the creation of the Trust OK -Token. These specifications could and possibly will affect the piloting phase by being the main basis for the piloting Member States to also prepare their own signature. The results of the development and integration of the solution are based on this deliverable and could have a huge impact on the success of the piloting phase which also might affect the stakeholders. 10

12 1.6 Quality Management External quality checks have been performed by the External Quality Manager. Internal quality checks have been done by WP1 team as well as the members of WP4 and several other members of e-codex. The following table gives an overview about the quality checks performed on this deliverable. Category Remarks Checked by Conformance to e-codex template Language & Spelling Delivered on time Each technology description contains the correct elements Consistency with description in the TA and in other e-codex deliverables Content is fit for purpose Firstly done by WP4 leader and also checked by WP1 before submission to EC. Remarks from EQM were taken into account and the deliverable was re-checked by WP4 leader before submission. One-month extension for the submission of the deliverable was given to WP4. Checked by IT-architects working on the deliverable. Checked by WP4 leader and WP1. Checked by IT-architects working on the deliverable. WP4 WP1 EQM WP4 EQM WP4 WP1 EC WP4 WP4 WP1 Content is fit for use Checked by IT-architects working on the deliverable. WP4 Commitment within WP Checked by WP4 leader. WP4 Table 1: Quality Checklist WP4 11

13 1.7 Risk Management The following table gives an overview of the main risks of WP4: Description Probability Impact Priority Response Owner The e-signature Directive is subject to changes. We create a solution that is not in accordance with the new e-signature Directive or we remain inactive while waiting for the new e-signature Directive. Ambition to create a universal solution that can be re-used everywhere. The scope will be too wide. Some Member States do not have existing solutions. We have to do additional work and create a central solution for those Member States. National solutions are not in accordance with the standards and regulations and cannot be integrated into the developed solution. We are unable to create a working solution for e-codex. Low High Medium We must participate in the process of creation of the new e-signature Directive and always be informed about the process. We must be active and assist in creating a solution. Medium High High We have to keep in mind that when the solution works with pilots, it may be sufficient. Problems need to be solved one at a time, not all at once. Medium Medium Medium Decisions have been taken that a central solution will not be created. Member States are responsible for creating their own national solutions. In addition solutions in e-justice Portal will be for central use. Medium Medium Medium Member States have to modify their national solutions to be in accordance with given standards and regulations. Medium High High Experts and skilled developers need to be included in the specification and development phase. Table 2: Risks WP4 WP4 WP4 WP4 WP4 12

14 1.8 Structure of the Document The document is structured as follows: 1. Introduction 2. Technical Environment 2.1 Architecture 2.2 Key Components 3. Functionalities 3.1 Connector 3.2 Recipient 4. Processes and Tasks 4.1 Submission of Documents 4.2 Signature Revalidation 4.3 Signature Verification 4.4 Create a Trust Ok -Token (XML and PDF) 4.5 Create a Content Archive 4.6 Create and Sign an ASiC-S Signature Container 4.7 Create Validation Reply 5. Modules and Building Blocks 5.1 Java Library for Usage within the Connector 5.2 Signature Verification 5.3 Signature Creation on Business Documents 5.4 Signature Creation on Trust Ok -Tokens 5.5 Validation Report 5.6 Trust Ok -Token 13

15 2 Technical Environment This chapter gives a general overview about technical parameters that need to be considered as e-codex is intended to operate in an environment that is regulated by the European Commission and affected by European and national law. 2.1 Architecture As stated in the Annex 1 of the Grant Agreement, e-codex is an interoperability layer for electronic exchanges in Europe in the field of Justice and should operate within the context of existing solutions of each ecm (e-codex Member). It should not be a new centralised approach or duplication of any national solution at the European level. Within e-codex and in cooperation between the technical Work Packages it is agreed that the best way to achieve the goals is to use a gateway-based architecture. The function of the gateway is to act as an access point for each national solution to the interoperability layer developed by e-codex. The gateway approach guarantees subsidiarity as it does not overrun the national applications. It converts messages from the national format to a format supported by e-codex and vice versa. Figure 1: E-CODEX Architecture App Server: Identity Provider: Gateway: Business Boundary: Application that needs to exchange data with other members of e-codex Authenticates End Users Interface between MS national or European solution and e-codex Logical group of business specific requirements In detail every member of the e-codex project can have a solution with a different topology but in general there always is an application that implements business logic for its users and exchanges electronic data with another ecm. 14

16 2.1.1 e-codex Service Provider An e-codex Service Provider, under the responsibility of a public authority, provides services to users (citizen, judge, lawyer, notaries) or general services (e.g. find a competent court). An e-codex Service Provider can be either a National Service Provider or a European Service Provider like the e-justice Portal. Two types of e-codex Service Providers exist: The first type can be used by a human being, i.e. by a claimant, a defendant, a representative (i.e. lawyer) or a judicial authority, to create PDF / XML documents and send them or to receive documents. The second type is an automated e-codex Service Provider. It can be used for e-payment, EPO and small claims or to find the competent court. The following example describes the latter case: The e-codex service provider receives a business document containing information from another ecm. With this information, the service provider responds automatically to the business document providing the information about the competent court. As this information has no legal value, there is no need for a Trust-OK -Token Connector Under the responsibility of the respective Ministry of Justice, the DG Justice of the European commission or any other competent national authority, the connector contains the functionalities to: Add a Trust OK -Token to a document generated by an e-codex Service Provider. Transform the XML document from the national standard to the European standard and vice versa. Retrieve the end user address (e.g. by extracting it from the business XML) for the final national routing e-codex Gateway Under the responsibility of the respective Ministry of Justice, the DG Justice of the European Commission or any other competent authority, the gateway has the following functionalities: Communicate: Establish a connection to other gateways and connectors Send: Format the content of a message to the ebms3.0 standard. Receive: Extract the contents of an ebms3.0 message. 15

17 2.2 Key Components Trust OK-Token The idea behind the Trust OK -Token is to provide the possibility for the receiving party (e.g. a judge) to recognize documents filed by using a trustworthy advanced electronic system based on signature or authentication. By using the token in accordance with the Circle of Trust, the receiving party does not need to validate the signature and the certificate itself. Regardless of the signature assessment by the Trust OK -Token, the receiving party still has the right and is granted the means to revalidate the signature independently. The Trust OK -Token is human readable and contains either the result of the signature and certificate validation or information regarding the authentication process of the user Circle of Trust 1 Several identity providers agree upon that, in terms of identification of persons, they will trust information provided by each one of them in the same way that they trust their own information. That means that if one of them declares that he has properly registered a person, the others will trust in this information. The same principle applies to certification authorities in terms of qualified signatures: they trust each other s certification in the same way that they trust their own certification Advanced Electronic System As e-codex Service Provider for the civil use cases, e-codex will only accept an advanced electronic system, an electronic system which meets the following requirements: (a) (b) (c) (d) the created document is uniquely linked to the user; the system is capable of identifying the user; the document is created using means that the user can maintain under his control; any subsequent change of the data of a created document is detectable; According to this definition, the Austrian solution is an advanced electronic system. A system only using an electronic signature shall use at least an advanced electronic signature that is in accordance with the signature directive 2 to meet the requirement to be an advanced electronic system. 1 Description taken from D4.1.1 section

18 2.2.2 ASiC-S Container The important task to preserve the link between the Trust OK -Token and its associated documents and signatures is fulfilled by choosing the ASiC-S container, a data container holding different data objects and associated signatures within a ZIP file. Figure 2: ASiC Container Structure By using this container format: The relation between the token and its files can be preserved. The integrity of the Trust OK -Token can be preserved. Any change of content is detectable. This includes: o Addition of unrelated files. o Removal of existing files. o Modification of existing files. Long-term validity can be achieved by using archival signatures. The container will be generated and signed within the sending country s Connector and validated by the receiving country s Connector. Details including the specification can be found in section

19 2.2.3 Digital Signature Services DG Market s Digital Signature Services (DSS) Tool provides a solution to create and validate signatures that follow the ETSI standards and thereby should be accepted across Europe. The close collaboration with ETSI is reflected in both signature creation and signature verification. WP4 decided, together with the e-justice portal, that DSS offers the most appropriate solution for e-codex needs. This decision is based on the results of the comparison of DG Market DSS and PEPPOL that can be found in the Appendix: Results of the Comparison of DSS and PEPPOL Signature Certificate The Trust OK -Token requires to be signed to ensure that it has been created by the sending connector and that it has not been altered. As the connector is located on the same system as the sending gateway, the gateway s signature certificate can be accessed to sign the token, either directly or indirectly as content of the ASiC-S container. By using consistent gateway signatures, it can be avoided that different nationally accepted signature formats are used to sign the token which would negate the advantage of using the Trust OK -Token to not have to validate signatures across borders. This is based on decision 27 of the e-codex deliverable D7.3 High Level Architecture Definition. 18

20 3 Functionalities 3.1 Connector General Description The Connector is located on the same system as each country s National Gateway and has the task to convert the message data from national format to e-codex format and vice versa. It also validates signatures applied to documents submitted by a Service Provider, generates a Trust OK -Token and validates an existing Trust OK -Token Connector (outgoing) The Connector (outgoing) is located on the same system as the sending country s National Gateway and has the task to convert the message data from national format to e-codex format. It also validates documents, signed or not, submitted by the National Service Provider. The validation results are verified through generation of a signed Trust OK -Token. The Connector (outgoing) will receive data from different service providers: One will be the e-justice Portal that basically acts as a European Service Provider, the others will be the different National e- CODEX Service Providers. In all cases, the Connector will create both the Trust OK -Token and the ASiC-S Container and generates signatures on both of them using DSS and the gateway s certificate e-justice Portal The e-justice Portal decided to use DSS for providing the functionality to sign documents. By doing so, possible signatures on documents submitted via the portal are automatically restricted to the signatures supported by e-codex. This simplifies the process of signature validation. The DSS validation report is available in English and will be included in the Trust OK -Token National e-codex Service Provider Each Member State will have its own national solution to ensure the validity of documents. Regardless of whether this is achieved by signing the documents or by using an authentication-based advanced electronic system, the National e-codex Service Provider can provide a validation report that will be included in the Trust OK -Token. 19

21 3.1.3 Connector (incoming) The Connector (incoming) is located on the same system as the receiving country s National e-codex Gateway. It has the tasks to convert the message data from e-codex format to national format and check the signatures of the ASiC-S Container and the Trust OK -Token. If the integrity of all documents is guaranteed, the documents can be passed on to the recipient. It still has to be decided what procedure applies if the documents cannot be validated successfully. A possible solution would be to add a watermark 3 to the Trust OK -Token to indicate that it is defective and continue with the submission of the documents to the recipient. 3.2 Recipient Manual Revalidation The recipient (i.e. a judge) should always have the possibility to revalidate documents. Instead of revalidating the original signatures on a document cross border, revalidating the signature on the Trust OK -Token is sufficient as the main purpose of the token is to attest that the documents are legally valid in the sending country. The process is described in section A watermark is a visible overlay embedded in the document. 20

22 4 Processes and Tasks 4.1 Submission of Documents A user of e-codex submits and receives files though his national system. Such systems, for the purpose of e-codex, act as e-codex Service Provider. This chapter describes the complete process of submitting a business document from the Service Provider (SP) in the sender s country up to the delivery to the Service Provider / the user in the receiving country. For a better overview, it is divided into sending and receiving side. Sending a file SP Connector Sending Gateway Receiving Gateway Authenticate the User Create the Business Document (optional) Give the User the Ability to Sign the Business Document Send the Business Document and Attachments to the Connector Receive the File(s) Signature Verification Create the Trust Ok - Token Create the ASiC-S Signature Container Transform the Message to European Format Send the File(s) to the Gateway Transportation of File(s) 21 Figure 3: Submission of business documents - Sending side

23 1 SP: Authenticate the User: The Service Provider authenticates the user by means not within the scope of e-codex. 2 SP: Create the Business Document: After successful authentication, the user is able to create a business document based on the data he provides as input. 3 SP: (Optional) Give the User the Ability to Sign the Business Document: If the Service Provider supports signature, it can grant the user the possibility to sign the business document. 4 SP: Send the Business Document and Attachments to the Connector: All related documents including the attachments are sent to the connector. 5 Con: Receive the File(s): The connector receives the files. 6 Con: Signature Verification: The connector checks the integrity of the business document by checking the applied signatures. For this reason, the connector can rely either on the signature validation of e-codex and DSS or on the nationally accepted solution. The process of signature verification is described in more detail in section Con: Create the Trust OK -Token: All relevant information provided by the Service Provider and the results of the signature verification are processed in the generation of the Trust OK-Token. Due to the language of the validation report, the token itself is only available in English and provided in both supported formats: PDF and XML. See section 4.4 for more information. 8 Con: Create the ASiC-S Signature Container: The ASiC-S signature container containing the documents and the token is created and signed. See section 4.5 and 4.6 for detailed information. 9 Con: Transform the Message to European Format: Within the connector, the ecm transforms the message to the European format. The definition of the European format is provided by WP5. 10 Con: Send the File(s) to the Gateway: The connector submits the message to the gateway. 11 SG: Transportation of File(s): The sending gateway handles the transportation of the message via the e-codex network. 22

24 Receiving a file Sending gateway Receiving gateway Connector SP Transportation of Files Receive the File(s) Check the Signature on the Trust Ok -Token Check the Signature on the Signature Container (Optional) Sign the Container Transform to National Format Send the Document(s) to the NSP Receive the Documents (Optional) Check the Signature on the Document Figure 4: Submission of business documents Receiving side 23

25 1 RG: Transportation of File(s): The receiving gateway receives the message via the e-codex network and forwards it to the connector. 2 Con: Receive the File(s): The connector receives the files. 3 Con: Check the Signature on the Trust OK -Token: The connector checks the signature on the Trust OK -Token. See section Con: Check the Signature on the Signature Container: It also checks the signature on the signature container. See section Con: (Optional) Sign the Signature Container: After all checks have been completed successfully, the connector signs the signature container to guarantee the integrity of the token and the content archive. 6 Con: Transform to National Format: The message is transformed from European format to the nationally accepted format. 7 Con: Send the Document(s) to the SP: The connector forwards the message to the Service Provider. 8 SP: Receive the Documents: The Service Provider receives the documents and takes care of delivering them to the end user. 9 SP: (Optional) Check the Signature on the Document: The Service Provider also provides means to let the user revalidate signed documents if he wants to do so by forwarding the files in question to the connector and displaying the results of the revalidation, see section

26 4.2 (Optional) Signature Revalidation This chapter describes the process of allowing the recipient to initiate a revalidation of the documents or the Trust OK -Token and the applied signatures. The actual means to make the revalidation of a signature accessible for an end user will have to be realised by the Service Provider. Recheck the signature on the document SP Connector Send a File Receive a File Signature Verification Create Validation Reply Receive Validation Reply Send Validation Reply Display Answer Figure 5: Signature Revalidation 25

27 1 SP: Send a File: The user sends documents via a Service Provider to his Connector to receive a report about their validity including the results of signature verification of signed files. These documents can be: ASiC-S container created by e-codex Signed Trust OK -Token Signed or unsigned forms created by e-codex or a Service Provider Signed or unsigned attachment. Any other signed or unsigned file not related to e-codex. 2 Con: Receive a File: The connector receives the file(s). 3 Con: Signature Verification: The connector checks the signatures on the file(s) he received. See section SP: Create Validation Reply: A validation reply is generated by the connector. See section SP: Send Validation Reply: The connector sends the validation reply back to the Service Provider that sends the request. 6 SP: Receive Validation Reply: The Service Provider receives the validation reply. 7 SP: Display Answer: The Service Provider is in charge of displaying the results of the validation to the end user. 26

28 4.3 Signature Verification This chapter describes the process of signature verification and the collection of information necessary for the creation of a validation report Preconditions A file, signed or unsigned, with the need of a signature validation Process Flow: Signature Verification 1 Supported Signature available? Depending on whether the file is signed with a signature supported by e-codex or not, the process continues as followed: 1.1 Yes: If the file is signed with a supported signature, the signature will be checked. The file might be signed more than once and every signature should be checked according to the process described in the following chapter. 1.2 No: If the file is not signed with a supported signature at all, a validation report entry should be generated that states that the file is not signed. 2 The Validation Report is created basing the conclusion on each test result. The process of the report creation is similar to the process described in section 4.7. Figure 6: Basic View on Signature Verification 27

29 Predefined Process: Check Signature 1 Signature Integrity Analysis: The first step in analysing a signature is performing the integrity check on the signature itself, see section VRE Signature Integrity Analysis Result Information: The results of the signature integrity analysis are added to the report. 3 Certificate Integrity Analysis: At this point, the certificate analysis described in section is performed. 4 VRE - Certificate Integrity Analysis Result Information: The results of the certificate analysis are added to the report. Figure 7: Check Signature 28

30 Predefined Process: Signature Integrity Analysis 1 Signature Structure Analysis: This is the process that analyses the signature to find out which signature standard (XAdES, PAdES) and what profile (BES, etc) is used and whether the signature is in accordance with the approved standards or not. 2 VRE - Signature Structure Information: The results of the signature structure analysis are added to the report. 3 Certificate Access: By accessing the signatory s certificate, the public key and information regarding used algorithms can be extracted. 4 VRE - Certificate Information: Information about the signatory s certificate and used algorithms are added to the report. 5 Integrity Verification: Use the information of the certificate to validate the signature and to verify that the signed content has not been changed. 6 VRE - Integrity Information: The results of the complete integrity analysis are added to the report. Figure 8: Closer view on "Signature Integrity Analysis" 29

31 Predefined Process: Certificate Integrity Analysis Figure 9: Closer view on "Certificate Integrity Analysis" 1 Certificate Structure Analysis: This is the process that analyses the certificate structure to receive detailed certificate information including time stamp information and qualified statements. 2 VRE - Certificate Structure Information: The results of the certificate structure analysis are added to the report. 3 Certificate Integrity Analysis: As a certificate is signed by the issuing CA, the signature on the certificate needs to be checked to verify its integrity. The necessary steps are described in Figure 8 in steps 3 to 6. 4 VRE - Certificate Integrity Information: The results of the certificate integrity analysis are added to the report. 5 Certificate Authority Analysis: Not every CA is allowed to issue certificates to create signatures with a legal value. For this reason, the CA has to be validated as described in Figure VRE - Certificate Authority Validation: The results of the certificate authority validation are added to the report. 7 Certificate Status Analysis: Finally there is the possibility that the certificate is invalid, e.g. if it has been revoked. The certificate status analysis, as it is closer described in section , helps to perform this analysis. 8 VRE - Certificate Status Information: The results of the complete certificate status check including OCSP and CRL information are added to the report. 30

32 Predefined Process: Certificate Authority Analysis Figure 10: Closer view on "Certificate Authority Analysis" 1 Access CA Information: The information about the issuing CA has to be extracted from the certificate. In a usual X.509 v3 certificate, this can be located within the entry Issuer and follows the rules defined in RFC Extract Country Information: Usually, the information about the issuing CA contains an attribute about its countryname (e.g. c = DE). This information needs to be extracted to be able to locate the national TSL of the issuing CA. 3 Contact EU TSL: The European TSL, containing links to every national TSL within European borders, has to be contacted to discover the national TSL containing information about national CAs. 4 Check signature on EU TSL: As the European TSL has been signed by an official authority to verify its validity, the signature on the European TSL should be validated. 5 Extract National TSL: Based on the country information of the issuing CA, the responsible national TSL can be extracted from the European TSL. 6 Contact National TSL: The extracted, national TSL can be contacted to verify the validity of the CA. 7 Check signature on National TSL: Equal to the EU TSL, every national TSL is signed to ensure that it has not been altered and that it is valid. 8 Validate CA at National TSL: The CA can be validated at the national TSL. For this reason, at least two actions should be performed: Ensure, that the CA can be discovered within the national TSL Compare the CA certificate written down in the national TSL with the issuer certificate written down in the signature. 9 VRE - CA Validation Information: The collected information about the validity of the CA is added to the validation report. 31

33 Predefined Process: Certificate Status Analysis 1 Get OCSP Information: Details for OCSP verification are obtained either from the certificate or from the TSL. 2 OCSP Certificate Status Check: If an OCSP is available, the OCSP certificate status check is performed. 3 VRE - OCSP (Validation) Information: The results of the OCSP check is added to the validation report. 4 Status Check returned revoked or good If the response of the OCSP contains a valid result, the validation via CRL is not needed. 5 Get CRL Information: Details for CRL verification are obtained either from the certificate or from the TSL. 6 CRL Certificate Status Check: If CRL is available, the CRL certificate status check is performed. 7 VRE - CRL (Validation) Information: The results of the CRL check are added to the validation report. Figure 11: Closer view on Certificate Status Analysis 32

34 4.3.3 Post Conditions At least one file has been validated. The XML version of a validation report, containing the results of each process step, has been generated. 4.4 Create the Trust Ok -Token (PDF & XML) This chapter describes the process of the creation of both the XML- and the PDF version of the Trust Ok -Token Preconditions The signature on the business document has to be verified. An XML version of a validation report, containing information about the validity of the signature on the business document, has to be in place. This validation report can either be created by a European- or a national solution. If the document was created by an advanced electronic system, details regarding this advanced electronic system and the identity of the user have to be provided. 33

35 4.4.2 Data flow: Creation of the Trust Ok -Token Figure 12: Creation of a Trust Ok -Token 34

36 1. Create Empty Token: Create both an empty XML- and an empty PDF document to be the basis for the Trust Ok -Token. 2. Advanced Electronic System? Checks whether the PDF version of the business document has been created by an advanced electronic system. 3. Signature Based Advanced Electronic System? Checks whether a signature is mandatory for the business document. In case of a mandatory signature, a validation report has to be in place. 4. Validation Report? Checks whether a validation report is in place. 5. Add Information about Advanced Electronic System to Token: Add the information, that the PDF version of the business document has been created by usage of a signature- or authentication based advanced electronic system, to both the XML and the PDF version of the Trust Ok -Token. 6. Add Validation Information to Token: Adds the validation report to both the XML- and the PDF version of the Trust Ok -Token. 7. Add Information Document not signed to Token: In case of authentication based advanced electronic systems, the information about the missing signature is added to the token. 8. Add Additional Information to the Token: All additional information being of interest for the end user, e.g. conformance of the business documents legal value within the borders of the creating ecm, is added to both versions of the token. A closer view on what Information should be relevant is written down in section Create PAdES Signature on Token: Sign the created Trust Ok -Token with a signature that is in conformance with the PAdES standard Post Conditions The XML- and the PDF version of the Trust Ok -Token have been created, including the validation report and the information about the existence of an advanced electronic system. The PDF version of the Trust Ok -Token has been signed. 35

37 4.5 Create Content Archive The usage of ASiC-S dictates, that only one file can be signed by an undefined number of signatures. For this reason, the business document, the Trust Ok -Token and all attachments the user decides to submit along to the business document have to be packaged in one single, ZIP based archive before being able to create a valid ASiC-S signature container. As the creation of the ASiC-S signature container will take place in the connector, the ability to create this ZIP archive will be mandatory for the connector as well. The creation of the ASiC-S signature container will be closer described in section Preconditions The PDF version of the business document is in place: o The integrity and validity of the business document have to be verified, either by validating the signature on the document or the identity of the document creator. The PDF version of the signed Trust Ok -Token has to be available. Attachments have to be filtered with respect to the file size and supported or unacceptable file formats (e.g. executable files). The restrictions for the file formats are written down in section , the limit for the file size is defined in section 3.7 and 3.8 of e-codex deliverable D5.3. In case of the usage of detached signatures within the borders of the ecm: o (Optional) Documents with detached signatures could be put together within a container file to improve the usability for the receiving SP and possibly the end-user Data flow: Creation of a Content Archive 1. Create a ZIP archive: As first step, an empty ZIP based archive has to be created. 2. Add more files? Makes sure that every file will be added to the archive Add file(s) to ZIP archive: This step describes the process of adding new files to the archive. This is described in Figure 14: Closer view on the process Add file(s) to ZIP archive. Figure 13: Creation of a Content Archive 36

38 4.5.3 Predefined Process: Add file(s) to ZIP Archive Figure 14: Closer view on the process Add file(s) to ZIP archive 37

39 Kind of file? Checks which functionality has to be used: Business Document 1.1. Existing Business Document? Checks the attribute that has to be set when the business document has been added to the ZIP archive. o o Replace Business Document: Replaces the current business document in the ZIP archive. Add Business Document: Add the business document to the ZIP archive 1.2. Set attribute Business Document: Set the respective attribute to remember the business document. Trust Ok -Token 2.1. Existing Trust Ok -Token? Checks the attribute that has to be set when the Trust Ok -Token has been added to the ZIP archive. o o Replace Trust Ok -Token: Replaces the current Trust Ok -Token in the ZIP archive. Add Trust Ok -Token: Add the Trust Ok -Token to the ZIP archive 2.2. Set attribute Trust Ok -Token: Set the respective attribute to remember the Trust Ok -Token. File 3.1. Add file to the ZIP archive: Add a single file to the ZIP archive. List of Files 4.1. Add all files to ZIP archive: Add multiple files to the ZIP archive Post conditions A single ZIP archive, containing one main document, one Trust Ok -Token and an undefined number of attachments, has been created and is available for further processing. The attributes being used to remember the business document and the Trust Ok -Token are only meant to be used for the creation of the ZIP archive and will not be a part of it. 38

40 4.6 Create and sign an ASiC-S signature container The creation of a signature container following the ASiC-S standard has to be done after the creation of a content archive (see section 4.5) and needs to be a part of the connector Preconditions A single ZIP archive, containing one business document, one Trust Ok -Token and an undefined number of attachments has to be available. The Trust Ok -Token has to be in place in XML format. The possibility to create signatures has to be available at the connector. This should be the gateway certificate at the national gateway Data flow: Creation of ASiC-S Signature Container Figure 15: Basic Process of ASiC-S signature container creation 1. Valid archive? This is a validity check for the content archive that will be signed by the ASiC-S signature container. The steps of the validation process are described in Figure 16: Closer view on Valid Archive?. 2. If the content archive is valid: 2.1. Create signature container: This step prepares the ASiC-S signature container for the signature creation. The processes done for this preparation are described in Figure Create XAdES Signature: The content archive is signed by a detached XAdES signature. The process of signature creation is described in Figure Add XAdES signature to signature container: The created XAdES signature is added to the ASiC-S signature container. 3. If the content archive is not valid: 3.1. Generate Error Report: In case that the content archive is not valid, an error report is filed. 39

41 Valid Archive? 1. Valid file? Checks whether the received file is a ZIP based archive or not. 2. Existing Business Document? As a business document is mandatory for e-codex, an archive without a business document has to be seen as invalid. 3. Existing Trust OK -Token? If there is a business document, there has to be a Trust OK -Token as well. 4. Set Attribute Archive to valid or invalid: The attribute Archive is only set to valid if the content archive meets all requirements listed above. Figure 16: Closer view on Valid Archive? Predefined Process: Create Signature Container 1. Create ZIP container: The basis for the signature container is a ZIP based container. 2. Add Mimetype to ZIP container: The usage of the additional file mimetype as it has been described in [ASiC-S] section is mandatory for this container. 3. Add content archive to ZIP container: Finally, the content archive, containing all data that is meant to be signed, has to be added to the signature container. Figure 17: Closer view on Create signature container 40

42 Predefined Process: Create XAdES Signature 1. Create XAdES Structure: The basic structure of the detached XAdES signature as it has been defined in [XAdES] section has to be created. Note: All information available at the time the structure is created will be added to it. At this time, the XMLDSig-Part of the XAdES signature will be empty! 2. Create signature: The XMLDSig-Part of the XAdES signature is created, signing the content archive as detached signature. 3. Add signature to XAdES structure: The created XMLDSig-Part is added to the prepared XAdES structure. Figure 18: Closer view on Create XAdES Signature Post conditions A valid ASiC-S signature container has been created: The content archive is signed once with a detached XAdES signature that has been created by the connector of its SP of origin. The content of the signature container is a ZIP archive containing one business document, one PDF version of the Trust Ok -Token and an undefined number of attachments. The file extension of the ASiC-S signature container still is.scs. 41

43 4.7 Create Validation Report 1 Process Signature Information: In this step, information regarding the signature itself is processed. This includes the occurrence of a supported signature, its structural information, the used algorithms as well as the results of the integrity check. 2 Process Certificate Information: In this step, information regarding the signatory s certificate is processed. This includes the results of the structural analysis, the integrity checks and the OCSP and / or CRL certificate status checks. 3 Process Certificate Authority Information: All information related to the certification authority that issued the signatory s certificate is processed at this point. 4 Calculate Trust-Level: The trust level is calculated based on a set of rules that is specified independantly for each sending country. This calculation relies on the results of previously performed analytic processes that are compared to the applicable rule set. Some examples: If all required tests are successful the trust level is set to green, according to the traffic light principle. If it is not possible to conduct some tests successfully, but these are not required in the sender country to have a legally valid document, this can also be considered and the trust level could be set to green or yellow. Figure 19: Closer View on "Create Validation Report 42

44 5 Description of modules and building blocks to be realised 5.1 Java Library for Usage within the Connector The signature verification, creation of the Trust-Ok -Token and the creation of the ASiC-S signature container will be a part of the adapter that has to be implemented within every Service Provider. To prevent every ecm to have to create a solution on its own, e-codex will create a library to provide these functionalities. This Java library will be provided as single Java archive (jar file) to make its usage as comfortable as possible Requirements To make the usage of the library possible, the following requirements need to be fulfilled: Java needs to be installed. (At least Java 1.6) Connection to the internet needs to be in place. e-codex gateway certificate needs to be accessible Packaging The functionalities of the library are, from a user s point of view, separated into three important packages: eu.ecodex.trust This package contains all classes being involved in the handling of signatures and advanced electronic systems, ranging from the validation of a signature to the creation of a Trust Ok - Token. eu.ecodex.signaturecontainer The creation and handling of the ASiC-S signature container can be managed using the classes defined within this package. eu.ecodex.common The package eu.ecodex.common contains helpful functionalities, e.g. to make the handling of files easy. 43

45 5.1.3 Public Classes This chapter will provide specifications for classes and enumerations being available for usage within every connector. The purpose of these classes is to reduce the necessary effort for the creation of a connector Validation The purpose of this class is to find signatures on a document and, in case that there is a signature in place, to validate the signature. For further computing, a validation report containing the outcome of the validation will be provided. Class Name: Validation Package: eu.ecodex.trust Constructor Summary Validation(InMemoryDocument document) Validation(byte[] document, String filename) Constructor Details: Validation(InMemoryDocument document) Initialises a newly created Validation object. Parameters: document The document with the need for signature verification. Validation(byte[] document, String filename) Initialises a newly created Validation object, whereby the parameters are translated into a single InMemoryDocument object. This InMemoryDocument object will be stored within the Validation object for further computing. Parameters: document filename The document with the need for signature verification. Name of the document. Should consist of filename and file extension, e.g. Message.xml. 44

46 Method Summary void void Document void void void void setdocument(byte[] document, String filename) setdocument(inmemorydocument document) verifysignature() sethttpproxy(string host, String port) sethttpproxy() sethttpsproxy(string host, String port) sethttpsproxy() Method Details: setdocument(byte[] document, String filename) Sets a document with the need of a signature validation, whereby the parameters are translated into a single InMemoryDocument object. This InMemoryDocument object will be stored within the Validation object for further computing. Parameters: document filename The document with the need for signature verification. Name of the document. Should consist of filename and file extension, e.g. Message.xml. setdocument(inmemorydocument document) Sets a document with the need for signature validation. Parameters: document verifysignature() The document with the need for signature verification. Tries to verify the signature on the defined document and creates a report about the outcome of the signature verification. Returns: A verification report containing information about the validity of the signature. Throws: NoDocumentException InvalidDocumentException If the document to be verified is null If the documents content or the name of the document is null or the name of the document is an empty string 45

47 sethttpproxy(string host, String port) Makes the object use the http proxy defined within the parameters. If the parameter port is null, the default value for the port will be used. Parameters: host The host name of the proxy server port The port number, the default value is 80 sethttpproxy() Makes the object use the http proxy as it has been set within the system properties, e.g. via the Java methods System.setProperty( http.proxyhost, myhost ) and System.setProperty( http.proxyport, 8080 ). sethttpsproxy(string host, String port) Makes the object use the https proxy defined within the parameters. If the parameter port is null, the default value for the port will be used. Parameters: host The host name of the proxy server port The port number, the default value is 443 sethttpsproxy() Makes the object use the https proxy as it has been set within the system properties, e.g. via the Java methods System.setProperty( https.proxyhost, myhost ) and System.setProperty( https.proxyport, 443 ) TrustOkToken This class contains the functionality to create both the unsigned XML- and the signed PDF Version of the Trust Ok -Token and to prepare the Trust Ok -Token for the usage within a signature container. It has to be made sure, that the XML version of the token corresponds to the PDF version! Class Name: TrustOkToken Package: eu.ecodex.trust Constructor Summary TrustOkToken() TrustOkToken(TokenContent content, Document report) TrustOkToken(TokenContent content, Document report, PrivateKey privkey, X509Certificate cert) 46

48 Constructor Details: TrustOkToken() Initialises a newly created TrustOkToken object. TrustOkToken(TokenContent content, Document report) Initialises a newly created TrustOkToken object and creates both the XML- and the PDF version of the Trust Ok -Token. Parameters: content report Information about the content of the Token. The XML of the report that has been created by the national solution or using means provided by e-codex. TrustOkToken(TokenContent content, Document report, PrivateKey privkey, X509Certificate cert) Initialises a newly created TrustOkToken object, creates both the XML- and the PDF version of the Trust Ok -Token and signs the PDF version with a PAdES signature. Parameters: content report privkey certificate Throws: InvalidKeyException Information about the content of the Token. The XML of the report that has been created by the national solution or using means provided by e-codex. The private Key that shall be used to create the PAdES signature. The certificate, that shall be attached to the PAdES signature to make its validation possible. Thrown for every key related issue, e.g. if the private key is invalid or if the private key does not correspond to the public key of the certificate. 47

49 Method Summary InMemoryDocument InMemoryDocument byte[] List<InMemoryDocument> void List<InMemoryDocument> getpdf() getxml() gettrustoktoken(mimetype mimetype) gettrustoktoken() signpdftoken(privatekey privkey, X509Certificate cert) createtoken(tokencontent content, Document report) Method Details: getpdf() Method to get the PDF version of the Trust Ok -Token as an InMemoryDocument object. Returns: The PDF version of the Trust Ok -Token as InMemoryDocument object. getxml() Method to get the XML version of the Trust Ok -Token as an InMemoryDocument object. Returns: The XML version of the Trust Ok -Token as an InMemoryDocument object. gettrustoktoken(mimetype mimetype) Method to get a specific version of the Trust Ok -Token as byte array. Parameters: mimetype Defines, whether the XML- or the PDF version of the Trust Ok -Token shall be returned. Returns: Depending on the mimetype parameter, the XML- or the PDF version of the Trust Ok -Token as byte array. Throws: InvalidMimeTypeException Thrown if the mimetype is neither MimeType.PDF nor MimeType.XML as these are the only allowed mimetypes. 48

50 gettrustoktoken() Method to get both the PDF- and the XML version of the Trust Ok -Token. Returns: A list of InMemoryDocument objects, containing both the PDF- and the XML version of the Trust Ok -Token. createtoken(tokencontent content, Document report) This method can be used to create the unsigned PDF- and the XML versions of the Trust Ok - Token. If there already is a PDF- and / or the XML version of a Trust Ok -Token in place, both existing versions will be overwritten! Parameters: content report Throws: InconsistentInformationException signpdftoken(privatekey privkey, X509Certificate cert) Contains various information about the content of the Trust Ok -Token. The validation report that shall be attached to the Trust Ok -Token. If there is no signature on the business document, this parameter can be null. Thrown, if the information transmitted within the TokenContent object seems to be inconsistent, e.g. if the Issuer is null or if a signature was mentioned to be in place and the validation report is null. This method can be used to sign the PDF version of the Trust Ok -Token. Parameters: privkey certificate Throws: InvalidKeyException The private key that shall be used to create the PAdES signature on the Trust Ok -Token. The certificate that shall be attached to the PAdES signature to make its validation possible. Thrown for every key related issue, e.g. if the private key is invalid or if the private key does not correspond to the public key of the certificate. 49

51 TokenContent This class will be used to communicate the content of the Trust Ok -Token to a TrustOkToken object. Class Name: TokenContent Package: eu.ecodex.trust Constructor Summary TokenContent() Constructor Details: TokenContent() Initialises a new TokenContent object with default values. Method Summary void void void setissuer(string serviceprovider, String country, AdvancedElectronicSystem advsystem) setdocument(inmemorydocument document) setvalidationdata(validationdata valid) Method Details: setissuer(string serviceprovider, String country, AdvancedElectronicSystem advsystem) Provides information about the issuer of the Trust Ok -Token. Parameters: serviceprovider country advsystem The authority that is responsible for the creation of the Trust Ok -Token. The member state the authority is working for. Defines if the token has been created within an advanced electronic system and whether it was a signature based or an authentication based system. setdocument(inmemorydocument document) This method sets the document the Trust Ok -Token is meant to refer to. Parameters: document The document this token refers to. 50

52 setvalidationdata(validationdata valid) Can be used to provide various information about the signature on the business document. This information cannot be taken from the validation report as the report does not necessarily follow a standard. If the validation data of a TokenContent object is not set, the business document is handled as being unsigned. Parameters: valid Contains various validation data about the signature on a document ValidationData This class can be used to communicate various validation data to a TokenContent object. Class Name: ValidationData Package: eu.ecodex.trust Constructor Summary ValidationData() Constructor Details: ValidationData() Initialises a new ValidationData object with default values. Method Summary void void void void setverificationresult(string trustlevel, String comment) setverificationtime(time time) setauthenticationdata(string idp, String username, Time authtime) setsignaturedata(signatureinformation siginfo) 51

53 Method Details: setverificationresult(string trustlevel, String comment) This method is used to communicate the result of the verification of the document to the Trust Ok -Token. Parameters: trustlevel comment Assessment of the trust this document gets at the national solution, ranging from red (not trusted) over yellow (conditionally trustworthy) to green (trusted and legally binding) Optional parameter for system specific comments. Can be null if it is not needed. setverificationtime(time time) Method to add the time the verification of the document took place to the Trust Ok -Token. Parameters: time The time the verification of the document was performed and the Trust Ok -Token was created. setauthenticationdata(string idp, String username, Time authtime) In case of authentication based advanced electronic systems, this method can be used to communicate information about the authentication to the Trust Ok -Token. If the advanced electronic system is signature based, this method is not needed. Parameters: idp username authtime setsignaturedata(signatureinformation siginfo) Information about the system the user was authenticated at. The name of the user being authenticated. The time the user was authenticated. This method is used for signature based advanced electronic systems to set the information about the validity of the signature. If the advanced electronic system is authentication based, this method is not needed. Parameters: siginfo Contains information about the signature. 52

54 SignatureInformation This class can be used to communicate various information about the validity of a signature to a ValidationData object. Class Name: SignatureInformation Package: eu.ecodex.trust Constructor Summary SignatureInformation() Constructor Details: SignatureInformation() Initialises a new SignatureInformation object with default values. Method Summary void void void setsignatureinformation(boolean sigveri, boolean structveri, String sigformat, String siglevel) setverificationtime(time verificationtime) setcertificateinformation(boolean certveri, boolean validatsigtime, String issuer) Method Details: setsignatureinformation(boolean sigveri, boolean structveri, String sigformat, String siglevel) This method adds various data about the validity of a signature to the Trust Ok -Token. Parameters: sigveri structveri sigformat siglevel Answer on the question Is this a valid signature? Answer to the question Is the structure in accordance with the recommendations to this kind of signature format? What signature format has been used (e.g. XAdES, PAdES) If there are different signature levels, the signature level can be transmitted with this parameter (e.g. BES for XAdES-BES). In cases without different signature levels, this parameter can be null (e.g. at proprietary solutions) 53

55 setverificationtime(time verificationtime) Method to communicate the time of signature verification to the Trust Ok -Token. Parameters: verificationtime Information about the time of the signature verification. setcertificateinformation(boolean certveri, boolean validatsigtime, String issuer) Used to communicate various information about the validation of the certificate being used for signature verification. Parameters: certveri validatsigtime issuer Answer to the question Has the certificate successfully been verified? Was the certificate valid at the time the signature has been created? The issuer entry of the certificate Creation This class can be used to create an ASiC-S signature container, signed by the MS it has been created in and containing: One PDF business document One signed PDF version of a Trust Ok -Token An undefined number attachments Class Name: Creation Package: eu.ecodex.signaturecontainer Constructor Summary Creation(byte[] businessdocument, String filename) Creation(InMemoryDocument businessdocument) Creation(byte[] businessdocument, String filename, TrustOkToken trustoktoken) Creation(InMemoryDocument businessdocument, TrustOkToken trustoktoken) 54

56 Constructor Details: Creation(byte[] businessdocument, String filename) Basic constructor, preparing an ASiC-S signature container for further processing. Shall only be used if the Trust Ok -Token is not yet in place. Parameters: businessdocument filename The business document, provided as byte array. The filename of the business document. Creation(InMemoryDocument businessdocument) Basic constructor, preparing a signature container for further processing. Shall only be used if the Trust Ok -Token is not yet in place. Parameters: businessdocument The business document, provided as InMemoryDocument object. Creation(byte[] businessdocument, String filename, TrustOkToken trustoktoken) Constructor for the Creation object, providing enough information to be able to create the signature container. Parameters: businessdocument filename trustoktoken The business document, provided as byte array. The filename of the business document. A TrustOkToken object containing at least a signed PDF version of the Trust Ok -Token Creation(InMemoryDocument businessdocument, TrustOkToken trustoktoken) This is the recommended constructor to be used, providing as much information as possible to the Creation object. Parameters: businessdocument trustoktoken The business document, provided as InMemoryDocument object. A TrustOkToken object containing at least a signed PDF version of the Trust Ok -Token 55

57 Method Summary void void void void void List<InMemoryDocument> void void InMemoryDocument setbusinessdocument(byte[] businessdocument, String filename) setbusinessdocument(inmemorydocument businessdocument) settrustoktoken(trustoktoken trustoktoken) addattachment(inmemorydocument attachment) addattachment(list<inmemorydocument> attachments) getattachments() removeattachment(int number) removeallattachments() createsignaturecontainer(privatekey privkey, X509Certificate cert) Method Details: setbusinessdocument(byte[] businessdocument, String filename) Fills the business document attribute of the Creation object with the received data, whereby an existing business document will be replaced. Parameters: businessdocument filename The business document, provided as byte array. The filename of the business document. setbusinessdocument(inmemorydocument businessdocument) Fills the business document attribute of the Creation object with the received data, whereby an existing business document will be replaced. Parameters: businessdocument The business document, provided as InMemoryDocument object. settrustoktoken(trustoktoken trustoktoken) Sets the TrustOkToken object within the Creation object. If the TrustOkToken object is already set, the existing object will be overwritten. Parameters: trustoktoken A TrustOkToken object containing at least a signed PDF version of the Trust Ok -Token 56

58 addattachment(inmemorydocument attachment) Adds a single attachment to the Creation object. Parameters: attachment A single attachment, provided as InMemoryDocument object addattachment(list<inmemorydocument> attachments) Adds a list of attachments to the Creation object. Parameters: attachments A list of attachments, provided as InMemoryDocument objects getattachments() Method to receive a list of attachments Returns: All attachments as a list of InMemoryDocument objects removeattachment(int number) Removes a single attachment from the Creation object. Parameters: number Throws: IndexOutOfBoundsException removeallattachments() Removes all attachments from the Creation object. The position of the attachment within the internal list of InMemoryDocument objects. The number is not in the range of the list of attachments (number is smaller than 0 or greater than the count of attachments 1) 57

59 createsignaturecontainer(privatekey privkey, X509Certificate cert) Creates and signs a signature container containing at least one business document and a signed PDF version of the Trust Ok -Token. Parameters: privkey certificate Returns: A signature container, signed by the connector of its origin. Throws: MissingBusinessDocumentException MissingTrustOkTokenException The private Key used to create the PAdES signature. The certificate that shall be attached to the PAdES signature to make its validation possible. Thrown if the business document is missing. Thrown if the PDF version of the Trust Ok -Token is missing Reception This class can be used to alleviate the work with a received signature container, e.g. to read its content and to verify the signature on the container. Class Name: Reception Package: eu.ecodex.signaturecontainer Constructor Summary Reception(byte[] signaturecontainer, String filename) Reception(InMemoryDocument signaturecontainer) Constructor Details: Reception(byte[] signaturecontainer, String filename) Initialises a Reception object with a signature container. Parameters: signaturecontainer filename Reception(InMemoryDocument signaturecontainer) Initialises a Reception object with a signature container. Parameters: signaturecontainer A signature container created by the class eu.ecodex.signaturecontainer.creation The filename of the signature container A signature container created by the class eu.ecodex.signaturecontainer.creation 58

60 Method Summary void void Document byte[] void void void void void setsignaturecontainer(byte[] signaturecontainer, String filename) setsignaturecontainer(inmemorydocument signaturecontainer) verifysignature() getsignedcontent() signcontent(privatekey privkey, X509Certificate cert) sethttpproxy(string host, String port) sethttpproxy() sethttpsproxy(string host, String port) sethttpsproxy() Method Details: setsignaturecontainer(byte[] signaturecontainer, String filename) Sets a signature container. If a signature container is in place, the existing signature container will be replaced. Parameters: signaturecontainer filename A signature container created by the class eu.ecodex.signaturecontainer.creation The filename of the signature container setsignaturecontainer(inmemorydocument signaturecontainer) Sets a signature container. If a signature container is in place, the existing signature container will be replaced. Parameters: signaturecontainer A signature container created by the class eu.ecodex.signaturecontainer.creation verifysignature() Method to verify the signatures used within the signature container to sign its content archive. Returns: A validation report about the validity of the signatures the ASiC-S content archive is signed with. 59

61 getsignedcontent() Returns the content archive that has been signed by the signature container. Returns: The ZIP based content archive as byte array. signcontent(privatekey privkey, X509Certificate cert) Attaches an additional XAdES signature to the signed content. Parameters: privkey certificate The private key that shall be used to create the XAdES signature. The certificate that shall be attached to the XAdES signature to make its validation possible. sethttpproxy(string host, String port) Makes the object use the http proxy defined within the parameters. If the parameter port is null, the default value for the port will be used. Parameters: host the host name of the proxy server port the port number, the default value is 80 sethttpproxy() Makes the object use the http proxy as it has been set within the system properties, e.g. via the Java methods System.setProperty( http.proxyhost, myhost ) and System.setProperty( http.proxyport, 8080 ). sethttpsproxy(string host, String port) Makes the object use the https proxy defined within the parameters. If the parameter port is null, the default value for the port will be used. Parameters: host the host name of the proxy server port the port number, the default value is 443 sethttpsproxy() Makes the object use the https proxy as it has been set within the system properties, e.g. via the Java methods System.setProperty( https.proxyhost, myhost ) and System.setProperty( https.proxyport, 443 ). 60

62 InMemoryDocument This class can be used to improve the handling of files. Class Name: InMemoryDocument Package: eu.ecodex.common Constructor Summary InMemoryDocument (byte[] document) InMemoryDocument (byte[] document, String name) InMemoryDocument (byte[] document, String name, MimeType mimetype) Constructor Details: InMemoryDocument (byte[] document) Initialises an InMemoryDocument object with a nameless document and without any information about the mimetype. Parameters: document the content of a document InMemoryDocument (byte[] document, String name) Initialises an InMemoryDocument object, whereby the mimetype of the object will be set automatically based on an analysis of the filename. Parameters: document name the content of a document the filename of the document. In case of an existing extension, the mimetype of the InMemoryDocument object will be set automatically, e.g. the mimetype of the file Message.xml will be set to MimeType.XML. In cases of no or an unknown file extension, the mimetype will be set to MimeType.BINARY. InMemoryDocument (byte[] document, String name, MimeType mimetype) This constructor should usually be used when working with InMemoryDocument objects as it makes it necessary to give all important information to work with a file. Parameters: document name mimetype The content of the document The filename of the document The mime type of the document 61

63 Method Summary byte[] String MimeType getdocument() getname() getmimetype() Method Details: getdocument() Returns the document. Returns: The document as byte array getname() Returns the name. Returns: The name of the document as String. getmimetype() Returns the mime type. Returns: The mime type of the document as MimeType object. 62

64 MimeType The enumeration MimeType will alleviate the handling of mime types within the handling of documents. As its main purpose is to be used in the context of signature creation and verification, there will only be the differentiation between three mime types. Enumeration Name: MimeType Package eu.ecodex.common Name BINARY XML PDF Translation application/octet-stream text/xml application/pdf Method Summary MimeType String fromfilename(string name) getcode() Method Details: fromfilename(string name) This method returns a MimeType based on the extension of a filename. Parameters: filename Name of a document Returns: The mime type of a filename, e.g. XML for the filename Message.xml. getcode() Returns the translation to the mime type the object has been set to. Returns: The translation for the mime type, e.g. text/xml if the mime type has been set to XML. 63

65 AdvancedElectronicSystem The enumeration AdvancedElectronicSystem will be usable to help with the decision whether the advanced electronic system is authentication- or signature based. Enumeration Name: AdvancedElectronicSystem Package eu.ecodex.common Name AUTHENTICATION SIGNATURE Translation authentication based advanced electronic system Signature based advanced electronic system Method Summary String getcode() Method Details: getcode() Returns the translation to the advanced electronic system the object has been set to. Returns: The translation for the AdvancedElectronicSystem, e.g. authentication based advanced electronic system if the AdvancedElectronicSystem has been set to AUTHENTICATION. 64

66 5.1.4 Configuration As the library is meant to be usable on different systems, several properties might need to be initialized or configured to guarantee faultless procedures Certificate The library will have to create valid signatures for several documents, e.g. the ASiC-S signature container and the Trust Ok -Token. For this reason, the solution using this library needs to have access to the gateway certificate of the national e-codex gateway and the respective keystore Proxy Configuration The Java library needs to be able to contact TSLs and CAs. For this reason, the library will have to send and receive http- and https messages. As a national solution might use a proxy server, it is necessary to configure a proxy within the class. For this reason, the library will provide several possibilities to contact the proxy: Every class with the possible need of proxy support contains the methods sethttpproxy(string host, String port) and sethttpsproxy(string host, String port), that can be used to set a proxy for the created object. These methods will take use of the class Proxy as it is provided by the official Java sources. If the proxy that is meant to be used has been configured within the system properties of the national solution, the method sethttpproxy() and sethttpsproxy() can be called to tell the object to use this proxy. If there is no need for a proxy, neither the 1st nor the 2nd method needs to be called. This way, the methods of the respective object will not try to use a proxy Logging As recording system events might become necessary for several participants, the Java library that will be provided by e-codex, will create several logging messages for important processes, e.g.: Sending of data and requests to the internet (e.g. contacting a TSL, certification authority) Receiving data from the internet (e.g. receiving data about a TSL, certification authority) Creation of the signature container Signature validation on the signature container To create these logging messages, e-codex will rely on the free to use library log4j 4. Every MS is free to create and configure a log4j -logger within the connector to log these messages

67 5.2 Signature verification Signature verification can be separated in three topics. One of them is the verification of the business document at the sending Service Provider. This verification is necessary to make the creation of the Trust Ok -Token possible, as, in case of signed documents, the token is meant to provide information about the signatures validity to the end user. The second topic is the verification at a receiving Service Provider and will mainly be used for the verification of signatures on the ASiC-S signature container. As last and most complicated topic, the cross-border verification of signatures has to be kept in mind. This will be necessary for both the signature verification at cross-border Service Providers (e.g. the European e-justice portal) and the revalidation of signed business documents that have been received by an end user Verification at Sending Service Provider The verification of a signature created at an ecm is under the responsibility of the respective ecm. The outcome of this verification can be transformed to a validation report (See section 5.5). This validation report can be transmitted to the e-codex Java library to be included in the Trust Ok - Token. In case of a cross-border Service Provider (e.g. the e-justice portal), usage of DG MARKT DSS is recommended to verify a signatures validity. As DSS creates a validation report as it is described in section 5.5 and the current version of DSS will be a part of the Java library provided by e-codex, there will not be a need to install additional packages. Nonetheless, every cross-border Service Provider is free to decide which solution shall be used for cross-border signature verification Verification at Receiving Service Provider As the verification of the signature on the business document has been done at the sending Service Provider, the only signature with a need to be verified is the signature on the ASiC-S signature container. This verification will be done by the method verifysignature() of the class eu.ecodex.signaturecontainer.reception as it has been described in section 5.1. The outcome of this verification will be a validation report (section 5.5) that can be used to decide, whether the ASiC-S signature container can be trusted or not. In case of a trusted ASiC-S signature container, the receiving Service Provider can decide to: Add its own signature to the signature container by calling the method signcontent(privatekey privkey, X509Certificate cert) of the class eu.ecodex.signaturecontainer.reception and forwarding the whole signature container to the end user. Unpackage the signature container by calling the method getsignedcontent() of the class eu.ecodex.signaturecontainer.reception and forward the files. This solution is advised not to be used as the link between the files and the Trust Ok -Token gets lost. 66

68 5.2.3 Cross-Border Verification The cross-border verification of signatures will be necessary for the first validation and revalidation of signatures at cross-border Service Providers and the revalidation of signatures for received documents at the receiving Service Provider. For this reason, the Java library described in section 5.1 provides the method verifysignature() within the class eu.ecodex.trust.validation. This method mainly uses the classes of DG MARKT DSS and creates a validation report that is in conformance with the specifications in section Signature creation on business documents The business document of a case is highly recommended to be signed by the user to make changes to the document detectable and to create a trustworthy link between user and document. The possibility to create this signature should be implemented at the Service Provider and should rely on nationally accepted means. In case of the European solution, the European e-justice portal, e-codex recommends the signature creation to be realised by: Usage of DSS, provided by DG MARKT, as main solution. Providing a possibility to download, sign and upload the document. This solution should be available for the signature solutions not being supported by DSS. Nevertheless, the final decision about how to implement the necessary cross border signature creation service is up to the e-justice portal. 5.4 Signature creation on Trust Ok -Token The Trust Ok -Token is necessarily signed to ensure: The token has been created by an authority that is allowed to create this kind of token, e.g. the connector of a service provider. The token has not been altered during its transmission. As the Trust Ok -Token will be created and signed at the connector of the Service Provider, it is necessary to provide a certificate for the automated creation of electronic signatures at every connector. The recommended certificate to be used is the certificate of the national e-codex gateway Signature on the PDF version The signature on the PDF version of the Trust Ok -Token will be created at the connector and has to be mandatory for further processing of the token. A signature created by a connector shall be in accordance with the standard PAdES and has to be realised with the profile PAdES-BES as a minimum. 67

69 5.4.2 Signature on the XML version To be accessible in an easy way, the XML version of the Trust Ok -Token is planned to be transported outside of the ASiC-S signature container. To prevent changes on the content of the XML token, it is highly recommended to sign it at the connector of the sending Service Provider. For this reason, an enveloping XAdES signature seems to be most suitable, at least in the profile BES as it is described in XAdES. In addition, the signature should involve the PDF version of main document to provide a trustworthy link to the signed content. This could be realised by an additional reference - element within the XMLDSig-Part of the XAdES signature. The following tables describe the structure of the described solution based on an example. 1) 2) 3) 4) 5) 6) <?xml version="1.0" encoding="utf-8" standalone="no"?> <ds:signature xmlns:ds=" Id="sigId-ideebe4db20c4c dda2410e3665"> +<ds:signedinfo> <ds:signaturevalue Id="value-ideebe4db20c4c dda2410e3665"> Signature </ds:signaturevalue> +<ds:keyinfo> +<ds:object > <Object Id="Signed Data ID" xmlns=" XML Version of the Trust Ok Token</Object> </ds:signature> Table 3: Basic View on a XAdES Signature 1. ds:signature This is the root element of the XAdES signature as it is described in XAdES. 2. ds:signedinfo The element ds:signedinfo contains information about the signed content and is described in section 4.3 of the XMLDSig specification. This element will be described closer in Table 4 as this is an important element to understand, what has to be signed. 3. ds:signaturevalue This element contains the actual value of the digital signature and is specified in section 4.2 of XMLDSig. 4. ds:keyinfo The element ds:keyinfo shall contain the signatories certificate to allow the verification of the signature and is described in section 4.4 of XMLDSig. In the case of e-codex, this will be the certificate of the sending Service Provider s Connector. 68

70 5. ds:object The element ds:object contains all additional information about the signature that has to be in place to be in accordance with XAdES. 6. Object This element contains the signed object(s) that are meant to be a part of the XAdES signature. In case of e-codex, this will be the element containing the XML version of the Trust Ok -Token. <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" /> <ds:signaturemethod Algorithm=" /> 1) 2) 3) <ds:reference URI="Filename: PDF Version of the business document"> <ds:digestmethod Algorithm=" /> <ds:digestvalue>6k87kqqcq4frsszcp0mgga/y3yc=</ds:digestvalue> </ds:reference> <ds:reference URI="#Signed Data ID"> <ds:transforms> <ds:transform Algorithm=" /> </ds:transforms> <ds:digestmethod Algorithm=" /> <ds:digestvalue>6k87kqqcq4frsszcp0mgga/y3yc=</ds:digestvalue> </ds:reference> <ds:reference Type=" URI="#xades-ideebe4db20c4c dda2410e3665"> <ds:transforms> <ds:transform Algorithm=" /> </ds:transforms> <ds:digestmethod Algorithm=" /> <ds:digestvalue>ghlbctrqhpezb42l7rnaomxseu4=</ds:digestvalue> </ds:reference> </ds:signedinfo> Table 4: Detailed View on the Element "ds:signedinfo" 69

71 1. ds:reference URI= Filename: PDF version of business document The digest of the PDF version of the Trust Ok -Token. The URI should refer only to the name of the file (e.g. Document.pdf) 2. ds:reference URI= #Signed Data ID This part of the signature contains the digest of the XML version of the Trust Ok -Token. The URI refers to the ID of the signed content (compare to the element Object in Table 3) 3. ds:reference URI= #xades-ideebe4db20c4c dda2410e3665 This reference contains the part of the signature, that contains the additional XAdES information. The reference has to be in place to be in accordance with [XAdES] (section 4.4.1). 70

72 5.5 Validation Report The validation report contains all validation data that can be collected within the process of signature validation. In case of e-codex, this leads to two scenarios: Signature validation with nationally accepted solutions If the signature validation is done by the nationally accepted solution, e.g. at the sending Service Provider to create a report for the Trust Ok -Token, the report will follow the nationally accepted standards. Signature validation with cross-border solutions In case of the European e-justice portal as a sending participant of e-codex and the revalidation of a signature by means of the e-codex signature validation mechanism, the signature validation will be realised by DG MARKT DSS. For this reason, the result of a signature validation will be a report as it has been defined within the documentation of this solution 5. There will be no standardised validation report as the content of the report is mostly under the control of each member state. From a legal point of view, e-codex is not allowed to either add information to these reports or to remove information. The only mandatory requirement to the report is that is has to be transmitted as XML. 5 See A Appendix: Validation report structure 71

73 5.6 Trust Ok -Token As already stated in section 2.2.1, the idea behind the Trust OK -Token is to provide the possibility for the receiving party (e.g. a judge) to recognise documents filed using trustworthy advanced electronic systems based on signature or authentication. By using the token in accordance to the Circle of Trust, the receiving party does not need to validate the documents, applied signatures and used certificates itself and can rely solely on the token. By doing so, it is no longer necessary to validate signatures and certificates cross-border and deal with the different national standards and implementations. The Trust-OK -Token will be a PDF-File generated by the sending Connector to provide a human readable document. It will be easy to understand with the aim to aid the receiving party in the signature verification process. Additionally, a machine readable form will be generated to support future developments Content To fulfil the requirement, that the Trust OK -Token should be easy to understand, the token itself will be divided into two parts: The first part consists of basic information necessary for the receiving party to recognise documents as trustworthy which includes information on the advanced electronic system, an evaluation of the trust level according to the traffic light principle as well as other data listed below. The second part will be made of the original validation report provided by either the national solution itself or by the DSS validation tool. The Trust OK -Token will contain: Information on the used advanced electronic system Information on the time the documents have been filed Basic Information on applied signatures and used certificates or the identity of the user Evaluation of the trust level (red / yellow / green) Original validation report provided by the national solution or the DSS validation tool 72

74 5.6.2 Structure Human Readable Token (PDF) As mentioned in 5.6.1, the human readable token will consist of two parts. The first part will be presented on the first page of the actual token. It includes information on the advanced electronic system, the summary of the validation process and the approval of the validity of the filed documents. The second part, the validation report, will be presented on the following page(s). Figure 20: Exemplary "Trust OK"-Token 73

75 Machine Readable Token (XML) This chapter provides the XML schema that defines the structure of the XML version of the Trust Ok -Token. <?xml version="1.0" encoding="iso "?> <xsd:schema xmlns:xsd=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:element name="trust-ok Token" type="tokentype"/> </xsd:schema> <xsd: simpletype name=" advsystemenum"> <xsd:restriction base= xsd:string > <xsd:enumeration value="signature-based" /> <xsd:enumeration value="authentication-based" /> </xsd:restriction> </xsd:simpletype> <xsd: complextype name="issuertype"> <xsd:sequence> <xsd:element name="service Provider" type="xsd:string" /> <xsd:element name="country" type="xsd:string" /> <xsd:element name="advanced Electronic System" type= advsystemenum /> </ xsd:sequence> </xsd: complextype> <xsd:complextype name=" DocumentType"> <xsd:sequence> <xsd:element name="filename" type="xsd:string" /> <xsd:element name="type" type="xsd:string" /> <xsd:element name="digest" type="xsd:string" /> </xsd:sequence> </xsd: complextype> <xsd:complextype name=" SourceType "> <xsd:any minoccurs= 0 maxoccurs= unbounded /> </xsd: complextype> <xsd:complextype name=" SignatureInformationType "> <xsd:sequence> <xsd:element name="signature Verification" type="xsd:boolean" /> <xsd:element name="structure Verification" type="xsd:boolean"/> <xsd:element name="signature Format" type="xsd:string" /> <xsd:element name="signature Level" type="xsd:string" minoccurs= 0 /> </xsd:sequence> </xsd: complextype> <xsd:complextype name=" CertificateInformationType "> <xsd:sequence> <xsd:element name="issuer" type="xsd:string" /> <xsd:element name="certificate Verification" type="xsd:boolean" /> <xsd:element name="validity At Signing Time" type="xsd:boolean" /> </xsd:sequence> </xsd: complextype> 74

76 <xsd:complextype name=" AuthenticationInformationType "> <xsd:sequence> <xsd:element name="identity Provider" type="xsd:string" /> <xsd:element name="username/synonym" type="xsd:string" /> <xsd:element name="time Of Authentication" type="xsd:datetime" /> </xsd:sequence> </xsd: complextype> <xsd:complextype name="signaturedatatype"> <xsd:sequence> <xsd:element name="signing Time" type="xsd:datetime" /> <xs:element name=" Signature Information " type="signatureinformationtype" /> <xs:element name="certificate Information" type="certificateinformationtype" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name=" VerificationDataType "> <xsd:choice> <xs:element name="signature Data" type="signaturedatatype" /> <xs:element name= Authentication Data type="authenticationinformationtype" /> </xsd:choice> </xsd: complextype> <xsd:complextype name=" ResultType "> <xsd:sequence> <xsd:element name="trust-level" type="xsd:string" /> <xsd:element name="comments" type="xsd:string" minoccurs= 0 /> </xsd:sequence> </xsd: complextype> <xsd:complextype name=" ValidationType "> <xsd:sequence> <xs:element name="verification Time" type="xsd:datetime" /> <xs:element name="verification Data" type="verificationdatatype" /> <xs:element name="result" type="resulttype"/> <xs:element name= Original Validation Report type="sourcetype"/> </xsd:sequence> </xsd: complextype> <xsd:complextype name=" TokenType"> <xsd:sequence> <xsd:element name="issuer" type="issuertype" /> <xsd:element name="document" type= DocumentType /> <xsd:element name="validation" type= ValidationType /> </xsd:sequence> </xsd:complextype> 75

77 5.6.3 Link to the Validated Documents Depending on the decision whether the Trust Ok -Token is allowed to be a container file, the standard ASiC-S will be applicable for e-codex needs Description The ASiC-S format provides the possibility to create a signature container for a single file with an undefined number of signatures. To make this solution suitable for e-codex needs, it would be possible to create a ZIP file containing all files that have to be transported. Afterwards, this ZIP file can be signed by both the sending and the receiving gateway. Figure 21: Example for ASiC-S structure applied to a nested container file 6 6 Source: 76

78 Technical Specification ASiC-S Signature Container As described before, all files that are meant to be signed and transported by the ASiC-S signature container need to be packaged in a single ZIP archive with the following recommendations: Name: Format: Signed_Content.zip ZIP archive Content: 1 Main Document (Allowed Formats: PDF, In case of a detached signature: ZIP) 1 Trust Ok -Token (Allowed Format: PDF) 0 X Attachments (Format restriction: No executable files) Table 5: Specification of the content archive If the Service Provider discovers the usage of a detached signature on the business document or on an attachment, it should be possible to package the signed file and the respective signature within an additional ZIP archive. The next step in the creation of the ASiC-S signature container will be the creation and preparation of the container itself. Within this process, several rules have to be followed: The basis for the ASiC-S signature container should be a ZIP based container. The first file within the ASiC-S signature container has to be the file mimetype. o The content of the file has to be application/vnd.etsi.asic-s+zip. The folder META-INF has to be in place. o The folder META-INF has to contain the file signatures.xml. The name of the ASiC-S signature container should be e-codex_signature_container.scs. To follow the standard, the file extension for transportation should be.scs. This could be changed to.zip at the receiving Service Provider to make it more user friendly to the end user. The file Signed_Content.zip has to be on the root level of the container. No additional files or folders are allowed. Neither on the root level of the ASiC-S container nor in the folder META-INF. Figure 22: Example for a valid signature container 77

79 Technical Specification signatures.xml 7 The file signatures.xml has to be in accordance with the rules described in [ASiC-S]. Within Annex 3 of the ASiC specification, the following namespace declarations apply for the XML Schema definitions: <?xml version="1.0" encoding="utf-8"?> <xsd:schema targetnamespace=" xmlns:ds=" xmlns=" xmlns:xsd=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:import namespace=" schemalocation=" The XML Schema itself is described in Annex 5 of the ASiC specification, whereby the element <XAdESSignatures> is meant to be the root element of the XML: <xsd:complextype name="xadessignaturestype"> <xsd:sequence> <xsd:element ref="ds:signature" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:element name="xadessignatures" type="xadessignaturestype"> <xsd:annotation> <xsd:documentation>schema for parallel detached XAdES Signatures </xsd:documentation> </xsd:annotation> </xsd:element> 7 Sources: TS v1.1.1 (ASiC), TS v1.2.1 (ASiC) and TS v1.3.2 (XAdES) 78

80 5.6.4 Transmission of the token The signature container described in section 5.6 can be attached to the XML version of the main document creating the structure described in Figure 23: Signature container within the e-codex transport infrastructure. This structure can easily be transmitted via the transport infrastructure provided by WP5. Figure 23: Signature container within the e-codex transport infrastructure 79