EPUB Open Container Format (OCF) 3.1（日本語訳版）

要約

この仕様、EPUB Open Container Format (OCF) 3.1 は、単一のファイルコンテナに関連するリソースのセットをカプセル化するためのファイルフォーマットと処理モデルを定義する。

3. OCF 抽象コンテナ

3.1 導入

このセクションは規定ではない。

OCF 抽象コンテナのファイルシステムのモデルは、コンテンツのすべてに単一で共通のルートディレクトリを使用する。EPUB 出版物の全てのローカルリソースは、ルートディレクトリを先頭にしてディレクトリツリー内に配置されるが、この仕様によって強制される、それらのための特定のファイルシステム構造はない。

ファイルシステムのモデルは、ルートディレクトリの直接の子で、以下の特別なファイルを補完するに利用する META-INF という名前の必須ディレクトリを包含する。

container.xml [必須]: EPUB 出版物の各レンディションを定義するパッケージドキュメントを識別する。
signatures.xml [省略可]: 様々な資産のためのデジタル署名が含まれている。
encryption.xml [省略可]: 出版物リソースの暗号化に関する情報が含まれている。このファイルは、難読化をするとき、必須である。
metadata.xml [省略可]: OCF ZIP コンテナに関するメタデータを格納するために使用する。
rights.xml [省略可]: デジタル著作権に関する情報を格納するために使用する。
manifest.xml [省略可]: オープンドキュメントフォーマット [ODF] によって許可されるコンテナコンテンツのマニフェスト。

META-INF ディレクトリの各ファイルのための適合性要件は、META-INF ディレクトリで定義されている。

3.2 ファイルとディレクトリの構造

OCF 抽象コンテナのための仮想ファイルシステムは、コンテナのコンテンツのすべてに単一の共通のルートディレクトリを持たなければならない（MUST）。

OCF 抽象コンテナは、コンテナのルートディレクトリの直接の子である META-INF という名前のディレクトリを包含しなければならない（MUST）。このディレクトリのコンテンツのための要件は、META-INF ディレクトリに記載されている。

ルートディレクトリにあるファイル名の mimetype は、OCF ZIP コンテナで説明されているとおり、OCF ZIP コンテナによって使用するために予約済みである。

OCF 抽象コンテナ内の他の全てのファイルは、META-INF ディレクトリ内に存在せず提供され、ルートディレクトリから任意の場所の子孫でもよい（MAY）。

EPUB 出版物のコンテンツは、ルートディレクトリ配下の専用のディレクトリに格納されることを推奨する（RECOMMENDED）。

3.3 他のコンポーネントを参照するための相対 IRI

OCF 抽象コンテナ内のファイルは、相対 IRI 参照（[RFC3987] と [RFC3986]）経由して相互に参照しなければならない（MUST）。

次の例は、XHTML コンテンツドキュメントと同じディレクトリにあるファイル名 image1.jpg が、どのように [HTML] の img 要素から参照されるかを示している。

<img src="image1.jpg" alt="…" />

相対 IRI 参照は、ベース IRI [RFC3986] に与えられたファイル形式に関連のある言語仕様によって決定される。例えば、CSS は、CSS スタイルシートとプロパティ宣言 [CSS Snapshot] のコンテクストでどのように相対 IRI 参照が動作するのかを定義する。

Note

いくつかの言語仕様は、先行する [RFC3987] のリクエストフォーコメンツ [RFC] を参照し、その場合、以前の RFC は、特定の言語でコンテンツに適用される。

ほとんどの言語仕様とは異なり、META-INF ディレクトリ内の全てのファイルのためのベース IRI は、初期設定のベース IRI としてOCF 抽象コンテナのルートディレクトリを使用する。

例えば、META-INF/container.xml が以下の内容の場合：

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="EPUB/Great_Expectations.opf"
media-type="application/oebps-package+xml" />	
</rootfiles>
</container>

この場合、EPUB/Great Expectations.opf のパスは OCF 抽象コンテナのためのルートディレクトリから相対であり、META-INF ディレクトリからの相対ではない。

全ての相対 IRI 参照は、OCF 抽象コンテナ内のリソース（すなわち、ルートディレクトリ以下）を解決しなければならない（MUST）。

3.4 ファイル名

このセクションで説明されたファイル名の制約は、最も一般的に使用されているオペレーティングシステム上で変更なしに使用されているパス名とファイル名を考慮にいれて設計されている。本仕様書は、OCF ファイルとパス名を表すことのできない OCF プロセッサの相互互換性を補う方法を指定しない。

OCF 抽象コンテナのコンテクストでは、ファイル名とパス名の大小文字を区別し、次の基準を満たさなければならない（MUST）：

ファイル名は、UTF-8 [Unicode] でエンコードしなければならない（MUST）。
ファイル名は、255バイトを超えてはならない（MUST NOT）。
OCF 抽象コンテナ内の任意のディレクトリまたはファイルのパス名は、65,535バイトを超えてはならない（MUST NOT）。
ファイル名は、これらの文字は、一般的に使用されるオペレーティング・システムの間で一貫してサポートされない場合があり、以下の [Unicode] は使用してはならない（MUST NOT）：
- スラッシュ: / (U+002F )
- クォーテーションマーク: " (U+0022 )
- アスタリスク: * (U+002A )
- ピリオド: . (U+002E )
- コロン: : (U+003A )
- 小なり記号: < (U+003C )
- 大なり記号: > (U+003E )
- クエスチョンマーク: ? (U+003F )
- バックスラッシュ: \ (U+005C )
- DEL (U+007F )
- C0 領域 (U+0000 … U+001F )
- C1 領域 (U+0080 … U+009F )
- 私用領域 (U+E000 … U+F8FF )
- アラビア表示形 A の非文字 (U+FDDO … U+FDEF )
- 特殊用途文字 (U+FFF0 … U+FFFF )
- タグと異体字セレクタ補助 (U+E0000 … U+E0FFF )
- 補助私用領域A (U+F0000 … U+FFFFF )
- 補助私用領域B (U+100000 … U+10FFFF )
同じディレクトリ内にあるすべてのファイル名は、[Unicode] のセクション 3.13 で定義されているような正規化のケースに従い一意でなければならない（MUST）。
同じディレクトリ内にあるすべてのファイル名は、NFC または NFD の正規化 [TR15] に従い一意であるべきである（SHOULD）。

Note

いくつかの商用 ZIP ツールは、完全な Unicode の範囲をサポートしておらず、ファイル名のみ [US-ASCII] の範囲のみサポートするかもしれない。これらの制限を持つ ZIP ツールを使うことを望む製作者は、[US-ASCII] 範囲にこれらのファイル名を制限することが最善であることに気づくだろう。ファイルの名前は、解凍処理の中に保存することができない場合、そのファイルはコンテンツ内のURIにより参照されるときに行われた任意の名前に変換を相殺する必要がある。

3.5 META-INF ディレクトリ

3.5.1 導入

全ての OCF 抽象コンテナは、それらのルートディレクトリに META-INF と呼ばれるディレクトリを包含しなければならない（MUST）。

このディレクトリは、META-INF 予約済みファイルで指定されたファイルを含む。そのセクションに記載されているもの以外のファイルは、META-INF ディレクトリに包含されてもよい（MAY）。このようなファイルに遭遇したとき、OCF プロセッサは、機能しなくなってはならない（MUST NOT）。

3.5.2 予約済みファイル

3.5.2.1 コンテナファイル (container.xml)

META-INF ディレクトリにある必須の container.xml ファイルは、OCF 抽象コンテナの EPUB パッケージを識別する。

このファイルのコンテンツは、（このような要素のすべての属性と内容を含む）他の名前空間から全ての要素と属性を取り除いた後に、container.xml のスキーマにあるスキーマに妥当でなければならない（MUST）。

各 rootfile 要素は、EPUB 出版物のひとつのレンディションを表しているパッケージドキュメントの配置を特定しなければならない（MUST）。

OCF プロセッサは、含まれている EPUB 出版物の初期設定のレンダリングを表現するために rootfiles 要素内の最初の rootfile 要素を考慮しなければならない（MUST）。リーディングシステムは、初期設定のレンディションの表示は必須（REQUIRED）だが、コンテナ内の他のレンディションを表示してもよい（MAY）。

以下のサンプルは、ルートファイルの EPUB/My Crazy Life.opf（パッケージドキュメント）を持つ EPUB 出版物のためのサンプル container.xml を示している：

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="EPUB/My_Crazy_Life.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</container>

以下のサンプルは、同じコンテナ内にバンドルされている SVG と XHTMLのレンディションを示している：

<?xml version="1.0"?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<rootfiles>
<rootfile full-path="SVG/Sandman.opf"
media-type="application/oebps-package+xml" />
<rootfile full-path="XHTML/Sandman.opf"
media-type="application/oebps-package+xml" />
</rootfiles>
</container>

省略可能（OPTIONAL）な links 要素は、OCF ZIP コンテナの処理に必要なリソースを識別する。その子 link 要素のそれぞれは、値が、リソースの配置を識別する href 属性を包含しなければならない（MUST）。各 link 要素は、値が、リソースの関係性を識別する rel 属性もまた包含しなければならず（MUST）、値が、link によって参照されたリソースの種類と形式を指定するメディアタイプ [RFC2046] でなければならない（MUST） media-type 属性を包含してもよい（MAY）。

rootfile 要素の full-path 属性と link 要素の href 属性の値は、path component [RFC3986] を含まなければならなず（MUST）、要は、path-rootless [RFC3986] の形式のみから得なければならない（MUST）。path component は、ルートディレクトリに相対的である。

OCF プロセッサは、container.xml ファイル内にある外部の要素と属性を無視しなければならない（MUST）。

3.5.2.2 暗号化ファイル (encryption.xml)

META-INF ディレクトリ内にある省略可能（OPTIONAL）な encryption.xml ファイルは、コンテナのコンテンツの全ての暗号化情報を保持する。コンテナ内の任意のリソースが暗号化されているとき、encryption.xml は、リソースが暗号化されていることを示し、暗号化されている方法の情報を提供するために存在していなければならない（MUST）。

このファイルは、ルート要素の encryption の XML 文書である。encryption 要素は、[XML ENC Core] で定義されている EncryptedKey と EncryptedData 型の子要素を含む。EncryptedKey 要素が、暗号化された各ファイルを説明するのと同時に、EncryptedData 要素は、コンテナ内で使用される各暗号化キーを説明する。各 EncryptedData 要素は、XML Encryption で説明されているように、EncryptedKey 要素を参照する。

encryption.xml ファイルのコンテンツは、encryption.xml のスキーマのスキーマに妥当でなければならない（MUST）。

OCF は、独立して個々のファイルを暗号化し、これらはセキュリティとパフォーマンスのトレードオフだが、コンテナのコンテンツは一つ一つ復号化される。この方法による暗号化は、パッケージ全体のディレクトリの構造とファイルの命名を公開する。

OCF は、様々なアルゴリズムを使用できるように、暗号化のフレームワークを提供する XML Encryption [XML ENC Core] を使用する。XML Encryption は、任意のデータを暗号化し、結果を XML で表現するための処理を規定している。OCF 抽象コンテナは、非 XML データが含まれてもよく、XML Encryption は、OCF 抽象コンテナに含まれるすべてのデータを暗号化するために使用できる。OCF 暗号化は、コンテナ内のファイル全体のみをサポートし、ファイルの一部の暗号化はサポートしない。encryption.xml ファイルは、もし存在するなら、暗号化はしてはならない（MUST NOT）。

暗号化データは、OCF 抽象コンテナ内の非暗号化データを置き換える。例えば、photo.jpeg という名前の画像が暗号化されているとき、photo.jpeg リソースのコンテンツは、その暗号化されたコンテンツにより置き換えられるべきである（SHOULD）。ZIP ディレクトリ内では、暗号化されたフィルは、デフレートで圧縮するよりは、むしろ格納するべきである（SHOULD）。

状況によっては、"親" の EPUB 出版物に繋ぎ、（例えば、フォントなどを）無制限に使用するための抽出をより困難にするために、レンディションによって参照される埋め込みリソースのストレージを難読化する必要があることに注意されたい。難読化は暗号化ではないので、encryption.xml ファイルは、それらを使用する前に、難読化解除に必要なリソースを識別するために IDPF リソース難読化アルゴリズムと共に使用される。

以下のファイルは、初期設定か特定の暗号化が求められているかどうかに関わらず暗号化してはならない（MUST NOT）：

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

パッケージドキュメント

署名済みリソースは、続けて XML 署名復号変換 [XML SIG Decrypt] を使用して暗号化してもよい（MAY）。この機能は、例えば署名後に暗号化したデータから署名する前に暗号化されたデータを識別する OCF エージェントなどのアプリケーションを可能にする。署名後に暗号化されたデータのみ、署名を検証するために使用する要約を計算する前に複合しなければならない（MUST）。

次の例では、[XML ENC Core] のセクション 2.2.1 から適合したリソース image.jpeg は、対象鍵アルゴリズム (AES) を使用する暗号化と、対象鍵は、ジョン・スミスのキーを持つ非対称鍵アルゴリズム (RSA) を使用してさらに暗号化される。

<encryption
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#">
<enc:EncryptedKey Id="EK">
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo>
<ds:KeyName>John Smith</ds:KeyName>
</ds:KeyInfo>
<enc:CipherData>
<enc:CipherValue>xyzabc</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedKey>
<enc:EncryptedData Id="ED1">
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
<ds:KeyInfo>
<ds:RetrievalMethod URI="#EK"
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
</ds:KeyInfo>
<enc:CipherData>
<enc:CipherReference URI="image.jpeg"/>
</enc:CipherData>
</enc:EncryptedData>
</encryption>

圧縮と暗号化の順番

ZIP コンテナに格納されているとき、非コーデックのコンテンツタイプであるデータのストリームは、それらが圧縮される前に暗号化されるべきで（SHOULD）、デフレート圧縮が使用されなければならない（MUST）。この方法は、ZIP コンテナに格納されるファイルエントリが小さなサイズであることを保証する。

コーデックのコンテンツタイプであるデータのストリームは、それらが暗号化される前に圧縮されるべきではない（SHOULD NOT）。このような場合、追加の圧縮は、（特に大きなリソースファイルを含む）制作時におけるオーバーヘッドの不要な処理を取り込むだろうし、消費時における音声/動画の再生パフォーマンスに影響を与えるであろう。場合によっては、いくつかの暗号化スキームを伴う圧縮の組み合わせは、（例えば、HTTP Content-Length header など）メディアの再生に先んじて完全なリソースの長さを決定することが技術的に不可能なために、（例えば、HTTP byte ranges など）部分的なコンテンツの要求を処理するリーディングシステムの能力を損なうかもしれない

暗号化する前に圧縮されたデータのストリームは、次で定義されている Compression XML 要素に従って、初期リソースのサイズ（すなわち、圧縮と暗号化する前）を指定する、追加の EncryptionProperties メタデータを提供するべきである（SHOULD）。暗号化する前に圧縮されていないデータのストリームは、初期リソースのサイズ（すなわち、暗号化する前）を指定する、追加の EncryptionProperties メタデータを提供してもよい（MAY）。

要素名

Compression

名前空間

http://www.idpf.org/2016/encryption#compression

使用例

省略可能（OPTIONAL）な EncryptionProperty の子。

属性

Method [必須（required）]

使用している圧縮方法を識別する。

値は、「0」（非圧縮）かそれとも「8」（デフレートアルゴリズム）である。

OriginalLength [必須（required）]

初期リソースのサイズ（バイト数）を表す。

値は、正の整数である。

コンテンツモデル

空

次の例は、デフレート圧縮され、元のサイズが 3500000 バイトの MP4 ファイルを示している。

<encryption xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
        ...
<enc:CipherData>
<enc:CipherReference URI="OEPBS/video.mp4"/>
</enc:CipherData>
<enc:EncryptionProperties>
<enc:EncryptionProperty xmlns:ns="http://www.idpf.org/2016/encryption#compression">
<ns:Compression Method="8" OriginalLength="3500000"/>
</enc:EncryptionProperty>
</enc:EncryptionProperties>
        ...
</enc:EncryptedData>
</encryption>

3.5.2.3 マニフェストファイル (manifest.xml)

META-INF ディレクトリの省略可能（OPTIONAL）な manifest.xml ファイルは、コンテナ内にあるファイルのマニフェストを提供する。

OCF 仕様は、マニフェストにメタデータ形式を指定しない。

パッケージドキュメントに含まれる manifest 要素は、規定のレンディションを処理するために使用される、ただひとつのマニフェストを識別することに注意されたい。ZIP アーカイブもしくは省略可能（OPTIONAL）な manifest.xml に含まれている補助的なマニフェスト情報は、レンディションを処理するために使用してはならない（MUST NOT）。

3.5.2.4 メタデータファイル (metadata.xml)

META-INF ディレクトリに省略可能（OPTIONAL）な META-INF/metadata.xml ファイルが、もし存在するなら、コンテナレベルのメタデータのために使用しなければならない（MUST）。

metadata.xml ファイルが存在するとき、そのコンテンツは、名前空間で装飾された要素 [XMLNS] のみにするべきである（SHOULD）。ファイルは、名前空間 http://www.idpf.org/2013/metadata のルート要素 metadata を含むべきだが（SHOULD）、他のルート要素は、後方互換性のために許可する。リーディングシステムは、認識されていないルート要素を持つ metadata.xml ファイルを無視するべきである（SHOULD）。

OCF 仕様のこのバージョンは、metadata.xml ファイルで使用するためのメタデータを定義しない。コンテナレベルのメタデータは、この仕様の将来のバージョンと IDPF が定義する EPUB 拡張仕様で定義してもよい（MAY）。

3.5.2.5 著作権管理ファイル (rights.xml)

META-INF ディレクトリの省略可能（OPTIONAL）な rights.xml ファイルは、権利者、仲介者、そして利用者の間で EPUB 出版物の交換のための信頼できるデジタル著作権管理 (DRM) 情報のために予約されている。

OCF 仕様のこのバージョンでは、DRM 情報に特定の形式を要求しないが、将来のバージョンでは、そうするかもしれない。rights.xml ファイルのコンテンツは、将来の形式との衝突を回避するために、名前空間で装飾された要素 [XMLNS] のみにするべきである（SHOULD）。

rights.xml ファイルが存在しないとき、コンテナの何れの部分も、コンテナレベルで管理される権利はない。権利の表現は、含まれているレンディション内に存在するかもしれない。

rights.xml ファイルが存在しない場合、OCF 抽象コンテナのいかなる部分も権利に抑制されない。

3.5.2.6 電子署名ファイル (signatures.xml)

META-INF ディレクトリ内の省略可能（OPTIONAL）な signatures.xml ファイルは、コンテナとコンテンツのための電子署名を保持する。このファイルのコンテンツは、signatures.xml のスキーマのスキーマに妥当でなければならない（MUST）。

signatures.xml ファイルのルート要素は、signatures 要素である。この要素は、[XML DSIG Core] で定義されているように Signature 型の子要素を含んでいる。署名は、全体または部分的に、EPUB 出版物へ適用でき、（XML だけでなく）あらゆる種類のデータの署名を特定することができる。

signatures.xml ファイルが存在しないとき、コンテナのいかなる部分もコンテナレベルで電子的に署名されていない。電子署名は、EPUB 出版物内に存在するかもしれない。

データの署名がコンテナのために作られるとき、署名は、signatures 要素の最後の子 Signature 要素として追加されるべきである（SHOULD）。

Note

signatures.xml ファイルの各 Signature は、[XML DSIG Core] の Manifest 要素とその Reference サブ要素を使用して、IRI の署名が適用されるデータによって識別される。単一で含まれるファイルは、個々にまたは統合して署名されるかもしれない。個々に署名された各ファイルは、独立して検証できるリソースのダイジェスト値が作られる。このアプローチでは、署名の要素が大きくなってもよい。ファイルが統合して署名されるとき、署名されたファイルのセットは、単一の XML 署名の Manifest 要素のリスト化され、一つ以上の Signature 要素によって参照することができる。

コンテナの任意または全てのファイルは、計算された署名情報を含んでいる signatures.xml ファイルを除外して、全体を署名することができる。signatures.xml ファイルを署名するべきか、またその署名方法は、署名者の目的に依存する。

署名者が、署名者の署名を無効にせずにコンテナに署名を追加したり削除したりできるようにしたい場合は、signatures.xml ファイルに署名するべきではない（SHOULD NOT）。

署名者が、署名の任意の追加または削除をしたときに署名者の署名を無効にしたい場合は、[XML DSIG Core] のセクション 6.6.4 で定義されているエンベロープ署名変換を作成済みの Signature を除いた全体の既存の署名ファイルに署名するために使用することができる。この変換は、既存の全ての署名を署名できるだろうが、パッケージに後で署名が追加されると無効になる。

Note

署名者が、既存の署名の削除時に署名者の署名を無効にしたいが、署名の追加は許したいとき、既存の署名を署名するのに XPath 変換を使用することができる。しかしながら、このような変換の詳細は、この仕様の範囲外である。

[XML DSIG Core] 仕様は、署名に任意のセマンティクスを紐付けないが、エージェントが、例えば、署名を表現する Signature 要素に情報を加えることにより、セマンティクスな情報を包含してもよい（MAY）。[XML DSIG Core] 仕様は、（例えば、SignatureProperties 要素を使うことによって）追加情報を署名に追加する方法を説明する。

以下の XML 表現は、signatures.xml フィルの例のコンテンツを示し、[XML DSIG Core] のセクションで見つかるサンプルを基にしている。それはコンテナに、一つの署名を含んでおり、署名は、EPUB/book.xhtml と EPUB/images/cover.jpeg の二つのリソースに提供される。

<signatures xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
<Signature Id="sig" xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod 
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="#Manifest1">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>…</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>…</P><Q>…</Q><G>…</G><Y>…</Y> 
</DSAKeyValue>
</KeyValue>
</KeyInfo>
<Object>
<Manifest Id="Manifest1">
<Reference URI="EPUB/book.xhtml">                    
<Transforms>                                                
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>                        
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue></DigestValue>
</Reference>
<Reference URI="EPUB/images/cover.jpeg">
<Transforms>                                                
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>                        
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue></DigestValue>
</Reference>
</Manifest>
</Object>
</Signature> 
</signatures>

5. リソース難読化

5.1 導入

このセクションは規定ではない。

OCF ZIP コンテナは、基本的に ZIP ファイルなので、一般的に入手可能な ZIP ツールを、パッケージから任意の非暗号化したコンテンツストリームを抽出するのに使用できる。また、ZIP ファイルの性質は、その内容が一部のシステム上の任意の他のネイティブコンテナ（例えば、フォルダなど）に表示されるかもしれないことを意味する。

この ZIP ファイルの単純さは非常に便利だが、それはまたリソースを抽出する容易さは、暗号化していないリソースの予期しない副作用の問題を引き起こす。サードパーティ製フォントの包含したい製作者は、例えば、典型的にフォントが他人によって抽出され再利用されるのを望まない。より重要なことは、多くの商業フォントは埋め込みを許可しているが、フォントの埋め込むことは、単にコンテンツと一緒にオリジナルのフォントファイルを提供せず、出版物の重要な部分を形成していることを意味する。

統合された ZIP のサポートは、モダンなオペレーティングシステムに偏在しおり、ZIP アーカイブ内に単純に配置したフォントは、他のコンテクストで再利用されることは意図しないフォントであることを意味するには不十分である。この不確定要素は、他の非常に便利な EPUB 出版物のフォント埋め込みの機能を弱めることができる。

フォントの再利用を防ぐために、多くのフォントベンダーは、もしそれらのフォントが、出版物に何らかの方法で固定化されている場合、EPUB 出版物内のこれらのフォントの使用のみ許可するかもしれない。フォントファイルが、コンピュータデバイスの組み込みツールを使ってオペレーショングシステム上で使用するため直接インストールできないならば、他の EPUB 出版物によって直接使用することはできない。

そのようなリソースのためのデジタル著作権管理や施工システムを提供することはこの仕様の範囲を超える。このセクションは、任意の難読化したリソースへの一般的なアクセスを得るための最終的な OCF 受容者側の追加の作業として必要になる難読化の方法を定義する。

この仕様や IDPF によって作られた要求ではなく、これが暗号化を構成するわけでも、リソースが著作権侵害から安全であることを保証するわけでもないことに注意されたい。しかしながら、このアルゴリズムが、コンテナを解凍することによってそれらのリソースを簡単に抽出できないようにするいくつかの保証を求める多くのベンダーの要求を満たすであろうというのが IDPF の期待である。

フォントの場合、暗号化のための主要なユースケースは、定義されたメカニズムは、ライセンスの詳細に気付いていない人に障害を提供する。これは、フォントへの完全なアクセスを得ようと考えているユーザーは防げないだろう。OCF コンテナが提供されると、RAW フォントファイルを抽出するために定義したアルゴリズムを適応することが可能である。難読化のこの方法は、個々のフォントライセンスの要件を満たすかどうかに関わらず、使用許諾者や被許諾者の課題が残る。

5.2 難読化キー

難読化アルゴリズムに用いられるキーは、初期設定のレンディションの一意識別子から得られる。

XML 1.0 仕様書のセクション 2.3 [XML] によって定義されている、全ての空白文字、具体的には Unicode コードポイント U+0020 、U+0009、U+000D と U+000A は、この識別子から削除されなければならない（MUST）。

結果として生じる文字列の UTF-8 表現の SHA-1 ダイジェストは、Secure Hash Standard [SHA-1] で規定されているように生成するべきである（should）。このダイジェストは、その後、アルゴリズムのためのキーとして直接使用される。

5.3 難読化アルゴリズム

アルゴリズムは、リソースを難読化するために、ファイルの最初の 1,040 バイト (~1KB) の変更から成る。万一、ファイルが 1,040 バイトに満たない場合、ファイル全体が変更される。

元データを難読化するのに、RAW ファイルの最初のバイトと難読化キーの最初のバイトの排他的論理和（XOR）の計算の結果は、埋め込まれたリソースの最初のバイトとして格納される。

この処理は、ソースとキーの次のバイトで繰り返され、キー内の全てのバイトが使用されるまで続く。ここで、キーの最初のバイトとソースの 21 バイト目から処理が始まり継続する。1,040 バイトがこの方法で（またはソースの終わりに到達して）エンコードされたら、ソース内の残りのデータは、格納先に直接コピーされる。

リソースの難読化は、それらが圧縮または OCF コンテナに追加される前に生じなければならない（MUST）。難読化は暗号化ではなく、この要件は、それらを暗号化する前にリソースを圧縮する暗号化ファイル (encryption.xml)のひとつに違反しないことに注意されたい。

次の擬似コードは、難読化アルゴリズムを示している。

set ocf to OCF container file
set source to file
set destination to obfuscated file
set keyData to key for file
set outer to 0
while outer < 52 and not (source at EOF)
    set inner to 0
while inner < 20 and not (source at EOF)
        read 1 byte from source     //Assumes read advances file position
        set sourceByte to result of read
        set keyByte to byte inner of keyData
        set obfuscatedByte to (sourceByte XOR keyByte)
        write obfuscatedByte to destination
        increment inner
end while
    increment outer
end while
if not (source at EOF) then
    read source to EOF
    write result of read to destination
end if
Deflate destination
store destination as source in ocf

元のフォントデータを得るには、処理は単純に逆になり、ソースファイルは、難読化データと RAW データが格納されている格納先のファイルからなる。

Note

フォントの難読化は、EPUB 3.0.1 で先行して許可されるが、難読化と圧縮の順序は指定しない。その結果、無効なフォントは、圧縮解除と難読化解除の後に遭遇するであろう。このような場合、伸張する前の難読化解除データは、妥当なフォントを返すかもしれない。この仕様のこのバージョンで対応していないので、この仕様は、この復旧方法のサポートを要求しないが、一般的には EPUB 3 コンテンツをサポートするときに考慮する必要がある。

5.4 難読化されたリソースの指定

すべての難読化リソースは、技術的には暗号化データではないけれど、EPUB 出版物に添付する encryption.xml ファイル（暗号化ファイル (encryption.xml)を参照）に記入しなければならない（MUST）。

EncryptionMethod 要素は、各難読化リソースのために包含されなければならない（MUST）。それぞれが、値に http://www.idpf.org/2008/embedding を設定された Algorithm 属性を EncryptedData 要素の子に包含しなければならない（MUST）。この属性の存在は、本仕様書に記載されているアルゴリズムの使用を示している。難読化リソースへのパスは、CipherData 要素の子の CipherReference に記載しなければならない（MUST）。

次の例は、encryption.xml ファイル内の難読化フォントのためのエントリーを示している。

<encryption 
xmlns="urn:oasis:names:tc:opendocument:xmlns:container" 
xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
<enc:EncryptedData> 
<enc:EncryptionMethod Algorithm="http://www.idpf.org/2008/embedding"/> 
<enc:CipherData> 
<enc:CipherReference URI="EPUB/Fonts/BKANT.TTF"/>  
</enc:CipherData> 
</enc:EncryptedData>  
</encryption>

他の EPUB 出版物へ埋め込みリソースのささいな複製を防ぐために、難読化キーを、encryption.xml ファイルに提供してはならない（MUST NOT）。

要約

このドキュメントのステータス

1. 概要

1.1 目的とスコープ

1.2 用語

1.3 適合性宣言

2. OCF 適合性

2.1 コンテナの適合性

2.2 リーディング システムの適合性

3. OCF 抽象コンテナ

3.1 導入

3.2 ファイルとディレクトリの構造

3.3 他のコンポーネントを参照するための相対 IRI

3.4 ファイル名

3.5 META-INF ディレクトリ

3.5.1 導入

3.5.2 予約済みファイル

3.5.2.1 コンテナ ファイル (container.xml)

3.5.2.2 暗号化ファイル (encryption.xml)

圧縮と暗号化の順番

3.5.2.3 マニフェスト ファイル (manifest.xml)

3.5.2.4 メタデータ ファイル (metadata.xml)

3.5.2.5 著作権管理ファイル (rights.xml)

3.5.2.6 電子署名ファイル (signatures.xml)

4. OCF ZIP コンテナ

4.1 導入

4.2 ZIP ファイルの要件

4.3 OCF ZIP コンテナのメディア タイプの識別

5. リソース難読化

5.1 導入

5.2 難読化キー

5.3 難読化アルゴリズム

5.4 難読化されたリソースの指定

A. 補足 A. スキーマ

A.1 container.xml のスキーマ

A.2 encryption.xml のスキーマ

A.3 signatures.xml のスキーマ

B. 補足 B. 用例

C. 補足 C. application/epub+zip メディア タイプ

D. 謝辞と貢献者

IDPF Members

Invited Experts/Observers

E. 参照・参考

E.1 参照文献

E.2 参考文献

2.2 リーディングシステムの適合性

3.5.2.1 コンテナファイル (container.xml)

3.5.2.3 マニフェストファイル (manifest.xml)

3.5.2.4 メタデータファイル (metadata.xml)

4.3 OCF ZIP コンテナのメディアタイプの識別

C. 補足 C. application/epub+zip メディアタイプ