Source: http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.html
Timestamp: 2019-04-23 22:02:45+00:00

Document:
This document is part of the OASIS Open Document Format for Office Applications (OpenDocument) Version 1.2 specification.
This document is part of the Open Document Format for Office Applications (OpenDocument) Version 1.2 specification.
It defines a package format for OpenDocument documents.
This document is part of the Open Document Format for Office Applications (OpenDocument) Version 1.2 specification. It defines a package format for OpenDocument documents.
Text with a gray background color which is contained in boxes is informative. It lists the XML element-element and element-attribute relations for cross reference purposes.
Within the normative text of this specification, the terms “shall”, “shall not”, “should”, “should not”, “may” and “need not” are to be interpreted as described in Annex H of [ISO/IEC Directives].
XML Element, attribute names, attribute value types, and attribute values appear in monospace font.
[OWL] Deborah L. McGuinness, Frank van Harmelen, OWL Web Ontology Language Overview, http://www.w3.org/TR/2004/REC-owl-features-20040210/, W3C, 2004.
[PNG] David Duce, Portable Network Graphics (PNG) Specification (Second Edition), http://www.w3.org/TR/2003/REC-PNG-20031110, W3C, 2003.
[RDF-CONCEPTS] Graham Klyne, Jeremy J. Carroll, Brian McBride, Resource Description Framework (RDF): Concepts and Abstract Syntax, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/, W3C, 2004.
[RDF-XML] Dave Beckett, Brian McBride, RDF/XML Syntax Specification (Revised), http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/, W3C, 2004.
[RFC2898] B. Kaliski, PKCS #5: Password-Based Cryptography Specification Version 2.0, http://www.ietf.org/rfc/rfc2898.txt, IETF, 2000.
[RFC3174] D. Eastlake, 3rd, P. Jones, US Secure Hash Algorithm 1 (SHA1), http://www.ietf.org/rfc/rfc3174.txt, IETF, 2001.
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt, IETF, 2005.
[RFC3987] M. Duerst, M. Suignard, Internationalized Resource Identifiers (IRIs), http://www.ietf.org/rfc/rfc3987.txt, IETF, 2005.
[RFC4288] N. Freed, J. Klensin, Media Type Specifications and Registration Procedures, http://www.ietf.org/rfc/rfc4288.txt, IETF, 2005.
[XAdES] XML Advanced Electronic Signatures (XAdES) (ETSI TS 101 903 v1.4.1 June 2009), ETSI, 650 Route des Lucioles, F-06921 Sophia Antipolis Cedex, FRANCE, http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=28064, 2009.
[XML-ID] Jonathan Marsh, Daniel Veillard, Norman Walsh, xml:id Version 1.0, http://www.w3.org/TR/2005/REC-xml-id-20050909/, W3C, 2005.
[xml-names] Tim Bray et al., Namespaces in XML 1.0 (Second Edition), http://www.w3.org/TR/2006/REC-xml-names-20060816, W3C, 2006.
[XML1.0] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau , Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/2006/REC-xml-20060816/, W3C, 2004.
[xmldsig-core] Donald Eastlake, Joseph Reagle, David Solo, Frederick Hirsch, Thomas Roessler, XML Signature Syntax and Processing (Second Edition), http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/, W3C, 2008.
[xmlenc-core] Donald Eastlake, Joseph Reagle, XML Encryption Syntax and Processing, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/, W3C, 2002.
[xmlschema-2] Paul V. Biron, Ashok Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, W3C, 2004.
[Schneier-Errata] Bruce Schneir, Applied Cryptography 2nd. Ed. - Errata, http://www.schneier.com/book-applied-errata.html, 1998.
The namespaces used or defined by OpenDocument part 3 are listed in tables 1 and 2.
The prefix column in tables 1 and 2 lists the namespace prefixes this specification uses when referring to elements and attributes in different namespaces. Conforming OpenDocument documents may substitute other namespace prefixes, bound to the listed namespace URI's, in accordance with the Namespaces in XML specification [xml-names].
Note: XML namespaces are employed in accordance with the Namespaces in XML W3C Recommendation [xml-names].
Elements and attribute contained in the package manifest.
Elements and attribute contained in digital signature files.
OWL classes and properties contained in metadata manifest files.
The OpenDocument specification defines conformance for packages, package consumers, and package producers, with two conformance classes called conforming and extended conforming. This chapter defines the basic requirements for the individual conformance targets.
A)It shall be a Zip file, as defined by [ZIP]. All files contained in the Zip file shall be non compressed (STORED) or compressed using the “deflate” (DEFLATED) algorithm.
B.1)The file shall be a well formed XML document in accordance with the [XML1.0] specification.
B.2)The XML root element of the file shall be a <manifest:manifest> element 4.2.
B.3)The XML file shall be valid with respect to the manifest schema defined in appendix A.1 OpenDocument Manifest Schema.
C)It should contain a file “mimetype”.
D.1)The files shall be well-formed XML files in accordance with [XML1.0].
D.2)The XML root element of each file shall be a <dsig:document-signatures> element 5.2.
D.3)The files shall be valid with respect to the digital signature schema defined in appendix A.2 OpenDocument Digital Signature Schema.
E)It shall not contain other files whose relative path begins with “META-INF/” other than than those listed in B) and D).
F.1)They shall be namespace-well-formed with regard to the XML Namespaces specification [xml-names].
F.2)They shall conform to the xml-id specification [XML-ID].
G)An OpenDocument Extended Package shall meet all requirements of a conforming package except item E) of 2.2.1.
A)It may produce conforming OpenDocument extended packages, but it shall have a mode of operation where all OpenDocument packages that are created are conforming OpenDocument packages.
B)It shall be accompanied by a document that defines all implementation-defined values used by the OpenDocument package producer.
An OpenDocument Package Extended Producer is a program that creates conforming OpenDocument extended packages. It shall be accompanied by a document that defines all implementation-defined values used by the OpenDocument package producer.
A)It shall be able to parse and interpret OpenDocument packages and OpenDocument extended packages, but it need not interpret the semantics of all elements, attributes and attribute values.
B.1)It shall be a nonvalidating XML processor with regard to the XML 1.0 specification [XML1.0].
B.2)It shall be a conforming processor with regard to the XML Namespaces specification [xml-names].
B.3)It shall conform to the xml-id specification [XML-ID].
OpenDocument defines a package file to store the XML content of a document as separate parts together with associated binary data as file entries in a single package file. These file entries may be compressed to further reduce the storage taken by the package. This package is a Zip file [ZIP], whose structure is described in Appendix C. OpenDocument Packages impose additional structure on the Zip file to accomplish the representation of OpenDocument Format documents.
A document within a package may consist of a set of files creating a unit, for instance the set of files specified by OpenDocument part 1. These files may be located in the root of the package, or within a directory. If they are contained in the root of the package, they are called document. If they are located within a directory, the document they constitute is called a sub document. A package may contain multiple sub documents, but only a single document can be contained in the root of the package. Unless otherwise stated, the term document refers to the document contained in the root of the package. This may include sub documents.
•A list of all of the files in the package (except those specifically excluded from the manifest).
•The MIME media type of each file in the package.
•If a file is stored in the file data in encrypted form, the manifest provides information required to decrypt the file correctly when the encryption key is also supplied.
The format of the manifest file is specified in chapter 4.
For all files contained in a package, with exception of the “mimetype” file and files whose relative path starts with “META-INF/”, the “META-INF/manifest.xml” file shall contain exactly one <manifest:file-entry> element whose manifest:full-path attribute's value references the file.
The “META-INF/manifest.xml” file need not contain <manifest:file-entry> elements 4.3 whose manifest:full-path attribute 4.8.4 references files whose relative path start with "META-INF/". The file shall not contain <manifest:file-entry> elements whose manifest:full-path attribute value references the “META-INF/manifest.xml” file itself or the “mimetype” file.
The “META-INF/manifest.xml” file should contain a <manifest:file-entry> element whose manifest:full-path attribute has the value "/". This element specifies information regarding the document stored in the root of the package. This entry shall exist if the package contains a file "mimetype"
If a MIME media type for a document exists, then an OpenDocument package should contain a file with name “mimetype”. The content of this file shall be the ASCII encoded MIME media type associated with the document. See [RFC4288].
The “mimetype” file shall be the first file of the zip file. It shall not be compressed, and it shall not use an 'extra field' in its header.
If the file named “META-INF/manifest.xml” contains a <manifest:file-entry> element whose manifest:full-path attribute has the value "/", then a "mimetype" file shall exist, and the content of the “mimetype” file shall be equal to the value of the manifest:media-type attribute 4.8.10 of that element.
•the media type itself beginning at position 38.
•A single start key is generated and used for all of the keys that will be derived.
•The derived key is generated based on the start key.
•The files are encrypted based on the derived key and the encryption algorithm.
The information regarding the algorithms that were used to encrypt a file and required parameters are contained in the manifest. The manifest shall not be encrypted.
Each file entry that is encrypted shall be compressed with the “deflate” algorithm before being encrypted. Encrypted file entries shall be flagged as 'STORED' rather than 'DEFLATED' in the Zip file's central directory. The size of the encrypted file should replace the real size value in the file entry's central directory records, its local file header and the data descriptor, if any. The original uncompressed, unencrypted size shall be contained in the manifest:size 4.8.13 attribute of the <manifest:file-entry> 4.3 element for the file entry.
The encrypted form can be of greater size than the DEFLATED file used as the plaintext.
Note: The encrypted form may be of greater because of padding of plaintext, inclusion of additional information, and other characteristics of the encryption technique).
The encryption method shall be such that the exact size and value of the plaintext DEFLATED file is recovered by the corresponding decryption process.
1.The start key is generated: The byte sequence representing the password in UTF-8 is used to generate a 20-byte SHA1 digest (see [RFC3174]).
2.For each file to be encrypted, a separate derived key is generated from the start key: The PBKDF2 algorithm based on the HMAC-SHA-1 function (see [RFC2898]) is used for the key derivation. For each file, a 16-byte salt is generated by a random generator. The salt is used together with the start key to derive a unique 128-bit key for each file. The default iteration count for the algorithm is 1024.
3.The files are encrypted: The random number generator is used to generate the 8-byte initialization vector for the algorithm. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in 8-bit cipher feedback (8-bit CFB) mode (see [Schneier]).
Files within a package may have a digital signature applied. Digital signatures are stored in one or more files whose relative paths begin with “META-INF/”. The names of these files shall contain the term “signatures”.
The format of digital signature files is specified in chapter 5.
Metadata for documents contained in an OpenDocument package may be expressed using the model of the W3C Resource Description Framework [RDF-CONCEPTS].
A document or sub document that is stored in a package may contain any number of metadata files. The content of a metadata files shall conform to the [RDF-XML] specification. Implementations that are consumers as well as producers should preserve all metadata files.
All metadata files of a document or sub document shall be listed in a separate metadata manifest file, which has the file name “manifest.rdf”. This file enumerates metadata files and their relationships to other files in an OpenDocument package. See chapter 6.
In addition to metadata files, the "manifest.rdf" file may list other files which are contained in the document or sub document that contain RDF metadata, like files that contain RDFa metadata. The "manifest.rdf" file need not exist if a document or sub document does not contain any files that contain RDF metadata.
All references to a resource within the same package that occur within metadata file shall be represented by relative IRIs to the resource. This includes values of rdf:about attributes occurring within metadata files or metadata manifest files.
1.The file entry path is the file name of the file within the Zip file which contains the relative IRI, including its relative path.
2.The package base IRI is the base IRI which would be established for the package itself as defined in §5.1 of [RFC3986].
3.If the relative IRI does not match the rule for "relative-ref" defined in §4.2 of [RFC3986] or if the relative IRI does start with a "/" character (U+002F, SOLIDUS) then it is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
4.If the relative IRI references matches the rule for "relative-ref" defined in §4.2 of [RFC3986] and its "relative-part" component matches the "path-empty" rule it shall be resolved as a "Same-Document" references defined in §4.4 of [RFC3986].
6.If the file entry path does contain a "/" character (U+002F, SOLIDUS) then the file path up to and including the last "/" character is copied into the file entry buffer.
7.If the relative IRI buffer starts with the character sequence "./" (U+002E, FULL STOP, followed by U+002F, SOLIDUS) then that character sequence it removed from the buffer. Continue with step 7.
8.If the content of the relative IRI buffer is the character sequence "." (U+002E, FULL STOP), the content of the relative IRI buffer is removed. Continue with step 11.
•if the file entry path buffer is empty, then the content of the relative IRI buffer is replaced with "." (U+002E, FULL STOP). The query and fragment components of the relative IRI, if present, are appended to the relative IRI buffer, including the "?" (U+003F, QUESTION MARK) and "#" (U+0023, NUMBER SIGN) delimiter characters. The content of the relative IRI buffer then is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
•if the file entry path buffer contains at least one relative path component, the last relative path component up to and including the last "/" character (U+002F, SOLIDUS) is removed. The ".." character sequence is removed from the IRI buffer. Continue with step 11.
10.If a fragment buffer has been created and is not empty, its content may be resolved as fragment identifier, as defined by §3.5 of [RFC3986].
•if the file entry path buffer is empty, then the "../" is replaced with "./" (U+002E, FULL STOP, followed by U+002F, SOLIDUS) in the relative IRI buffer. The query and fragment components of the relative IRI, if present, are appended to the relative IRI buffer, including the "?" (U+003F, QUESTION MARK) and "#" (U+0023, NUMBER SIGN) delimiter characters. The content of the relative IRI buffer then is resolved as defined in §5.2 of [RFC3986] with the package base IRI as base URI.
•if the file entry path buffer contains at least one one relative path component, the last relative path component up to and including the last "/" character (U+002F, SOLIDUS) is removed. The "../" character sequence is removed from the IRI buffer. Continue with step 7.
11.The content of the file entry buffer is inserted into the relative IRI buffer before any existing content.
12.The content of the relative IRI buffer is interpreted as a file or directory name within the package, that is, as the name of a file or directory including its relative path within the Zip file. An empty buffer denotes the package root. Path segments in the relative IRI buffer that originally came from the relative IRI shall be interpreted according to IRI syntax rules, while segments that originally came from the file entry path must be interpreted according to Zip path name syntax rules.
13.If the relative IRI contains a fragment component, it is resolved as fragment identifier, as defined by §3.5 of [RFC3986].
Note: Files whose relative path starts with “META-INF/” are considered to be part of the OpenDocument package rather than of the content stored within the package. Therefore, different rules regarding the resolution of relative IRIs may apply.
Unless a document is encrypted, package producers should generate a preview image of the document that is contained in the package. It should be a representation of the first page, first sheet, etc. of the document. For maximum re-usability of the preview images they shall be generated without any effects, surrounding frames, or borders.
Note: Such effects might interfere with effects added to the preview images by the different file system explorers or may not be desired at all for certain use cases.
The preview image shall be contained in a file named “Thumbnails/thumbnail.png”.
Preview images shall be saved in [PNG] format.
Note: Current desktops display preview images within squares of up to 256 pixel width and height, and 24 bit per pixel. While this specification does not define upper or lower limits for preview image sizes, producers should only use image sizes that are displayed with a reasonable quality if scaled to fit into 256x256 pixel square.
Encrypted documents are intended to be unreadable for unauthorized users and package producers shall not generate preview images for such documents. They may include a preview image that is independent of the contents of the document. Such preview images should not be encrypted.
The format of the manifest file is defined by the OpenDocument manifest Relax-NG [RNG] schema. See appendix A. This chapter describes the semantics of the elements and attributes defined by this schema.
The <manifest:manifest> element is the root element of the manifest file. It contains <manifest:file-entry> child elements 4.3, each of which specifies information for a a file or directory in the package.
The <manifest:manifest> element is a root element.
The <manifest:manifest> element has the following attribute: manifest:version 4.8.14.2.
The <manifest:manifest> element has the following child element: <manifest:file-entry> 4.3.
The <manifest:file-entry> element specifies the media type of a single file or sub document within the package. It may also specify the data required to decrypt a file.
For directories, the manifest file should contain a <manifest:file-entry> element only if a directory contains a document or a sub document. See 3.1. A directory for administrative or convenience purposes, such as a directory that contains various unrelated image files, should not have an entry in the manifest file.
Directories have no corresponding file entries within the Zip file.
The <manifest:file-entry> element is usable within the following element: <manifest:manifest> 4.2.
The <manifest:file-entry> element has the following attributes: manifest:full-path 4.8.4, manifest:media-type 4.8.10, manifest:preferred-view-mode 4.8.11, manifest:size 4.8.13 and manifest:version 4.8.14.1.
The <manifest:file-entry> element has the following child element: <manifest:encryption-data> 4.4.
The <manifest:encryption-data> element contains information required to decrypt a file entry.
The <manifest:encryption-data> element is usable within the following element: <manifest:file-entry> 4.3.
The <manifest:encryption-data> element has the following attributes: manifest:checksum 4.8.2 and manifest:checksum-type 4.8.3.
The <manifest:encryption-data> element has the following child elements: <manifest:algorithm> 4.5, <manifest:key-derivation> 4.7 and <manifest:start-key-generation> 4.6.
The <manifest:algorithm> element specifies the algorithm used to encrypt data.
Depending on the algorithm specified by the manifest:algorithm-name attribute 4.8.1 , the <manifest:algorithm> element may have further child elements.
When the manifest:algorithm-name attribute value matches one of those defined in section §3.2 of [xmlenc-core], the <manifest:algorithm> element shall not have child elements except those permitted as child elements of the [xmlenc-core] <EncryptionMethod> element whose Algorithm attribute value is the same as the <manifest:algorithm> manifest:algorithm-name attribute value.
When the value of the manifest:algorithm-name attribute identifies the legacy Blowfish algorithm, <manifest:algorithm> shall be an empty element.
The <manifest:algorithm> element is usable within the following element: <manifest:encryption-data> 4.4.
The <manifest:algorithm> element has the following attributes: manifest:algorithm-name 4.8.1 and manifest:initialisation-vector 4.8.5.
The <manifest:start-key-generation> element specifies how the encryption start key is derived from a user specified password. The password shall be provided as a sequence of bytes in UTF-8 encoding.
When a <manifest:start-key-generation> element is absent as a child of a <manifest:encryption-data> element, interpretation is the same as if the element is present with default attribute values.
The <manifest:start-key-generation> element is usable within the following element: <manifest:encryption-data> 4.4.
The <manifest:start-key-generation> element has the following attributes: manifest:key-size 4.8.7 and manifest:start-key-generation-name 4.8.6.
The <manifest:start-key-generation> element has no child elements.
The <manifest:key-derivation> element specifies how the encryption key was calculated from the encryption start key.
The <manifest:key-derivation> element is usable within the following element: <manifest:encryption-data> 4.4.
The <manifest:key-derivation> element has the following attributes: manifest:iteration-count 4.8.8, manifest:key-derivation-name 4.8.9, manifest:key-size 4.8.7 and manifest:salt 4.8.12.
The <manifest:key-derivation> element has no child elements.
The manifest:algorithm-name attribute specifies the algorithm and mode used to encrypt a file entry.
•An IRI listed in §5.2 of [xmlenc-core]: The algorithm and mode specified in §5.2 of [xmlenc-core] for this IRI.
•Blowfish CFB: The Blowfish algorithm in 8-bit CFB mode. See [Schneier].
•urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#blowfish: The same algorithm as identified by Blowfish CFB.
•The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core]. Alternative algorithms may be specified by extended conforming packages only. They shall not be specified by conforming packages.
•Package producers that support encryption shall support the value Blowfish CFB. Package consumers that support encryption shall support the values Blowfish CFB and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#blowfish.
Note: An errata for [Schneier] is available at [Schneier-Errata].
The manifest:algorithm-name attribute is usable with the following element: <manifest:algorithm> 4.5.
The values of the manifest:algorithm-name attribute are Blowfish CFB or a value of type anyURI 7.2.
The manifest:checksum attribute specifies a digest in BASE64 encoding that can be used to detect password correctness as specified by a manifest:checksum-type attribute 4.8.3 .
The manifest:checksum attribute is usable with the following element: <manifest:encryption-data> 4.4.
The manifest:checksum attribute has the data type base64Binary 7.2.
The manifest:checksum-type attribute specifies the name of a digest algorithm that can be used to check password correctness. The digest is build from the compressed unencrypted file.
•SHA1/1K: SHA1 algorithm (see [RFC3174]) applied to first 1024 bytes of the compressed unencrypted file.
•SHA1: The same as http://www.w3.org/2000/09/xmldsig#sha1.
•urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1-1k: The same as SHA1/1K.
•urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k: SHA256 algorithm (see [RFC3174]) applied to first 1024 bytes of the compressed unencrypted file.
•An IRI listed in §5.7 of [xmlenc-core]: The algorithm specified in §5.7 of [xmlenc-core] for this IRI.
Package producers that support encryption should use the urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k algorithm, Package consumers that support encryption shall support the values SHA1/1K, urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha1-1k and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#sha256-1k.
The manifest:checksum-type attribute is usable with the following element: <manifest:encryption-data> 4.4.
The values of the manifest:checksum-type attribute are SHA1/1K or a value of type anyURI 7.2.
The manifest:full-path attribute describes the location of a file or directory within the package. It's value is the name of a file or folder within the Zip file for which the manifest entry defines additional information, including its relative path in the package. The notation is the same as for the “filename” fields of the Zip file's central directory.
The attribute value "/" denotes a manifest entry for the package itself.
Note: The Zip file's central directory and the manifest file may have different text encodings.
The manifest:full-path attribute is usable with the following element: <manifest:file-entry> 4.3.
The manifest:full-path attribute has the data type string 7.2.
The manifest:initialisation-vector attribute value provides the byte-sequence for the initialization vector used by the encryption algorithm when delivery of a required initialization vector is not specified as part of the encryption algorithm definition. The initialization vector is a BASE64 encoded binary sequence. The format and length of an initialization vector, in bytes, shall be as required by its encryption algorithm specification.
The manifest:initialisation-vector attribute is usable with the following element: <manifest:algorithm> 4.5.
The manifest:initialisation-vector attribute has the data type base64Binary 7.2.
The manifest:start-key-generation-name attribute specifies the algorithm used to generate a start key from the user password.
•SHA1: The SHA1 algorithm (see [RFC3174]).
•The IRI of an alternative algorithm as specified in §5.1 of [xmlenc-core] Alternative algorithms may be specified by extended conforming packages only. They shall not be specified by conforming packages.
The default value for this attribute is SHA1.
Package producers that support encryption should use the http://www.w3.org/2000/09/xmldsig#sha256 algorithm. Package consumers that support encryption shall support the values SHA1, and http://www.w3.org/2000/09/xmldsig#sha1 and http://www.w3.org/2000/09/xmldsig#sha256.
The manifest:start-key-generation-name attribute is usable with the following element: <manifest:start-key-generation> 4.6.
The values of the manifest:start-key-generation-name attribute are SHA1 or a value of type anyURI 7.2.
The manifest:start-key-generation-name attribute has the value SHA1 or a value of data type anyURI.
The manifest:key-size attribute specifies the length in octets of a key delivered by a key-developing algorithm.
For a <manifest:start-key-generation> element, the default value for this attribute is 20.
Note: The value used will need to be compatible with the result obtain from the start-key-generation algorithm and the input requirements of the key derivation algorithm.
For a <manifest:key-derivation> element, the default value for this attribute is 16.
Note: The value used will need to be one obtainable from the key-derivation algorithm and acceptable for the encryption algorithm being used.
The manifest:key-size attribute is usable with the following elements: <manifest:key-derivation> 4.7 and <manifest:start-key-generation> 4.6.
The manifest:key-size attribute has the data type nonNegativeInteger 7.2.
The manifest:iteration-count attribute specifies the number of iterations used by the key derivation algorithm to derive a key.
The manifest:iteration-count attribute is usable with the following element: <manifest:key-derivation> 4.7.
The manifest:iteration-count attribute has the data type nonNegativeInteger 7.2.
The manifest:key-derivation-name attribute specifies the password-based key-derivation algorithm used to derive a cryptographic key for use in encryption and decryption of the file.
•PBKDF2: The PBKDF2 key derivation method with HMAC-SHA-1 for the Pseudo-Random Function(PRF). See [RFC2898] sections 5.2 and B.1.1.
•urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#pbkdf2: The same algorithms as identified by PBKDF2.
•The IRI of an implementation-defined alternative algorithm. Alternative algorithms may be specified by extended conforming packages only. They shall not be specified by conforming packages.
Package producers that support encryption shall support the value PBKDF2. Package consumers that support encryption shall support the values PBKDF2 and urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#pbkdf2.
If the value of this attribute is PBKDF2 or urn:oasis:names:tc:opendocument:xmlns:manifest:1.0#pbkdf2 the <manifest:encryption-data> 4.4 shall contain a <manifest:start-key-generation> 4.6 child element that specifies the start key for the PBKDF2 algorithm.
The manifest:key-derivation-name attribute is usable with the following element: <manifest:key-derivation> 4.7.
The values of the manifest:key-derivation-name attribute are PBKDF2 or a value of type anyURI 7.2.
The manifest:media-type attribute specifies the MIME media type of a file or directory. See [RFC4288].
A manifest:media-type attribute should be present for all files and directories where a MIME media type exists for the content of the file, or the document or sub document contained in a directory.
The manifest:media-type attribute is usable with the following element: <manifest:file-entry> 4.3.
The manifest:media-type attribute has the data type string 7.2.
The manifest:preferred-view-mode attribute specifies a preference on how the author of the document would like the document to be presented upon the document being opened. This attribute is only applicable to the root file entry with the manifest:full-path 4.8.4 attribute value of "/".
•edit: The author's preference is to open the document as an editable document.
•presentation-slide-show: The author's preference is to open the document as presentation slide show.
•read-only: The author's preference is to open the document as a read-only document.
•A namespaced token value: Specifies an implementation defined view.
Preferred view modes are not necessarily generally applicable to all media types. The default preferred view mode is implementation defined. The behavior for cases where the manifest:preferred-view-mode attribute is absent is implementation defined.
The manifest:preferred-view-mode attribute is usable with the following element: <manifest:file-entry> 4.3.
The values of the manifest:preferred-view-mode attribute are edit, presentation-slide-show, read-only or a value of type namespacedToken 7.3.1.
The manifest:salt attribute carries the value of a cryptographically-random binary value designed to mitigate certain cryptographic attacks on the password. There is no maximum length to the salt. See [RFC2898] for further considerations in the use of salts with key-derivation and other cryptographic functions. The salt is encoded in the attribute value as base64binary.
The manifest:salt attribute is usable with the following element: <manifest:key-derivation> 4.7.
The manifest:salt attribute has the data type base64Binary 7.2.
The manifest:size attribute shall be present for encrypted files. See 3.4. Its value shall be size of the uncompressed, unencrypted file in bytes.
The manifest:size attribute is usable with the following element: <manifest:file-entry> 4.3.
The manifest:size attribute has the data type nonNegativeInteger 7.2.
The manifest:version attribute specifies the format version of a file entry. For documents that are composed from multiple files, this attribute is specified at the manifest entry that references the folder that contains these files.
The interpretation of the attribute value depends on the MIME media type specified in the manifest:media-type attribute.
The manifest:version attribute is usable with the following element: <manifest:file-entry> 4.3.
The manifest:version attribute has the data type string 7.2.
The manifest:version attribute identifies the version of OpenDocument specification that defines the schema and interpretation of the package manifest. The value of the manifest:version attribute shall be "1.2".
The manifest:version attribute is usable with the following element: <manifest:manifest> 4.2.
The only value of the manifest:version attribute is 1.2.
The format of the digital signature files is defined by the OpenDocument digital signature schema Relax-NG [RNG] schema. See appendix A. This chapter describes the semantics of the elements and attributes defined by this schema.
The <dsig:document-signatures> root element serves as a container for any number of <ds:Signature> 5.3 elements. If the <dsig:document-signatures> element contains multiple <ds:Signature> elements, then there should be a relation between the digital signatures they define, for instance, they may all apply to the same set of files.
•if the <ds:Reference> child elements of the <ds:Signature> element reference a certain set of files.
In particular, consumers may require that a digital signature references all files contained in a package.
If a digital signature file is not encrypted, consumers shall not decrypt files that are referenced by <ds:Reference> elements and that are encrypted before validating the signature.
If a digital signature file is encrypted, consumers shall decrypt files that are referenced by <ds:Reference> elements and that are encrypted before validating the signature.
The <dsig:document-signatures> element is a root element.
The <dsig:document-signatures> element has the following attribute: dsig:version 5.4.1.
The <dsig:document-signatures> element has the following child element: <ds:Signature> 5.3.
The <ds:Signature> element is defined by the [xmldsig-core] specification. Each <ds:Signature> element shall contain an Id attribute specifying a unique value. A producer may use the XAdES extensions as specified in ETSI TS 101 903 v1.4.1 [XAdES], or later versions of the XAdES specification.
A <ds:KeyInfo> element, as specified in [xmldsig-core], section 4.4 shall be included. The <ds:KeyInfo> element should contain an <ds:X509Data> element containing an <ds:X509IssuerSerial> element specifying the issuer and serial number of the signing certificate, and an <ds:X509Certificate> element specifying the full signing certificate.
Additional <ds:X509Certificate> elements may be placed in the <ds:X509Data>, or may be placed in the <xades:CertificateValues> element of the XAdES <ds:Object>, as defined in [XAdES] section 7.6.1. The additional certificates should represent the entire certificate chain used for verification at signing time.
1.A <ds:Reference> element which has a Type attribute value of "http://docs.oasis-open.org/office/v1.2/OS/OpenDocument-v1.2.odt" shall refer to files in the same package in the accordance with the procedure for resolving IRIs 3.7, except that the file entry path shall be the name of the signature file with its relative path omitted.
Note: Consequently, an IRI-Reference consisting entirely of "#" followed by an ifragment (§2.2 of [RFC3987]) refers to the ID of an XML element within the same XML document containing this <ds:signature> element.
2.A <ds:Reference> element which has a Type attribute with a value of "http://uri.etsi.org/01903/v1.2.2#SignedProperties" refers to an XAdES SignedProperties element.. A <ds:Reference> element which refers to the XAdES SignedProperties element (if present) shall be as specified in [XAdES] section 6.3.1.
3.A <ds:Reference> element which does not have a Type attribute shall be processed the same a <ds:Reference> element which has a Type attribute with a value of "http://docs.oasis-open.org/office/v1.2/OS/OpenDocument-v1.2.odt".
The only permitted <ds:Transform> elements which apply to files contained within the archive shall be canonicalization transforms, as specified in [xmldsig-core], section 6.5.
a.An Id attribute with a value containing a unique identifier.
b.A Target attribute corresponding to the Id attribute of the <ds:Signature> element.
c.A <date> element from the namespace "http://purl.org/dc/elements/1.1/" containing the UTC time as [xmlschema-2] dateTime value.
2.A <xades:SigningTime> element as specified in [XAdES] section 7.2.1.
1.The <xades:SignedSignatureProperties> element shall contain a <xades:SigningCertificate> property as specified in [XAdES] section 7.2.2.
2.A <xades:SigningTime> element should be present as specified in [XAdES] section 7.2.1.
3.If any timestamp elements of type XAdESTimeStampType are present, such as the <xades:SignatureTimeStamp> or <xades: SigAndRefsTimestamp> elements, the time stamp information shall be specified as an EncapsulatedTimeStamp element containing DER encoded ASN.1. Data.
4.If references to validation data are present, the <xades:SigAndRefsTimestamp> element as specified in [XAdES] sections 7.5.1 and 7.5.1.1 shall be used.
5.There shall be a <ds:Reference> element specifying the digest of the SignedProperties element, as specified in [XAdES], section 6.2.1. This <ds:Reference> element shall be contained within the <ds:SignedInfo> element of the <ds:Signature> element.
The <ds:Signature> element is usable with the following element: <dsig:document-signatures> 5.2.
The dsig:version attribute identifies the version of OpenDocument specification that defines the schema and interpretation of the digital signature file. The value of the dsig:version attribute shall be "1.2".
The dsig:version attribute is usable with the following element: <dsig:document-signatures> 5.2.
The only value of the dsig:version attribute is 1.2.
Metadata manifest files (see 3.6) have the file name “manifest.rdf”. The metadata manifest file for a document (see 3.1) shall be stored in the root of the package. The metadata manifest file for a sub documents shall be stored in the sub document's directory.
Metadata manifest files enumerate metadata files and their relationships to other files in that document or sub document as defined by this specification.
The relationships are expressed in the metadata manifest files using [RDF-XML] and the [OWL] Metadata Manifest Description ontology that is defined in appendix B. The following OWL classes and properties are defined.
An instance of the pkg:Document class in the metadata manifest file represents the document or sub document itself.
The following property is defined for the pkg:Document class: pkg:hasPart 6.6.
A file in an OpenDocument package is represented by an instance of class pkg:File or by one of its subclasses, for example pkg:MetadataFile.
An instance of the pkg:File class (or one of its subclasses) is identified by an IRI.
The relationship between a file and a package is expressed using the property pkg:hasPart 6.6.
The following property is defined for the pkg:File class: pkg:mimeType 6.7.
An instance of the pkg:MetadataFile class represents a metadata file.
The pkg:MetadataFile class is a subclass of pkg:File 6.3.
The pkg:Element class describes an XML element contained in a file within an OpenDocument package.
The pkg:hasPart property locates a file described by pkg:File or its subclasses within a document or sub document.
This property can be used with the following class: pkg:Document 6.2.
The pkg:mimeType property is used to specify the MIME media type [RFC4288] of file described by an pkg:File class or one of its subclasses.
This property can be used with the following class: pkg:File 6.3.
The values of attributes and elements are often described as having datatypes. These datatypes either are datatypes defined within [xmlschema-2], or are defined by this specification. Datatypes for which no [xmlschema-2] datatype exists are expressed in the schema by [xmlschema-2] datatypes. Some of these datatypes have additional constraints.
The OpenDocument manifest schema is defined by a separate document, whose location can be found in the Related work section on the introductory pages.
The OpenDocument digital signature schema is defined by a separate document, whose location can be found in the Related work section on the introductory pages.
The OpenDocument metadata manifest ontology is defined by a separate document, whose location can be found in the Related work section on the introductory pages.
A Zip file starts with a sequence of files, each of which can be compressed or stored in raw format. Each file has a local header immediately before its data, which contains most of the information about the file, including time-stamps, compression method and file name. The compressed file contents immediately follow, and are terminated by an optional data descriptor. The data descriptor contains the CRC and compressed size of the file, which are frequently not available when writing the local file header. If these details were included, the data descriptor can be skipped.
Each file in the archive is laid down sequentially in this format, followed by a central directory at the end of the Zip archive. The central directory is a contiguous set of directory entries, each of which contains all the information in the local file header, plus extras such as file comments and attributes. Most importantly, the central directory contains pointers to the position of each file in the archive for navigation of the Zip file.
For more details about the Zip file format, see [ZIP].
The OpenDocument specification has been divided into three parts and has been restructured.
This appendix describes changes that are related to part 3 of this specification.
The following is a list of major features that have been added. For minor features please see the lists of new and changed elements and attributes.

References: V. 
 §5
 §4
 §5
 §4
 §4
 §5
 §3
 §5
 §3
 §3
 §5
 §5
 §5
 §5
 §5
 §5