BSI Technical Guideline 03125 Annex TR-ESOR-F Formats and ...

BSI Technical Guideline 03125 

Preservation of Evidence of Cryptographically Signed 

Documents 

Annex TR-ESOR-F 

Formats and Protocols 

Designation Formats and Protocols 

Abbreviation BSI TR-ESOR-F 

Version 1.1. 

Date 18.02.2011 

Parts of the document are not barrier free.

Preservation of Evidence of Cryptographically Signed Documents (TR-ESOR) BSI TR 03125 

Federal Office for Information Security 

Post Box 20 03 63 

53133 Bonn 

Phone: +49 228 99 9582-0 

E-Mail: digsig@bsi.bund.de 

Internet: http://www.bsi.bund.de 

© Federal Office for Information Security 2011 

Federal Office for Information Security

TR-ESOR-F 

Table of Contents 


1. Introduction........................................................................................................................................5 

2. Overview............................................................................................................................................7 

3. Definition of the Archival Information Package (XAIP)....................................................................9 

3.1 Overview of the XAIP Data Structure..........................................................................................9 

3.2 The Package Header (packageHeader).......................................................................................10 

3.3 The Metadata Section (metaDataSection)...................................................................................14 

3.4 The Data Object Section (dataObjectsSection)...........................................................................15 

3.5 The Credentials Section (credentialsSection)..............................................................................16 

3.6 Realisation of the XAIP Data Structure in XML........................................................................21 

3.6.1 Overview of the XAIP container..........................................................................................22 

3.6.2 The Archival Information Package Header (xaip:packageHeader)......................................22 

3.6.3 The Metadata Section (xaip:metaDataSection)....................................................................24 

3.6.4 The Content Data Section (xaip:dataObjectsSection)..........................................................25 

3.6.5 The Credentials Section (xaip:credentialsSection)...............................................................26 

3.6.6 Sample realisation of the XAIP data structures on the basis of XFDU................................32 

3.6.7 Fundamentals of XFDU.......................................................................................................32 

3.6.8 Realisation of an XAIP with XFDU.....................................................................................39 

4. Payload data formats........................................................................................................................43 

4.1 Metadata.....................................................................................................................................43 

4.1.1 Extensible Markup Language (XML)..................................................................................43 

4.1.2 XML Schema (XSD)...........................................................................................................44 

4.2 Content Data (Object Data)........................................................................................................44 

4.2.1 Documents (Records)..........................................................................................................45 

4.2.2 Multi-Media Formats...........................................................................................................50 

4.3 Base64 coding............................................................................................................................53 

5. Cryptographic data formats..............................................................................................................55 

5.1 Signature formats........................................................................................................................55 

5.1.1 PKCS#7 / CMS / CAdES.....................................................................................................55 

5.1.2 XML Signatures / XAdES...................................................................................................56 

5.2 Certificate formats......................................................................................................................56 

5.3 Certificate Validation Formats....................................................................................................57 

5.3.1 Online Certificate Status Protocol (OCSP / RFC 2560).......................................................57 

5.3.2 Server-Based Certificate Validation Protocol (SCVP / RFC 5055)......................................57 

5.4 Time Stamp.................................................................................................................................58 

5.5 Evidence Record).......................................................................................................................58 

Federal Office for Information Security 3

Preservation of Evidence of Cryptographically Signed Documents (TR-ESOR) BSI TR 03125 

6. Definition of a reliable transaction rrotocol......................................................................................61 

6.1 Derived Requirements................................................................................................................61 

6.2 Recommendations for the implementation..................................................................................62 

7. Annex - XML Schema Definition.....................................................................................................64 

4 Federal Office for Information Security

BSI TR-ESOR-F 

1. Introduction 


The goal of the Technical Guideline “Preservation of Evidence of Cryptographically Signed Documents” 

is to specify technical security requirements for the long-term preservation of evidence of 

cryptographically signed electronic documents and data along with associated electronic administrative 

data (meta data). 

A Middleware defined for this purpose (TR-ESOR-Middleware) in the sense of this Guideline 

includes all of the modules (M) and interfaces (S) [for the German "Schnittstellen"] used for securing 

and preserving the authenticity and proving the integrity of the stored documents and data. 

The Reference Architecture introduced in the Main Document of this Technical Guideline consists of 

the functions and logical units described in the following: 

• The input interface S.4 of the TR-ESOR-Middleware serves to embed the TR-ESOR- 

Middleware in the existing IT and infrastructure landscape; 

• The central Middleware module M.1, which regulates the flow of information in the 

Middleware, that implements the security requirements for the interfaces with the IT 

applications and which ensures that the application systems are decoupled from the 

ECM/long-term storage; 

• The “Cryptographic" module M.2 and the associated interfaces S.1 and S.3 that provide the 

functions needed for the creation (optional) and verification of electronic signatures, the postverification 

of electronic certificates, and for the obtainment of qualified time stamps for the 

Middleware. Furthermore, it can provide the functions for the encryption and decryption of 

data and documents; 

• The “ArchiSig” module (TR-ESOR-M.3) with the interface S.6 that provides the functions 

needed for the preservation of evidence of the digitally signed documents; 

• An ECM/long-term storage with the interfaces S.2 and S.5 that assumes the physical 

archiving/storage and also the storage of the meta data that preserve evidence. 

This ECM/long-term storage is no longer directly a part of the Technical Guideline, but 

requirements will be made of it through the two interfaces that are still part of the TR-ESOR- 

Middleware. 

The application layer that can include an XML-adapter is not a direct part of this Technical 

Guideline, either, even though this XML-adapter can be implemented as part of a Middleware. 

The IT Reference Architecture depicted in Figure 1 is based on the ArchiSafe 1 Reference Architecture 

and is supposed to make possible and support the logical (functional) interoperability of future 

products with the goals and requirements of the Technical Guideline. 

1 For more information, see http://www.archisafe.de . 



Application - 

Layer 

TR-ESOR- 

Middleware 

Figure 1: Schematic Depiction of the IT Reference Architecture 


Application ... Application ... Application ... Application 

Crypto-Interface (TR-S.1 / TR-S.3) 

Crypto-Module 

(TR-M.2) 

XML-Adaptor 

ArchiSafe-Interface (TR-S.4) 

ArchiSafe-Module (TR-M.1) 

ArchiSig-Interface (TR-S.6) 

ArchiSig-Module (TR-M.3) 

TR-S.2 TR-S.5 

ECM-/Storage-Interface 

ECM/long-term storage 

This Technical Guideline is modularly structured, and the individual annexes to the Main Document 

specify the functional and technological security requirements for the needed IT components and interfaces 

of the TR-ESOR-Middleware. The specifications are strictly platform, product, and manufacturer 

independent. 

The document at hand bears the designation “Annex TR-ESOR-F” and specifies data formats and protocols 

that are suitable for the preservation of evidence of cryptographically signed documents from 

the perspective of the functional and legal requirements. 



2. Overview 


The goal of the storage of electronic data with preservation of evidence over long periods of time is 

the provable, authentic, i.e. attributable and intact saving, conservation, and availability of electronic 

data and meta data at least of the duration of the legally prescribed retention periods. In doing so 

guarantying the negotiability is part of securing the availability of electronic documents, i.e. the 

readability and context of the data and context of the data and meta data with the transactions at their 

basis over long periods of time using the IT systems typical at the time they are made available. 

As a rule, the contents of electronic data and documents are coded as a stream (sequence) of characters 

of a finite set of characters Z1 by IT systems at the application level. The meta data are also coded as a 

sequence of the character set Z2. The sets of characters Z1 and Z2 can be the same, but they do not have 

to be. Furthermore, the meta data satisfy certain syntactic and semantic rules that are founded in the 

specifications of the meta data sets. 

The associated meta data can be divided into two categories: 

• A set of meta data M1 includes information about the set of characters Z1 used to code the 

documents and thus includes information regarding the display and formatting of the actual 

contents of the data. 

• A set of meta data M2 includes additional descriptive meta data regarding the digital 

documents (e.g. creator, date, file reference number, etc.) and thus can ensure, for example, 

that the documents or data can be found again and assigned to a transaction. 

Therefore, the goal of the storage of electronic documents with preservation of evidence is to guaranty 

for the digital contents, their meta data, and character sets 

• the authenticity (from which the non-repudiation follows), 

• the integrity (intactness), and the 

• availability 

for long periods of time, but at least as long, though, as the period of the statutory retention periods. 

The prerequisite for this are standardised, reliable, and verifiable trusted data infrastructures and 

transactions for the electronic documents to be preserved. 

In order to ensure the long-term availability of the stored electronic documents, solely open, 

standardised, and stable data formats that support a long-term largely system and platform independent 

interpretation of the data should be used for both the content data and the meta data. The primary 

intention of this requirement is to avoid a format transformation of the stored electronic documents at 

least for the duration of the legally prescribed retention periods, because this is connected to a 

significant amount of effort – in particular in the case of electronically signed documents. 

In order to prove the integrity and authenticity of the data to be preserved, this Guideline stipulates the 

use of trusted cryptographic security measures that include both the actual content data and the 

“descriptive” meta data, reliably link them, and are able to maintain and renew the probative value of 

the cryptographic security measures for the duration of the statutory retention periods. 

The securing of the authenticity of stored electronic data and documents also includes the reliable and 

permanent linking of the stored electronic documents with all meta information that are needed to find 

the documents and for the legally viable and auditable traceability (reconstruction) of the transactions 

at the basis of the data. 




The purpose of this specification is to define and describe electronic data formats and transaction 

protocols that are suitable for adequately mapping and executing the legal and functional requirements 

of long term storage with preservation of evidence in the sense of this Guideline. 

Thus, Section 3 of this document first describes basic syntactic and semantic structures that an 

Archival Information Package that conforms to the goals and requirements of this Technical Guideline 

should implement. 

Then, Section 4 of this document describes electronic data formats for the content data (primary data) 

and the meta data that are recommended primarily with regard to long-term availability and automatic 

readability and interpretability. 

Section 5 of this document describes structure, formats, and algorithms for the generation and 

interpretation of cryptographic data that are suitable for the long-term securing of the integrity, 

authenticity, and probative value of electronic documents at the time this Technical Guideline is 

published. 

The final Section, 6, dedicates itself to the definition of a trusted transaction protocol from the 

perspective of the technically necessary characteristics of such protocols. 

The annex to this document contains the definition of a corresponding XML schema for the syntactic 

and semantic data structures explained in Section 3. 



3. Definition of the Archival Information Package (XAIP) 


An Archival Information Package, i.e. an electronic document in the sense of this document intended 

for long-term storage in an electronic archive system, is a self-explanatory and well-formed XML 

document that can be verified against a valid and authorised XML schema (also called XML 

formatted Archival Information Package or XAIP for short in the following). 

Such an Archival Information Package contains all content data (primary information) and meta 

information that are needed for a reliable and complete reconstruction of the transaction or 

administrative procedures up until the expiry of the legally prescribed retention periods. 

The description of Archival Information Packages in a valid XML schema ensures that: 

• The Archival Information Packages can be evaluated for syntactic correctness before 

submission to the electronic long term storage, 

• Necessary additions or augmentations to the meta data can be made by expanding or 

augmenting existing meta data structures and/or including additional XML schema, and 

• The cryptographic security measures needed for proving the authenticity and integrity of data 

subject to the duty of retention on account of legal requirements, such as electronic signatures 

or electronic time stamps can be permanently and reliably linked to the securing data. 

The following sections of this document first describe basic syntactic and semantic structures that an 

Archival Information Package that conforms to the goals and requirements of this Technical Guideline 

should implement. They are based in large part on agreements and experiences of the ArchiSafe 

project of the Physikalisch-Technische Bundesanstalt [PTB 05] and concepts of the OAIS reference 

model [OAIS], the Metadata Encoding and Transmission Standards [METS], the Victorian Electronic 

Records Strategy [VERS], and the draft of an XML Formatted Data Unit [XFDU] Standard of the 

Consultative Committee for Space Data Systems (CCSDS) of NASA. 

In the definition and description of the XML data structures, these specifications differentiate between 

binding (obligatory) and optional data elements. A binding data element shall be present in an Archival 

Information Package that conforms with these specifications and be interpretable by an electronic 

archiving system that conforms with this Guideline. An optional element can be present. It does not 

necessarily have to be interpretable, but it may not hinder the automatic processing (interpretation) of 

other elements. An optional element shall be present if its presence is linked to certain conditions, such 

as the present of an electronic signature, and these conditions have been fulfilled. 

3.1 Overview of the XAIP Data Structure 

An Archival Information Package pursuant to this Guideline should have the following data structure: 

• An archive package header (packageHeader) with information about the logical structure(s) 

of the XAIP document and the sender, 

• a data section for meta information for description of the transactional and archiving context 

of the content data (metaDataSection), 

• a data section for the content data (dataObjectsSection), and 

• in the event of the storage of electronically signed documents, a data section for the storage of 

signatures, certificates, signature verification information, and electronic time stamps 

(credentialsSection). 



XMLArchivalInformationPackage ::= SEQUENCE { 

packageHeader [0]PackageHeader, 

metaDataSection [1]MetaDataSection, 

dataObjectsSection [2]DataObjectsSection, 

credentialsSection [3]CredentialsSection OPTIONAL 

} 

3.2 The Package Header (packageHeader) 


The package header (packageHeader) of an XAIP document is a complex XML data type and 

should contain information that concerns the entire Archival Information Package. This includes 

information about the local structure(s) of the Archival Information Package, and administrative 

information about the sender of the data to be archived. 

The package header contains the following elements: 

1. An optional package identifier (packageID) for the Archival Information Package that is 

generated by the archiving business application and can be used to identify the Archival 

Information Package (e.g. within the business application), 

2. an AOID element for storing a unique Archival Information Package ID (AOID) generated by 

the TR-ESOR-Middleware or the ECM/long-term storage 2 , 

3. an optional schemaLocation (such as a URL) with information about the version and the 

name of the syntactic definition of the XML schema at the basis of the Archival Information 

Package, 

4. an optional packageInfo field with basic information about the Archival Information 

Package in text format that makes a future user able to understand the format of the XAIP 

document and interpret the contents, 

5. a sequence of versionManifest elements in which the contents of the various versions of 

the Archival Information Package are specified, 

6. an optional canonicalization element that refers with an URI to the canonicalization 

algorithm 3 with which the XAIP at hand was normalised and finally 

7. an optional extension element that contains additional information if necessary. 

2 The archive object ID serves the ability to find the stored documents and data in a reliable manner and as a 

key for the authorised return or deletion of the data. 

3 Also see TR-ESOR-M.3 Chapters 2.4.1 and 4.3 and TR-ESOR-M.2 Chapter 4.4 




PackageHeader ::= SEQUENCE { 

packageID [0] GeneralName OPTIONAL, -- Packet ID 

AOID [1] UTF8String, -- Identifier 

schemaLocation [2] GeneralName OPTIONAL, -- XML Schema 

packageInfo [3] UTF8String OPTIONAL, -- narrativ Descr. 

versionManifests [4] VersionManifests OPTIONAL, -- vers.spec. Table of 

content 

canonicalization [5] IA5String OPTIONAL, -- canonicalization algo 

extension [6] Extension OPTIONAL -- optional extensions 

} 

The structured data type GeneralName can be used in order to code different forms of names or 

identifiers. The suggested structure describes a selection of seven standard names (identifiers) and 

makes it possible to develop locally defined names or identifiers. The ASN.1 syntax for the 

GeneralName data type is defined in [RFC2459]. 4 

As a rule, the AOID is a unique identifier for an Archival Information Package generated by the TR- 

ESOR-Middleware or the ECM/long-term storage. This AOID is returned to the requesting application 

and re-used by it for every additional transaction that concerns the archived information package. 

The “version specific table of contents” (VersionManifest) of an XAIP document is a complex data 

type structured in the following manner: 

VersionManifests ::= SEQUENCE SIZE (1..MAX) OF VersionManifest 

VersionManifest ::= SEQUENCE { 

versionID [0] GeneralName, -- ID 

versionInfo [1] UTF8String OPTIONAL, -- Description 

preservationInfo [2] GeneralizedTime OPTIONAL, –- Retention period 

submissionInfo [3] SubmissionInfo OPTIONAL, –- Sender information 

packageInfoUnits [4] PackageInfoUnits, –- Seq. of Archive Info Units 

extension [5] Extension OPTIONAL,-- optional extensions 

} 

Each VersionManifest contains the following information: 

• Obligatory, 

an identifier, versionID, for a unique reference to the version of the Archival 

Information Package, 

• o ptional, 

a data element versionInfo for describing the version of the Archival Information 

Package, 


a preservationInfo field that should contain the time up to which the Archival 

Information Package shall be preserved at a minimum, 


a submissionInfo data type with information about the sender of the Archival 

Information Package, 

• o bligatory, 

a sequence of packageInfoUnit elements that refer to the payload data, meta 

data, and evidence records belonging to a version of the XAIP, and finally 

• an optional extension element that contains additional information if necessary. 

4 See http://www.ietf.org/rfc/rfc2459.txt 



The Extension data type is defined as follows: 

Extension ::= SEQUENCE { 

extensionType OBJECT IDENTIFIER, 

extensionValue [0] ANY DEFINED BY extensionType 

} 


The data structure of the submission information (submissionInfo) in the package header is a 

complex data type and should contain information about the sender of the archival information 

packages. This includes the following elements: 


a multi-client capable identifier unique in the context of a certain TR-ESOR system 

for the transaction application making the request (clientID), 


a unique identification characteristic (identifier) for the submitting organisational 

unit (submissionUnit), 


a unique identifier for the author or creator (sender) of the Archival Information 

Package, 


indication of the time sent, and 


a complex data type trackingInfos that can contain information that could be 

used to authenticate the communication partners, such as an X.509 v3 certificate [X.509]. 

SubmissionInfo ::= SEQUENCE { 

clientID [0] GeneralName, -- Business Application 

submissionUnit [1] GeneralName OPTIONAL, -- Business Unit 

submissionAuthor [2] GeneralName OPTIONAL, -- Author 

submissionTime [3] TimeInfo OPTIONAL, -- Time of submission 

trackingInfos [4] TrackingInfos OPTIONAL -- Authentication information 

} 

TimeInfo ::= CHOICE { 

generalTime GeneralizedTime, -- System time YYYYMMDDHHMMSSZ 

timestamp TimeStampToken -- Time stamp according RFC 3161 

} 

TrackingInfos ::= SEQUENCE SIZE (1..MAX) OF TrackingInfo 

TrackingInfo ::= ContentInfo 

ContentInfo ::= SEQUENCE { 

contentType ContentType, 

content EXPLICIT ANY DEFINED BY contentType 

} 

ContentType ::= OBJECT IDENTIFIER 




The “version-specific table of contents" (VersionManifest) contains a sequence of archive-infounits 

(PackageInfoUnits), in which case each PackageInfoUnit itself can include one or more 

PackageInfoUnits. The logical content of a package info unit is defined by the references 

(IDREFs) contained in the PackageInfoUnit element. Furthermore, it is clarified by the sequence of 

the protectedObjectPointers which payload data, meta data, and evidence record objects must 

be included by the Archive Time Stamp. 

Regardless of that, additional references from payload data objects to logically associated meta data 

and evidence records can exist that are not (directly) relevant for the generation and maintenance of 

the archive time stamp. 

PackageInfoUnits ::= SEQUENCE SIZE (1..MAX) OF PackageInfoUnit 

PackageInfoUnit ::= SEQUENCE { 

packageUnitID [0] GeneralName, -- ID 

unitType [1] UTF8String OPTIONAL, -- Classification 

textInfo [2] UTF8String OPTIONAL, -- Description 

protectedObjectPointers [3] IDREFs OPTIONAL, -- Link to integrityprotected 

data, meta data and evidence objects 

unprotectedObjectPointers [4] IDREFs OPTIONAL, -- Link to not 

integrity-protected data, meta data and evidence objects 

packageInfoUnits [5] PackageInfoUnits OPTIONAL -- additional 

archive info units 

extension [6] Extension OPTIONAL -- optional extensions 

} 

Each PackageInfoUnit contains the following information: 


an identifier, packageUnitID, for a unique reference to the version of the 

packageInfoUnit, 


a unitType data element that enables classification of the individual information 

packages, 


a textInfo data element, i.e. an additional text field for describing the 

packageInfoUnit, 


a protectedObjectPointers data element that contains a sequence of references 

(IDREF in XML notation) that contains integrity-protected payload data, meta data, and 

credentials that are assigned to this PackageInfoUnit. The data elements referenced by this 

flow into the generation of the hash tree that is protected by an archive time stamp pursuant to 

[RFC 4998] or [XMLERS]. Additional information on this can be found in [TR-ESOR-M.3], 


an unprotectedObjectPointers data element that contains a sequence of 

references (IDREF in XML notation) that contains non-integrity-protected payload data, meta 

data, and evidence records that are assigned to this PackageInfoUnit. 


a PackageInfoUnits elements that, in turn, contains a sequence of 

PackageInfoUnit elements. Thus, a hierarchy or structure of the primary information 

packages contained in this Archival Information Package can be depicted. 

• Furthermore, an optional extension element that contains additional information if 

necessary can exist. 



The IDREFs structure is defined as follows: 

IDREFs ::= SEQUENCE SIZE (1..MAX) OF IDREF 

IDREF ::= GeneralName 

3.3 The Metadata Section (metaDataSection) 


The meta data section (metaDataSection) of an XAIP document is a complex XML data type and 

shall contain all meta information that is needed for transparent and permanent interpretation of the 

transaction and archiving context for all content information packages summarized (subsumed) in the 

Archival Information Package. Multiple meta data packages can be stored in this section, each of 

which contains the meta information for a separate content data object stored in the Archival 

Information Package (XAIP document). 5 

The following structure is recommended for the syntactic structure of the meta data 

(metaDataObject): 

Each meta data object shall contain a unique reference (identification characteristic) metaDataID of 

the concerned meta data section. Furthermore, the meta data object can contain the following 

(optional) data elements: 

• A classification characteristic classification, 

• a categorisation characteristic, category, 

• an additional text description (explanation) of the meta data in the textInfo element. 

The data elements classification and category support the mapping of the OAIS information 

module by indicating typing information for the meta data object and can also be used for the search 

algorithms within the archive system among other things. With such a construction, one can, for 

example, also categorise retention periods as "Preservation Description Information (PDI)” and 

classify them with periods and other preservation information. 

The meta data themselves can be stored in the metaData element either as an XML data element or as 

Base64 coded binary data. With the MetaData data type, a reference to the meta data (IDREF) can be 

realised that is already contained in the corresponding payload data object in the dataObjectsSection 

or a hierarchy of meta data can be mapped. 6 

5 This construction makes it possible to adequately map not just complete but also different file and index 

structures in an XAIP document. The construction makes it possible to use different XML schemata as the 

basis for each meta data object. 

6 Also see http://tools.ietf.org/html/draft-ietf-ltans-ltap-07.txt 




MetaDataSection ::= SEQUENCE SIZE (1..MAX) OF MetaDataObject 

MetaDataObject ::= SEQUENCE { 

metaDataID [0] GeneralName, -- Identifier 

dataObjectID [1] IDREF, –- Link to payload objects 

classification [2] UTF8String OPTIONAL, -- Classification 

category [3] UTF8String OPTIONAL, -- Categorisation 


metaData [5] MetaData -- Metadata 

} 

MetaData ::= SEQUENCE { 

type OBJECT IDENTIFIER OPTIONAL, 

value [0] EXPLICIT ANY DEFINED BY type 

} 

3.4 The Data Object Section (dataObjectsSection) 

The data object section of an XAIP document, dataObjectsSection, should have the content data 

to be archived in the dataObject data structure. In doing so, the data object section can contain any 

number of such content data objects. It can be used, for example, to store content data in different data 

formats, for example platform or application specific ones, in an XAIP container, or archive entire 

folders with many different documents together. 

Each of these content data objects should be described by the following data elements: 


a unique identification characteristic (dataObjectID) for this section, 


a contentData data element for include of the content data, 


a cryptographic checksum of the content data, and 


information about any transformations of the payload data object that have been 

carried out. 

DataObjectSection ::= SEQUENCE SIZE (1..MAX) OF DataObject 

DataObject ::= SEQUENCE { 

dataObjectID [0] GeneralName -- ID 

contentData [1] ContentData, -- Payload 

checkSum [2] CheckSum OPTIONAL, -- Checksum 

transformInfo [3] TransformInfo OPTIONAL -- Transformation information 

} 

The contentData element includes the actual content data either as Base64 coded binary data 

(binaryData) or as complex data types in XML notation (XMLData). 

ContentData ::= CHOICE { 

binaryData OCTET STRING, -- Base64 coded binary data 

structured XMLData -- XML data 

} 




Optionally, each content data object can also have a cryptographic checksum (checksum) of the data; 

in this case the algorithm data element for the algorithm of the checksum generation shall be 

indicated, e.g. SHA-256. The checksum also refers to the payload data as they are present in the XAIP, 

thus in particular also taking any transformations that have been performed into account. 

CheckSum ::= SEQUENCE { 

algorithm GeneralName, 

checkSum CheckSumValue 

} 

CheckSumValue ::= OCTET STRING 7 

The likewise optional data element transformInfo is used in order to document one or more 

operations (transformations) performed on the original data before storage in the archive system. 

TransformInfo ::= SEQUENCE SIZE (1..MAX) OF TransformObject 

TransformObject ::= SEQUENCE { 

transformObjectID GeneralName, -- ID 

order INTEGER, -- Sequence of Transformations 

transformType TransformType, -- Type of Transformation 

transformAlgorithm OBJECT IDENTIFIER, -- Transformation algorithm 

parameter ANY DEFINED BY transformAlgorithm OPTIONAL 

-- additional parameters 

} 

TransformType ::= ENUMERATED {compressed (0), canonicalization (1), encryption (2), 

other (3)} 

3.5 The Credentials Section (credentialsSection) 

The credentials section serves to accommodate EvidenceRecord elements pursuant to [RFC4998] / 

[XMLERS] and other supplemental evidence data such as signatures, time stamps, certificates, and 

associated status information for each of the content data objects stored in the XAIP document. 8 

The relationship between the Evidence Records or the supplemental evidence data and the 

corresponding payload or meta data is realised with the relatedObjects attribute of the 

7 Realised in the XML schema by the “hexBinary” data type. 

8 The Evidence Record serves to prove the intactness of the integrity and authenticity of the archived data 

objects. In accordance with the specifications of the ERS standard of IETF, an evidence record includes an 

Archive Time Stamp of sufficient quality for the stored (signed) archive data objects that prove the integrity 

of the data and additional information that prove the correctness and validity of electronic signatures at the 

time of signing as well as the timely renewal of signature pursuant to the legal requirements. “Supplemental 

evidence data” are signatures or time stamps for exactly one data object or document, and they also include 

the verification data necessary for the signature or time stamp signature, such as certificates as well as the 

CRL lists and OCSP responses to these certificates. The Evidence Records prove that the document was not 

changed after it was archived. The supplemental evidence data prove that the signatures and time stamps 

which may have been created outside of the archive were valid at the time of creation or archiving. 




Credential element explained below. If no evidence record objects are needed in the entire XAIP, 

the CredentialsSection can be omitted completely. 

CredentialsSection ::= SEQUENCE SIZE (1..MAX) OF Credential 

Each (individual) credential object (of the Credential data type) is itself in turn identified by a 

unique identifier (name or characteristic), the credentialID. 

The type of the credential can be specified using the category data element. The likewise optional 

textInfo data element can be used for an additional text description that makes a future user able to 

understand the format of the object and interpret the contents 9 . 

-- Credial section for a single evidence object (e.g. a signature) 

Credential ::= SEQUENCE { 

credentialID [0] GeneralName, -- ID 

relatedObjects [1] IDREFs OPTIONAL –- Link to related 

payload, meta data or evidence objects 

category [2] UTF8String OPTIONAL, -- Type of Credentials 


credentialData [4] CredentialData, -- evidence related 

objects 

} 

The obligatory CredentialData data type encapsulates the supplemental evidence data specified by 

category: Signatures in the SignatureObject data element, time stamps pursuant to [RFC3161] 

in the TimeStampToken data element, certificates pursuant to [RFC5280] and [RFC3281] in the 

CertificateValue data element, references to such certificates in the certificateRefs element, 

revocation information pursuant to [RFC5280] in the RevocationValue data element, references to 

revocation information in the recovationRefs data element, evidence records in the ERS standard 

format of IETF pursuant to [RFC4998] / [XMLERS] in the EvidenceRecordInfos data element, 

information on the validity of evidence records in the verificationReport data element, or other 

evidence records in the other data element. 

CredentialData ::= CHOICE { 

signature SignatureObject, -- Signature data 

timestamp TimeStampToken, -- Time stamp [RFC3161] 

certificates CertificateValues, -- Certifikate [RFC 3281,5280] 

certificateRefs CertificateRefs, –- Links to Certifikate 

revocationValues RevocationValues, -- Revocation infos[RFC5280] 

revocationRefs RevocationRefs, –- Link to Revocation infos 

evidenceRecord EvidenceRecord, -- Evidence Record according 

[RFC4998] or [XMLERS] 

verificationReport VerificationReport, –- Verification infos 

other Extension, -- other evidences 

} 

9 It is up to the user if he wishes the describe the category of the credential object in more detail within this 

field. 




The SignatureObject data element contains signature data either as CMS/PKCS#7 signatures 

[RFC5652] or as XML signatures [XMLDSIG] 10 . 

SignatureObject ::= ContentInfo 

ContentInfo ::= SEQUENCE { 

contentType ContentType, 

-- id-signedData OBJECT IDENTIFIER [RFC5652] for CMS/PKCS#7 Signatures, 

-- xlmns:ds = “http://www.w3.org/2000/09/xmldsig#” for XML Signatures 

content [0]EXPLICIT ANY DEFINED BY contentType 

} 

NOTICE: The corresponding type definitions for id-signedData and signedData are found in 

the CMS specification [RFC5652]; the corresponding syntactic and semantic definitions for XML 

signatures in the W3C Recommendation from 9 January 2009. 

For XML and XAdES signatures, the Guideline recommends that verification information such as 

certificates or revocation information be inserted into the XML signature as unsigned characteristics 

(also see Chapter 5.1.2 in this document). 

The TimeStampToken data element encapsulates time stamp information pursuant to [RFC3161] 11 . 

TimeStampToken ::= ContentInfo 

-- [RFC3161] 

-- contentType is id-signedData ([RFC5652]) 

-- content is SignedData ([RFC5652]) 

NOTICE: The TimeStampToken shall not contain any signatures besides the signature of the time 

stamp service provider. The supplemental evidence data that goes beyond that shall be saved pursuant 

to [CAdES] in unsigned fields of the TimeStampToken. 12 

The CertificateValues data element encapsulates X.509 certificates pursuant to [RFC5280] and 

attribute certificates pursuant to [RFC3281] as well as other certificate information. 

CertificateValues ::= SEQUENCE (1..MAX) OF CertificateValue 

CertificateValue ::= CHOICE { 

encapsulatedX509Certificate Certificate, -- [RFC5280] 

10 In the XML definition (see Annex), data elements of the SignatureObject type are realised on the basis 

of OASIS "Digital Signature Service Core Protocols, Elements, and Bindings" version 1.0 from 11 April 

2007 as a form of dss:SignatureObject (see http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-specv1.0-os.html). 

11 In the XML definition the TimeStampToken data element is listed as an option in the general data 

structure on the basis of the dss:SignatureObject OASIS "Digital Signature Service Core Protocols, 

Elements, and Bindings" version 1.0 from 11 April 2007 as a form of dss:SignatureObject (see 

http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html). 

12 CAdES are preferred to regular CMS signature here because CMS does not expressly stipulate structures 

such as CRLs and OCSP responses for saving status information on certificates. 



} 

otherCerts OtherCertificates 

OtherCertificates ::= SEQUENCE { 

certType OBJECT IDENTIFIER, 

certValue ANY DEFINED BY certType 

} 

CertificateRefs ::= IDREFs 


The RevocationValues data element contains revocation information on technical evidence 

records. 

RevocationValues ::= SEQUENCE (1..MAX) OF RevocationValue 

RevocationValue ::= SEQUENCE { 

crlVals [0] SEQUENCE OF CertificateList OPTIONAL, -- RFC 5280 

ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, -- RFC 2560 

otherVals [2] OtherRevocationValues 

} 

RevocationRefs ::= IDREFs 

A RevocationValue different from a CertificateList or OCSPResponse can be stored in the 

OtherRevocationValues structure. This allows to use SCVP responses according to [RFC5055] 

for example. 

OtherRevocationValues ::= SEQUENCE { 

otherRevValType OBJECT IDENTIFIER, 

otherRevVals ANY DEFINED BY otherRevValType 

} 

-- SCVP Certificate Validation Response 

id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 } 

NOTICE: In doing so, it is to be noted that revocation information besides certificate lists or OCSP 

answers is hardly supported by any applications at the time this Technical Guideline is published. 

Thus, it is recommended to resolve the original revocation information in the corresponding CRLs or 

OCSP responses in such a case. 

In the event of migration of the archival information packages into a new archive system, the 

CredentialData structure can also be used to store the Evidence Records that belong to the XAIP 

document. For doing so, the EvidenceRecord data element pursuant to [RFC4998] / [XMLERS] that 

can accommodate multiple reduced archive time stamps for one payload data object is stipulated. 

NOTICE: An Archival Information Package (XAIP container) must also be able beyond the original 

(first) archiving to depict different versions and migrations from one archive to another in a correct 

and traceable manner. In doing so, the evidence records (ERS entries or the reduced archive time 

stamp) that are normally managed separately from the XAIP document also have to be taken into 

account along with the XAIP container. 




In the event that a new version of an XAIP container is created, a new, version-specific manifest is 

added to the header that defines the integrity and non-integrity protected content of the new version. 

Details on versioning can be found in [TR-ESOR-M.3]. 

In the event of a migration, the old XAIP container can be nested in a new XAIP container as a 

payload data object. The difference in version creation here is that the entire reduced hash tree is 

stored in the credentialsSection of the new XAIP container as a Crendential in the form of an 

evidence record. 

The definition of the EvidenceRecord data type can be found in [RFC4998] in Chapter 5.5 and in 

the Main Document of this Technical Guideline [TR-ESOR]. 

The optional CredentialValidity data element in the Credential element serves the 

depositing of additional validity or verification information that may be requested for individual 

CredentialData insofar as they could or should not be added as unsigned attributes to the 

signature or time stamp data – as stipulated in [CAdES] or [XAdES] – or were already stored in the 

CredentialData data structure. 

CredentialValidity ::= SEQUENCE { 

validityInfoType OBJECT IDENTIFIER, 

-- id-pkix-ocsp-response OBJECT IDENTIFIER ::= {id-pkix-ocsp 4}:OCSCP 

-- id-ct-scvp-certValResponse OBJECT IDENTIFIER ::= { id-ct 11 }:SCVP 

-- urn:oasis:name:tc:dss:1.0:profiles:verficationreport:schema#:OASIS-VR 

validityInfoValue ANY DEFINED BY validityInfoType 

} 

Based on the validityInfoType, the verification results (ValidityInfoValue) for 

signatures, time stamp, or certificates that are not already part of a signature are stored as 

OCSPResponse pursuant to [RFC2560], as SCVPResponse pursuant to [RFC5055], or as 

individual verification reports pursuant to [OASIS-VR]. 

ValidityInfoValue is stipulated as the general vr:IndividualReport data type on the 

basis of the OASIS profile [OASIS-VR] and can arise in the following specifications (also see Chapter 

3.6): 

• As a DetailedSignatureReport for the verification of electronic signatures, 

• as an IndividualTimeStampReport for the verification of individual time stamps 

pursuant to [RFC3161] that are not already part of a signature, 

• as an IndividualCertificateReport for public key certificates pursuant to 

[RFC5280] that are not already part of a signature, 

• as an IndividualAttributeCertificateReport for attribute certificates pursuant 

to [RFC3281] that are not already part of a signature, 

• as an IndividualCRLCertificateReport for revocation lists pursuant to [RFC5280] 

that are not already part of a signature, 

• as an IndividualOCSPReport for OCSP responses pursuant to [RFC5280] that are not 

already part of a signature or 




• as an EvidenceRecordReport for evidence records pursuant to [RFC4998] or 

[XMLERS]. 

There is detailed information on the data formats for signatures, time stamps, and certificate 

verification information that are recommended by this Guideline in Chapter 5. 

3.6 Realisation of the XAIP Data Structure in XML 

The following section describes the realisation of the XAIP data structure in XML notation. 

(A3.6-1) For the preservation of evidence of cryptographically signed documents the XAIP-format 

described in this section and specified by the corresponding XML-schema should be used. Deviations 

from this XML-format are possible, but in this case it must be explained that equal functionality is 

provided. In particular it must be explained how a transformation to the present XAIP-format is 

possible. 

The documentation of the complete XML schema can be found in the annex to this document. Because 

simple mapping to the ASN.1 specifications of the XAIP container in the previous chapter is possible 

in most cases on account of the same names, this chapter does not describe the individual data 

elements in detail. XML conventions and standards, such as OASIS DSS and XAdES, were given 

priority when translating the ASN.1-based data types to XML. It is recommended for the necessary 

resolving of structures declared in the XAIP schema by means of XML namespaces in the case of an 

automatic validation of an XML document that the associated schema definitions be deposited 

together with the XAIP schema described in the annex in the access of the validator. 

Notice: The following figures were mapped with XML Viewer Eclipse 3.1. For reasons of clarity the 

attributes are not depicted. An (a) inside of a circle in the mapped data elements refers to the existence 

of additional attributes in the respective data structure. 



3.6.1 Overview of the XAIP container 

Figure 2: Overview of the XAIP container 

As explained in Section 3.1, an XAIP document contains (also see Figure 2): 


• An Archival Information Package header (xaip:packageHeader) with information about 

the logical structure(s) of the XAIP document, 

• a section of data for the meta information for describing the transaction and archiving context 

of the content data (xaip:metaDataSection), 

• a data section for the content data, (xaip:dataObjectsSection), and 

• in the case of the preservation of electronically signed documents, a data section 

(xaip:credentialsSection) for the depositing of cryptographic evidence records and 

supplemental evidence data. 

The respective elements of the XAIPType are optional so that all kinds of different applications can be 

supported. 

3.6.2 The Archival Information Package Header (xaip:packageHeader) 

As explained in section 3.2, the package header includes information about the logical structure(s) of 

the Archival Information Package and administrative information about the sender of the data to be 

archived. 




This includes, in addition to the Archival Information Package ID (AOID) 13 and information about the 

XML schema at the basis of the archival information container (xaip:schemaLocation), textual 

information about the Archival Information Package (xaip:packageInfo), “version-specific 

manifests” with information about the logical design and structure of a certain version of the archival 

information (xaip:versionManifest, also see Section 3.2 and Figure 3), and an optional 14 

canonicalization method (ds:CanonicalizationMethod) with which all XML based data 

structures of the XAIP shall be normalised before hash value generation, and, finally, optional 

extension (xaip:extension). 

Figure 3: Overview of the Package Header 

The “version-specific manifest” (xaip:versionManifest) of an XAIP document can – as described 

already in Section 3.2 – contain, in addition to the version information, a text version-specific 

information (xaip:versionInfo), a retention period (xaip:preservationInfo), information on 

the sender of the Archival Information Package (xaip:submissionInfo), and a sequence of 

xaip:packageInfoUnit‘s (“chapters”). 

13 The Archival Information Package ID (AOID) serves the ability to find the stored documents and data in a 

reliable manner and, if applicable, as an authentication characteristic for the return or deletion of the data. 

14 Insofar as this element is not present, the canonicalization is done with the standard algorithm (C14N - 

Canonical XML [C14N]). Additional information on canonicalization can also be found in TR-ESOR-M.2, 

Chapter 4.4. 



Figure 4: Overview of a packageInfoUnit 


Such a xaip:packageInfoUnit can, in turn, contain type information (xaip:unitType), a text 

description (xaip:textinfo), a sequence of references to integrity protected 

(xaip:protectedObjectPointer), and non-integrity-protected payload data, meta data, and 

credential objects (xaip:unprotectedObjectPointer) that are assigned to this 

PackageInfoUnit and, in turn, an additional sequence of xaip:packageInfoUnit elements 15 and, 

finally, additional information in the xaip:extension element (also see Section 3.2 and Figure 4 

with regard to this). 

3.6.3 The Metadata Section (xaip:metaDataSection) 

As explained in Section 3.3, the meta data section (xaip:metaDataSection) of an XAIP 

document contains all meta information that supports the understanding of the transaction and 

archiving context of the content data objects summarized in an Archival Information Package. 

Multiple meta data objects of the xaip:metaDataObject type can of course also be stored in this 

section, each of which contains the meta information for a content data package stored in an Archival 

Information Package (XAIP document) (see Figure 5). 

15 Thus, a hierarchy or structure of the content data contained in the Archival Information Package can be 

depicted. 




Each meta data object contains a unique reference (identification characteristic) of the concerned meta 

data section medaDataID. Then, optional data elements follow that allow classification, 

categorisation, and/or description of the meta data object (also see Section 3.3). 

The meta data themselves are be deposited in the xaip:metaData element either as an XML-based 

data element or as Base64 coded binary data. 

Figure 5: Overview of the metaDataSection 

3.6.4 The Content Data Section (xaip:dataObjectsSection) 

As already explained in Section 3.4, the data object section of an XAIP document 

(xaip:dataObjectsSection) serves to accommodate the content data to be archived in one or 

more data structures of the xaip:dataObject type (also see Figure 6). This can, as described in 

Section 3.4, be used, for example, to store content data in different or platform and application specific 

data formats in an XAIP container. 

Figure 6: Overview of the dataObjectsSection 

The xaip:dataObject element encapsulates the actual content data, either as Base64 coded 

binary data or as complex data types in XML notation. Optionally, a cryptographic checksum 




(xaip:CheckSum) about the payload data and information about any operations (transformations) 

executed on the original data can be added to each content data object. 

Figure 7: Transformation information 

The information about the individual operations (transformations) can be deposited in a sequence of 

one or more transformation objects (xaip:tranformObject). A transformation object is 

identified by an ID, then an indication of the sequence of the operation, the operations type, and the 

associated operations algorithm and any necessary parameters follow (also see Figure 7). 

3.6.5 The Credentials Section (xaip:credentialsSection) 

As explained already in Section 3.5, the credentials section serves to deposit Evidence Records and 

supplementary evidence data such as signatures, time stamps, certificates, and status information 

(validity information) on the credentials contained in the XAIP document. 

Figure 8: Overview of the CredentialsSection Data Structure 

As shown in Figure 8, the xaip:credentialsSection consists of a sequence of 

xaip:credential elements. 

Such a credential object (xaip:credential) contains two attributes (relatedObjects and 

credentialID) with which the relationships between a credentials object and the associated payload 

or meta data objects or other Evidence Record objects is documented. The relatedObjects attribute 

is of the xs:IDREFs type and contains references to other payload data, meta data, or evidence record 

objects. The credential attribute is of the xs:ID type and makes it possible for a different evidence 

record object or a "version specific manifest” (xaip:versionManifest) to refer to the concerned 

credential object. 




The data structure depicted in Figure 9, xaip:credential may contain the following objects: 

• Signatures (CMS/PKCS#7 signatures [RFC3852] or XML signatures [XMLDSIG]) in the 

dss:SignatureObject data element of the OASIS “Digital Signature Service Core 

Protocols, Elements, and Bindings” version 1.0 from 11 April 2007 16 , 

• time stamps pursuant to [RFC3161] in the dss:Timestamp element of the OASIS „Digital 

Signature Service Core Protocols, Elements, and Bindings“ Version 1.0 from 11 April 2007 in 

as the specification of the dss:SignatureObject. 

• certificates pursuant to [RFC5280] and [RFC3281] in the xaip:certificateValues 

data element, 

• references to certificates in the xaip:certificateRefs data element, 

• revocation information pursuant to [RFC5280] in the xaip:revocationValues data 

element, 

• references to revocation information in the xaip:revocationRefs data element, 

• Evidence Records in the ERS standard format of the IETF pursuant to [RFC4998] or the 

XML based variation pursuant to [XMLERS] in the xaip:evidenceRecord data element, 

• a verification report for a credential object (vr:VerificationReport), or 

• other supplemental evidence data in the xaip:other data element. 

16 See: http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html 



Figure 9: Overview of the credential 17 data structure 


Certificates can be deposited as supplemental evidence data in the xaip:certificateValue data 

element, validity information for the certificates (revocation lists or OCSP responses) can be deposited 

in the xaip:revocationValue data element (also see Figure 10). 

17 Executed on the basis of the OASIS "Digital Signature Service Core Protocols, Elements, and Bindings“ 

version 1.0 from 11 April 2007. See: http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html. 




Figure 10: Signature objects and certificate information stored as Evidence Records 



Figure 11: Revocation information stored as credential 


NOTICE: The OCSP protocol cannot replace CRLs and other revocation technologies in every case. 

The OCSP responder retrieves the status information if applicable from CRLs, from another 

(additional) OSCP responder, a database, or another source of information. The advantage of a 

protocol compared to CRLs is that only the status information on the respective certificates that are 

requested has to be transmitted and stored. In contrast, a CRL contains a great deal of revocation 

information that is useless for the inquiry, and a CRL does not provide any proof that a certificate was 

ever issued. 

The xaip:ersInfo data structure serves to deposit the Archive Time Stamps pursuant to 

[RFC4998] belonging to an Archival Information Package that have to be included in a new archive 

system in the event of a migration and, in doing so, have to be embedded into the “migrated” XAIP 

container. Optionally, the Archival Information Package ID (AOID) can also be deposited for each 

evidence record. 



Figure 12: The evidenceRecord data structure 


Two possibilities are stipulated for the storing of an Evidence Record pursuant to [RFC4998] / 

[XMLERS] in the xaip:evidenceRecord data element. One is on the basis of the XML 

specification [XMLERS] and the other is as Base64 coded binary data on the basis of the ASN.1 

specifications published in [RFC4998]. 

The vr:VerificationReport data element in the xaip:credential data structure (also see 

Figure 9) serves for storing additional validity or verification information that may be requested for 

individual xaip:credential insofar as they can or should not be added as unsigned attributes to the 

signature or time stamp data – as stipulated in [CAdES] or [XAdES] – or were already deposited in the 

xaip:credential data structure. 

In vr:VerificationReport, the verification results for technical evidence records and other 

supplementary evidence data (e.g. signatures, time stamps, certificates, and revocation information 

that is not already a part of the signature) can be stored in the form of verification reports pursuant to 

the OASIS "Profile for comprehensive multi-signature verification reports for OASIS Digital 

Signature Services“ [OASIS-VR]. 

The CredentialValidity is of the vr:IndividualReport data type (see [OASIS-VR]) and 

can include the following elements in the optional Details element (also see Chapter 3.5): 

• A DetailedSignatureReport for the verification of electronic signatures, 

• an IndividualTimeStampReport for the verification of individual time stamps 

pursuant to [RFC3161] that are not already part of a signature, 

• an IndividualCertificateReport for public key certificates pursuant to [RFC5280] 


• an IndividualAttributeCertificateReport for attribute certificates pursuant to 

[RFC3281] that are not already part of a signature, 

• an IndividualCRLCertificateReport for revocation lists pursuant to [RFC5280] 


• an IndividualOCSPReport for OCSP responses pursuant to [RFC5280] that are not 

already part of a signature, and finally 

• an EvidenceRecordReport for evidence records pursuant to [RFC4998] or [XMLERS]. 




The following Figure 13 depicts again the structure of the vr:VerificationReport structure 

concretised on the basis of the OASIS Profile [OASIS-VR]. 

Figure 13: Overview of the vr:VerificationReport dData sStructure [OASIS-VR] 

3.6.6 Sample realisation of the XAIP data structures on the basis of XFDU 

It is explained in this section how the XAIP data structure introduced above can be realised on the 

basis of the [XFDU] specifications by means of which any synergies with the preliminary work in the 

XFDU environment can be used. In particular, this is how the experiences collected in the aerospace 

industry executing XML based archival information packages pursuant to [OAIS] can be applied and 

the freely available XFDU 18 library of the European Space Agency (ESA) can be used. 

To do so, the main structures of [XFDU] will be introduced briefly in Section 3.6.7 before 

recommendations for the realisation of an XAIP on the basis of [XFDU] are made in Section 3.6.8. 

3.6.7 Fundamentals of XFDU 

After a rough overview of XFDU in section 3.6.7.1, the following sections will go into the realisation 

of the elements of the XFDU structure relevant for the realisation of an XAIP: 

• packageHeader (see Section 3.6.7.2) 

• informationPackageMap (see Section 3.6.7.3) 

• metadataSection (see Section 3.6.7.4) 

18 See http://www.gael.fr/xfdu/site/ . 



• dataObjectSection (see Section 3.6.7.5) 


Because no behaviorSection is needed for the realisation of an XAIP, it will not be described 

here in more detail. 

3.6.7.1 Overview of XFDU 

As implied in Figure 14 and explained in more detail in [XFDU], an XFDU (XML Formatted Data 

Unit) generally consists of a (compressed) Package Interchange File that contains, in addition to an 

XML based manifest document, additional files to which the manifest document refers. 

However, for the realisation of an XAIP for the purposes of trusted long-term storage, only the XML 

based manifest document is used so that an Archival Information Package that bears all of the 

information in it arises. 

Figure 14: Conceptual look at an XFDU package (from [XFDU], figure 2-1) 

The XFDU manifest is itself an XML file that fulfils the schema specified in [XFDU]. 



Figure 15: Structure of the XFDU manifest document 

As can be seen in Figure 15, the XFDU manifest includes the following elements: 


• packageHeader – can contain general information about the entire information package 

and its environment. Additional details can be found in [XFDU], Section 5. 

• informationPackageMap – contains a sequence of content data derived by means of an 

abstraction mechanism from the contentUnitType data type. In the case of the 

ContentUnit elements arising in this manner, this can be a sequence of references to data 

objects (dataObjectPointer), references to complete XFDU structures 

(XFDUPointer), included ContentUnit structures, or structures defined in the scope of 

an extension (extension). Furthermore, the ContentUnit elements have attributes 

which can refer to the correspondingly classified meta data and, as the case may be, a 

stipulated behaviorObject. Additional details can be found in [XFDU], Sections 6-7. 

• metadataSection – can contain a sequence of metaDataObject elements. Additional 

details on this can be found in section 3.6.7.2 and [XFDU], Section 9. 

• dataObjectSection – can contain a sequence of dataObject elements. Additional 

details on this can be found in section 3.6.7.5 and [XFDU], Section 8. 

• behaviorSection – can contain a sequence of behaviorObject elements by means of 

which executable functions can be linked with the content data. To do so, the 

behaviorObject element contains the interfaceDefinition element that, in turn, 

contains a sequence of input parameters (inputParameter). Additional details can be 

found in [XFDU], Section 10. The behaviorSection element is not needed in the scope 

of the trustworthy long-term storage on account of the system environment that is, as a rule, 

defined. 




Furthermore, the XFDU element possesses an objID attribute by means of which the entire 

information package is designated in a unique way (also see archiveObjectID in the 

xaip:packageHeader structure, Section 3.2). 

As sketched in Figure 16, a ContentUnit that can be assigned to a behaviorObject can refer to 

other contents in the form of additional ContentUnit elements as well as corresponding objects in 

the xfdu:dataObjectSection and xfdu:metadataSection. 

Figure 16: Logical view of the XFDU manifest (from [XFDU], Figure 2-2) 

3.6.7.2 Structure of the xfdu:packageHeader element. 

As seen in Figure 17, the xfdu:packageHeader element consists of a volumeInfo element 

and, as the case may be, a sequence of environmentInfo elements. 



Figure 17: The structure of the packageHeader element 


The volumeInfo element contains information on the used XFDU specifications 

(specificationVersion) and, if applicable, additional information on the relative position of 

the current XFDU in a sequence of XFDUs (sequenceInformation). Information about the 

environment in which the XFDU arose can be contained in the environmentInfo elements. 

3.6.7.3 Structure of the xfdu:informationPackageMap element 

As can be seen in Figure 18, the xfdu:informationPackageMap element consists of a sequence 

of content units (xfdu:abstractContentUnit elements) which, in turn, 

• refer to additional XFDU structures (XFDUPointer), 

• refer to data objects (dataObjectPointer), 

• a sequence of subordinated content units (xfdu:abstractContentUnit), or 

• contain other information defined by means of a specifications extension (extension). 



Figure 18: Structure of the xfdu:informationPackageMap element 

3.6.7.4 Structure of the xfdu:metadataSection element 


As seen in Figure 19, the xfdu:metadataSection element consists of a sequence of 

metadataObject elements. 

Figure 19: Structure of the xfdu:metadataSection element 

The metadataObject element can, in turn, contain the following elements: 

• metadataReference – to refer to meta data outside of the information package, 

• metadataWrap – to encapsulate XML based or binary meta data, and 

• dataObjectPointer – to refer to data objects that are deposited in the 

dataObjectSection (also see Section 3.6.7.5) or that are referred to there. 




In addition to an obligatory ID attribute that can be referred to in the ContentUnit elements, the 

metadataObject contains attributes for classification of the meta data 19 . In doing so, one should 

differentiate between the following categories pursuant to [OAIS] (see Section 4.2.1.4 in [OAIS]) and 

[XFDU] (see Section 9 in [XFDU]: 

• Representation information (REP), 

• Preservation description information (PDI), and 

• Descriptive information (DMD). 

In turn, there are different classes in these categories. For example, there are especially important PDI 

categories in the Guideline for Preservation of Evidence of Cryptographically Signed Documents at 

hand, among others those in the following classes (also see [OAIS], section 4.2.1.4.2): 

• REFERENCE – contains indentifiers by means of which the ContentUnit is uniquely 

identified in the “outside world,” 

• CONTEXT – describes the relationship between the ContentUnit and its environment, 

• PROVENANCE – describes the origin of the ContentUnit and any changes since it arose, 

and 

• FIXITY – contains information by means of which the integrity and authenticity of the data 

can be proved. It will be described in section 3.6.8.5 how certain supplemental evidence data 

can be deposited in the XFDU structure. 

3.6.7.5 Structure of the xfdu:dataObjectSection Element 

As seen in Figure 20, the xfdu:dataObjectSection element consists of a sequence of 

dataObject elements. 

Figure 20: Structure of the xfdu:dataObjectSection element 

A dataObject element can, in turn, contain the following elements: 

19 The meta data are defined as “data about other data" in [OAIS] and [XFDU]. 




• byteStream – can arise multiple times and contains either direct binary or XML based 

contents (fileContent) or references to the corresponding data (fileLocation), which 

in turn can be furnished with checksums (checksum). 

• checksum – can contain a checksum for the data object. 

• transformObject – can arise multiple times and specifies which transformation steps 

were applied to the original data before depositing, and thus must be reversed to reconstruct it. 

Furthermore, multiple attributes are assigned to a dataObject by means of which one can refer to 

them and, e.g. to REP meta data (see Section 3.6.7.2). Furthermore, the MIME-type and the size of the 

data can be stored in these attributes. 

3.6.8 Realisation of an XAIP with XFDU 

A possible realisation of an XAIP container will be sketched in this section on the basis of the 

previously described XFDU structure. To do so, first in Section 3.6.8.1 a rough overview of the 

correspondence between XAIP and XFDU will be provided before the realisation of an XAIP on the 

basis of XFDU is described in more detail in the following sub-chapters. 

3.6.8.1 Overview of correspondence between XAIP and XFDU 

As shown in Figure 21, the packageHeader structure of the XAIP (see Sections 3.2 and 3.6.7.2) 

contains approximately the same information as the element in XFDU of the same name, including the 

"table of contents" in the xfdu:informationPackageMap element. Whereas there is a direct 

correlation between the XAIP and the XFDU regarding the metadataSection (see Section 3.3 and 

3.6.7.4) and the dataObjectSection (see Section 3.4 and 3.6.7.5), the contents of the 

credentialSection of the XAIP are stored as specific meta data in XFDU (in the 

xfdu:metaDataSection) because the XFDU specification does not stipulate any specific section 

for supplemental evidence data in the style of a credentialSection. 

The xfdu:behaviorSection is not needed for the intended purposes for trustworthy long-term 

storage, and is not present in the case of an XAIP for that reason. 



Figure 21: Overview of realisation of an XAIP with XFDU 

3.6.8.2 Realisation of the XAIP packageHeader in XFDU 


As explained in Section 3.2, the PackageHeader in particular contains the following elements: 

• AOID – corresponds to the objID attribute in XFDUType. 

• textInfo – corresponds to the attribute of the same name in XFDUType. 

Furthermore, there is a range of additional elements in the XAIP packageHeader that should be 

deposited with the XFDU as meta data in the preservation description information (PDI) category with 

the classification described below (see Section 3.6.7.4) in more detail: 

• packageID – includes if applicable the identifier of the Archival Information Package used for 

the transaction application and is deposited as meta data in the REFERENCE class. 

• submissionInfo – contains information about the archiving transaction application and 

the process of archiving and is deposited as meta data in the PROVENANCE class. 

• preservationInfo – contains the retention period and is deposited as meta data in the 

PROVENANCE class. 

After all, XAIP has an explicit schemaLocation element that is implicitly included in the XML 

based XFDU structure and a packageManifest that includes information on the contents of the 

Archival Information Package and corresponds to the informationPackageMap in [XFDU]. 

As explained in Section 3.2, the xaip:PackageInfoUnit as the heart of the 

xaip:VersionManifest element contains the following elements in particular that correspond 

directly to the following attributes in the informationPackageMapType: 

• packageUnitID – corresponds to the ID attribute. 

• unitType – corresponds to the packageType attribute. 



• textInfo – corresponds to the attribute of the same name. 


Additionally, the xaip:PackageInfoUnit element in an XAIP contains a sequences of references to 

associated payload data, meta data, and credential objects. With the XFDU, such references are not 

contained in the “table of contents," but rather arise from the data objects. 

After all, there is a dataObjectPointer element in the XAIP element that corresponds to the 

element of the same name in [XFDU], and it is possible in both cases to use it to map hierarchical 

relations between content units. 

3.6.8.3 Realisation of the XAIP metaDataObjectSection in XFDU 

The metaDataObjectSection of the XAIP container (see Section 3.3) and the XFDU (see 

Section 3.6.7.4) are very similar, so it is possible for there to be especially simple assignment of the 

respective elements. 

In both cases, the metaDataObjectSection consists of a sequence of meta data objects 

(xaip:metaDataObject or 20 xfdu:metaDataObject) that have the following contents: 

• metaDataID – corresponds to the ID attribute. 

• classification – corresponds to the attribute of the same name. 

• category – corresponds to the attribute of the same name. 

• Contents of the metaData – corresponds to the metaDataWrap element in XFDU. 

Furthermore, with XAIP there is also the possibility of inserting free text information (textInfo) 

that must be contained in the xfdu:metaData element itself in case of [XFDU]. 

On the other hand, [XFDU] also offers the ability to refer additionally to externally deposited meta 

data (xfdu:metaDataReference) or to data objects contained in XFDU 

(cfdu:dataObjectPointer). 

For the realisation of an XAIP, though, no references to externally deposited meta data 

(xfdu:metaDataReference) should be used; rather, the XML based Archival Information Package 

should contain all of the meta data itself in order to make migration easy. 

3.6.8.4 Realisation of the XAIP dataObjectSection in XFDU 

The dataObjectSection of the XAIP container (see Section 3.4) and the XFDU (see Section 

3.6.7.5) are also very similar, so it is possible for there to be especially simple assignment of the 

respective elements. 

In both cases, the dataObjectSection consists of a sequence of data objects (DataObject or 

dataObject) that, in addition to the actual content data (contentData or byteStream 21 ) and 

20 In the following comparison, the XAIP element (e.g. MetaDataObject) will be listed first, then the 

corresponding XFDU element (e.g. xfdu:metaDataObject). 

21 The [XFDU] specifications make it possible to divide a payload data unit into different byteStream 

elements. This option should not be used. In accordance with this, the combinationName attribute with 

the realisation of an XAIP will, as a rule, be missing. 




an identifier (dataObjectID or ID (as XML attribute) optionally contains a checksum (CheckSum 

or checksum). In both cases, XML based and binary data can be stored. 

As with XAIP, there can be an optional sequence of xfdu:transformObject elements in 

[XFDU] with which the stored data can be transformed (e.g. canonicalized or encrypted). In the case 

of the realisation of an XAIP, though, no such elements should be used; rather any transformations 

should always be executed outside of the archive. 

Furthermore, the following attributes exist pursuant to [XFDU]: 

• repID – makes it possible to refer to associated REP meta data. 

• mimeType – makes it possible to indicate of the MIME-type 22 of the data. 

• size – makes it possible to indicate the size of the data object. 

• registrationGroup – makes it possible to provide information about the registration 

process associated with the data. 

3.6.8.5 Realisation of the XAIP credentialsSection in XFDU 

As shown in Figure 15, there is no specific (credentialsSection) element (see Section 3.5) in 

which the signature data and evidence records would be stored in the XFDU structure. Rather, as 

implied in Figure 21, it is recommended that the signature data be deposited as meta data of a certain 

category and classification in the xfdu:metaDataSection element (see Section 3.6.7.4). 

In particular, the CredentialObject described in more detail in the following should be contained 

in a corresponding xfdu:metadataObject/metadataWrap/xmlObject in the XFDU 

structure for each supplementary evidence data object (signature, time stamp, certificate, certificate 

status information). 

In this metaDataObject, the attribute category=”PDI” and classification=”FIXITY” 

are also to be occupied in addition to the obligatory ID attribute. The optional elements 

metaDataReference and dataObjectPointer as well as the vocabularyName and 

mimeType attributes should not be present. 

The xfdu:metaDataObject has exactly one child, metadataWrap, which in turn contains an 

xaip:CredentialObject element (see Sections 3.5 and 3.6.5) in its child, xmlData. 

22 See http://www.iana.org/assignments/media-types/ . 



4. Payload data formats 


The following section describes electronic data formats that are recommended at the time of the 

publication of this Technical Guideline for the long-term preservation of payload data, primarily with 

consideration for the long-term ability and automatic readability and interperability 23 . 

Payload data includes both the actual content data (primary information or also object data) and the 

meta data that describes the transaction and archiving context. 

4.1 Metadata 

In the broadest sense, meta data are data that describe other data. Metadata are markup data that 

describe the structures and context of data during the processing of data by IT systems that create, 

processes, manage, and store the data. The meta data of an Archival Information Package serve the 

identification and reconstruction of the administrative or transaction context of the stored content data. 

XML based solutions have established themselves as the global standard for the cross-platform 

exchange of data for the structural description of electronic documents, i.e. the mapping and 

describing in a machine-readable manner of document structures. 24 

An Archival Information Package, i.e. an electronic document intended for long-term depositing in an 

electronic archive system in the sense of this Guideline is therefore a self-explanatory and properly 

formed XML document that can be verified against a valid and authorised XML schema. 

4.1.1 Extensible Markup Language (XML) 

The Extensible Markup Language [XML] is a format description language developed primarily for the 

Internet for the exchange of structured data and was standardised in 1997 by the Word Wide Web 

Consortium (W3C). 25 

On the syntax level, XML, as a text-based meta markup language, does not just support the 

description, rather it also supports the automatic display, manipulation, and processing of logically 

structured data, and furthermore, it is characterised by good expandability and a great deal of 

flexibility. 

Rules and structure definitions in XML syntax (XML schema) on a semantic level support the 

mapping of structured content models. XML schemas do not only allow a formal and machinereadable 

description of an XML vocabulary allowed for the exchange of data, but rather they also 

allow the development of complex data structures and the formulation of processing instructions. An 

XML schema uses a formal grammar to determine which XML elements are defined, which 

processing rules should be executed in what manner, and which meaning the individual elements have. 

23 Additional definitions and recommendations regarding suitable document formats can be found at 

http://www.kbst.bund.de/saga. 

24 For that reason, the Standards and Architectures for E-Government applications [SAGA] in the version 3.0 

from October 2006 promote XML as the universal and primary standard for the exchange of data in and with 

the administration. Newly created systems should principally be able to exchange data using XML. 

25 more at: http://www.w3c.org/XML/. 




The confidentiality of XML documents can be ensured by means of “XML Encryption” [XMLENC], 

the integrity and authenticity by means of “XML Digital Signature” [XMLDSIG]. In doing so, 

different forms of XML signatures will be differentiated depending on whether the signatures are 

within or outside of the XML document. 

Use 

For all data/documents and as character set and descriptive language for all of the Archival 

Information Packages that comform to this Technical Guideline: A valid XML formatted Archival 

Information Package shall fulfil the XML specifications of the World Wide Web Consortium (W3C) 

[XML]. 

4.1.2 XML Schema (XSD) 

XML schema is an XML markup language to define the structures of XML documents (XML 

instances). With the help of an XML schema it is possible to formalise structures and limitations 

expressed in the form of rules or structure modules that apply to a class of XML documents. XML 

schema are used as a rule in order to document an applicable and valid XML vocabulary for the 

exchange of data within a business area or branch. 

In doing so, the main purpose of an XML schema is the validation of XML documents. By validating 

an XML document against a schema one can ensure that the contents of the XML document 

correspond to the agreed rules. 

An Archival Information Package in the sense of this Guideline shall be verified against a valid and 

authorised XML schema before being deposited in electronic long-term storage. The authorisation 

shall ensure that the creator (owner) of the schema is uniquely identified and that the schema cannot 

be manipulated without being noticed. 

Use 

For all archival information packages that conform to this Guideline: A schema that conforms to this 

Guideline shall implement the normative recommendations of the XML Schema Working Group of the 

W3C [XSD] 26 . 

4.2 Content Data (Object Data) 

It shall be ensured for a long-term legally compliant preservation of electronic primary information 

(content data) that the negotiability and (machine) readability of the stored electronic information can 

be guaranteed by suitable measures for the duration of the statutory preservation periods at a 

minimum. 

In order to ensure the long-term negotiability, solely standardised data formats that are stable over the 

long term with a public description should be used. 27 The use of standard formats does not only reduce 

26 A basic set of requirements that is described in the XML Schema Requirements Note of the W3C leads to a 

number of uses for schemas and the draft guidelines upon which they were based (see 

http://www.w3.org/TR/NOTE-xml-schema.req ). 

27 See also: Printing 16/5927 of the German Bundestag from 4 July 2007. According to this, standards are to be 

considered open "if they make the exchange between different platforms and applications possible and are 

adequately documented. The interfaces must be open and the technical specifications executable. In doing so, 




the dependence on hardware and software environments, but also the necessity for future format 

transformations, which require a non-insignificant amount of effort, in particular when electronic 

signatures are used. 

4.2.1 Documents (Records) 

The DOMEA Organisation Concept 2.1 28 and the Standards and Architectures for 

E-Government Applications (SAGA) 29 , like the Model Requirements for the Management of 

Electronic Records - Moreq2 30 of the European Commission, recommend that only a few standardised 

data formats be used for the long-term depositing of electronic written documents. 

These include (at the time of the publication of this Technical Guideline): 

4.2.1.1 Text (ASCII) 

ASCII (American Standard Code for Information Interchange) stands for a character set and for a text 

format. An ASCII text describes a document that only consists of characters of the ASCII character set, 

and thus does not include any layout information and is thus particularly well suited for simple text 

information and meta data. The ASCII code was specified in 1972 by the International Organization 

for Standardization as ISO 646 31 and, from the perspective of today, offer the best prerequisites for 

ongoing negotiability. Because ASCII by its definition does not incorporate any character sets, correct 

display is not always guaranteed. 

The format originally consists of 7 bit with which 128 (character) combinations can be displayed, and 

thus a character set based on the Latin alphabet as used in the modern English language. 8-bit ASCII 

character sets were defined in order to map some special characters, such as the umlauts in the German 

language. 

The so-called Unicode Standard is a further development of the ASCII coding 32 . Depending on the 

coding table, it is based on 8 (UTF-8), 16 (UTF-16) or 32 (UTF-32) bits per character code. 

Use 

For simple, unformatted texts (text data): Documents (text data) that are solely in Latin letters should 

only use the character set defined in ISO Standard ISO 646:1991 (ASCII) [ANSIX3.4]. 

Documents (text data) that are not solely in Latin letters should use the current version of the Unicode 

Standard [UNICODE]. 

Unicode is the functional equivalent to Standard ISO 10646-1:2000. Texts that conform to Unicode are 

principally coded in UTF-8 or UTF-16. 

the design of the conditions of use should correspond to the specifications of the international standardisation 

organisation.” 

28 See http://www.kbst.bund.de/domea . 

29 See http://www.kbst.bund.de/ saga . 

30 See http://ec.europa.eu/transparency/archival_policy. 

31 See http://www.iso.org/. 

32 These specifications are available at http://www.unicode.org/ . 



4.2.1.2 PDF/A 


PDF/A-1 33 is a standard established as an ISO standard on the basis of [PDF 1.4] for the long-term 

archiving of electronic documents. 

Published as ISO 19005-1:2005 34 , PDF/A-1 defines the requirements of a PDF that conforms to the 

standard and regulates the use of PDF with regard to the long-term stability and reproducibility. 

The standard specifies two levels of conformance: 

• PDF/A-1a - Level A conformance: Both unique visual reproducibility and the consistent use of 

Unicode and content structuring of the document. 

• PDF/A-1b - Level B conformance: unique visual reproducibility. 

PDF/A is set up as a series of standards. Additional parts are currently being worked on in the 

competent ISO committee (ISO TC171 SC2 WG5). A second part of the standard PDF/A-2 will likely 

appear in the second quarter of 2011 that is based on the ISO version of the PDF format (ISO32000 35 ) 

and takes into account a number of technological innovations that have arisen in the meantime, such as 

JPEG2000. 

Because there is another series of standards based on PDF since 2001, PDF/X 36 - for the exchange of 

masters in the graphic industry, it was ensured during the development of PDF/A that a valid PDF/ A 

file can also be a valid PDF/X file. 

PDF/A, like PDF version 1.4, supports various security measures, in particular also the embedding of 

electronic signatures in the internationally recognised PKCS#7 format [PKCS#7]. 

PDF/A is also recommended for archiving by the the Guidelines for Electronic Records Management 

[Moreq2] promoted by the European Commission as the format for archiving. 

Use 

For all (primarily) character oriented static documents. 

Recommendation 

PDF files should fulfil the ISO 19005-1 (PDF/A-1) standard. In doing so, the following limitations 

apply based on the conformity level: 

• Converting: If the file is converted from another file format, e.g. Microsoft Word, into PDF/A 

then a program shall be used that explicitly enables the creation of PDF/A compliant files. 

Alternatively, it can be outputed in version 1.4 of PDF, for example with the help of the 

program developed by Adobe, Acrobat Distiller version 5.0 or higher, or the freely available 

AFPL GhostScript in version 7.0 or higher. In this case, too, final conversion into PDF/A with 

a corresponding converter should be carried out because PDF 1.4 allowes structures and 

contents that are not allowed in PDF/A. 

• Tagged PDF: Tagged PDF stipulates a defined internal structure for text content of a PDF file 

in order to retrieve its contents with suitable tools so that they can be processed further for 

other purposes. Possible applications are the transmission of contents in file formats like 

33 See http://www.adobe.de/products/acrobat/pdfs/pdfarchiving.pdf . 

34 See http://www.iso.org/ . 


36 PDF/X is standardised in the ISO standards 15929 and 15930; ISO 15929 defines the PDF/X approach in 

general; ISO 15930 defines concrete parts of the standard, more under http://www.iso.org/ . 




XML, HTML, or RTF. Files shall be created in such a manner that they correspond to Tagged 

PDF as described in the [PDF 1.4]. The conformity level A (PDF/A-1a) can be reached in this 

manner. 

• Linearised PDF: Linearised PDF was developed in order to be able to show the pages of a 

PDF file as quickly as possible within network environments, such as the World Wide Web. 

This profile does not impair the ability to archive the data over the long term; it is allowed to 

use it when generating PDF files. 

• Meta data: A file that can be archived should be self-explanatory insofar as possible, which 

can be guaranteed, among other ways, by storing meta data on the basis of the eXtensible 

Metadata Platform (XMP) 37 developed by Adobe in the file itself. The storage of the meta data 

must be done in XMP format. This also concerns the original PDF meta data such as author, 

title, creation tool, etc., insofar as they are used in the document. 

• Encryption and other security settings: Read-access to a file may not be subject to any 

limitations whatsoever; in particular no passwords may be used in order to prevent the 

application of certain functions to the file. It is thereby guaranteed, for example, that the file 

can be transmitted into other formats for the purposes of archiving if this is necessary to 

maintain its contents. 

Limitations on printing shall be avoided. Security options that go further, such as limitations 

on the extraction of passages of text or copying options shall not be used. 

• Authenticity and integrity: The use of cryptographic procedures (electronic signatures and 

time stamps) in order to prove the authenticity and integrity of a PDF file is recommended 

when not expressly required by legal regulations. In doing so, though, only those signature 

creation applications should be used that have been evaluated and certified by the BSI as 

secure signature application componentsin the sense of the German Signature Act SigG. 

Should signatures be embedded in the document, the container structure introduced with PDF 

1.3 based on PKCS#7 applies. 

• Text: Each font used in the text of the file shall be embedded in the file; therefore, the file 

shall contain the graphic descriptions of all of the fonts used therein in addition to the actual 

text. For optimisation, only the characters currently used for description of the test must be 

embedded (Subsetting). This measure ensures that PDF display programs can display the file 

in the form intended by the author without having to make use of replacement fonts that could 

change the appearance of the file. The standard fonts provided by Adobe shall also always be 

embedded insofar as they are used in the document. 

Principally, only public available fonts should be used, that are in no way subject to 

limitations by the owners of the rights. Insofar as possible, all of the characters contained in 

the file should be present in machine-readable coded form and not as digitalised pictures of 

characters so that they are available for search functions. 

For sections of text that include characters that go beyond the ISO-8859-1 character set for 

American English and Western European languages [ISO-Latin-1] 38 , the [UNICODE] 

character set should be used. Thus, an author should encode texts either in ISO-Latin-1 or in 

37 See XMP Adobe eXtensible Metadata Platform; more under http://www.adobe.com/products/xmp 

38 

ISO/IEC 8859-1:1998 Information technology -8-bit single-byte coded graphic character sets, Part 1: Latin 

alphabet no. 1, see: http://www.iso.org/ . 

Federal Office for Information Security 47 

.



UNICODE, which is realised concretely by choosing a corresponding font that has consistent 

coding such as Arial Unicode MS. 

• Graphics: If the file contains graphic depictions (figures), then they shall be included either 

with their source colour profiles (e.g. CalRGB) or all graphics are assigned a uniform source 

colour profile or OutputIntent (e.g. standard red-green-blue [sRGB] 39 . This ensure a deviceindependent 

colour space specification. 

The so-called transparency key introduced as a visual effect in PDF version 1.4 that makes it 

possible to generate graphics that appear to overlap or be translucent generally shall not be 

used in general. Corresponding pictures with transparency are to be converted (flattening). 

Alternative views (e.g. so-called downsampling for quick previews in the web) are allowed 

neither for colour nor for black and white pictures. The same applies to levels. 

The picture formats allowed in a PDF/A-1 file are, among others, TIFF/G4, JBIG, JBIG2 and 

JPEG. The JPEG2000 format is not allowed in PDF/A-1. 

• Integration: All contents needed for the presentation of the document shall be included in the 

file itself so that it is not necessary to load data streams from external sources. The file may 

not included any object that would require an external application for its display. A view that 

requires a rendering for specific output devices is not allowed. 

• Audio/Video: For the reasons listed above, a file may not contain audio or video data streams. 

• Links: Internal links that refer to jump labels within the file, such as headlines, are allowed. 

External links that refer to jump labels outside of the file, such as hyperlinks to resources in 

the Internet, should be designed if possible so that all symbolic addresses of these links, such 

as file path, uniform resource locators (URL), or persistent identifiers, are contained in the text 

of the file and can be displayed on the screen or printed on paper without any additional 

measures. For example: instead of “Website of the ArchiSafe project" with a link behind the 

text, one should write: “Website of the ArchiSafe Project (http://www.archisafe.de)". 

• Commentary: The use of commentary is allowed as long as they do not contain audio or 

video data streams or any other data attachments. 

• Executable Actions: The file shall not request executable command strings such as scripts; in 

particular JavaScript may not be included in the fields of forms or any other place. Form fields 

themselves are allowed. 

4.2.1.3 ODF 

The Open Document Format (ODF) was standardised by OASIS 40 as an XML-based document format 

for texts, spreadsheet calculations, presentations, and other office documents. The contents of the 

documents and information about their layout are separated from each other and thus they can be 

processed independently. It can be used to exchange complex documents that are intended for further 

processing. 

39 

sRGB: http://www.srgb.com/srgb.html or as IEC-Standard: IEC 61966-2-1 – Ed. 1.0 – Bilingual 

Multimedia systems and equipment - Colour measurement and management - Part 2-1: Colour management - 

Default RGB colour space - sRGB, see: http://webstore.iec.ch/webstore/webstore.nsf/ . 

40 See http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf . 




In November 2006, OpenDocument v1.0 was published as a standard under the name ISO/IEC 

26300:2006 41 . The OpenDocument format is supported by the platform-independent, licence-cost-free 

Open Office package OpenOffice.org 42 , among others. 

Use 

For all (primarily) character oriented documents 

4.2.1.4 TIFF 43 

The “Tagged Image File Format” (TIFF) makes it possible to save graphic information without loss of 

information and has been standardised pursuant to ISO 12639 for media-independent image 

processing. The coding of the format makes it possible to store multiple views (e.g. thumbnails) or 

versions of a graphic as well as text information as meta data in a file. 

The use of TIFF is especially recommended if the graphic information of a document is of great 

significance to its explanatory power. TIFF is supported by all major graphic and presentation 

applications. 

In order to achieve maximum interoperability, only those characteristics from the "Baseline TIFF" 44 

should be used. TIFF can be used if the ability of the format to depict multilaterial documents is 

needed. TIFF is especially well suited for scanned text documents (grey scale or B/W graphics). 

Use 

For figures (non coded information, for example raster images). 

TIFF files should fulfil the basic version 6.0 TIFF specifications [TIFF6]. 

Furthermore, the following extensions can be used: 

• CCITT bitlevel coding, and 

• LZW compression. 

4.2.1.5 JPEG 

The JPEG format 45 (Joint Photographic Experts Group) stands for a compression procedure and a 

graphic format and is one of the most comment graphic formats used in the Internet. The JPEG 

standard was published in 1992 as ISO/IEC 10918-1. Because the definition of the structure of JPEG 

files allows many freedoms, a standard that organises the exchange of image files compressed as 

JPEGs with the "JPEG File Interchange Format" (JFIF). JFIF is based on the JPEG standard and is 

platform independent. 

The use of the JPEG format as the alternative for the TIFF can be advisable if one has to compromise 

between picture quality and file size. 

Use 


42 See http://de.openoffice.org/ . 

43 

See http://partners. adobe.com/public/developer/en/tiff/TIFF6.pdf 

. 

44 Those characteristics that all TIFF-capable applications should support are summarized under "Baseline 

TIFF". For example, only the "Huffman” and “Packbits” compression procedures belong to “Baseline TIFF”, whereas 

“LZW”, “JPEG”, “ZIP”, and “CCITT” are optional expansions not implemented in every TIFF-capable program. 

45 See http://www.jpeg.org/index.html?langsel=de, standardised as ISO/IEC 10918-1:1994, see http://www.iso.org/ 

standardised as ITU-T.81, see http://www.itu.int/rec/T-REC-T.81/en . 

Federal Office for Information Security 49 

,



4.2.1.6 PNG 


PNG 46 (Portable Network Graphics Format) was developed from the later “PNG Development Group” 

as an alternative to the GIF format and is especially suitable for use in the Internet because of the 

opportunity for loss-free compression and incremental display of the graphics. The PNG specifications 

are open and were elevated to an international standard in 2003 as ISO/IEC 15948 47 . Most image 

editing programs support PNG as standard. So called calibrating data blocks allow the calibration of 

the display so that, for example, the picture can be printed exactly as the author sees it on the screen. 

Use 


4.2.2 Multi-Media Formats 

“Multimedia" is characterised by the opportunity to use diverse digital means for portraying 

information (video, audio, picture, and text). 

In this context, a multi-media format is a self-explanatory file format that contains the content data and 

(in the case of container formats, see below) their structure and interrelations. 

Three multimedia formats can be differentiated: 

• An audio format describes the structure of an audio file, 

• a video format describes the structure of a video file, 

• a container format can contain multiple data elements (called “streams”) with different 

formats. This is initially not limited to multimedia formats. The container regulates the 

interplay and sequence of the individual data streams. Thus, for example, a container can 

contain multiple audio streams on a video stream, and it is possible to embed subtitles (e.g. in 

the form of graphics). The audio streams can also be coded with various Codecs 48 that can be 

used to code or decode analogue signals or digital audio or video data and thereby map 

different tone qualities, for example. 

In the following sections, the most common representatives of the file format classes "audio", "video", 

and "container" are described briefly. The common container formats are not normally perceived as 

container formats, but rather as audio or video formats. Thus, the container formats are also described 

in the following sections. The recommended file formats are labelled in the corresponding manner. 

46 See http://www.w3.org/TR/PNG/ 

47 See http://www.iso.org/ 

48 Codec, a word coined for Coder/Decoder, a program or procedure (format) with which multimedia files 

(audio and/or video signals) can be digitally coded for the transmission by digital services/networks and then 

decoded again when playing. In most cases, the analogue signal is not digitalised without losses during the 

coding, rather there is a dynamic reduction of the analogue signal and a data compression of the digital signal 

which, according to the extent and the procedure can make a significant difference in the quality of the 

reconversion of the digital data stream into analogue signals. The main goal of the dynamic reduction and 

compression is a reduction in the bandwidth needed for the transmission of the digital signal or a reduction in 

the amount of storage capacity needed for the saving. The compressed data are deposited in a special code 

format. 




NOTICE: The multimedia formats that are common today and recommended in this document have 

not been analysed yet adequately for their suitability for long-term storage in a manner comparable to 

PDF. Thus, for the long-term availability of the archived data, it may be necessary to archive 

additional data, such as sound models or video drivers, along with the raw data. 

NOTICE: Naturally, only a small selection of recommended multimedia formats can be provided 

here. Numerous other formats used in the scope of the digital saving of audio and video information 

exist. However, at this time in the context for long-term storage, these formats can only be given a 

qualified recommendation or none at all, either because they are not common enough, there are no 

open specifications, or the legal situation (in particular the licence conditions) make use more difficult 

or do not recommend it. Thus, this Guideline is oriented – insofar as possible and sensible – on the 

general Standards and Architectures for E-Government Applications of the Federal Government 

(SAGA V4.0). 

4.2.2.1 Audio Formats 

4.2.2.1.1 Ogg Encapsulation Format 

Ogg 49 is a container format for multimedia files. The development of the container format is directed 

by the Xiph.org Foundation 50 . Codecs are also made available. 

The best-known and most popular codec is the Vorbis 51 audio codec. As an alternative, for better 

quality the loss-free FLAC 52 audio codec can be used. 

Ogg is an alternative to proprietary formats that is free from software patents and unlimited and 

therefore it is suitable for electronic long-term storage, in particular on account of the existing detailed 

format specifications that are available. 

Ogg-Vorbis is recommended as an audio format in SAGA V 4.0 (Standards and Architectures for E- 

Government Applications). 

The format also has the advantage that is can also be used as a recommended video format (with 

another codec), which contributes to the reduction in the overall number of data formats suitable for 

long-term storage. 

4.2.2.1.2 MP4 / MPEG-4 Part 14 

MP4 is also a container format for multimedia files. The development of the container format was 

directed by the Moving Picture Experts Group and is standardised in ISO/IEC 14496-12 and -14 

(MPEG-4 part 12 and 14) 53 . 

As an audio format, MPEG-4 is an open, manufacturer independent standard and is suitable for 

electronic long-term storage. The audio format is recommended in SAGA V 4.0. 

49 Published as RFC3533, see: http://www.ietf.org/rfc/rfc3522.txt . 

50 See http://www.xiph.org/ogg/ . 

51 See http://www.vorbis.com . 

52 See http://flac.sourceforge.net/ . 





MP4 also has the advantage that is can also be used as a recommended video format (with another 

codec), which contributes to the reduction in the overall number of data formats suitable for long-term 

storage. 

4.2.2.1.3 Advanced Audio Coding (AAC) 

Advanced Audio Coding (AAC) is a standardised audio format subject to losses. AAC is specified in 

ISO/IEC 13818-7 54 and is treated as an improved successor to MP3 because the quality is usually 

higher with the same bit-rate. 

AAC is a part of the MPEG-2 and MPEG-4 specifications and was developed by the Moving Pictures 

Experts Group. AAC itself is free of patents and licenses, but manufacturers of Codecs for AAC must 

pay licence fees. 

SAGA 4.0 does not mention AAC. Regardless of this, its openness and expected future popularity 

mean that it can certainly be recommended for long-term storage. 

4.2.2.1.4 EBU Broadcast Wave Format (BWF) 

In certain situations, it can also make sense to use the Broadcast Wave Format (BWF) pursuant to 

[EBU-BWF] format of the European Broadcasting Union (EBU) for the long-term preservation of 

audio files. 

4.2.2.2 Video Formats 

4.2.2.2.1 OggEncapsulation Format 

Ogg 55 is a container format for multimedia files. The development of the container format is directed 

by the Xiph.org Foundation 56 . The Theora 57 video codec, which was also developed by the Xiph.org 

Foundation, is available as the suitable codec. 

Ogg is an alternative to proprietary formats that is free from software patents and unlimited and 

therefore it is suitable for electronic long-term storage, in particular on account of the existing detailed 

format specifications that are available. 

Ogg-Theora is recommended as a video format in SAGA V 4.0 (Standards and Architectures for E- 

Government Applications). 

4.2.2.2.2 MP4 / MPEG-4 Part 14 

MP4 is also a container format for multimedia files. The development of the container format was 

directed by the Moving Picture Experts Group and is standardised in ISO/IEC 14496-12 and -14 

(MPEG-4 part 12 and 14) 58 . 

As a video format, MPEG-4 is an open, manufacturer independent standard and is suitable for 

electronic long-term storage. The video format is recommended in SAGA V 4.0. 


55 Published as RFC3533, see: http://www.ietf.org/rfc/rfc3522.txt 

56 See http://www.xiph.org/ogg/ 

57 See http://www.theora.org/ 





MP4 also has the advantage that is can also be used as a recommended audio format (with another 

codec), which contributes to the reduction in the overall number of data formats suitable for long-term 

storage. 

4.3 Base64 coding 

All (binary) primary information (content data) that was introduced in Chapter 4.2 should be saved 

within the XAIP structure of the Archival Information Package (see Chapter 3.4). Naturally, at the 

same time there is also the requirement here that the format and data be readable for a long time in the 

future, also by other systems and platforms. 

Entering binary data into an XML structure without changes is technically possible, but as a rule this 

causes a number of problems and is sure to lead to a certain dependency on a software or platform. For 

that reason, binary data must first be brought into a platform-independent form. For legal reasons, the 

coding necessary on the contents of the binary data may not make any changes; thus this shall be a 

bijective mapping 59 . 

BASE64 coding pursuant to [RFC4648] 60 is the most common method. It is primarily used in the 

Internet standard MIME 61 (Multipurpose Internet Mail Extensions) and is thus used primarily when 

sending e-mail attachments. This is required to ensure the problem-free transport of any binary data 

because the Simple Mail Transfer Protocol (SMTP) 62 in its original version was only designed for the 

sending of 7-bit ASCII characters. 

In the case of BASE64 coding, 3 byte (24 bit) of the original file are mapped to 4 blocks, each with 6 

bit of the target file. In doing so, the sequence of the bits is always maintained. 6 bit per block allow 2 6 

= 64 possible characters. That is where the name of the procedure comes from. For these 64 possible 

characters, the characters A-Z, a-z, 0-9, + and / were chosen. These characters are contained both in 

ASCII and in EBCDIC and are independent of a code page. Thus, data can also be exchanged between 

non-ASCII systems. 

The mapping of 3 bytes to 4 characters increases the need for space by 33%. However, this 

disadvantage is usually accepted 63 . 

The following procedure should be used for encapsuling content data in an XAIP document that 

conforms to this Technical Guideline. 

• If the content data consist solely of text (ASCII) (see Chapter 4.2.1.1) or XML, these data can 

be inserted without re-coding into the XAIP data structure. 

• All other data formats shall be coded in BASE64 before they are inserted into the XAIP data 

structure. 

59 A mapping f:A->B is called bijective (or unique in reverse) if different elements in an original mass A are 

mapped to different elements in an image mass B, and if each element from B appears as a depiction of 

exactly one element of the original mass A. 

60 See http://www.ietf.org/rfc/rfc4648.txt . 

61 See http://www.ietf.org/rfc/rfc2045.txt. 

62 See http://www.ietf.or/rfc/rfc821.txt. 

63 Another coding procedures also exist. However, they are usually only used for special applications (e.g. in 

the post-script file format from Adobe or for the address coding of IPv6 addresses) or not at all. 




• For BASE64 coded data, there should be an entry stipulated for the corresponding MIME 

format of the content data in the meta data section that contains information that could be 

needed for adequate representation of the content data. 



5. Cryptographic data formats 


The following section describes a few cryptographic data formats that are recommended at the time of 

the publication of this Technical Guideline for Preservation of Evidence of Cryptographically Signed 

Documents. 

5.1 Signature formats 

The signature formats common in practice include in particular ASN-1 based signatures of the CMS 

family pursuant to [PKCS#7, RFC5652, ETSI 101733] (see Section 5.1.1) and the XML based 

signatures pursuant to [XMLDSIG, ETSI 101903] taken into account in Section 5.1.2. 

Insofar as the signature formats used in the environment of the trustworthy long-term storage can be 

influenced, these formats should be used. Principally, though, depending on the application-specific 

requirements, the use of other signature formats (see [HK 06b]) can be necessary and sensible. 

5.1.1 PKCS#7 / CMS / CAdES 

The Cryptographic Message Syntax (CMS) signature format going back to [PKCS#7] pursuant to 

[RFC5652] is the most commonly used ASN.1 based signature format in practice. Because the data to 

be signed in this signature format are treated merely as binary objects – without consideration for an 

internal structure – any data can be signed, but the signatures cannot be embedded into the payload 

without further ado. 

Building on the basic CMS structure, specific expansions are defined in [ETSI 101733] and 

[RFC5126] that take the special requirements for advanced electronic signatures pursuant to § 3 no. 2 

[SigG] into account. For example, there are attributes for counter signatures, (CounterSignature), 

the insertion of attribute certificates (SignatureAttributes), time stamps (ContentTimeStamp, 

SignatureTimeStampToken, ESCTimeStampToken, TimestampedCertsCRLs and 

ArchiveTimeStampToken), certificates (CertificateValues), and revocation information 

(RevocationValues). The Guideline at hand has the following recommendations for the treatment 

of CMS and CAdES based signatures: 

CMS based signatures should be verified before the generation of the initial archive time stamp. In 

doing so, a CMS signature should be supplemented by a so-called CAdES-X Long (CadES-X-L) 

signature pursuant to [RFC5126, section 4.4.3.1] so that the renewed signature verification with any 

CAdES conformant signature application component is possible. In the case of such signatures, not 

only unique references to the certificates and revocation information used during the signature 

verification are inserted as with the CAdES-C signatures, but rather the actual values of the certificates 

(CertificateValues) and revocation information (RevocationValues) are inserted as 

unsigned attributes into the CMS container so that all of the information needed for a complete 

verification of the signature is contained in the signature itself. 



5.1.2 XML Signatures / XAdES 


In addition to the CMS based signatures described above, XML based signatures pursuant to 

[XMLDSIG] are also increasingly being used in practice. The advantage of this signature format is 

that the specific characteristics of XML based data are taken into account and, thus, for example, one 

can also sign explicitly defined parts of a document and the signatures themselves can be embedded 

into the payload data. Here, too, there are specific expansions for advanced electronic signatures 

pursuant to § 2 no. 2 [SigG] that are defined in [ETSI 101903] and [XAdES]. 

For example, planned here are properties for counter signatures (CounterSignature), the insertion 

of attribute certificates (SignerRole), time stamps (AllDataObjectsTimeStamp, 

IndividualDataobjectsTimeStamp, SignatureTimeStamp, SigAndRefsTimeStamp, 

RefsOnlyTimeStamp, and ArchiveTimeStamp), certificates (CertificateValues), and 

revocation information (RevocationValues). 

The Guidelines at hand have the following recommendations for the treatment of XML and XAdES 

based signatures: 

XML based signatures should be verified before the generation of the initial archive time stamp. 

In doing so, a XML signature should be supplemented by a so-called XAdES-X Long signature 

pursuant to [ETSI 101903, Annex B.2] so that the renewed signature verification with any XAdES 

conformant signature application component is possible. Similar to the CAdES-X Long Signature 

recommended above, here the certificates (CertificateValues) and revocation information 

(RevocationValues) needed for the signature verification are inserted into the XML signature as 

unsigned properties (UnsignedSignatureProperties). 

5.2 Certificate formats 

Of particular importance for trustworthy long-term storage among the various standardised certificate 

formats are the public key and attribute certificates pursuant to [X.509] (see [HK 09]). 

In the field of trustworthy long-term storage, certificates are used in particular for the verification of 

(qualified) electronic signatures. In doing so, the recommendations in [Common-PKI] (part 5 and 9) 

should be taken into account and corresponding verifications of the certificate status should be carried 

out (see Section 5.3). 

The certificate chain up to a trustworthy root entity that is constructed in doing so should be inserted 

into the unsigned CertificateValues attribute (see Section 5.1.1 with regard to this) for CMS 

signatures and, in the case of XML signatures, into the unsigned CertificateValues 

characteristic (in UnsignedSignatureProperties, see Section 5.1.2) 64 . 

Insofar as no analogous opportunities for the depositing of certificates are stipulated for alternative 

signature formats, certificates themselves should be inserted in a CredentialObject into the 

Archival Information Package (see Sections 3.3, 3.6.7.4 and 3.6.8.3). 

64 Corresponding to the data type OtherCertificates in Chapter 3.5. 



5.3 Certificate Validation Formats 


Insofar as the validity of the certificates is not ensured in another way in the certificate path built 

during the signature verification, there shall be an explicit verification of the validity of the 

certificates. 

For this, the Online Certificate Status Protocol (OCSP) pursuant [RFC2560] should be used. 

Alternatively, the Server Based Certificate Validation Protocol (SCVP) pursuant to [RFC5055] can be 

used insofar as they are based on OCSP information from the certificate issuer. 

Insofar as one can influence the mechanisms available for verifying the certificate status for the used 

certificates in the field of the trustworthy long-term storage, no revocation pursuant to [RFC5280] 

should be used because this cannot determine the validity of a (qualified) electronic signature in 

general beyond a doubt. 

5.3.1 Online Certificate Status Protocol (OCSP / RFC 2560) 

In the case of the Online Certificate Status Protocol (OCSP) pursuant to [RFC2560], current 

information about the certificate status is requested directly through a challenge-response protocol, as 

a rule directly from the issuer of the certificate. Because the disclosure from the issuer occurs 

practically at the time of the signature verification, it can be ensured that the revocation information is 

up-to-date, unlike the case when, for example, certificate revocation lists are used. In environments 

with a high number of OCSP transactions, the recommendations pursuant to [RFC5019] can be 

observed. 

Insofar as the certificates are assigned to a certain CMS or XML based signature for which there is 

OCSP based status information at hand, the revocation information should be stored in the 

RevocationValues element (see Section 5.1.1-5.1.2) in the signature. Otherwise, OCSP answers 

can be stored in their own CredentialObject. 

5.3.2 Server-Based Certificate Validation Protocol (SCVP / RFC 5055) 

With a server-based certificate validation protocol (SCVP) pursuant to [RFC5055] the tasks necessary 

in the scope of the validation of a certificate, which can be very complex under certain circumstances, 

can be outsourced to a specialised service. This is sensible when, for example, a complex signature 

validation of a component with low computing power (e.g. a mobile terminal) must be carried out. For 

these purposes, the SCVP client sends a request to the SCVP server in which, for example, the 

certificate to be verified is submitted or otherwise specified. After that, the SCVP server constructs and 

verifies the complete certificate path; in doing so it is supported by the primary revocation information 

in the form of OCSP responses or revocation lists, which are typically provided by the issuer of the 

certificate. 

When the SCVP server is requested, it should be made clear in the wantBack element (in the query 

element of the CVRequest) by means of the PID id-swb-pkc-revocation-info that the 

corresponding revocation information should be returned. The revocation information returned in the 

CVResponse (in the 

replyObjects/replyWantBacks/revInfoWantBack/RevocationInfos) should be extracted 

and saved as an unsigned element in the CMS or XML based signature (see Sections 5.1.1-5.1.2) or 




with other signature formats as a separate CredentialObject (see Section 3.6.8.5) so that a 

renewed signature verification with any CAdES or XAdES conformant signature application 

component is possible. 

Additionally, in the case of a CMS or XML based signature, the complete CVResponse can be 

deposited in RevocationValues or as a CredentialObject. 

5.4 Time Stamp 

The Time Stamp Protocol (TSP) pursuant to [RFC3161] should be used in particular 65 for the request 

of (qualified) time stamps. 

In order to make it easy to verify the time stamp later, the verification of the time stamp should occur 

automatically after the generation of the time stamp and the end of the so-called “grace period” (see 

[ETSI 101733] Section 4.4.2). In doing so, as explained in Section 5.1.1, the certificates used for 

verification in the unsigned CertificateValues attribute and the revocation information in the 

unsigned RevocationValues attribute should be stored. 

5.5 Evidence Record) 

Pursuant to the Evidence Record Syntax (ERS) Standard of the IETF [RFC4998], an evidence record 

is a unit of data with which the existence of saved data and documents at a defined point in time can 

be technically proven. It includes cryptographic evidence records with which the integrity and 

authenticity of electronically saved data and documents can be verified at any time. The ERS standard 

is technically based on the approach that cryptographic checksums (hash values) of the archival 

information packages (XAIP documents) are organized in a hash tree (pursuant to Merkle [MER 

1980]) when stored in the archive system as cryptographically unique representatives of the data to be 

preserved, and the roots of the hash tree are secured ("sealed") with a qualified time stamp containing 

a qualified electronic signature for proving the integrity (also see Annex TR-ESOR-M.3). This first 

time stamp is also designated as the Initial Archive Time Stamp pursuant to the ERS standard 

[RFC4998]. 

The source of trust for the archival time stamp and thus for legally compliant re-signing pursuant to 

§17 SigV is the qualified time stamp that contains a qualified electronic signature. Its data structure 

should fulfil the requirements of the “Time Stamp Protocol (TSP)” [RFC3161] and the “Cryptographic 

Message Syntax (CMS)” [RFC5652]. 

In the case of that a signature or time-stamp renewal is necessary that is sufficient insofar as only the 

used digital signature procedure is threatened to lose its suitability as a security message but the hash 

algorithm used remains suitable, the new archive time stamp includes the hash value of the original 

time stamp in a hash tree that is to be reconstructed with a new qualified time stamp as the conclusion 

so that a secure and verifiable, chronological chain of evidence made of cryptographically linked 

archive time stamps arises. The hereby arising evidence record contains an additional 

65 Furthermore, in environments with a high number of necessary individual time stamps, the use of the Archive 

Time Stamp (ArchiveTimeStamp) that is based on hash trees and standardised in [RFC4998] or the 

construction of so-called "interval-qualified time stamps" explained in [HK 09] is recommended. 




ArchiveTimeStamp element in an ArchiveTimestampChain element pursuant to [RFC4998] that 

already existed beforehand. 

Insofar as the security suitability of the used hash algorithm is (also) threatened, the hash tree shall be 

renewed. In doing so, the Archival Information Package is hashed with a suitable algorithm and a new 

ArchiveTimestampChain element with a corresponding ArchiveTimeStamp element is inserted 

into the ArchiveTimeStampSequence. Additional information can also be found in [RFC4998]. 

The technical proof of the the maintenance of the integrity and, if necessary, the authenticity of the 

archival information packages stored in the electronic long-term storage then occurs along with the 

presentation of the actual archival data and the associated, valid certificates, existing electronic 

signatures, and in particular the proof of the integrity of the cryptographic representatives of the 

Archival Information Package, i.e. the hash values and the archive time stamp. 

The ERS standard specifies a so-called Evidence Record for these purposes. This Evidence Record 

contains, in particular, a sequence of Archive Time Stamps with which the integrity and authenticity of 

the Archival Information Package can be proven. An Archive Time Stamp, in turn, contains all of the 

necessary data from the hash tree (reducedHashTree) needed for verifying that the Archival 

Information Package belongs to the hash tree. The root of the hash tree is furnished with a qualified 

time stamp (also see Annex TR-ESOR-M.3). 

EvidenceRecord ::= SEQUENCE { 

version INTEGER { v1(1) }, 

digestAlgorithms SEQUENCE OF AlgorithmIdentifier, 

cryptoInfos [0] CryptoInfos OPTIONAL, 

encryptionInfo [1] EncryptionInfo OPTIONAL, 

archiveTimeStampSequence ArchiveTimeStampSequence 

} 

CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute 

The version field (e.g. v1) describes the current version of the ERS standard. 

The digestAlgorithms field contains a list of all hash algorithms with which hash values were 

created for the saved data during the retention period. 

The optional cryptoInfos field makes it possible to transport data that were needed for the 

validation of the information contained in the archiveTimeStampSequence field. 

The encryptionInfo field, which is also optional, includes necessary information on the correct 

handling of encrypted contents. 

The archiveTimeStampSequence field contains a sequence of linked archive time stamps that 

were generated for the stored data over the course of the retention period. 

ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain 

ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp 

The ArchiveTimeStampChain and ArchiveTimeStampSequence are chronologically 

ordered based on the time of the final time stamp. All reduced hash trees have the exact same hash 

algorithm as their basis within an Archive Time Stamp Chain. 

Pursuant to the ERS standard of the IETF, an Archive Time Stamp is defined as follows: 



ArchiveTimeStamp ::= SEQUENCE { 

digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, 

attributes [1] Attributes OPTIONAL, 

reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, 

timeStamp ContentInfo -- TimeStampToken nach [RFC3161] 

} 

TimeStampToken ::= ContentInfo 

-- [RFC3161] 

-- contentType is id-signedData ([RFC3852]) 

-- content is SignedData ([RFC3852]) 


The digestAlgorithm field identifies the used hash algorithm. If the field is not present, the ERS 

standard assumes that the hash algorithm of the time stamp was used for the hash value generation. 

The optional attributes field can contain additional information on the rules applied for resigning 

or the application of the archive time stamp. 

The reducedHashtree field contains all hash values that are needed for the mathematical 

verification of the hash value nodes into which the original hash value of the Archival Information 

Package including the final qualified time stamp. 

The timeStamp field contains a qualified time stamp that was generated using a qualified electronic 

signature as cryptographic confirmation of the integrity of the data returned with the evidence record. 



6. Definition of a reliable transaction rrotocol 


The definition of a reliable transaction protocol in this chapter does not elaborate so much on the data 

submitted with this protocol, but rather on the technically necessary characteristics of such a protocol. 

The data to be submitted arise automatically from the interface specifications in the annexes TR- 

ESOR-S and TR-ESOR-E and therefore are not discussed here in more detail. This also includes the 

operations that can be executed on the archive, because the corresponding “function requests” are 

interpreted as parts of the data to be submitted. 

6.1 Derived Requirements 

[RFC4810] specifies the requirements of a long-term archive in a very general manner. The following 

points can be picked up here for the transaction protocol: 

• The archive shall accept all data formats for archiving. Thus, the protocol must be able to 

handle all kinds of data. 

• Cryptographic additions like signature or time stamps on the documents to be archived can 

(but do not have to) exist. Thus, the protocol must be able to handle these additions and the 

not lose the assignment of the document to the addition. 

• Meta data on the documents to be archived can (but do not have to) exist. Thus, the protocol 

must be able to handle these additions and the not lose the assignment of the document to the 

addition. 

• The data integrity shall also be protected during transmission. 

• The confidentiality shall also be protected during transmission. 

• It shall be possible to authenticate requests as well as answers. 

• The protocol shall work efficiently and reliably for large numbers of information packages. 

In addition to these very general requirements, the necessity for supporting asynchronous 

communication musters could exist. In this case, the following aspects are to be considered: 

(1): The client needs a technical confirmation that his submitted request has arrived at the other entity 

at all. 

• (2) The actual answer can be submitted much later from the server to the client. 

• The confirmation (1) can be omitted if the actual answer (2) is available immediately after the 

request. 

• A client can make a request several times if the confirmation (1) or the actual answer (2) has 

not arrived after a certain period of time. Thus follows: Each transaction needs a unique ID, 

■ So that the client can mark the request as a repetition of a request that has already 

been made, 

■ So that the archive system can recognise a request that has been made multiple times 

and not execute it multiple times, 

■ Because answers to multiple requests can arrive at the client in any sequence and the 

client must be able to assign the archive transactions to the correponding transactions 

in the transaction application. 




• The client should be able to request the status of operations that have been requested and not 

answered yet. Thus follows: 

■ The unique transaction ID, 

■ All possible conditions of all possible transactions are defined. 

• The protocol knows several parties, at least Client and Server. More parties are also possible, 

e.g. relay or proxy. 

6.2 Recommendations for the implementation 

Based on the requirements listed above, this section makes recommendations for the manner in which 

these requirements should be implemented concretely for the S.4 XML Adapter - ArchiSafe Module 

interface. The same procedure can be used for all other interfaces. 

(A3.6-2) In order to be able to process any data format and to be able to link the cryptographic data 

and meta data with the payload data, the XAIP container defined in Chatper 3 or a derivative thereof 

should be used as the central data element in the protocol. 

This means that, especially for the protocol, all data must be kept in a single data element and in this 

manner be logically connected to each other. The protocol is not responsible for the logical correctness 

of this data element after receipt. 

(A3.6-3) To protect the integrity and the confidentiality during the transmission and to authenticate 

the requests and answers, a TLS tunnel 66 should be constructed with certificate-based authentication on 

both sides before any communication between the XML module and the ArchiSafe module. Neither 

requests nor answers shall be sent through insecure channels. Both the client and the server should 

ensure this. 

(A3.6-4) The TLS tunnel shall ensure the integrity and confidentiality of the data transmitted in it 

with sufficiently strong cryptographic procedures pursuant to [TR 02102]. The archive system shall 

enforce this and not accept any weak procedure upon establishment of the tunnel. 

(A3.6-5) The TLS tunnel shall be maintained for the duration of a transaction at a minimum. 

Requests and answers to a transaction shall be transmitted through the same TLS tunnel. 

(A3.6-6) If a tunnel is disrupted during a transaction for any reason, the client shall not expect any 

answer of any kind from the archive system. In this case, the client shall create a new TLS tunnel and 

report the current status or the end of the transaction to the server by means of a status requests. 

(A3.6-7) The TLS tunnel should be maintained as long as desired and used for any number of 

transactions (also parallel). 

(A3.6-8) A TLS tunnel can be used for just one transaction and can then be terminated. Howover, 

this is only advisable if this client and the archive system only rarely communicate. 

(A3.6-9) A connection oriented protocol (e.g. TCP) shall be chosen as the transmission protocol 

within the TLS tunnel. The technical confirmation of the receipt of a client request, among other 

things, is realised by means of this protocol. 

66 The secure connection can indeed be realised with means other than with a TLS tunnel. For reasons of 

simplification, though, merely the “TLS tunnel” or “tunnel” will be referred to in the following. 




(A3.6-10) Building on the TCP protocol, a protocol shall be realised on the application level that 

maps the client requests and the final archive system answers. 

(A3.6-11) The protocol on the application level shall be a protocol without connections in order to 

map the asynchronous character. 

(A3.6-12) The protocol on the application level must be routing capable in order to take aspects like 

relays, load distribution, sessions handling, etc. into account. 

(A3.6-13) Recommendation for the protocol on the application level is SOAP document literal 

encoding67 . The external interfaces of all archive system components will be published as WSDLspecification, 

which can be based on an external XML schema. 

(A3.6-14) The lifecycle model introduced in the previous section shall be completely supported by 

the protocol and both communication partners. It shall continue to be taken into account that the 

archive module can process several (many) transactions - also arising from multiple client applications 

- simultaneously. The condition model within the archive-module shall take this into account. 

(A3.6-15) The client shall have all data on a transaction available until the transaction has been 

completely concluded68 . 

Additional information about the reliable execution of an asynchronous protocol can be found, for 

example, in [LTAP] or in [OASIS-Async]. 

67 Literal Encoding uses an XML schema for validating the SOAP data and offers significantly better 

performance than RPC Encoding, in particular in the case of large payload data (also see [FC 07] p. 76 et. 

seq. or http://www-128.ibm.com/developerworks/webservices/library/ws-soapenc). 

68 e.g. the Client should not “forget” the XAIP after it was transmitted for the first time, because the client 

cannot assume that the XAIP was transmitted correctly. 



7. Annex - XML Schema Definition 


 

 

 

 

 

 

 

 

 

 

 

 




 

 

 

 

 

XML basiertes Archivdatenobjekt (XML formatted 

Archival 

Information Package) 

 

 

 

 

 

 

XML basiertes Archiv Information Paket 

(Typdefinition) 

 

 

 

 

 

 

enthält Informationen über die 

logische(n) 

Struktur(en) des Archivdatenobjektes 

 

 

 

 

 

 

enthält Metainformationen zur 

Beschreibung des 

Geschäfts- und Archivierungskontextes 

der 

Inhaltsdaten 

 

 



minOccurs="0"> 


 

 

 

 

 

 

Typdefinition für Inhaltsdaten 

 

 

 

 

 

 

Typdefinition für ContentInfo 

 

 

 

 



/> 


 

 

 

 

 

 

Typdefinition für einen Zeiger auf Daten 

 

 

 

 

 

 

 

 

 

Typdefinition für generischen Object Identifier 

 

 

 



 

 

 

Typdefinition für einen beliebigen Bezeichner 

 

 

 

 

 

 

 

 

 

 

Typinformation für Zeitangabe 

 

 

 

 

 

 

 

 

 

 

Typdefinition für TrackingInfo 

 

 

 

 

 

 

 

 

 

Typdefinition für strukturierte (XML) Daten 

 

 

 



kann. 


 

 

 

 

 

 

 

 

 

Typdefinition für eine ArchiveInfo 

 

 

 

 

 

 

 

 

 

 

Explizites ArchiveToken-Element, das in 

Schnittstellenspezifikation referenziert werden 

 

 

 

 

 

 

Typdefinition für den Package Header des XAIP 

 

 

 

 

 

 




durch das Archivsystem oder die 

erzeugtes, eindeutiges 

Identifikationsmerkmal 

 

 

 

 

 

 

Name, Version des XML Schemas 

 

 

 

 

 

 

zusätzliche Verständnisinformtionen im 

Textformat 

 

 

 

 

 

 

Inhaltsverzeichnis 

 

 

 

 

 

 

 

 

 

 

Typdefinition für eine Package Info Unit 




 

 

 

 

 

 

Klassifikationsmerkmal 

 

 

 

 

 

 

Textfeld zur Beschreibung 

 

 

 

 

 

 

Referenz auf Metadatenobjekt 

 

 

 

 

 

 

Referenz auf beweisrelevante Daten 

(kryptographische Sicherungsmittel) 

 

 

 

 

 



zu 

 

 

 


 

 

 

Typdefinition für ein Inhaltsverzeichnis (Manifest) 

einem XAIP 

 

 

 

 

 

 

 

Aufbewahrungsfristen 

 

 

 

 

 

 

Informationen über den "Absender" des 

Archivdatenobjektes 

 

 

 

 

 

 

das Inhaltsverzeichnis kann ein oder 

mehrere 

"Kapitel" oder wieder ein erneutes 

Unterverzeichnis enthalten 




 

 

 

 

 

 

 

 

 

 

 

Typdefinition für die Submissionsinformationen 

 

 

 

 

 

 

Identifikationsmerkmal für die 

aufrufende 

Geschäftsanwendung 

 

 

 

 

 

 

versendende Organisationseinheit 

 

 

 

 

 

 

Autor, resp. Absender (Ersteller) 

 

 

 




 

 

 

Versendezeitpunkt 

 

 

 

 

 

 

Informationen zur Authentifikation der 

Kommunikation 

 

 

 

 

 

 

 

 

/> 

 

 

 

Typdefinition für ein Metadatenobjekt 

 

 

 

 

 

 



 

 

 

 

 

Txpdefinition für den Metadatenabschnitt 

 

 

 

 

 

 

Metainformationen zu einem oder mehreren 

Inhaltsdatenobjekten 

 

 

 

 

 

 

 

 

 

 

 

Typdefinition für CheckSum 

 

 

 

 

 

 

 

 

 

 

Typdefinition für ein Nutzdatenobjekt 



 

 

 

 

 

 

 

 

 

 

 

 

 

Inhaltsdaten 

vor der 


 

 

 

 

 

kryptographische Prüfsumme über die 

 

 

 

 

 

 

Information über auf den Inhaltsdaten 

Speicherung ausgeführte Operationen 

(Transformationen) 

 

 

 

 

 




 

 

 

 

Typdefinition für den Nutzdatenabschnitt 

 

 

 

 

 

 

ein oder mehrere Inhaltsdatenobjekte 

 

 

 

 

 

 

 

 

Typdefinition für Transformationsinformationen 

 

 

 

 

 

 

 

 

 

Typdefinition für Transformationoperationen (objekte) 

 

 

 

 


maxOccurs="1" minOccurs="0" /> 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

 

 

 

 

Typdefinition für Algorithmenbezeichner 

 

 

 

 

 

 

 

 

 

 

Typdefinition für Standard OCSP Antwort 

 

 

 

 




 

 

 

 

 

 

 

 

Typdefinition für die Beweisdaten (Signaturen, 

Zeitstempel) 

 

 

 

 

 

 

 

 

 

 

Typdefinition für eine Beweisdatenhülle

BSI Technical Guideline 03125 Annex TR-ESOR-F Formats and ...

Create successful ePaper yourself

Delete template?

Save as template?