The document discusses the role and functions of a Trusted Archive Authority (TAA). A TAA is responsible for long-term storage of data and ensuring evidence of data integrity over time. The document outlines the key components and functionalities needed to enable a TAA service, including policies, procedures, infrastructure design, security, and audit capabilities. It also discusses document management systems, electronic signatures, timestamping, and other relevant standards and technologies.

1. TAA-Trusted Archive Authority Presented by Jan Biets [email_address] +32(0)477 32 90 11 Mechelen - Belgium

2. “PRE” All rights reserved by the author . No citing, abstracting, or other usage is permitted without written permission Contact address: [email_address]

3. Agenda Definitions: LTANS: Long-Term Archive and Notary Services TAA: Trusted archive authority Description TAA.org: “ A TAA accepts data for long-term storage and is responsible for ensuring that an evidence trail is produced and stored to enable demonstration of data integrity at any point in the future. “ Non-repudiation - undeniable - legally binding

4. TSA E-SIGN CA - PKI ERS Management LAW Policy Security Business Process User interface Agenda

5. Agenda law & standards managed documented other modules operations TAA

6. RFC3281 : An Internet Attribute Certificate Profile for Authorization RFC3280 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R FC3369 :Cryptographic Message Syntax (CMS) RFC3126 : Electronic Signature Formats for long term electronic signaturesRFC3161 : Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) RFC2459 : Internet X.509 Public Key Infrastructure Certificate and CRL Profile PKCS#7 : Cryptographic Message Syntax Standard PKCS#11 : Cryptographic Token Interface Standard PKCS#12 : Personal Information Exchange Syntax Standard FIPS PUB 186-2 digital signature standard RfC 4871 - DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Service Overview draft-ietf-dkim-overview-10 (11 juli 2008)RfC 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileRfC 5055 - Server-Based Certificate Validation Protocol (SCVP)RfC 3379 - Delegated Path Validation and Delegated Path Discovery Protocol RequirementsETSI 201 733 - ETSI Electronic Signatures and InfrastructuresACVS: An Advanced Certificate [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 0989, February 1987.[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. INTERNET DRAFT DKIM Service Overview February 2008 Hansen, et al. Informational [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. TAA – the complexity (?)

7. TAA – functional architectural design IAM CA TSA DMS ERS i-Sign HW Event logging (audit trail) storage SA* Abbreviations : IAM – identity & access management CA – Certification authority RA – registration authority SA – “source authentic” ERS – Evidence record syntax

8. TAA - IAM CA – PKI and RA: strong identification and access management (authorisation) “ face to face” issuing smart cart / token, Based on authentic source (SA): database of members of closed environment / target public. Accurate management of authentic source, and respectively authorisations. Class 3: for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority. Abbreviations : CA - Certification Authority , ETSI TS 101 456 PKI - Private Key Infrastructure, SA – “source authentic” RA - Registration Authority , ETSI TS 101 456

9. TAA - electronic signature XAdES ( XML Advanced Electronic Signatures ) is a set of extensions to XML- DSig recommendation making it suitable for advanced electronic signature. Xades XL, extended long-term, adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available; XAdES specifies precise profiles of XML- DSig for use with advanced electronic signature in the meaning of European Union Directive 1999/93/EC. One important benefit from XAdES is that electronically signed documents can remain valid for long periods, even if underlying cryptographic algorithms are broken. Based on : Xades , ETSI 101 903

10. TAA - electronic signature Legal points of interest / attention: sometimes constraints: only one copy as the original ! or not allowed to store abroad (difficult to verify on internet!) sign documents individually (not batch files) use Pdf-a format Based on : Xades , ETSI 101 903

11. TAA - TSA The technique is based on digital signatures and hash functions . First a hash is calculated from the data. A hash is a sort of digital fingerprint of the original data: a string of bits that is different for each set of data. If the original data is changed then this will result in a completely different hash. This hash is sent to the TSA. The TSA concatenates a timestamp to the hash and calculates the hash of this concatenation. This hash is in turn digitally signed with the private key of the TSA. This signed hash + the timestamp is sent back to the requester of the timestamp who stores these with the original data (see diagram). Since the original data can not be calculated from the hash (because the hash function is a one way function ), the TSA never gets to see the original data, which allows the use of this method for confidential data. Abbreviations : TSA - Timestamp Authority , ETSI TS 102 023

12. TAA - TSA Abbreviations : TSA - Timestamp Authority , ETSI TS 102 023

13. TAA - management Management has to provide: a set of resources (budget , and other means) , to enable the execution of the projects (programme) and the operations of the applications (well defined roles and responsibilities, policies , and a suitable organisation)

14. TAA - management

15. TAA - other elements Business Case Why, what, how (justification) Risk assessment What are the risks “what if not” Business Process Flow Define the streams of the document flows DMS Choice ‘commercial’ product , or open source User interface (GUI) Abbreviations : DMS - Document Management System, GUI – Graphic User Interface

16. TAA - approach creating a system to enable the TAA service : policy, A policy is typically described as a principle or rule to guide decisions and achieve rational outcome(s). a policy will contain the 'what' and the 'why', Obligations and liability Records to be deposited Time of deposit (retention) Data integrity, and access continuity assurances Accepted formats processes, procedures, procedures (or protocols) contain the 'what', the 'how', the 'where', and the 'when'. security, infrastructure/architectural design and audit Verify: systems, documents, and operations

17. TAA – Risk assessment 360° (off-site) Back-up policy ICT room policies processes People & staff Physical security operations TAA

18. TAA – Risk assessment 360°security tiers) Policy Security Policy HR Trusted Archival Authority Physical Security Building Security Policy Security Application security Server room Organisation & management Policy System Security Authorisation & authentification Network Security User interface Security procedures people

19. TAA – basic functionalities and features of a DMS Depose documents User management Access control Document life cycle management (retention policy) Audit trail (event logging) Proof of document integrity Web access (intranet, internet) Document management system (user interface),

20. TAA – functionalities: audit trail (logging of events) System: Authorisation matrix Change file detection Log file is encrypted Secure logging Operator alerts System alarms System modifications have to be done by ‘system administrator’ + logging (+ documented) Based on results of risk assessment 1/2 Remark : CWA 14167-1. Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures

21. TAA –functionalities: audit trail (logging of events) Procedures 4-eyes (or more) in case system operations / modifications Administrator access management by means of smart card and certificate by CSO Dashboard (events) Authorisation matrix Configuration user management , access management modifications Who has, when , what document deposed, modified, consulted, changed, deleted, shared? 2/2 Remark : CWA 14167-1. Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures Abbreviations : CSO – Chief Security Officer

22. TAA – basic functionalities: user management (system) authority assigns access rights to users User management data (access rights) information exchange via Certificate smart card, and authentic source; Roles: Authority Employee System administrator (local office/authority) Responsibilities: Depose Copy Share Delete View Annotate (other actions) Based on results of risk assessment

23. TAA – functionalities: proof of integrity System generates ‘ERS’ per document, to proof long term evidence (non-repudiation / undeniable ) Kind of ‘ fingerprint ’ Timestamp Electronic signature Certificate (status) Root chain certificate Hashing (verification / proof of ‘un-changed’ status of content System regenerates periodically ERS (based on certificate life cycle) Abbreviations : ERS – Evidence record syntax

24. TAA – Overview of Archiving Features Archived object Could be any electronic file / data. Object meta-data Author, category, size, version, date, key-word Digital Signature Relevance is depending on legal requirements. it is mandatory to proof the legal ‘serieux’ of the users; ‘ legal note’: Do not sign ‘batch’ –files , nor ‘zip’-ed formats. Archived Object Object META - DATA Digital Signature ( optional ) Complementary data Archive meta - data Evidence record O b j e c t ’ s c o n s e r v a t i o n a t t r i b u t e s

25. TAA – ERS , Overview of evidence record syntax Complementary data Digital certificate Certificate chain Certificate revokation list Archive meta-data Document owner Archival time Origin of document Evidence record Document finger print Timestamp Hash link

26. TAA – basic architectural design Hardware & Storage Policy & Procedures Web Service DMS – user interface ERS engine TSA Security & Legal

27. TAA – functional architectural design IAM CA TSA DMS ERS i-Sign HW Event logging (audit trail) storage SA* Abbreviations : IAM – identity & access management CA – Certification authority (RA – registration authority) SA – “source authentic” ERS – Evidence record syntax

28. TAA – architectural design Abbreviations : LTAP – long term archival protocol ERS – Evidence record syntax

29. Afterword Business case, justification Risk analysis, threat , vulnerability Legal: sometimes constraints: only one copy as the original ! Sometimes not allowed to store abroad (difficult to verify on internet!) Sign documents individually (not batch files) Advice to use Pdf-a format Business process flow; Select technology; Usability, user friendly GUI;

30. Afterwords : points of attention during conceptual design Recoverability and Data Integrity Architecture / Design to achieve required availability Reliability Manageability Backup and Recovery Performance Scalability [Not every application supports more transactions or more users when adding CPU and Memory] Installation Requirements Configuration Requirements Maintainability Requirements Localisation / Internationalisation Requirements & constraints Operations-, Support- and Troubleshooting Requirements Documentation Requirements M onitoring: Application Level Monitoring must be explicitly requested, otherwise you just get system- and database monitoring. Archiving and Restoring

31. TAA – some other fields of application 1. Liberal professions, have in some cases long term - legal- responsibilities, i.e. Lawyers architects : a 10 year professional responsibility for building plans accountants : also responsible for VAT declarations auditor/revisor (head of accountants): signing of fiscal year documents/statements 2. Log files log files (systems, applications,...) should not be changed, only by dedicated staff (i.e. chief security officer), and applicable policy, or local laws 3. Banks, insurance companies; stock exchange approval of credits and loans: who has done what in accordance of the mandate timeline and sequence (order) of the performed transactions (using time-stamping) 4. Medical statements and medicines prescription patients' medical records in electronic form

32. TAA – basic functionalities: proof of integrity 5. Justice (ministry) defined and traceable work streams from police statement to lawyers and judges, and classification of files: every ‘role’ has added, viewed, changed documents. Files can not be changed by un-authorised people, nor been lost, with dramtic legal consequences 6. Patenting (every country has a patent office; patent is public information) to be able to prove who was first to come up with an idea or to patent a document, drawing, design, music score, research results,... Escrow 7. IPP (intellectual property protection) research companies have a legal trace of the progress of the search for a new product this can/could be private information (un-disclosed for third parties)

33. TAA – basic functionalities: proof of integrity 8. Registered mail electronic mail with proof of content, 'addressee", time , and acceptance 9 . Closed environments tax governments, pension authority, banks, insurances, stock exchange (logging of transactions),.... 10. Accounting services companies storage of accounting companies customers' documents in electronic format– outsourced electronic archiving (is implemented in some Eastern European countries) 11. Apostilles: It specifies the modalities through which a document issued in one of the signatory countries can be certified for legal purposes in all the other signatory states. Such a certification is called an apostille ( French : certification ). It is an international certification comparable to a notarisation in domestic law. 12. Invoices: Electronic invoices archival, helpdesks, customer’s service , legal purposes.

34. Questions? ? ? ? ? ?

35. Certificate classification (Verisign) VeriSign uses the concept of classes of digital certificates Class 1 for individuals, intended for email. Class 2 for organizations, for which proof of identity is required. Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority . Class 4 for online business transactions between companies. Class 5 for private organizations or governmental security. https :// www.verisign.com /support/ roots.html

36. The EU Directive 1999/93/EC on a Community framework for electronic signatures [3] defines the term qualified certificate as: "a certificate which meets the requirements laid down in Annex I and is provided by a certification-service-provider who fulfils the requirements laid down in Annex II": Annex I : Requirements for qualified certificates Qualified certificates must contain: (a) an indication that the certificate is issued as a qualified certificate; (b) the identification of the certification-service-provider and the State in which it is established; (c) the name of the signatory or a pseudonym, which shall be identified as such; (d) provision for a specific attribute of the signatory to be included if relevant, depending on the purpose for which the certificate is intended; (e) signature-verification data which correspond to signature-creation data under the control of the signatory; (f) an indication of the beginning and end of the period of validity of the certificate; (g) the identity code of the certificate; (h) the advanced electronic signature of the certification-service-provider issuing it; (i) limitations on the scope of use of the certificate, if applicable; and (j) limits on the value of transactions for which the certificate can be used, if applicable.

37. The EU Directive 1999/93/EC on a Community framework for electronic signatures. Annex II Requirements for certification-service-providers issuing qualified certificates (a) demonstrate the reliability necessary for providing certification services; (b) ensure the operation of a prompt and secure directory and a secure and immediate revocation service; (c) ensure that the date and time when a certificate is issued or revoked can be determined precisely; (d) verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued; (e) employ personnel who possess the expert knowledge, experience, and qualifications necessary for the services provided, in particular competence at managerial level, expertise in electronic signature technology and familiarity with proper security procedures; they must also apply administrative and management procedures which are adequate and correspond to recognised standards; (f) use trustworthy systems and products which are protected against modification and ensure the technical and cryptographic security of the process supported by them; (g) take measures against forgery of certificates, and, in cases where the certification-service-provider generates signature-creation data, guarantee confidentiality during the process of generating such data; (h) maintain sufficient financial resources to operate in conformity with the requirements laid down in the Directive, in particular to bear the risk of liability for damages, for example, by obtaining appropriate insurance; (i) record all relevant information concerning a qualified certificate for an appropriate period of time, in particular for the purpose of providing evidence of certification for the purposes of legal proceedings. Such recording may be done electronically; (j) not store or copy signature-creation data of the person to whom the certification-service-provider provided key management services; (k) before entering into a contractual relationship with a person seeking a certificate to support his electronic signature inform that person by a durable means of communication of the precise terms and conditions regarding the use of the certificate, including any limitations on its use, the existence of a voluntary accreditation scheme and procedures for complaints and dispute settlement. Such information, which may be transmitted electronically, must be in writing and in readily understandable language. Relevant parts of this information must also be made available on request to third-parties relying on the certificate; (l) See next slide…

38. The EU Directive 1999/93/EC on a Community framework for electronic signatures. (l) use trustworthy systems to store certificates in a verifiable form so that: only authorised persons can make entries and changes, information can be checked for authenticity, certificates are publicly available for retrieval in only those cases for which the certificate-holder's consent has been obtained, and any technical changes compromising these security requirements are apparent to the operator.

39. The EU Directive 1999/93/EC on a Community framework for electronic signatures : Profiles XAdES defines six profiles (forms) differing in protection level offered. Each profile includes and extends the previous one: XAdES , basic form just satisfying Directive legal requirements for advanced signature; XAdES-T (timestamp), adding timestamp field to protect against repudiation; XAdES-C (complete), adding references to verification data (certificates and revocation lists) to the signed documents to allow off-line verification and verification in future (but does not store the actual data); XAdES-X (extended), adding timestamps on the references introduced by XAdES-C to protect against possible compromise of certificates in chain in future; XAdES-X-L (extended long-term), adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available; XAdES-A (archival), adding possibility for periodical timestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during long-time storage period.

40. Xades, electronic signature composition The XAdES-T envelope: contains a trusted timestamp over the signature. The goal is to prove that the signer’s certificate was valid at the time of signature. The XAdES-X envelope: “ When an OCSP response is used, it is necessary to time-stamp in particular that response in the case the key from the responder would be compromised” In other words, the goal is to prove that the OCSP responder’s signing certificate was valid at the time of OCSP response. “ The SignatureTimeStamp encapsulates the time-stamp over the SignatureValue element.” XADES : XML Advanced Electronic Signatures Specification from the ETSI that is built upon the Xmldsig specification. It provides “signatures that remain valid over long periods. XAdES - X - L XAdES - X XAdES - C XAdES - T XAdES - EPES OCSP Timestamp Certificates Chain Timestamp XAdES - a Timestamp

41. Xades, electronic signature composition

42. “ Xades – A”, electronic signature composition Signed Signature Properties Signing Time (non-authoritative: may be from signer’s computer) Signature Certificate Signature Policy Identifier Signature Production Place (optional) Signer Role (optional) Signed Data Properties Data Object Format * Commitment Type Indication * All Data Objects Time Stamp * Individual Data Objects Time Stamp * Unsigned Signature Properties Counter Signature * Signature Timestamp+ Complete Certificate Refs Complete Revocation Refs Refs Only Time Stamp - or – Sig and Refs Time Stamp Certificate Values Revocation Values Archive Time Stamp +

43. Xades, electronic signature process flow E-sign

44. TSA – timestamp , process flow