Information technology -- Digital publishing -- EPUB 3.0.1

This specification, EPUB Open Container Format (OCF) 3.0.1, defines a file format and processing model for encapsulating the set of related resources that comprise an EPUB® Publication into a single-file container. This specification is one of a family of related specifications that compose EPUB 3, the third major revision of an interchange and delivery format for digital publications based on XML and Web Standards. It is meant to be read and understood in concert with the other specifications that make up EPUB 3: The EPUB 3 Overview [EPUB3Overview], which provides an informative overview of EPUB and a roadmap to the rest of the EPUB 3 documents. The Overview should be read first. EPUB Publications 3.0.1 [Publications301], which defines the semantics and overarching conformance requirements for each Rendition of an EPUB Publication. EPUB Content Documents 3.0.1 [ContentDocs301], which defines profiles of XHTML, SVG and CSS for use in the context of EPUB Publications. EPUB Media Overlays 3.0.1 [MediaOverlays301], which defines a format and a processing model for synchronization of text and audio. OCF is the required container technology for EPUB Publications. OCF may play a role in the following workflows: During the preparation steps in producing an EPUB Publication, OCF may be used as the container format when exchanging an in-progress EPUB Publication between different individuals and/or different organizations. When providing an EPUB Publication from publisher or conversion house to the distribution or sales channel, OCF is the recommended container format to be used as the transport format. When delivering the final EPUB Publication to an EPUB Reading System or User, OCF is the required format for the container that holds all of the assets that make up the EPUB Publication. The OCF specification defines the rules for structuring the file collection in the abstract: the "abstract container". It also defines the rules for the representation of this abstract container within a ZIP archive: the "physical container". The rules for ZIP physical containers build upon the ZIP technologies used by [ODF]. OCF also defines a standard method for obfuscating embedded resources, such as fonts, for those EPUB Publications that require this functionality. This specification supersedes Open Container Format (OCF) 3.0 [OCF30]. Refer to [EPUB3Changes] for information on differences between this specification and its predecessor.

Technologies de l'information -- Publications numériques -- EPUB 3.0.1

General Information

Status
Published
Publication Date
18-Feb-2020
Current Stage
6060 - International Standard published
Start Date
02-Jan-2020
Completion Date
19-Feb-2020
Ref Project

Buy Standard

Standard
ISO/IEC 23736-4:2020 - Information technology -- Digital publishing -- EPUB 3.0.1
English language
31 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

INTERNATIONAL ISO/IEC
STANDARD 23736-4
First edition
2020-02
Information technology — Digital
publishing — EPUB 3.0.1 —
Part 4:
Open container format
Technologies de l'information — Publications numériques — EPUB
3.0.1 —
Partie 4: Format de conteneur ouvert
Reference number
ISO/IEC 23736-4:2020(E)
ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC 23736-4:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2020

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may

be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting

on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address

below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 23736-4:2020(E)
Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical

Commission) form the specialized system for worldwide standardization. National bodies that are

members of ISO or IEC participate in the development of International Standards through technical

committees established by the respective organization to deal with particular fields of technical activity.

ISO and IEC technical committees collaborate in fields of mutual interest. Other international

organizations, governmental and non‐governmental, in liaison with ISO and IEC, also take part in the

work.

The procedures used to develop this document and those intended for its further maintenance are

described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the

different types of document should be noted (see www.iso.org/directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

Details of any patent rights identified during the development of the document will be in the

Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC

list of patent declarations received (see http://patents.iec.ch).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and

expressions related to conformity assessment, as well as information about ISO's adherence to the World

Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html.
This document was prepared by the World Wide Web Consortium (W3C) [as EPUB Open

Container Format (OCF) 3.0.1] and drafted in accordance with its editorial rules. It was adopted,

under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.

A list of all parts in the ISO/IEC 23736 series can be found on the ISO websitte.e

Any feedback or questions on this document should be directed to the user’s national standards body. A

complete listing of these bodies can be found at www.iso.org/members.html.
© ISO/IEC 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 23736-4:2020(E)
EPUB Open Container Format (OCF) 3.0.1
Recommended Specification 26 June 2014
THIS VERSION
http://www.idpf.org/epub/301/spec/epub-ocf-20140626.html
LATEST VERSION
http://www.idpf.org/epub3/latest/ocf
PREVIOUS VERSION
http://www.idpf.org/epub/301/spec/epub-ocf-20140228.html
A diff of changes from the previous version is also available.

Please refer to the errata for this document, which may include some normative corrections.

Copyright © 2010-2013 International Digital Publishing Forum™

All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and

dissemination of this work with changes is prohibited except with the written permission of the International

Digital Publishing Forum (IDPF).
EPUB is a registered trademark of the International Digital Publishing Forum.
Editors
James Pritchett, Learning Ally (formerly Recording for the Blind & Dyslexic)
Markus Gylling, International Digital Publishing Forum (IDPF)
TABLE OF CONTENTS
1. Overview
1.1. Purpose and Scope
1.2. Terminology
1.3. Typographic Conventions
1.4. Conformance Statements
1.5. Content Conformance
1.6. Reading System Conformance
2. OCF Abstract Container
2.1. Overview
2.2. File and Directory Structure
2.3. Relative IRIs for Referencing Other Components
2.4. File Names
2.5. META-INF
2.5.1. Container – META-INF/container.xml
2.5.2. Encryption – META-INF/encryption.xml
2.5.3. Manifest – META-INF/manifest.xml
2.5.4. Metadata – META-INF/metadata.xml
2.5.5. Rights Management – META-INF/rights.xml
2.5.6. Digital Signatures – META-INF/signatures.xml
3. OCF ZIP Container
© ISO/IEC 2020 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO/IEC 23736-4:2020(E)
3.1. Overview
3.2. ZIP File Requirements
3.3. OCF ZIP Container Media Type Identification
4. Resource Obfuscation
4.1. Introduction
4.2. Obfuscation Key
4.3. Obfuscation Algorithm
4.4. Specifying Obfuscated Resources
A. Schemas
A.1. Schema for container.xml
A.2. Schema for encryption.xml
A.3. Schema for signatures.xml
B. Example
C. The application/epub+zip Media Type
D. Acknowledgements and Contributors
References
› 1 Overview
› 1.1 Purpose and Scope
This section is informative

This specification, EPUB Open Container Format (OCF) 3.0.1, defines a file format and processing

model for encapsulating the set of related resources that comprise an EPUB® Publication into a

single-file container.

This specification is one of a family of related specifications that compose EPUB 3, the third major

revision of an interchange and delivery format for digital publications based on XML and Web

Standards. It is meant to be read and understood in concert with the other specifications that make up

EPUB 3:

The EPUB 3 Overview [EPUB3Overview], which provides an informative overview of EPUB and

a roadmap to the rest of the EPUB 3 documents. The Overview should be read first.

EPUB Publications 3.0.1 [Publications301], which defines the semantics and overarching

conformance requirements for each Rendition of an EPUB Publication.

EPUB Content Documents 3.0.1 [ContentDocs301], which defines profiles of XHTML, SVG and

CSS for use in the context of EPUB Publications.

EPUB Media Overlays 3.0.1 [MediaOverlays301], which defines a format and a processing

model for synchronization of text and audio.

OCF is the required container technology for EPUB Publications. OCF may play a role in the following

workflows:

During the preparation steps in producing an EPUB Publication, OCF may be used as the

container format when exchanging an in-progress EPUB Publication between different

individuals and/or different organizations.

When providing an EPUB Publication from publisher or conversion house to the distribution or

sales channel, OCF is the recommended container format to be used as the transport format.

2 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC 23736-4:2020(E)

When delivering the final EPUB Publication to an EPUB Reading System or User, OCF is the

required format for the container that holds all of the assets that make up the EPUB Publication.

The OCF specification defines the rules for structuring the file collection in the abstract: the "abstract

container". It also defines the rules for the representation of this abstract container within a ZIP

archive: the "physical container". The rules for ZIP physical containers build upon the ZIP

technologies used by [ODF]. OCF also defines a standard method for obfuscating embedded

resources, such as fonts, for those EPUB Publications that require this functionality.

This specification supersedes Open Container Format (OCF) 3.0 [OCF30]. Refer to [EPUB3Changes]

for information on differences between this specification and its predecessor.
› 1.2 Terminology
EPUB Publication

A collection of one or more Renditions conforming to this specification and its sibling

specifications , packaged in an EPUB Container.

An EPUB Publication typically represents a single intellectual or artistic work, but this

specification and its sibling specifications do not circumscribe the nature of the content.

Rendition

A logical document entity consisting of a set of interrelated resources representing one

rendering of an EPUB Publication.
Default Rendition
The Rendition listed in the first rootfile element in the container.xml file.
Publication Resource

A resource that contains content or instructions that contribute to the logic and rendering of

at least one Rendition of an EPUB Publication. In the absence of this resource, the EPUB

Publication might not render as intended by the Author. Examples of Publication Resources

include a Rendition's Package Document, EPUB Content Document, EPUB Style Sheets,

audio, video, images, embedded fonts and scripts.

With the exception of the Package Document itself, the Publication Resources required to

render a Rendition are listed in that Rendition's manifest [Publications301] and bundled in

the EPUB Container file (unless specified otherwise in Publication Resource Locations

[Publications301] ).

Examples of resources that are not Publication Resources include those identified by the

Package Document link [Publications301] element and those identified in outbound

hyperlinks that resolve outside the EPUB Container (e.g., referenced from an [HTML5] a

element href attribute).
EPUB Content Document

A Publication Resource that conforms to one of the EPUB Content Document definitions

(XHTML or SVG).

An EPUB Content Document is a Core Media Type, and may therefore be included in the

EPUB Publication without the provision of fallbacks [Publications301] .
XHTML Content Document
© ISO/IEC 2020 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO/IEC 23736-4:2020(E)
An EPUB Content Document conforming to the profile of [HTML5] defined in XHTML
Content Documents [ContentDocs301] .
XHTML Content Documents use the XHTML syntax of [HTML5].
SVG Content Document
An EPUB Content Document conforming to the constraints expressed in SVG Content
Documents [ContentDocs301] .
Core Media Type

A set of Publication Resource types for which no fallback is required. Refer to Publication

Resources [Publications301] for more information.
Package Document

A Publication Resource carrying bibliographical and structural metadata about a given

Rendition of an EPUB Publication, as defined in Package Documents [Publications301] .

Unique Identifier

The Unique Identifier is the primary identifier for an EPUB Publication, as identified by the

unique-identifier attribute. The Unique Identifier may be shared by one or many

Renditions of the same EPUB Publication that conform to the EPUB standard and embody

the same content.

The Unique Identifier is less granular than the ISBN. However, significant revision,

abridgement, etc. of the content requires a new Unique Identifier.
EPUB Style Sheet (or Style Sheet)
A CSS Style Sheet conforming to the CSS profile defined in EPUB Style Sheets
[ContentDocs301] .
Viewport

The region of an EPUB Reading System in which the content of an EPUB Publication is

rendered visually to a User.
EPUB Container (or Container)

The ZIP-based packaging and distribution format for EPUB Publications defined in OCF

ZIP Container .
OCF Processor

A software application that processes EPUB Containers according to this specification.

Root Directory

The root directory represents the base of the Abstract Container file system. This directory

is virtual in nature: a Reading System might or might not generate a physical root directory

for the contents of the Abstract Container if the contents are unzipped.
Author

The person(s) or organization responsible for the creation of an EPUB Publication, which is

not necessarily the creator of the content and resources it contains.
User
4 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 23736-4:2020(E)
An individual that consumes an EPUB Publication using an EPUB Reading System.
EPUB Reading System (or Reading System)
A system that processes EPUB Publications for presentation to a User in a manner
conformant with this specification and its sibling specifications .
› 1.3 Typographic Conventions
The following typographic conventions are used in this specification:
markup

All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine

processable values (string, characters, media types) and file names are in red-orange

monospace font.
markup

Links to markup and code definitions are underlined and in red-orange monospace font. Only

the first instance in each section is linked.
http://www.idpf.org/
URIs are in navy blue monospace font.
hyperlink
Hyperlinks are underlined and in blue.
[reference]
Normative and informative references are enclosed in square brackets.
Term
Terms defined in the Terminology are in capital case.
Term

Links to term definitions have a dotted blue underline. Only the first instance in each section is

linked.
Normative element, attribute and property definitions are in blue boxes.
Informative markup examples are in white boxes.
NOTE
Informative notes are in yellow boxes with a "Note" header.
© ISO/IEC 2020 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO/IEC 23736-4:2020(E)
CAUTION
Informative cautionary note are in red boxes with a "Caution" header.
› 1.4 Conformance Statements

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY,

and OPTIONAL in this document are to be interpreted as described in [RFC2119].

All sections of this specification are normative except where identified by the informative status label

"This section is informative". The application of informative status to sections and appendices applies

to all child content and subsections they may contain.
All examples in this specification are informative.
› 1.5 Content Conformance

An OCF Abstract Container MUST meet the conformance constraints defined in OCF Abstract

Container .

An OCF ZIP Container (also referred to as an EPUB Container) MUST meet the conformance

constraints defined in OCF ZIP Container .
› 1.6 Reading System Conformance
An EPUB Reading System MUST meet all of the following criteria:

It MUST process the OCF ZIP Container in conformance with all Reading System conformance

constraints expressed in OCF ZIP Container .

If it has a Viewport, it MUST support deobfuscation of resources as defined in Resource

Obfuscation .
› 2 OCF Abstract Container
› 2.1 Overview
This section is informative

An OCF Abstract Container defines a file system model for the contents of the container. The file

system model uses a single common Root Directory for all of the contents of the container. All (non-

remote) resources for embedded Renditions are located within the directory tree headed by the

container’s root directory, although no specific file system structure is mandated for this. The file

6 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 23736-4:2020(E)

system model also includes a mandatory directory named META-INF that is a direct child of the

container's root directory and is used to store the following special files:
container.xml [required]

Identifies the file that is the point of entry for each embedded Rendition of the EPUB

Publication.
signatures.xml [optional]
Contains digital signatures for various assets.
encryption.xml [optional]

Contains information about the encryption of Publication Resources. (This file is required when

obfuscation is used.)
metadata.xml [optional]
Used to store metadata about the EPUB Container.
rights.xml [optional]
Used to store information about digital rights.
manifest.xml [allowed]
A manifest of container contents as allowed by Open Document Format [ODF].

Complete conformance requirements for the various files in META-INF are found in META-INF.

› 2.2 File and Directory Structure

The virtual file system for the OCF Abstract Container MUST have a single common Root Directory for

all of the contents of the container.

The OCF Abstract Container MUST include a directory named META-INF that is a direct child of the

container's root directory. Requirements for the contents of this directory are described in META-INF.

The file name mimetype in the root directory is reserved for use by OCF ZIP Containers, as explained

in OCF ZIP Container .

All other files within the OCF Abstract Container MAY be in any location descendant from the

container's root directory except within the META-INF directory.

It is RECOMMENDED that the contents of the EPUB Publication be stored within its own dedicated

directory under the container's root.
› 2.3 Relative IRIs for Referencing Other Components

Files within the OCF Abstract Container MUST reference each other via Relative IRI References

([RFC3987] and [RFC3986]). For example, if a file named chapter1.html references an image file

named image1.jpg that is located in the same directory, then chapter1.html might contain the

following as part of its content:
© ISO/IEC 2020 – All rights reserved 7
---------------------- Page: 10 ----------------------
ISO/IEC 23736-4:2020(E)
…

For Relative IRI References, the Base IRI [RFC3986] is determined by the relevant language

specifications for the given file formats. For example, the CSS specification defines how relative IRI

references work in the context of CSS style sheets and property declarations. Note that some

language specifications reference RFCs that preceded RFC3987, in which case the earlier RFC

applies for content in that particular language.

Unlike most language specifications, the Base IRIs for all files within the META-INF directory use the

Root Directory for the Abstract Container as the default Base IRI. For example, if META-

INF/container.xml has the following content:

xmlns="urn:oasis:names:tc:opendocument:xmlns:container">

media-type="application/oebps-package+xml" />


then the path EPUB/Great Expectations.opf is relative to the root directory for the OCF Abstract

Container and not relative to the META-INF directory.
› 2.4 File Names

The term File Name represents the name of any type of file, either a directory or an ordinary file

within a directory within an OCF Abstract Container.

For a given directory within the OCF Abstract Container, the Path Name is a string holding all

directory File Names in the full path concatenated together with a / (U+002F) character separating the

directory File Names. For a given file within the Abstract Container, the Path Name is the string

holding all directory File Names concatenated together with a / character separating the directory File

Names, followed by a / character and then the File Name of the file.

The File Name restrictions described below are designed to allow Path Names and File Names to be

used without modification on most commonly used operating systems. This specification does not

specify how an OCF Processor that is unable to represent OCF File and Path Names would

compensate for this incompatibility.

In the context of an OCF Abstract Container, File and Path Names MUST meet all of the following

criteria:
File Names MUST be UTF-8 [Unicode] encoded.
File Names MUST NOT exceed 255 bytes.

The Path Name for any directory or file within the Abstract Container MUST NOT exceed 65535

bytes.
8 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 23736-4:2020(E)

File Names MUST NOT use the following [Unicode] characters, as these characters might not be

supported consistently across commonly-used operating systems:
SOLIDUS: / (U+002F)
QUOTATION MARK: " (U+0022)
ASTERISK: * (U+002A)
FULL STOP as the last character: . (U+002E)
COLON: : (U+003A)
LESS-THAN SIGN: < (U+003C)
GREATER-THAN SIGN: > (U+003E)
QUESTION MARK: ? (U+003F)
REVERSE SOLIDUS: \ (U+005C)
DEL (U+007F)
C0 range (U+0000 … U+001F)
C1 range (U+0080 … U+009F)
Private Use Area (U+E000 … U+F8FF)
Non characters in Arabic Presentation Forms-A (U+FDDO … U+FDEF)
Specials (U+FFF0 … U+FFFF)
Tags and Variation Selectors Supplement (U+E0000 … U+E0FFF)
Supplementary Private Use Area-A (U+F0000 … U+FFFFF)
Supplementary Private Use Area-B (U+100000 … U+10FFFF)
› File Names are case sensitive.

All File Names within the same directory MUST be unique following case normalization as

described in section 3.13 of [Unicode].
All File Names within the same directory SHOULD be unique following NFC or NFD
normalization [TR15].
NOTE

Some commercial ZIP tools do not support the full Unicode range and may support only the

ASCII range for File Names. Content creators who want to use ZIP tools that have these

restrictions may find it is best to restrict their File Names to the ASCII range. If the names of

files cannot be preserved during the unzipping process, it will be necessary to compensate for

any name translation which took place when the files are referenced by URI from within the

content.
© ISO/IEC 2020 – All rights reserved 9
---------------------- Page: 12 ----------------------
ISO/IEC 23736-4:2020(E)
› 2.5 META-INF

All OCF Abstract Containers MUST include a directory called META-INF. This directory contains the files

specified below. Files other than the ones defined below MAY be included in the META-INF directory;

OCF Processors MUST NOT fail when encountering such files.
› 2.5.1 Container ­ META-INF/container.xml

All OCF Containers MUST include a file called container.xml within the META-INF directory. The

container.xml file MUST identify the media type of, and path to, the root file for each of the Renditions

of the EPUB Publication included within the Container.
The container.xml file MUST NOT be encrypted.

The schema for container.xml files is available in Schema for container.xml ; container.xml files

MUST be valid according to this schema after removing all elements and attributes from other

namespaces (including all attributes and contents of such elements).

The rootfiles element MUST contain one or more rootfile elements, each of which MUST uniquely

reference a Package Document representing a single Rendition of an EPUB Publication. If more than

one Rendition is stored in an OCF, each MUST be a different rendering of the same EPUB Publication.

An OCF Processor MUST consider the first rootfile element within the rootfiles element to

represent the Default Rendition for the contained EPUB Publication. Reading Systems are NOT

REQUIRED to use any Rendition except the default one.

The following example shows a sample container.xml for an EPUB Publication with the root file

EPUB/My Crazy Life.opf (the Package Document):

xmlns="urn:oasis:names:tc:opendocument:xmlns:container">

media-type="application/oebps-package+xml" />


The following example shows SVG and XHTML Renditions of The Sandman bundled in the same

container:

xmlns="urn:oasis:names:tc:opendocument:xmlns:container">

media-type="application/oebps-package+xml" />
media-type="application/oebps-package+xml" />

10 © ISO/IEC 2020 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 23736-4:2020(E)

The manifest element contained within the Package Document specifies the one and only manifest

used for processing a given Rendition. Ancillary manifest information contained in the ZIP archive or

in the optional manifest.xml file MUST NOT be used for processing the Rendition. Any extra files in the

ZIP archive MUST NOT be used in the processing of the Rendition (i.e., files within the ZIP archive that

are not listed within the Package Document's manifest element, such as META-INF files or or

resources specific to other Renditions of the EPUB Publication).

The container.xml file MAY include a links element following the rootfiles element, which, when

present, MUST contain one or more link elements. Each link element MUST include an href attribute

whose value identifies the location of a resource necessary for the processing of the EPUB Container.

Each link element also MUST include a rel attribute whose value identifies the relationship of the

resource, and MAY include a media-type attribute whose value MUST be a media type [RFC2046] that

specifies the type and format of the resource referenced by the link.

The value of the rootfile element full-path attribute and the link element href attribute MUST

contain a path component (as defined by RFC3986) which MUST take the form of a path-rootless only

(also defined by RFC 3986). The path components are relative to the root of the container in which

they are used.

OCF Processors MUST ignore foreign elements and attributes within a container.xml file.

› 2.5.2 Encryption ­ META-INF/encryption.xml

An optional encryption.xml file within the META-INF directory at the root level of the container file

system holds all encryption information on the contents of the container. If any resource within the

container is encrypted, encryption.xml MUST be present to indicate that the resource is encrypted and

provide information on how it is encrypted.

This file is an XML document whose root element is encryption. The encryption element contains

child elements of type EncryptedKey and EncryptedData as defined by [XML ENC Core]. An

EncryptedKey element describes each encryption key used in the container, while an EncryptedData

element describes each encrypted file. Each EncryptedData element refers to an EncryptedKey

element, as described in XML Encryption.

The schema for encryption.xml files is available in Schema for encryption.xml ; encryption.xml files

MUST be valid according to this schema.

OCF encrypts individual files independently, trading off some security for improved performance,

allowing the container contents to be incrementally decrypted. Encryption in this way exposes the

directory structure and file naming of the whole package.

OCF uses XML Encryption [XML ENC Core] to provide a framework for encryption, allowing a variety

of algorithms to be used. XML Encryption specifies a process for encrypting arbitrary data and

representing the result in XML. Even though an OCF Abstract Container may contain non-XML data,

XML Encryption can be used to encrypt all data in an OCF Abstract Container. OCF encryption

supports only the encryption of entire files within the container, not parts of files. The encryption.xml

file, if present, MUST NOT be encrypted.

Encrypted data replaces unencrypted data in an OCF Abstract Container. For example, if an image

named photo.jpeg is encrypted, the contents of the photo.jpeg resource SHOULD be replaced by its

© ISO/IEC 2020 – All rights reserved 11
---------------------- Page: 14 ----------------------
ISO/IEC 23736-4:2020(E)

encrypted contents. When stored in a ZIP container, streams of data MUST be compressed before they

are encrypted and Deflate compression MUST be used. Within the ZIP directory, encrypted files SHOULD

be stored rather than Deflate-compressed.

Note that some situations require obfuscating the storage of embedded resources referenced by a

Rendition to tie them to the "parent" EPUB Publication and make them more difficult to extract for

unrestricted use (e.g., fonts). Although obfuscation is not encryption, the encryption.xml file is used

in conjunction with the IDPF resource obfuscation algorithm to identify resources that need to be de-

obfuscated before they can be used.

The following files MUST NOT be encrypted, regardless of whether default or specific encryption is

requested:
mimetype
META-INF/container.xml
META-INF/encryption.xml
META-INF/manifest.xml
META-INF/metadata.xml
META-INF/rights.xml
META-INF/signatures.xml
EPUB rootfile (the Package Document)

Signed resources MAY subsequently be encrypted using the Decryption Transform for XML Signature

[XML SIG Decrypt]. This feature enables an application such as an OCF agent to distinguish data that

was encrypted before signing from data that was encrypted after signing. Only data that was

encrypted after signing MUST be decrypted before computing the digest used to validate the signature.

In the following example, adapted from Section 2.2.1 of [XML ENC Core] the resource image.jpeg is

encrypted using a symmetric key algorithm (AES) and the symmetric key is further encrypted using an

asymmetric key algorithm (RSA) with a key of John Smith.
xmlns ="urn:oasis:names:tc:opendocument:xmlns:container"
xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.