Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26300-2 — Open Document Format for Office Applications v1.3 Part 2
Reusable OpenDocument format (ODF) packages and package-level metadata
ISO/IEC 26300-2 is Part 2 of the Open Document Format for Office Applications (ODF) v1.3 standard, specifying the package format that encapsulates ODF content, metadata, and associated resources into a single file. While Part 1 defines the XML content schema (the actual document structure expressed as XML files within the package), Part 2 defines how those XML files are assembled into a ZIP-based container with manifest entries, metadata streams, and digital signature support. Understanding the package layer is essential for any engineer working on document processing, archiving, or interoperability.
ODF packages are valid ZIP files, but not all ZIP files are valid ODF packages. The package format requires specific files (META-INF/manifest.xml, mimetype), specific entry ordering (mimetype must be first, stored without compression), and specific directory structure. A generic ZIP tool that modifies an ODF file may produce a package that violates these constraints.
Package Structure and Requirements
The ODF package format is built on the ZIP archive specification, with additional constraints that ensure predictable processing across implementations:
| Package Element | Required | Location | Purpose |
|---|---|---|---|
| mimetype entry | Yes | First entry in ZIP, no compression | Media type identification (e.g., application/vnd.oasis.opendocument.text) |
| META-INF/manifest.xml | Yes | Standard XML file in META-INF directory | File listing, media types, encryption info, and version metadata |
| META-INF/signatures.xml | No | Optional file in META-INF directory | XML digital signatures for document integrity and authentication |
| Content files | Yes | Root or subdirectories | content.xml, styles.xml, meta.xml, settings.xml, and embedded resources |
| META-INF/manifest.key | No | Optional file in META-INF directory | Encryption key derivation data for password-protected documents |
The mimetype entry is the most constrained element in the package. It must be the very first entry in the ZIP archive, stored without compression, and contain exactly the media type string followed by a single newline character (0x0A). This design allows file-type detection tools (e.g., Unix file command) to identify an ODF document by reading the first 50-80 bytes of the file without parsing the full ZIP structure — significantly improving detection performance on large document archives.
The manifest.xml file serves as the package’s table of contents. Every file in the package (except the mimetype entry itself) must be listed in the manifest along with its media type, and optionally, encryption information. The manifest also stores the ODF version and any namespace declarations needed for processing the package contents.
The manifest.xml was significantly enhanced in ODF v1.3 to support richer metadata, including relationship types between files, better MIME type descriptions for embedded media, and improved support for accessibility metadata. These enhancements make ODF v1.3 packages more self-describing than previous versions.
Digital Signatures and Document Integrity
ISO/IEC 26300-2 specifies both envelope-based and manifest-based digital signature mechanisms. Envelope signatures cover the entire package as a binary blob, while manifest signatures cover individual files within the package, identified by their manifest entry paths.
Envelope signatures are simpler but less flexible: signing detects any modification to any file in the package. This is appropriate for archival use cases where document integrity is paramount. However, envelope signatures break when an application needs to add metadata (e.g., a print timestamp) to the package without invalidating the original signature.
Manifest-based signatures solve this flexibility problem by signing individual files independently. An application can add a new file to the package (e.g., an extended metadata stream) and sign only that new file, without affecting the signatures on existing content files. The manifest tracks which files are signed and which signature covers each file.
The digital signature format uses XML Signature Syntax and Processing (XML-DSig, W3C Recommendation), with support for X.509 certificates, HMAC-based keys, and referenced signature formats. ODF v1.3 added support for long-term validation (LTV) profiles, enabling signatures that remain verifiable decades after the signing certificate has expired — a critical requirement for electronic records management.
When implementing ODF digital signature verification, always validate the manifest.xml file itself. An attacker can strip signatures from an ODF package by modifying the manifest to remove signature entries while leaving the signatures.xml file intact. The manifest must be authenticated before any signature verification begins.
Engineering Insights for ODF Package Processing
Building robust ODF processing tools requires careful attention to package-level details that are often overlooked by developers focused on the XML content:
Streaming vs. random-access processing: For large ODF packages (e.g., presentations with embedded video, or spreadsheets with thousands of images), random-access ZIP reading is essential. The manifest provides the byte offsets for each entry, enabling a reader to seek directly to a specific file without decompressing the entire package. When performance matters, use a ZIP implementation that supports entry-level random access rather than decompressing sequentially.
Encryption handling: ODF v1.3 supports both package-level encryption (the entire content is encrypted) and file-level encryption (individual files within the package are encrypted). File-level encryption is more flexible but requires careful key management. The manifest.xml stores the encryption algorithm, key derivation method (PBKDF2 with configurable iteration count), and initialization vector for each encrypted file. Implementations must support at least AES-128 in CBC mode, with SHA-256 as the hash algorithm for key derivation.
Backward compatibility: ODF v1.3 packages are designed to be readable by ODF v1.2 implementations, provided the v1.2 implementation ignores unknown elements in the manifest and content files. However, v1.3-specific features (new metadata elements, enhanced digital signatures, additional media types) are silently ignored by v1.2 processors. Applications should always declare the minimum ODF version in the manifest that covers the features they use.
Never construct an ODF package by concatenating ZIP entries manually. Always use a conforming ZIP library that respects ODF-specific constraints: the mimetype entry must be stored (not compressed), must be first, and must contain exactly the correct media type string. A single byte of deviation from the specification can cause document processors (LibreOffice, Microsoft Word with ODF plugin, online viewers) to reject the document.
Frequently Asked Questions (FAQ)
Q1: What is the difference between ODF v1.3 Part 1 and Part 2?
Part 1 (ISO/IEC 26300-1) defines the XML schema for document content — the structure of text documents, spreadsheets, presentations, drawings, charts, and formulas. Part 2 (ISO/IEC 26300-2) defines the package format — how those XML files are organized in the ZIP container, along with manifest, encryption, and digital signature handling.
Part 1 (ISO/IEC 26300-1) defines the XML schema for document content — the structure of text documents, spreadsheets, presentations, drawings, charts, and formulas. Part 2 (ISO/IEC 26300-2) defines the package format — how those XML files are organized in the ZIP container, along with manifest, encryption, and digital signature handling.
Q2: Can I extract ODF content using standard ZIP tools?
Yes, because ODF packages are valid ZIP files. You can use any ZIP tool to extract the content XML files. However, modifying an ODF package with a standard ZIP tool may break ODF-specific constraints (mimetype ordering, compression settings). For safe modification, use libraries specifically designed for ODF processing.
Yes, because ODF packages are valid ZIP files. You can use any ZIP tool to extract the content XML files. However, modifying an ODF package with a standard ZIP tool may break ODF-specific constraints (mimetype ordering, compression settings). For safe modification, use libraries specifically designed for ODF processing.
Q3: How does ODF package encryption compare to encrypted ZIP?
ODF uses XML-Encryption at the file level within the package, while encrypted ZIP (AES-2 scheme) encrypts at the ZIP entry level. ODF’s approach allows selective encryption of individual files within the package — e.g., encrypting only the content.xml while leaving metadata files unencrypted for indexing purposes.
ODF uses XML-Encryption at the file level within the package, while encrypted ZIP (AES-2 scheme) encrypts at the ZIP entry level. ODF’s approach allows selective encryption of individual files within the package — e.g., encrypting only the content.xml while leaving metadata files unencrypted for indexing purposes.
Q4: What tools support ODF v1.3 digital signatures?
LibreOffice 7.3+ supports ODF v1.3 digital signatures. Several commercial document management systems and e-signature platforms also support the format. The reference implementation is available through the ODF Toolkit project, which provides Java libraries for creating and verifying ODF package signatures.
LibreOffice 7.3+ supports ODF v1.3 digital signatures. Several commercial document management systems and e-signature platforms also support the format. The reference implementation is available through the ODF Toolkit project, which provides Java libraries for creating and verifying ODF package signatures.
