44
page 1 • Fedisa_TAA 03-23-05 Juni 2011 TAA-Trusted Archive Authority TAA-Trusted Archive Authority Presented by Jan Biets [email protected] +32(0)477 32 90 11 Mechelen - Belgium

trusted archiving authority - LTANS

  • View
    1.639

  • Download
    3

Embed Size (px)

DESCRIPTION

an overview of all topics and applications to build a trusted archiving authority (TAA) aligned with LTANS.

Citation preview

Page 1: trusted archiving authority - LTANS

page 1 • Fedisa_TAA

03-23-05Juni 2011

TAA-Trusted Archive AuthorityTAA-Trusted Archive Authority

Presented by Jan Biets

[email protected] +32(0)477 32 90 11 Mechelen - Belgium

Page 2: trusted archiving authority - LTANS

page 2 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

““PRE” PRE”

All rights reserved by the author.

No citing, abstracting, or other usage is permitted without written permission

Contact address: [email protected]

Page 3: trusted archiving authority - LTANS

page 3 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

AgendaAgenda

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

Page 4: trusted archiving authority - LTANS

page 4 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TSA

E-SIGN

CA - PKI

ERS

Management

LAW

Policy

Security

Business Process

User interface

Agenda Agenda

Page 5: trusted archiving authority - LTANS

page 5 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

law & standards

managed documented

othermodules

operations

TAA

Agenda Agenda

Page 6: trusted archiving authority - LTANS

page 6 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

RFC3281 : An Internet Attribute Certificate Profile for AuthorizationRFC3280 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC3369  :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 (?)TAA – the complexity (?)

Page 7: trusted archiving authority - LTANS

page 7 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – functional architectural designTAA – functional architectural design

IAM

CATSA

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

Page 8: trusted archiving authority - LTANS

page 8 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - IAMTAA - 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

Page 9: trusted archiving authority - LTANS

page 9 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - electronic signatureTAA - 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

Page 10: trusted archiving authority - LTANS

page 10 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - electronic signatureTAA - 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

Page 11: trusted archiving authority - LTANS

page 11 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - TSATAA - 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

Page 12: trusted archiving authority - LTANS

page 12 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - TSATAA - TSA

Abbreviations:

TSA - Timestamp Authority , ETSI TS 102 023

Page 13: trusted archiving authority - LTANS

page 13 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - managementTAA - 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)

Page 14: trusted archiving authority - LTANS

page 14 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - managementTAA - management

Page 15: trusted archiving authority - LTANS

page 15 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - other elements 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

Page 16: trusted archiving authority - LTANS

page 16 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA - approachTAA - 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

Page 17: trusted archiving authority - LTANS

page 17 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – Risk assessment 360°TAA – Risk assessment 360°

(off-site)Back-up

policy

ICT room

policies processes

People & staff

Physical security

operations

TAA

Page 18: trusted archiving authority - LTANS

page 18 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – Risk assessment 360°security tiers)TAA – Risk assessment 360°security tiers)

Policy Security

Policy H

R

Trusted Archival Authority

Physical Security

Building Security

Policy Security

Application security

Server room

Org

anis

atio

n &

man

agem

ent

Pol

icy

System Security

Authorisation & authentification

Network Security

User interface Security

procedures people

Page 19: trusted archiving authority - LTANS

page 19 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – basic functionalities and features of a DMSTAA – 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),

Page 20: trusted archiving authority - LTANS

page 20 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – functionalities: audit trail (logging of events)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

Page 21: trusted archiving authority - LTANS

page 21 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA –functionalities: audit trail (logging of events)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

Page 22: trusted archiving authority - LTANS

page 22 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – basic functionalities: user managementTAA – 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

Page 23: trusted archiving authority - LTANS

page 23 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – functionalities: proof of integrityTAA – 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

Page 24: trusted archiving authority - LTANS

page 24 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – TAA – Overview of Archiving FeaturesOverview of Archiving Features

Archived object

Could be any electronic file / data.

Object meta-dataAuthor, category, size, version, date, key-word

Digital SignatureRelevance 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

Ob

ject

’sco

n ser

vat io

n a

ttrib

ute

s

Page 25: trusted archiving authority - LTANS

page 25 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – ERS , Overview of evidence record syntaxTAA – ERS , Overview of evidence record syntax

Archived Object

Object META-DATA

Digital Signature(optional)

Complementary data

Archive meta-data

Evidence record

Obj

ect’s

cons

erva

tion

attr

ibut

es

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

Page 26: trusted archiving authority - LTANS

page 26 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – basic architectural designTAA – basic architectural design

Hardware &

Storage

Policy &

Procedures

Web Service

DMS – user

interface

ERS engine

TSA

Security &

Legal

Page 27: trusted archiving authority - LTANS

page 27 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – functional architectural designTAA – functional architectural design

IAM

CATSA

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

Page 28: trusted archiving authority - LTANS

page 28 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – architectural designTAA – architectural design

S1

S2

S3

S4

Abbreviations:

LTAP – long term archival protocol

ERS – Evidence record syntax

Page 29: trusted archiving authority - LTANS

page 29 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

AfterwordAfterword

• 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;

Page 30: trusted archiving authority - LTANS

page 30 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

Afterwords : points of attention during conceptual designAfterwords : 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

• Monitoring: Application Level Monitoring must be explicitly requested, otherwise you just get system- and database monitoring.

• Archiving and Restoring

Page 31: trusted archiving authority - LTANS

page 31 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – some other fields of applicationTAA – 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

Page 32: trusted archiving authority - LTANS

page 32 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – basic functionalities: proof of integrityTAA – 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)

Page 33: trusted archiving authority - LTANS

page 33 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TAA – basic functionalities: proof of integrityTAA – 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.

Page 34: trusted archiving authority - LTANS

page 34 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

Questions?Questions?

?????

Page 35: trusted archiving authority - LTANS

page 35 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

Certificate classification (Verisign)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

Page 36: trusted archiving authority - LTANS

page 36 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatureselectronic signatures[3][3] defines the term defines the term qualified qualified certificatecertificate as: 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.

Page 37: trusted archiving authority - LTANS

page 37 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatures.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…

Page 38: trusted archiving authority - LTANS

page 38 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatures.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.

Page 39: trusted archiving authority - LTANS

page 39 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatures : 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.

Page 40: trusted archiving authority - LTANS

page 40 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

Xades, electronic signature compositionXades, electronic signature compositionThe 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 SignaturesSpecification 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

Page 41: trusted archiving authority - LTANS

page 41 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

Xades, electronic signature Xades, electronic signature compositioncomposition

Page 42: trusted archiving authority - LTANS

page 42 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

““Xades – A”, electronic signature Xades – A”, electronic signature compositioncomposition

• 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 +

Page 43: trusted archiving authority - LTANS

page 43 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

Xades, electronic signature process flowXades, electronic signature process flow

Electronic document

Creation (Pdf)

DocSign

Signature PIN code

TimeStamp

Public Key Verification

OCSP Verification

INPUT

Electronic document

Creation (Pdf)+

Timestamp profile

OUTPUT

0

12

3

4

5

6

78 9

E-sign

Page 44: trusted archiving authority - LTANS

page 44 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011

TSA – timestamp , process flowTSA – timestamp , process flowRequest

Time stamp

Verify validity certificate

logging

Verify validity > 1 < second

logging

Set Time stamp

TimeStampAccording ETSI TS 102 023

System audit process