Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26300-3 — Open Document Format Part 3: Package Architecture
Understanding the ODF Package Structure, Manifest, and Digital Signatures
Introduction to ISO/IEC 26300-3: The ODF Package Structure
ISO/IEC 26300-3 defines the package format for the Open Document Format (ODF), specifying how the various components of an ODF document — content, styles, metadata, and embedded resources — are bundled together into a single portable unit. While Parts 1 and 2 of the standard focus on the XML schema and the OpenFormula specification, Part 3 tackles the container architecture that makes ODF a practical, real-world document format.
The ODF package is fundamentally a ZIP archive with a well-defined internal structure. This means any tool that can read ZIP files — from Python’s zipfile module to 7-Zip — can inspect the raw contents of an ODF document.
The package structure defined in ISO/IEC 26300-3 follows a “container within container” model. The outer container is the ZIP archive itself, while the inner container is the XML-based manifest that enumerates every file in the package and its MIME type. This dual-container approach provides both broad compatibility (ZIP is universally supported) and rich metadata (the manifest enables content-type negotiation and digital signature verification).
A key design principle of the ODF package is that it must remain valid even when individual components are modified. For example, if you extract a document, replace an image, and repackage it, the manifest must be updated accordingly. The standard mandates that the manifest file (META-INF/manifest.xml) accurately reflects the current state of the package contents at all times.
| Component | Required | Description |
|---|---|---|
| mimetype | Yes | Uncompressed file at offset 0 containing the document MIME type (e.g., application/vnd.oasis.opendocument.text) |
| META-INF/manifest.xml | Yes | XML manifest listing all files, their MIME types, encryption status, and version information |
| content.xml | Yes | Primary document content in ODF XML format |
| styles.xml | No | Document-level and automatic styles applied to content |
| meta.xml | No | Document metadata including author, date, and statistics |
| Thumbnails/ | No | Optional thumbnail image for file manager preview |
The mimetype file must be stored as the first entry in the ZIP archive without compression. This allows file-type detection tools to read the MIME type by seeking to byte 30 (after the local file header) without decompressing any data — a significant performance optimization.
Manifest Structure and Digital Signatures
The manifest in META-INF/manifest.xml serves as the authoritative directory of the package. Each <manifest:file-entry> element declares a file path and its corresponding MIME type. The root entry (path “/”) declares the overall document type, while child entries describe subcomponents. This structure enables signature verification: a digital signature covers the manifest entries, which in turn reference the actual data files, creating an unbroken chain of trust.
ISO/IEC 26300-3 also specifies how encryption is layered onto the package. Individual files within the package can be encrypted using XML Encryption standards, with the encryption metadata stored in a separate META-INF/document-signatures.xml file. This granular encryption model allows document authors to encrypt only sensitive sections (e.g., financial data in a spreadsheet) while leaving the rest readable.
When implementing ODF package support, pay careful attention to the ZIP archive’s end-of-central-directory (EOCD) record. Some ZIP implementations place the EOCD comment field at an unexpected offset, causing interoperability issues. Always validate against the ZIP specification (ISO/IEC 21320-1) as referenced by 26300-3.
Engineering Design Insights for ODF Package Implementation
From an engineering perspective, implementing a conformant ODF package reader or writer requires attention to several subtle details. First, the “no compression on mimetype” rule is not merely a recommendation — it is a requirement for conformance. The mimetype file must be stored (method 0) as the very first entry in the archive. Failure to observe this order will produce a valid ZIP file but a non-conformant ODF package.
Second, path normalization is critical. The manifest uses forward slashes exclusively, and all paths are relative to the package root. Implementations must resolve “.” and “..” segments and reject any path that would escape the package boundary (a classic ZIP-slip vulnerability). The standard explicitly forbids absolute paths and parent-directory traversal.
Third, the relationship between content.xml and external resources deserves careful handling. While ODF packages can reference external URIs (e.g., linked images), a conformant viewer should gracefully degrade when external resources are unavailable. The standard recommends embedding frequently used resources within the package to ensure reliable offline access.
A common security pitfall in ODF package parsing is the “manifest poisoning” attack, where the manifest declares a different MIME type than the actual file content. Always perform content-sniffing validation by checking the actual bytes of each extracted file against its declared MIME type in the manifest.
Frequently Asked Questions
Q: Can I use a different compression algorithm for ODF packages?
A: No. ISO/IEC 26300-3 mandates the use of DEFLATE compression (the standard algorithm used by ZIP) for all entries except the mimetype file. Using alternative compression algorithms would render the package non-conformant.
A: No. ISO/IEC 26300-3 mandates the use of DEFLATE compression (the standard algorithm used by ZIP) for all entries except the mimetype file. Using alternative compression algorithms would render the package non-conformant.
Q: How does ODF package handle large documents (over 4 GB)?
A: The standard supports ZIP64 extensions, enabling packages larger than 4 GB. However, the mimetype file must still be the first entry and stored uncompressed, even in ZIP64 mode.
A: The standard supports ZIP64 extensions, enabling packages larger than 4 GB. However, the mimetype file must still be the first entry and stored uncompressed, even in ZIP64 mode.
Q: Is it possible to include executable content in an ODF package?
A: The standard does not define any mechanism for executable content. ODF packages are document containers, not application bundles. Including executables would violate the security model and is strongly discouraged.
A: The standard does not define any mechanism for executable content. ODF packages are document containers, not application bundles. Including executables would violate the security model and is strongly discouraged.
