European Federated Validation Service Study. Solution Profile Trustweaver on Demand

Transcription

1 European Federated Validation Service Study Solution Profile Trustweaver on Demand

2 This report / paper was prepared for the IDABC programme by: Author s name: Indicated in the solution profile below, under contact information Coordinated by: Hans Graux (time.lex), Christian Staffe (Siemens), Eric Meyvis (Siemens) Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N 14 Disclaimer The views expressed in this document are purely those of the writer and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof. Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative. This paper can be downloaded from the IDABC website: European Communities, 2009 Reproduction is authorised, except for commercial purposes, provided the source is acknowledged. 2

3 Executive summary The European Federated Validation Service (EFVS) Study was initiated by IDABC in order to assess the feasibility of specific measures to ensure the availability of a European scale federated electronic signature verification functionality. As a first step in the EFVS Study, information has been collected on twenty existing solutions that already provide all or some of the functionalities associated with European signature verification functionality, or that could provide valuable insights on how such an EFVS could be organised. This has been done by drafting standardised profiles of the identified solutions, focusing specifically on how each of these solutions (a) determine the validity of signature certificates; (b) verify electronic signatures created using these certificates; and (c) provide specific guarantees to their customers on the outcomes of these processes. The present document contains the solution profile for: Trustweaver on Demand. 3

4 Table of Contents EXECUTIVE SUMMARY 3 1 DOCUMENTS APPLICABLE DOCUMENTS REFERENCE DOCUMENTS 5 2 GLOSSARY DEFINITIONS ACRONYMS 8 3 SOLUTION PROFILE TRUSTWEAVER ON DEMAND 10 4

5 1 Documents 1.1 Applicable Documents [AD1] Framework Contract ENTR/05/58-SECURITY 1.2 Reference Documents [RD1] [RD2] [RD3] Project Management and Quality Plan (EFVS SC14 PMQP) DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999 on a Community framework for electronic signatures n.pdf Preliminary Study on Mutual Recognition of esignatures for egovernment applications 5

6 2 Glossary 2.1 Definitions In the course of this report, a number of key notions are frequently referred to. To avoid any ambiguity, the following definitions apply to these notions and should also be used by the correspondents. o Entity: anyone or anything that is characterised through the measurement of its attributes in an eidm system. This includes natural persons, legal persons and associations without legal personality; it includes both nationals and non-nationals of any given country. o eidm system: the organisational and technical infrastructure used for the definition, designation and administration of identity attributes of entities. This Profile will only elaborate on eidm systems that are considered a key part of the national eidm strategy. Decentralised solutions (state/region/province/commune ) can be included in the scope of this Profile if they are considered a key part of the national eidm strategy. o eidm token (or token ): any hardware or software or combination thereof that contains credentials, i.e. information attesting to the integrity of identity attributes. Examples include smart cards/usb sticks/cell phones containing PKI certificates, o Authentication 1 : the corroboration of the claimed identity of an entity and a set of its observed attributes. (i.e. the notion is used as a synonym of entity authentication ). o Authorisation: the process of determining, by evaluation of applicable permissions, whether an authenticated entity is allowed to have access to a particular resource. o Unique identifiers: an attribute or a set of attributes of an entity which uniquely identifies the entity within a certain context. Examples may include national numbers, certificate numbers, etc. o Official registers: data collections held and maintained by public authorities, in which the identity attributes of a clearly defined subset of entities is managed, and to which a particular legal of factual trust is attached (i.e. which are generally assumed to be correct). This includes National Registers, tax registers, company registers, etc. o egovernment application: any interactive public service using electronic means which is offered entirely or partially by or on the authority of a public administration, for the mutual 1 For the purposes of this Profile, the notion of authentication is considered to be synonymous with entity authentication, as opposed to data authentication. The notion of identification should be avoided to avoid confusion. 6

7 benefit of the end user (which may include citizens, legal persons and/or other administrations) and the public administration. Any form of electronic service (including stand-alone software, web applications, and proprietary interfaces offered locally (e.g. at a local office counter using an electronic device)) can be considered an egovernment application, provided that a certain degree of interactivity is included. Interactivity requires that a transaction between the parties must be involved; one-way communication by a public administration (such as the publication of standardised forms on a website) does not suffice. o esignature: data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication with regard to this data. Note that this also includes non-pki solutions. o Advanced electronic signature: an electronic signature which meets the following requirements: (a) it is uniquely linked to the signatory; (b) it is capable of identifying the signatory; (c) it is created using means that the signatory can maintain under his sole control; and (d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable; Again, this definition may cover non-pki solutions. o Qualified electronic signature: advanced electronic signatures which are based on a qualified certificate and which are created by a secure-signature-creation device, as defined in the esignatures Directive 2. o Validation: the corroboration of whether an esignature was valid at the time of signing. 2 See 7

8 2.2 Acronyms A2A...Administration to Administration A2B...Administration to Businesses A2C...Administration to Citizens CA...Certification Authority CRL...Certificate Revocation Lists CSP...Certificate Service Provider eid...electronic Identity eidm...electronic Identity Management IAM...Identity and Authentication Management IDM...Identity Management OCSP...Online Certificate Status Protocol OTP...One-Time Password PKCS...Public-Key Cryptography Standards PKI...Public Key Infrastructure SA...Supervision Authority SOAP...Simple Object Access Protocol SCVP...Server-based Certificate Validation Protocol SSCD...Secure Signature Creation Device USB...Universal Serial Bus TTP...Trusted Third Party XAdES...XML Advanced Electronic Signature XML...eXtensible Markup Language XML-DSIG...XML Digital Signature 8

9 9

10 3 Solution Profile Trustweaver on Demand General identification information Name and organisation The validation service is part of TrustWeaver On Demand, which is operated by TrustWeaver AB. Reference (on-line source) TrustWeaver s public web site is available at: TrustWeaver s repository is available at: At this repository site, it is possible to request an account, and then download all documentation of TrustWeaver On Demand. Contact information Johan Borendal johan.borendal@trustweaver.com Phone: Fax: Address: TrustWeaver AB, Wallingatan 12, Stockholm, Sweden 10

11 Scope of the solution Services offered (What services does the solution offer to a relying party? This should include most notably the three basic services above validation of certificates, verification of the signature, and ensuring trustworthiness and legal liability but may also cover additional services e.g. semantic services, archiving of documents/signatures, maintenance, time stamping, security/reliability metrics for the security level of the signature and the certificate, Services that are not currently available but which are planned for the future may also be indicated. ) Overview of TrustWeaver On Demand TrustWeaver On Demand is a comprehensive security compliance service. It offers support for a wide range of signing and validation mechanisms that are legally recognized by local tax authorities in a broad range of countries. Relying upon a modern Services Oriented Architecture (SOA), applications such as EAI-systems, archiving systems and B2B service providers ( hubs ) can rapidly integrate TrustWeaver On Demand in order to apply and validate electronic signatures. TrustWeaver On Demand s unique features including B2B-strength support for multiple certificates and a variety of signature formats can be mixed and matched in order to offer a high level of local recognition of electronic signatures for large, heterogeneous groups of businesses. 11

12 The following services and tools are provided by TrustWeaver On Demand: Signatory services: Sign, validate, timestamp, package This function applies the required type of digital signature(s) to documents depending on configuration (e.g. country parameters). It supports software-based (in EU terms: Advanced) electronic signatures and a variety of hardware-based (in EU terms: Qualified) electronic signatures. Multiple hardware Secure Creation Signature Devices (SSCDs) are supported, over which signing transactions can be load-balanced in order to increase performance. The signing function also normally adds certificate validity information and time-stamps. Relying party services: Validate, timestamp, package This function validates signatures, again possibly based on country parameters to achieve compliance with local requirements, when receiving a signed document. It supports multiple validation mechanisms and protocols, which allows the receiver to accept signatures based on certificates from a large number of CAs. Audit tools: Revalidate archived signed/validated document This function re-validates stored and signed document. For signatories, re-validation is based on revocation and certificate data that was created at the time of signing. For relying parties, it is the data 12

13 created during invoice validation that is the basis for re-validation. Provided that the archived documents (in particular e-invoices) contain signatures with time-stamped revocation and certificate data, the verification process is carried out without any dependencies on online validation services. Archive time-stamping services: Time-stamping using an Italian accredited TSA Due to Italian tax regulations, all tax-relevant documents need to be time-stamped by an accredited Italian TSA and signed with a qualified electronic signature within a maximum 15 days after they were received and archived. TrustWeaver On Demand includes mechanisms to perform these activities. The functions above support multiple signature formats. TrustWeaver On Demand also supports a number of input document formats allowing embedded signatures such as various XML formats and PDFs. The solution also allows any document to be signed using enveloping technology. Such enveloping signatures encapsulate the data to be signed, and the signatures typically have the formats attached CAdES-T/A 3 or S/MIME including CAdES-T/A. Detailed description of the Signature Validation service (part of the relying party service) Validation of signed documents is performed according to the following process: 1. The validation client creates a Web Services validation request. This validation request includes the signed document, sender/receiver tags, input signature format, and requested output data format. This Web Services validation request is sent over serverauthenticated SSL 4 to the Signature Validation service. 2. The signature(s) cryptographically verified according to conventional algorithms. 3. The signing certificate(s) is verified with respect to the CA s signature, as well as time and revocation status; when applicable, external validation services are used. 4. The signed document is validated on the business document level. This is achieved by the compliance logic checking that the sender/receiver tags match the country of the signing certificate(s). 5. The revocation and certificate data are time-stamped and embedded into the signature. If the signature envelope already contains such validation data from the sender, it is replaced with refreshed validation data. Also, the original document is parsed from the signature message. 6. Finally, the validation result, original document and embedded validation data are returned in the validate Web Services response. TrustWeaver On Demand supports two models for certificate validation: The shell validation model. In this model, the certificates are validated based on the current status of the CA-certificate. This is the default configuration for certificate validation in TrustWeaver On Demand. The chain validation model. In this model, the certificates are validated based on the status of the CA-certificate at the time when the certificate was issued. Hence, the CAcertificate may be revoked or expired at the time of validation, but validation will nevertheless succeed if the CA-certificate was valid when the certificate was issued. The chain model is widely adopted by CAs in Germany. Therefore the chain model is 13

14 configured in particular for the validation of German certificates. Specifically for use in e-invoicing, the legal requirements for validation of signed documents are outlined in TrustWeaver Compliance Map TM. Application domain (e.g. sector or application types) (Is the solution usable in any sector or application field (i.e. is it generic in scope), or is it currently limited to a specific sector, application or domain? If it is currently restricted, would it be possible to extend the solution to other sectors, applications or domains? What would need to be changed?) The principal application of TrustWeaver On Demand is currently the signing and validation of electronic invoices. In particular, the legal documentation i.e. TrustWeaver Compliance Map TM and optionally a legal design targets the legal instruments needed to validate e-invoices with respect to electronic signatures. Technically, however, TrustWeaver On Demand can be used for validating any signed document provided that the signature format and CA are supported by TrustWeaver On Demand. What may be subject to change, if needed, is the legal documentation required for validating other types of documents. If there is no need for any legal documentation for a certain type of signed documents, no changes are needed at all to TrustWeaver On Demand. CAs covered by the solution (How many CAs are presently covered by the solution, and which ones? Do they include CAs established in multiple countries or states?) CAs are supported in the following countries: Bulgaria, Cech Republic, Germany (2), Greece, Italy (2), Lithuania, Poland, Romania, Slovenia, Spain, Austria, France, Hungary, the Netherlands, Portugal and Switzerland. Information omitted at the solution owner's request. Extensibility of the solution (Can additional CAs be integrated into the solution? If so, are there restrictions? Have such extensions been done in the past yet, or are any extensions currently planned?) Yes, additional CAs can easily be integrated into TrustWeaver On Demand. Technically, there are no known restrictions with respect to adding CAs. Adding CAs to TrustWeaver On Demand is a well-proven process in TrustWeaver s release cycles, and more or less every product release has included support for one or more new CAs. In addition to the technical implementation, TrustWeaver performs an extensive legal process in close co-operation with local law firms to evaluate the applicable regulations in the countries where the CAs reside. 14

15 TrustWeaver is always open for receiving requests of new CAs and countries to be supported. The following countries will be added for e-invoicing compliance purposes based on existing CAs: Australia, Hong Kong, Iceland, New Zealand, Singapore, and United Arab Emirates. The final conclusions of legal research will drive the decision to add new CAs to the solution. Business model/cost model of the solution (How is the solution funded? Is it envisaged as a for-profit model? Who pays contributions, and for what type of services? What profits (if any) are made with the services provided by the solution? Upon request of the correspondent, any communicated price information or other commercially sensitive information will not be disclosed.) For electronic invoices, a transaction fee is used as the base commercial model. Information omitted at the solution owner's request The solution has not been designed to be offered on a non-profit basis, however different business models can lead to the provision for free or a nominal fee of relying party or audit services. Information omitted at the solution owner's request. 15

16 Technical approach Validation approach (Does the solution validate signature certificates, electronic signatures based on a hash value of the signed document(s), or signed documents with embedded signatures (attached signatures - enveloping or enveloped signatures detached signatures)? What is the maturity of the solution i.e. can it be classified as a known technical approach, such as a trusted list, bridge, or validation platform?) The current version of TrustWeaver On Demand, version 1.10, validates only documents with attached signatures and certificates. The attached signatures are enveloping in the cases of PKCS #7, CMS, CAdES-T/A, XAdES-T/A and S/MIME. The attached signatures are embedded (enveloped) in the cases of cxml with embedded XAdES-T/A and signed-pdf. TrustWeaver On Demand version 1.10 SP1 will support detached CMS signatures. With regard to certificates (How does the validation of certificates work based on OCSP, CRLs, or both? What certificate profiles are supported by the solution?) Both OCSP and CRLs are supported by TrustWeaver On Demand. The architecture of the Signature Validation service includes connectors to external CRL repositories and OCSPresponders. CRL repositories can either be accessed over LDAP or HTTP, while OCSPresponders are accessed using HTTP as the transport protocol. The retrieved revocation data, such as CRLs or OCSP responses, are used for checking the signing certificate s revocation status. The following certificate profiles are supported by TrustWeaver On Demand: ITU-T X.509, PKIX, and ETSI TS Qualified Certificate profile. The signing certificate is checked as follows: 1. The CA signature is cryptographically checked using the CA certificate. 2. The expiration date is checked. 3. The revocation status (at the time of the request) is checked against the CA's CRL or OCSP responder. 16

17 The CA certificate is validated as follows: 1. The CA signature is cryptographically checked using the root certificate. 2. The expiration date is checked. 3. When applicable, the CA certificate s revocation status is checked against the upperlevel s CA CRL or OCSP responder. With regard to signatures (What signature formats are supported by the solution - PKCS #7, CMS, XML signatures, PDF signatures, XAdES, CAdES, or others?) TrustWeaver On Demand supports a wide range of signature formats. The following signature formats are currently supported: CAdES-T/A, PKCS #7, CMS, S/MIME, XAdES-T/A, XMLsignature, XMLcon 5, and PDF-signature. By using appropriate combinations of those signature formats, cross-border document (in particular e-invoice) flows with double signatures and long term archiving using time-stamps can be ensured. The document and signature combinations currently recommended are outlined in the table below. Document type cxml PDF Recommended signature format cxml with enveloped XML signature(s) according to XAdES-A. 1. XMLcon with enveloped XAdES-A signatures. The PDF must be proper XML and e.g. BASE64 encoded. 2. S/MIME enveloping signature(s) according to CAdES-A. Input data must be MIME-encoded. 3. PDF with enveloped signatures according to CAdES-A. Other XML formats XMLcon with enveloped XAdES-A signatures. Other documents 1. XMLcon with enveloped XAdES-A signatures. Binary data must be proper XML and e.g. BASE64 encoded. 2. S/MIME enveloping signature(s) according to CAdES-A. Input data must be MIME-encoded. 3. PKCS #7 enveloping signature(s) according to CAdES-A. TrustWeaver is constantly adding more document formats as input data, and more signature formats as output data. 17

18 Multi-signatures (Is the solution capable of validating multiple signatures on a document? Does it support independent signatures (co-signatures) and/or overall countersignatures?) Yes, TrustWeaver On Demand has the capability of validating multiple signatures applied to one document. Independent signatures (co-signatures) are supported; counter-signatures are however not supported. Logging and auditing (Is the use of the solution logged, and if so, to what extent? Do users of the solution have the possibility to perform audits or to gain access to independent auditing reports?) All signing and validation calls are extensively logged by TrustWeaver On Demand. The following entries are logged: Operation Sign, Validate or ValidateArchive. Source client s SSL-certificate details and/or IP-address. InputType format of the data in the request. OutputType expected format of the processed data. JobType optional extension to the operation. SenderTag sender s country code. ReceiverTag receiver s country code. InDataHash hash of the data in the request. OutDataHash hash of the data in the response. The log files are transferred to a transaction database, where all entries are searchable. The log files mentioned above, plus the reverse proxy and switch logs, are reviewed daily. Any incident is reported and followed up immediately. All TrustWeaver On Demand activities are logged in Windows event viewer application log. Also, the system and security logs contain valuable information on the machine running TrustWeaver On Demand. When a critical event occurs, a notification is automatically triggered and sent via to a designated group of administrators. Such critical events can cover errors and warnings from TrustWeaver On Demand, the time synchronization service, the network load balancing service and the web server. In addition to these features, TrustWeaver On Demand is monitored by the data centre s 18

19 powerful host and service monitor tools. These tools monitors the network services, as well as host resources such as processor load, disk and memory usage, running processes, etc. In case of failures, SMS are sent out to the administrators. Finally, to measure availability, an independent monitoring service runs a transaction on TrustWeaver On Demand every five minutes from four different geographical locations. TrustWeaver On Demand is subject to SAS 70 Type II audits that are performed by PriceWaterhouseCoopers on a yearly basis. These audits are documented in a SAS 70 Type II report. Restrictions imposed on CAs (What technical requirements are imposed on CAs, e.g. with regard to standards, formats or certificate profiles that they need to adopt? This includes e.g. the inclusion of certain information in signature certificates that is necessary in specific sectors.) The CAs should support at least one of the following certificate profiles: ITU-T X.509, PKIX, and ETSI TS Qualified Certificate profile. In countries where Qualified Electronic Signatures are mandatory for a specific application (e.g. e-invoicing), the signing certificates should comply with the Qualified Certificate profile and the CA should be accredited by the appropriate authorization body. Usage of the solution by relying parties (How do relying parties use the solution? Are there software components which they need to integrate into their own systems, is it a web service, etc.) Information omitted at the solution owner's request. TrustWeaver On Demand is accessed over Web Services calls over client authenticated HTTPS. TrustWeaver provides sample code and extensive documentation to be used for integration with TrustWeaver On Demand using Web Services. Information omitted at the solution owner's request. Technical flexibility 19

20 (Given the technical characteristics outlined above, could the technical requirements of the solution be changed to increase its flexibility (e.g. by supporting other signature standards, validation methods, certificate profiles, etc...))? Yes, TrustWeaver On Demand s flexible architecture can easily be extended with more signature standards, validation methods and certificate profiles. Adding more such standards is an integral part of the TrustWeaver On Demand release project. More or less every TrustWeaver On Demand release introduces a new document format, signature format or certificate format. Status of the project/actual usage of the solution (What is the status of the project (e.g. in development, prototyped, in production, etc.). What is the actual usage of the solution (e.g. in terms of relying parties adopting the solution to validate electronic signatures) and what are the impacts of its use? How many transactions, how many certificates does it handle?) The solution has been in production since Many hundreds of end users access the solution for tens of millions of transactions annually. Information omitted at the solution owner's request. Legal approach Relationship with the CAs 6 (What requirements does a CA need to meet before being able to accede to the solution? Specifically, which processes and procedures have been foreseen to vet CAs? What kind of agreements are put in place with the CAs, and what are the main issues addressed in these agreements?) Depending on the application for which the service is used, applicable legal requirements concerning the CA in a specific country are carefully assessed in close co-operation with a local law firm. When a shortlist of CAs has been identified, TrustWeaver sends a questionnaire to these CAs with a list of technical and legal questions. The agreements settled with the CAs are mainly the agreements presented by the CA itself: enrolment forms, authorizations etc. In virtually all cases, those documents refer to the CA s CP/CPS, which in turn contains the service level terms which are the crucial issues when operating TrustWeaver On Demand with an integrated 20

21 CA. Relationship with the relying parties (How does a relying party get the right to use the solution? What kind of agreements are put in place in relation with the relying parties, and which services can be offered to the relying parties via these agreements?) The type of agreement with relying parties and the modalities of its formation depend on the individual circumstances including the type of application to be used. TrustWeaver offers an integrated service and the ambition to package the required agreements for each supported application. Reliability of the signature certificates (What procedures does the solution put in place to determine the reliability of signature certificates? Are certificate policies checked? Are supervision/accreditation schemes considered? Have specific security criteria been defined, and does the solution support multiple levels of reliability? If so, can the solution distinguish between qualified and nonqualified signature certificates?) In order to use TrustWeaver On Demand for automated validation purposes, a set of sender and receiver tags as ISO 3166 country codes for verification must be set. These verification tags in turn are connected to a certificate policy. Each validation request contains sender and receiver tags. The sender and receiver tags are explicitly included in the Web Services validate request as parameters. Those variables are matched against the available verification tags in the TrustWeaver On Demand configuration in order to identify a certificate policy. From this certificate policy, in turn, the appropriate CA certificate and revocation data can be obtained and used for validation of the signing certificate. If a document is signed with multiple signatures, each signature is verified independently from the other(s). The Signature Validation service s compliance logic ensures that the document is signed with an appropriate signature. Supervision, accreditation and security evaluations of the CA s are managed when the partnership with the CA is established. Legal value of the signatures (Can the solution make a statement on the legal value of signatures? If so, what factors are taken into account? If multiple degrees of validity are supported by the system (i.e. a statement on the reliability of the signature as a whole is provided), then how are these reliability levels defined and communicated to the relying party? Can the solution identify if a signature can be considered a qualified signature (i.e. if it is an advanced electronic signature based on a qualified certificate created by using a secure signature creation device, as defined in the esignatures Directive)? Finally, if the certificate policies contain restrictions on the use of the signatures (e.g. limitation to 21

22 transactions of a certain amount or exclusion of certain sectors), then are these restrictions taken into account when communicating the legal value of the signature?) The response below takes e-invoices as an example other applications can be addressed in similar ways using the same policy-driven logic to ensure legal validity and compliance of signed documents on different levels. TrustWeaver On Demand s validation logic is based on the TrustWeaver Compliance Map TM in conjunction with the compliance configuration. The compliance configuration is in turn constituted by a number of compliance items, where compliance is defined by the intersection of country x and country y. For country x and y, applicable certificate policies are configured as described in the question above. If country x requires a Qualified Electronic Signature created by a dedicated CA, this and only this CA will be able to validate the Qualified Electronic Signature. If country y requires an Advanced Electronic Signature created by a dedicated CA, this and only this CA will be able to validate the Advanced Electronic Signature. If both country x and y requires a dedicated CA to be used, the signature needs to be double, and both certificates must be validated as described above. Liability of the solution provider (What liability (if any) does the solution provider accept with regard to its services? Specifically, if the signatures rely on qualified certificates as defined under the European esignatures Directive (if this is applicable to the solution), then how does the solution address its liability for providing guarantees to the public in relation to such certificates?) TrustWeaver does not offer Certification-Service-Provider services and does not issue certificates to the public. The liability, whether based on legislation or private decisions, of supported CAs is determined in the CA s documentation and is part of the CA service parameters that TrustWeaver evaluates prior to supporting a CA. If TrustWeaver were to attract liability as a result of a CA breaching its contractual or legal obligations, TrustWeaver will seek appropriate recourse against the faulty CA. For liability aspects of the signing or validation services themselves, TrustWeaver typically works with industrial standard Service Level Agreements accepting comparatively high levels of liability. Quality of service and availability (Does the solution provide any guarantees with regard to the quality of its service (i.e. the reliability of the information it provides) and its availability to relying parties, other than already mentioned above?) TrustWeaver On Demand is operated in two highly secure data centres which are geographically separated, and is subject to a security policy which includes guidelines for maintenance, change management, disaster recovery, security and operations. The security policy is written to meet the demanding requirements defined by e.g. the German signature act and regulations. This section gives an overview of the security policy contents and the data centre operations with respect to TrustWeaver On Demand. 22

23 The data hosting centres where TrustWeaver On Demand is located provide a high level of physical security and related quality features: Information omitted at the solution owner's request. The quality of TrustWeaver On Demand operations are described extensively in the TrustWeaver On Demand service agreement which includes the service level and support terms. For example, 99.9% uptime of TrustWeaver On Demand is guaranteed in this agreement. Independence of the solution (Is the solution fully unaffiliated (legally unrelated) with all of the CAs that are integrated into the solution? If not, then how is trust created towards the relying party for affiliated CAs?) All signing CAs are legally unrelated to TrustWeaver. Compliance with the provisions of the esignatures Directive (Does the solution support signatures from CAs established in countries that are not subjected to the provisions of the esignatures Directive (Directive1999/93/EC)? If so, how are they integrated and how does the solution address their legal value?) All CAs currently supported by TrustWeaver On Demand are established in the European Union with one exception: Swisscom in Switzerland. The CAs in the European Union are subject to the provisions of the esignatures Directive (directive 1999/93/EC). TrustWeaver will in the future support other CAs, in addition to Swisscom, that are not established within the EU. For such CAs TrustWeaver will apply quality and regulatory compliance criteria that are required for a high level of recognition and legal compliance depending on the application used. This will be a case-by-case decision backed by local legal advice. As a general matter, local accreditation or certification in accordance with available public or voluntary standards will be an important factor in this assessment. Suitability of the solution at the European level Assessment of the solution owner 23

24 (Does the solution owner feel that the solution could be adapted to operate at the European level not applicable if the solution already functions at the European level?) TrustWeaver On Demand supports transactions (domestic and cross-border) in all EU Member States already today. TrustWeaver On Demand is extremely well adapted to operate at the European level. Currently 18 European CAs are supported by TrustWeaver On Demand, and for e-invoicing purposes additional 11 European countries rely upon those CAs. Issues to be addressed (Which issues does the solution owner feel would still need to be addressed before the solution could be made to operate at the European level?) For validation of externally signed documents, where a CA has been used that is currently not supported by TrustWeaver On Demand, support for this CA needs to be configured in TrustWeaver On Demand. The effort for doing so is estimated to be very low in most cases. A legal assessment may need to be part of this activity so as to ensure that relying parties will only get positive validations for signatures that meet minimum legal and commercial criteria the kinds and level of requirements for such assessments will depend on the circumstances such as the application for which TrustWeaver On Demand is used. Integration with other validation solutions (Is there any strategy to allow the solution to interoperate with other validation solutions, i.e. can the solution connect to other islands of trust?) TrustWeaver is currently running a project in order to significantly strengthen interoperability with other signature service providers and CAs. In the e-invoicing compliance market, which is TrustWeaver s main current focus, TrustWeaver On Demand will be interoperability tested with signatures created by external signature service providers. If or when needed, TrustWeaver On Demand will be integrated with islands of trust identified in such project. Market Impacts (How could the solution impact or influence the European market?) TrustWeaver On Demand is today by far the richest signature and validation/audit engine on the European Market. By integrating multiple levels of legal compliance and recognition validation and associated long-term auditability features, based on policy-driven and easily configurable parameters that can take into account transaction-specific requirements and features including applicable laws and industry-specific requirements, TrustWeaver On Demand has already enabled hundreds of companies of all sizes to transact effortlessly and with high degrees of legal 24

25 certainty over long periods of time for stored documents across the EU and beyond. TrustWeaver is open for broadening the scope of its services; validation of other signed documents may also be considered for the European market. Any other comments? (The solution owner can provide any other comments that (s)he feels were not adequately covered elsewhere) All cryptographic operations of TrustWeaver On Demand are performed in TrustWeaver SigG Library, which in turn is subject to a Manufacturer s Declaration which has been written in cooperation with T-Systems. The Manufacturer s Declaration has been approved by the German Bundesnetzagentur, and is published at TrustWeaver builds and provides solutions integrating legal, technical and process aspects through a multi-disciplinary team in which each person brings his or her unique experience to bear. Our legal team includes some of Europe s most experienced e-business and e-invoicing lawyers. With experience from organizations such as the International Chamber of Commerce, EU and the UN, they have a strong global network of contacts and references with key decision makers. Our multicultural team covers large parts of Europe directly and has established ongoing cooperation with expert tax and e business lawyers in other countries. Through their vast legal network, constant contacts with tax authorities and active participation in all relevant European standardization groups such as CEN and Fiscalis, TrustWeaver s team is always on top of the latest legal developments. We anticipate regulatory changes where these occur and ensure our customers systems use the right signature at any moment and can prove integrity, authenticity and trustworthiness of their data over very long periods of time without external dependencies. 25

26 26