CHIEF ARCHIVIST OF LITHUANIA

ORDERON APPROVAL OF THE ELECTRONIC DOCUMENT SPECIFICATION ADOC-V2.0

29 December 2014, No. (1.3 E)VE-57Vilnius

In accordance with Article 5 Part 3 Item 6 of the Law on Documents and Archives of the

Republic of Lithuania,

I hereby approve the Electronic document specification ADOC-V2.0 (attached).

Chief Archivist of Lithuania Ramojus Kraujelis

APPROVEDby Chief Archivist of LithuaniaOrder No. (1.3 E)VE-57 on 29 December 2014

ELECTRONIC DOCUMENT SPECIFICATION ADOC-V2.0

CHAPTER I

GENERAL PROVISIONS

1. Electronic document specification ADOC-V2.0 (hereinafter referred to as

Specification) defines the technical characteristics of the electronic document format, as well as the

requirements for validation of electronics document and ensuring its life cycle.

2. The Specification was developed in accordance with the Description of Requirements

for the Electronic Document Specifications, approved by the Chief Archivist of Lithuania in his

Order No. VE (1.3 E)-41 of 29 August 2014 (hereinafter – the Description of Requirements for the

Electronic Document Specifications), Decision of the European Commission 2011/130/ES of 25

February 2011, establishing minimum requirements for the cross-border processing of documents

signed electronically by competent authorities under Directive 2006⁄123⁄EC of the European

Parliament and the Council on services in the internal market, other standards and recommendations

referred to in Appendix 18 of the Specification.

3. The Specification defines the requirements for the structure (model, package, content,

metadata, XAdES signatures) and validation of the electronic document.

4. Definitions used in the Specification:

4.1. ASiC – LST ETSI TS 102 918 v1.3.1:2013 standard (Appendix 18 Item 8 of the

Specification), specifying the use of ZIP format container structures to associate electronic

signatures or time-stamp tokens with one or more signed objects to which they apply (hereinafter –

ASiC standard).

4.2. ASiC Baseline Profile – profile of the ASiC container format defined in the LST

ETSI TS 103 174 v2.2.1:2013 standard (Appendix 18 Item 10 of the Specification).

4.3. ASiC-E – extended container type defined in Article 6 of the ASiC standard.

4.4. ASiC-S – simple container type defined in Article 5 of the ASiC standard.

4.5. IRI – Internationalized Resource Identifier, used as a reference (address) for the

resource access, and composition of which is in conformity with the RFC 3987 (Appendix 18 Item

22 of the Specification).

4.6. Directory – a service file for storing information on other files and⁄or directories.

4.7. MIME type label – a sequence of text characters (e.g., text/xml) used to identify

the media type of associated file or data, in conformity with the requirements of the RFC 4288

(Appendix Error: Reference source not found Item 23 of the Specification).

4.8. CRL – a list of certificates, the validity of which has been terminated or suspended,

in conformity with the RFC 5280 recommendations (Appendix 18 Item 24 of the Specification).

4.9. OCSP service – service for certificate validity check, in conformity with the RFC

6960 recommendations (Appendix 18 Item 19 of the Specification).

4.10. Signature validation data – electronic data collected in accordance with the

existing legislation (sertificates, responses to the OCSP service requests, CRL lists), used for the

verification of the certificate authenticating the electronic signature. The data characterised in this

definition do not include time-stamps.

4.11. Secure signature creation system – the overall system of software and hardware

comprised of the signature creation device, conforming with the Requirements for the Electronic

Signature Devices (Chapter III), approved by the Resolution of the Government of the Republic of

Lithuania No. 2108 of 31 December 2002, and the electronic signature creation application

conforming with the LST CWA 14170:2005 standard (Appendix 18 Item 3 of the Specification) or

equivalent requirements for secure signature creation applications.

4.12. Grace period – time period which permits the certificate revocation information

to propagate through the revocation process to relying parties; it is the minimum time period an

initial verifier has to wait to allow signer or any authorized entity to request a certificate revocation,

and the relevant certification service provider, that issues qualified certificates, to process the

request and publish revocation status (Appendix 18 Item 4 of the Specification).

4.13. URI – Uniform Resource Identifier, the structure of which is in conformity with

the RFC 3986 recommendations (Appendix 18 Item 21 of the specification), used as a reference

(address) to access resources.

4.14. Public Key Infrastructure – a set of the organisational and technical measures,

allowing the certification service providers to uniquely asign public keys of asymmetric

cryptography to the individuals or entities of the electronic environment so that they can be identified

in the electronic environment.

4.15. XAdES – the XML format-based electronic signature standard LST ETSI TS 101

903 V1.4.2:2011 (Appendix 18 Item 7 of the Specification) (hereinafter referred to as XAdES

standard).

4.16. XAdES-A – an archival form of the XAdES signature created in conformity with

the XAdES standard.

4.17. XAdES Baseline Profile – XAdES signature profile defined in the LST ETSI TS

103 171 V2.1.1:2014 standard (Appendix 18 Item 9 of the Specification).

4.18. XAdES-BES – a basic XAdES signature created in conformity with the XAdES

standard.

4.19. XAdES-C – XAdES signature form with complete validation data references,

created in conformity with the XAdES standard.

4.20. XAdES-EPES – an explicit policy based XAdES electronic signature created in

conformity with the XAdES standard.

4.21. XAdES signature – an electronic signature or data, which secure the integrity and

authenticity of associated electronic data, created using XML syntax in conformity with the XAdES

standard.

4.22. XAdES-T – a XAdES signature with a time-stamp token, created in conformity

with the XAdES standard.

4.23. XAdES-X – an extended XAdES signature with verification references and a

time-stamp token created in conformity with the XAdES standard.

4.24. XAdES-X-L – an extended long-term XAdES signature created in conformity

with the XAdES standard.

4.25. XML – the descriptive eXtensible Markup Language for generic data structures

and their content encoding and processing, recommended by the World Wide Web Consortium,

W3C.

Other definitions used in the Specification are to be interpreted in the way they have

been defined in the Law on Documents and Archives of the Republic of Lithuania, in the Law on

Electronic Signature of the Republic of Lithuania, in the requirements for the electronic signature

devices, approved by the Resolution of the Government of the Republic of Lithuania No. 2108 of

31 December 2002 on the “Approval of the Requirements for Certification Service Providers

Issuing Qualified Certificates, Requirements for the Electronic Signature Devices, Registration

Order of the Certification Service Providers Issuing Qualified Certificates and Regulations of the

Electronic Signature Monitoring”, also in the Specification Procedure for the Time-stamping

Service Provision, approved by the Order of the Director of the Communications Regulatory

Authority No. 1V-407 of 19 April 2011 on the “Approval of the Specification Procedure for the

Provision of Time-stamping Services”, in the Specification of the Requirements for the Electronic

Signature Verification Procedure, approved by the Order of the Director of the Communications

Regulatory Authority No. 1V-409 of 19 April 2011 on the “Approval of the Description of the

Requirements for the Electronic Signature Verification Procedure”, and in the legal acts issued by

the Chief Archivist of Lithuania, stipulating general requirements for creation, management,

accounting, and preservation of electronic documents.

CHAPTER II

MODEL AND PACKAGE OF THE ELECTRONIC DOCUMENT

5. The package of the electronic document is a ZIP format archive in conformity with

the ASiC standard, ASiC Baseline Profile and the requirements of the Specification (Appendix

Error: Reference source not found of the Specification):

5.1. The package shall be in conformity with the requirements defined for the ASiC-E

extended container type.

5.2. The package contains one or several files grouped into directories, which may

contain subdirectories with other files and directories.

5.3. The package shall contain the files storing document content, metadata, XAdES

signatures and the package description (mimetype, META-INF/manifest.xml,

META-INF2/relations.xml, Thumbnails/thumbnail.png).

5.4. The package shall not be secured by passwords.

6. The files stored in the package are:

6.1. compressed using the DEFLATE compression algorithm;

6.2. uncompressed (STORED).

7. ZIP format (Appendix Error: Reference source not found Item 18 of the

Specification) applies the following limits to the electronic document:

7.1. the size of the electronic document package file shall not exceed 4 GB;

7.2. the uncompressed size of each file constituting the content of the electronic

document shall not exceed 4 GB;

7.3. the character length of each file pathname shall not exceed 65,535 symbols;

7.4. the total number of files and directories within the electronic document package

shall not exceed 65,535.

Model of the electronic document

8. The structures of the electronic document are as follows:

8.1. the logical structure of the document, describing separate parts (components) of the

electronic document;

8.2. the physical structure of the document, describing how the parts of the electronic

document are represented in files and directories.

9. The logical structure of the electronic document is comprised of the following parts

(Appendix Error: Reference source not found of the Specification):

9.1. single main document;

9.2. unmodifiable and modifiable metadata;

9.3. at least one electronic signature;

9.4. description of the types of the parts;

9.5. description of relationships among the parts.

10. The electronic document may also contain the following parts:

10.1. one or more appendices of the document;

10.2. one or more attached independent electronic documents.

11. The parts of the logical structure of electronic document in physical structure are

represented as files grouped into directories. As the package is not a constituent part of the electronic

document, the physical structure of the electronic document may be stored outside the package (for

example, in a computer directory structure, in database table records, etc.).

Structure of the package

12. The Specification defines the physical structure of the electronic document stored in

the package (Appendix Error: Reference source not found of the Specification).

13. The description of document parts and relationships of these parts in the physical

structure are represented by XML files with the fixed pathnames META-INF/manifest.xml

(containing the description of files and their content types) and META-INF2/relations.xml

(containing the description of relationships).

14. The physical structure for other parts of the electronic document is defined by the

author of the electronic document in conformity with the requirements of the Specification. When

describing the physical structure of the electronic document, the relationships of physical and

logical structures shall be specified (Appendix 4 of the Specification).

15. The extension of the package file shall be either “adoc”, “asice” or “sce” (in

lowercase letters).

16. Text file named mimetype shall be present in the package, containing the MIME

type label of the ASiC-E container “application/vnd.etsi.asic-e+zip” (without enclosed quotes).

This file shall be included into the package in accordance with requirements defined in Appendix A

Part 1 of the ASiC standard.

17. The META-INF directory shall be present in the root of the package containing the

following files and directories:

17.1. the manifest file manifest.xml, containing the list of all files within the package

and their MIME media types;

17.2. XAdES signature files containing XAdES signatures and which may be grouped

into META-INF sub-directories. The file name of the XAdES signature files shall contain the word

“signatures”.

18. In the root of the package the META-INF2 directory shall be present containing the

relations.xml file with the description of the relationships between the separate parts of the

electronic document and the files forming those parts.

19. Only one content file should be present in the root of the package – the file of the

main document.

20. There may be other directories in the root of the package with arbitrary names that

shall not match the names of META-INF and META-INF2 directories. They may contain other

subdirectories or files of appendices of the electronic document and/or attached electronic

documents.

21. In the root of the package the metadata directory shall be present, containing the

electronic document metadata files.

22. In the root of the package the Thumbnails directory may be present, containing the

thumbnail file with the the electronic document preview image, in conformity with the ODF

specification requirements (Appendix 18 Item 17 of the Specification).

Manifest file

23. The manifest file is an unsignable XML file that lists all the files and directories of

the electronic document and their MIME type labels. The package of the electronic document shall

contain only one manifest file with the fixed pathname META-INF/manifest.xml.

24. The structure of the manifest file shall be in conformity with the requirements

defined in Part 3 Chapter 4 of the ODF specification (Appendix 18 Item 17 of the Specification).

The requirements in Part 3 Sub-chapters 4.4–4.7 of the ODF specification are not applicable, as the

content of the electronic document shall not be encrypted according to this Specification.

25. The manifest file shall be in conformity with the “Open Document Manifest”

schema defined in Appendix A1 Part 3 of the ODF specification (Appendix 18 Item 17 of the

Specification). The manifest file XML content shall be UTF-8 encoded.

26. References to files and directories shall be indicated by the relative IRI references

(in conformity with the syntax of irelative-ref rule option from ipath-noscheme rule, as defined in

the RFC 3987 – Appendix 18 Item 22 of the Specification), where the root directory of the package

shall be specified as the reference point (base IRI). The presence of absolute IRI references, as well

as references or their fragments denoting files or directories outside the package, shall not be

permitted. The package is indicated by “/”character which shall not be the first character in other

references.

27. The manifest file shall specify MIME type labels for files and directories listed in

Appendix 9 of the Specification.

Relationship between the parts of the electronic document

28. Parts of the electronic document (files) are related with each other: the file of the

main document may have appendices or attached electronic documents as separate files; the

electronic document content files and metadata may be signed by XAdES signatures.

29. The type of the relationship of the electronic document package determine the way

one part of the electronic document relates to another part of the electronic document. These

relationships may also perform a function of references defining the type of the electronic document

parts (in terms of relationships of the physical and logical structures). Parts of the electronic

document, that have no direct cross-references, may be logically co-related to each other by means

of relationships as well.

30. The relationships describe how the parts of the logical structure of electronic

document maps to the physical structure of the electronic document package, and enable the

compatibility of the electronic documents, when they are transferred from one system to another.

Therefore, there are no requirements on forcing the use of some predefined set of fixed names for

files or directories for different parts of the electronic document.

Relationships file

31. The relationships file is an unsignable XML file describing the relationships

between the parts of the package of the electronic document and the files that make up these parts.

The package of the electronic document shall contain only one relationships file.

32. The path name of relationships file is META-INF/relations.xml.

33. The relationships file shall conform to XML schema, defined in Appendix 17

Chapter II of the Specification. UTF-8 character encoding shall be used for the XML content of

relationships file.

34. The <Relationships> element is the root element of the relationships file, containing

<SourcePart> elements that describe different relationships between the package or files in the

package with other files in the package (Appendix Error: Reference source not found of the

Specification).

35. The relationships file of the electronic document shall contain:

35.1 One element <SourcePart> describing the relationships of the package structure;

35.2 At least one element <SourcePart> describing the relationships between the files

of the electronic document;

36. The value “/” of the element <SourcePart> attribute full-path (full-path=“/“)

identifies the package. Different values of the attribute full-path indicate the IRI references to files

of the electronic document. The IRI reference in the element’s attribute full-path shall

unambiguously indicate the package itself or the file in the package.

37. References shall be indicated in accordance with the requirements of Item 26 of the

Specification.

38. The <Relationship> element describes the type of the relationship between the

package or the file, specified in the element <SourcePart>, and another file of the document.

Element’s attribute full-path specifies the IRI reference to the related file of the electronic

document, whereas the attribute type indicates the type of the relationship. Optional element’s

attribute id is the identifier of the relationship.

39. The set of relationship types are defined in Appendix Error: Reference source not

found of the Specification. The author of the document may define its own additional set of

relationship types to relate the parts of the electronic document or the files constituting these parts

that are required for the operation of the author’s informational system. Upon detection of the

relationship type that is unknown for the software application, it shall behave in the same way as

upon detection of unknown type of the logical relationship between the parts of the document; for

example, display the relationship indicating that the type of the relationship is unknown.

40. Each file in electronic document may participate in several relationships of different

type, each specified by a separate <SourcePart> element. Using the relationship types, defined in

Specification, relationships shall not form cycles unless custom defined relationship types are used.

41. When the relationship should be specified with some part of XML file (e.g., if only

several metadata elements in the XML file are secured by XAdES signature), <Element> elements

shall be used to list the related XML elements of that file. Only elements containing unique

identifier may participate in the relationship. The <Element> element’s in-source-part attribute

indicate which file in relationship contains the referenced XML element (either referred by the

<SourcePart> element or referred by the <Relationship> element), and the ref-id attribute shall

specify the identifier of referenced XML element.

42. Valid values of the element <Element> attribute in-source-part are:

42.1. true – the referenced XML element is present in the file indicated by the attribute

full-path of the element <SourcePart>;

42.2. false – the referenced XML element is present in the file indicated by the attribute

full-path of the element <Relationship>.

43. The physical structure of electronic document is defined in the relationships file by

specifying relationships between the physical and logical structures of electronic document

(Appendix Error: Reference source not found of the Specification) meeting the following

requirements:

43.1. the relationships file shall contain one element <SourcePart> identifying the

package itself;

43.2. files of the main document, modifiable and unmodifiable metadata files and

XAdES signature files shall be related to the package;

43.3. the image file (if present) shall be related to the package;

43.4. files of document appendices shall be related to the file of the main document or

the file of another appendix.

43.5. files of the attached e-documents shall be related to the file of the main document;

44. URI references to the signed parts of electronic document are stored in XAdES

signature files. In order to efficiently (without the help of software) determine whether the package

contains a specific file and which XAdES signature has secured it, the relationships file shall

contain the description of all files, that are secured by XAdES signatures, by specifying their

relationship with the files of those XAdES signatures. When XAdES signature has secured several

logically related metadata groups (Item 64 of Specification), single element defining the

relationship with that XAdES signature shall be used to list those secured metadata groups by

indicating the identifiers of XML elements denoting those groups.

CHAPTER III

CONTENT OF THE ELECTRONIC DOCUMENT

45. The content of the electronic document consist of the following parts:

45.1. main document – the mandatory part of the electronic document containing the

main information of the electronic document, or covering information on the attached electronic

documents;

45.2. appendices of the document (optional) – part of the electronic document

containing the information supplementing the main document;

45.3. attached electronic documents (optional) – independent electronic documents that

are attached to the main document as the information supplementing or explaining its content.

46. The main document part of electronic document content shall be stored in a single

file.

47. The content of electronic document may consist of one or more appendices stored in

separate files. Files of the main document and its appendices may contain one or more logical

appendices, but the body of the main document or any appendix shall not be split into several files

(Appendix Error: Reference source not found of the Specification). Appendices may have other

appendices stored in separate files.

48. The content of the electronic document may contain one or more files of the

attached e-documents, one attached document per file. The content of the attached electronic

document may comprise other attached documents.

49. The total number of the parts comprising the content of the electronic document

shall not exceed the limits indicated in Item 7 of the Specification.

50. The file of the main document part of the electronic document shall be stored in the

root directory of the package. The files of document appendices and attached electronic documents

may be stored in one or more directories (Appendix Error: Reference source not found of the

Specification).

51. Directories of appendices and/or attached documents may form the hierarchical

structure, where the directories may contain files of appendices or attached documents and other

directories.

52. The files of the main document and its appendices shall be signed by a qualified

electronic signature. The files of the attached electronic documents shall be secured by a XAdES

signature.

File formats for the electronic document content

53. The files of the main document and appendices parts of the electronic document

content shall be based on the set of open file formats listed in Appendix Error: Reference source not

found and shall meet the following requirements:

53.1. the file shall be in conformity with the requirements of its format specification

standard;

53.2. the file name shall contain an extension;

53.3. the file format shall be indicated using the MIME type label in the manifest file.

54. The attached electronic documents shall be in conformity with the requirements for

the formats of the attached electronic document (Appendix Error: Reference source not found of the

Specification).

CHAPTER IV

METADATA OF THE ELECTRONIC DOCUMENT

55. Metadata of the electronic document are data containing information on the format,

structure, content, usage and signing of the electronic document.

56. Specification defines these types of metadata:

56.1. unmodifiable metadata – the metadata which integrity shall be secured against

further modifications by XAdES signature;

56.2. modifiable metadata – the metadata which may be modified or they may be

optionally secured against modifications by the author’s XAdES signature. However, the values of

such secured metadata may be changed by providing additional information in metadata on the

change performed (Appendix 12 of the Specification).

57. Electronic document, depending on its life cycle, may contain metadata of the

categories indicated in Appendix Error: Reference source not found of the Specification, some of

which are unmodifiable metadata.

58. Metadata of the electronic document are stored using XML syntax in one or several

XML files.

59. All metadata of electronic document shall be stored in the metadata and XAdES

signature files (Appendix 12 of the Specification). Modifiable and unmodifiable metadata shall be

stored in separate metadata files. The electronic document shall contain at least one unmodifiable

metadata file and at least one modifiable metadata file. If electronic document during its life cycle is

supplemented with a group of both unmodifiable and modifiable metadata, they shall be stored in

separate files.

60. Files of unmodifiable and modifiable metadata are identified by the type of

relationship indicated in the relationships file (Appendix Error: Reference source not found of the

Specification).

61. The XML content of metadata files shall conform to associated XML schemas

defined in Appendix Error: Reference source not found, Chapter I of the Specification. Each

metadata file of the electronic document shall contain a reference to its relevant metadata XML

schema. The XML content of metadata files shall be UTF-8 encoded.

62. The definition of electronic document metadata, the files and XML elements for

metadata storage, the requirements for their presence and modifiability are defined in Appendix 12

of the Specification.

63. The root element in XML file of electronic document metadata shall be

<metadata>. All XML elements in this file shall be qualified with a namespace they are associated

to by their definition in metadata XML schemas (Appendix Error: Reference source not found,

Chapter 1 of the Specification).

64. The elements specifying logically related metadata groups, which can be secured

against the modifications by the XAdES signature (including the root element <metadata>;

Appendix 12 of the Specification) shall have the attribute ID containing an identifier, unique within

given metadata file.

65. The categories of metadata for describing the document and its formation, and of

document usage restrictions, if present, shall be covered by at least one qualified signature. The

unmodifiable metadata of other categories, if present, shall be covered by at least one XAdES

signature. The modifiable metadata, if present, may be covered by the XAdES signature (Appendix

11 of the Specification).

CHAPTER V

ELECTRONIC SIGNATURES

66. The electronic signatures to be applied with the purpose to sign, confirm, conciliate

or certify a copy of electronic document (Appendix 12 Note 9 of the Specification) shall be created

using secure signature creation system and valid qualified certificate conforming with the

requirements of the LST ETSI TS 101 862 V1.3.3:2007 standard (Appendix 18 Item 6 of the

Specification).

67. Electronic documents shall be signed by XAdES-EPES, XAdES-T or XAdES-A

format electronic signature, defined in the XAdES standard, which meets the requirements of B, T,

LT or LTA conformance level defined in the LST ETSI TS 103 171 V2.1.1:2014 standard

(Appendix18 Item 9 of the Specification). Since XAdES standard is universal and allows

alternatives, the Specification profiles the usage of certain XAdES signature properties.

68. A XAdES signature shall be created in conformity with the electronic signature

policy requirements. XAdES-BES format electronic signatures shall not be used.

69. XAdES-C, XAdES-X or XAdES-X-L format electronic signatures shall not be used,

as defined by the LT conformance level requirements of the XAdES Baseline Profile (8.1 Section of

the LST ETSI TS 103 171 V2.1.1:2014 standard; Appendix 18 Item 9 of the Specification). The

valid properties of XAdES electronic signature are listed in Appendix 13 of the Specification.

70. The creation of XAdES-A format electronic signature shall be based on the

XAdES-T format signature by incorporating validation data of signature and its time-stamps, as

defined by the LTA conformance level requirements of the XAdES Baseline Profile (Section 9 of

the LST ETSI TS 103 171 V2.1.1:2014 standard; Appendix18 Item 9 of the Specification).

71. All XAdES signatures shall be detached. The <ds:Reference> elements of XAdES

signature shall meet one of the following requirements:

71.1. shall reference the file within the package, other than XAdES signature file;

71.2. shall reference the XAdES signature element <xades:SignedProperties> (Section

6.3.1 of the XAdES standard).

72. A detailed description of the structure of XAdES signatures is provided in Appendix

13 of the Specification; the algorhitms for the XAdES signature creation are listed in Appendix

Error: Reference source not found of the Specification.

73. The XAdES signature file is XML, which root element is <asic:XAdESSignatures>

and conforms to the requirements defined in Section 6.2.2 Part 3a of the ASiC standard.

74. The XAdES signature file shall be valid against XML schema, defined in Appendix

17 Chapter III of the Specification. XML file content shall be UTF-8 encoded.

75. Each signature file shall contain only one XAdES signature, which shall be created

in one of the following ways:

75.1. parallel signature method is applied when every XAdES signature is independent

and is used to secure the content and metadata of the electronic document without covering other

XAdES signatures;

75.2. countersignature method is applied when XAdES signature is used to secure other

XAdES signatures as well.

76. All XAdES signatures created as countersignatures shall be stored in separate files;

the attribute Type of <ds:Reference> elements referencing other XAdES signatures shall contain

the value “http://uri.etsi.org/01903#CountersignedSignature” (XAdES Standard Section 7.2.4.1).

77. To ensure long-term validity of XAdES signatures they should be covered by the

time-stamps. The time-marks are not applicable. Time-stamp tokens shall be incorporated into

XAdES signature without explicit references to the data covered by the time-stamp; implicit

reference mechanism shall be applied instead (XAdES Standard Section 7.1.4.3).

78. Two types of time-stamps may be used in XAdES signatures:

78.1. signature time-stamp, stored in the XAdES signature element

<SignatureTimeStamp> (XAdES Standard Section 7.3), providing the evidence of existence of this

XAdES signature before the time indicated in the time-stamp;

78.2. archival time-stamp, stored in the XAdES signature element

<xadesv141:ArchiveTimeStamp> (XAdES Standard Section 8.2), providing the evidence of

existence of covered signature validation data and other time-stamps in this XAdES signature

before the time indicated in the time-stamp.

79. To validate XAdES signature after the end of the validity of the signer’s certificate

(after the certificate has expired or has been revoked), signature validation data, signature time-

stamps and archival time-stamps should be incorporated into the XAdES signature, as defined in the

XAdES standard.

80. The information on the certificate revocation shall be obtained using the OCSP

service or CRL.

81. All time-stamps shall be in conformity with the requirements of LST ETSI TS 101

861 V1.3.1:2007 standard (Appendix 18 Chapter 5 of the Specification). Time-stamp tokens shall

be obtained via HTTP or HTTPS protocol as defined in the RFC 3161 recommendations (Appendix

18 Item 20 of the Specification).

82. XML elements in modifiable and unmodifiable metadata files can be secured by the

XAdES signature. Only those XML elements can be secured, that contain the ID attribute and

specify groups of logically related metadata, which cannot be secured separately (e.g., the name and

code of the author (person or entity) of the document). Such XML elements are secured in its

entirety with all its attributes and child elements when present.

83. For each secured XML element specifying groups of logically related metadata

elements, a separate corresponding <ds:Reference> element shall be generated in securing XAdES

signature. The attribute ds:URI of the referencing element <ds:Reference> shall point to the entire

metadata file. The specific secured XML element is extracted by applying transformation and

canonicalization algorithms (element <ds:Transforms>). The resulted canonicalized XML element

shall meet the following requirements (Appendix Error: Reference source not found of the

Specification):

83.1. No element in the secured XML element subtree may be excluded during

transformations;

83.2. No attribute of any element in the secured XML element subtree (including the

secured XML element itself) may be excluded during transformations;

83.3. No new element may appear in the sub-tree of the secured XML element as a

result of transformations;

83.4. No new attribute may appear in elements of the secured XML element subtree

(including the secured XML element itself) as a result of transformations;

83.5. The ordering of XML elements in the sub-tree of the secured XML element may

not be changed as a result of transformations.

84. The whole metadata file in its entirety as a binary file may be secured by XAdES

signature. Such method of signing secures all metadata elements contained in that metadata file.

CHAPTER VI

VERIFICATION OF THE ELECTRONIC DOCUMENT

85. The process of verification of electronic document is comprised of the following

stages:

85.1. verification of the conformance of the electronic document with the Specification

requirements;

85.2. verification of the validity of XAdES signatures of the electronic document.

86. During the verification of electronic document content files, the conformance to

their corresponding content format shall be verified (Appendices 5 and 6 of the Specification).

During the electronic document verification, the validation of electronic signatures in attached

electronic documents is optional and shall not affect the verification of the electronic document, to

which those documents are attached.

87. During the electronic document verification, the conformance to the requirements,

defined in Specification for the electronic document structure, metadata and XAdES signature

format, shall be verified. If electronic document is stored within the package, its compliance to the

requirements for the package, defined in the Specification, shall be verified.

88. All XAdES signatures shall be verified in accordance to the Specification of the

Requirements for the Electronic Signature Verification Procedure, approved by the Order No. 1V-

409 of Director of the Communications Regulatory Authority of 19 April 2011, and in accordance

to the requirements defined by the XAdES standard.

89. During the verification of validity of XAdES signatures of electronic document, the

validity of all XAdES signatures shall be verified by performing the initial and the subsequent

verification, as defined in the LST CWA 14171:2005 standard (Appendix 18 Section 4 of the

Specification):

89.1. During the initial verification, the integrity and validity of XAdES signature shall

be verified. Collected signature validation data allows preparing the electronic document for long

term preservation and validity by upgrading the signature to XAdES-A format, which enables its

subsequent validation without the presence of Public Key Infrastructure. During the initial

verification, the grace period shall be considered, as defined in the LST CWA 14171:2005 standard

(Appendix 18 Item 4 of the Specification). The validation data shall be collected as specified in

Item 80 and Item 81 of the Specification.

89.2. The subsequent verification is performed using the validation information

incorporated in the XAdES signature.

90. The XAdES signature shall be authenticated with the certificate, issued by

certification authority issuing qualified certificates, or the certification service provider whom the

XAdES signature verifier trust.

91. The time-stamps in XAdES signature shall be produced by the time-stamping

authorities providing time-stamping services in accordance with the requirements defined in the

Specification Procedure for the Time-stamping Services, approved by the Order No. 1V-407 of

Director of the Communications Regulatory Authority on 19 April 2011, or the time-stamping

authority whom XAdES signature verifier trust.

92. The XAdES signature validation data shall be produced by the qualified certification

service provider or the certification service provider whom XAdES signature verifier trust. The

service provider must be authorized to provide validation information for the certificate being

verified.

93. If XAdES signature being verified is covered by the time-stamps, the validity of

certificate, used to authenticate the signature, and its chain of certificates are verified against the

earliest time indicated in those time-stamps. If such time-stamps do not exist, then the validity of

certificate used to authenticate the XAdES signature, and its chain of certificates shall be verified

against the current time.

94. If validation data of XAdES signature being verified are covered by the time-

stamps, it shall be verified against the earliest time indicated in those time-stamps. If such time-

stamps do not exist, XAdES signature validation data shall be verified against the current time.

95. If time-stamp being verified is covered by other time-stamps, the certificate, used to

authenticate that time-stamp, and its chain of certificates shall be verified against the earliest time

indicated in those covering time-stamps. If such covering time-stamps do not exist, the certificate,

used to authenticate the time-stamp, and its chain of certificates shall be verified against the current

time.

96. Signature validation data shall be considered acceptable to be used for validation of

XAdES signature or time-stamp, if they meet at least one of the following requirements:

96.1. validation data were collected during the process of verification of XAdES

signature or time-stamp;

96.2. validation data were incorporated into signature later than the earliest time-stamp

providing the evidence of existence of the covered XAdES signature before the time indicated in

that time-stamp. In the case of the time-stamp verification – later than the time-stamp being verified

was incorporated itself.

97. Each XAdES signature shall be verified irrespective of the validity of other XAdES

signatures of the electronic document.

__________________