CHIEF ARCHIVIST OF LITHUANIA
ORDER
ON APPROVAL OF THE ELECTRONIC DOCUMENT SPECIFICATION ADOC-V2.0
29 December 2014, No. (1.3 E)VE-57
Vilnius
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
APPROVED
by Chief Archivist of Lithuania
Order 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 timestamps 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. 1V409 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 timestamps, it shall be verified against the earliest time indicated in those time-stamps. If such timestamps 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.
__________________