ISO/IEC 23736-4:2020

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"/>
     ...