Translation:Encryption

From IDMLWiki

1.9　暗号化

UCFでの暗号化のサポートは仕様の将来の改正まで延期されました。 下記に示す例外を除いて、この仕様はOCF仕様と一致するでしょう。 例外は、特別のアルゴリズムが暗号化の前にデータのFlate圧縮を要求しないと明示可能であることです。

コンテナーファイルシステムのルートレベルの「META-INF」ディレクトリ内の任意の（OPTIONAL）「encryption.xml」ファイルは、コンテナーのコンテンツの暗号化情報をすべて保持します。 このファイルはそのルートエレメントが<encryption>であるXMLドキュメントです。 XML Encryption Syntax and Processingによって定義されている通り、<encryption>エレメントは <EncryptedKey>と<EncryptedData>の子要素を含んでいます。 各EncryptedKeyエレメントは1個以上のコンテナファイルがどのように暗号化されているかを説明します。 従って、コンテナの中の何かリソースが暗号化されているなら、「encryption.xml」は暗号化しているリソースを示し、それがどう暗号化されているのかを提供しなければなりません（MUST）。

<EncryptedKey>エレメントはコンテナで使用されるそれぞれの暗号化キーについて説明しますが、<EncryptedData>エレメントはそれぞれの暗号化されたファイルについて説明します。 XML暗号化に記述されるように、各<EncryptedData>エレメントは<EncryptedKey>エレメントを参照します。 付録Aで説明したとおり、RELAX NG UCFスキーマでは、<encryption>エレメントはencryption.xmlのルートエレメントでなければなりません（MUST）。

encryption.xmlファイルが存在しない場合、UCFコンテナーはコンテナーのどんな部分が暗号化されるかを示す情報を提供しません。

コンテナコンテンツを漸増的に解読可能にし、性能の向上とセキュリティのトレードオフの中で、UCFは独自に個々のファイルを暗号化します。 この方法での暗号化は、全体のパッケージを指定するディレクトリ構造およびファイルを暴露しています。

UCFは、様々なアルゴリズムを使用可能にして、暗号化フレームワークを供給するためにXML暗号化を使用します。 XML暗号化は、任意のデータを暗号化し、XMLの中で結果を表わす過程を指定します。

UCFコンテナは非XMLデータを含むかもしれません（MAY）が、UCFコンテナのすべてのデータを暗号化するのにXML暗号化を使用できます。 UCF暗号化は全体のファイルの暗号化だけをサポートします。 encryption.xmlファイルは暗号化してはなりません（MUST NOT）。

UCFコンテナの非暗号化データを暗号化データに置き換えます。 例えば、"photo.jpeg"というイメージを暗号化しているなら、photo.jpegリソースのコンテンツを暗号化されたコンテンツに取り替えるべきです（SHOULD）。 Zipコンテナーに格納された時、暗号化される前にファイルを圧縮しなければなりません（Flate圧縮を使用しなければなりません（MUST））。 Zipローカルファイルヘッダーと主要なディレクトリ内では、暗号化ファイルはFlate圧縮ではなく、ファイルは格納されるようにリストされるべきです（SHOULD）。

（デフォルトまたは特定の暗号化が必要かどうかにかかわらず）以下のファイルを決して暗号化してはいけません（MUST）。；

• mimetype
• META-INF/container.xml
• META-INF/manifest.xml
• META-INF/metadata.xml
• META-INF/signatures.xml
• META-INF/encryption.xml
• META-INF/rights.xml

署名されたリソースは、XML署名の復号変換を使って暗号化されるかもしれません（MAY）。 この機能は、UCFエージェントなどのアプリケーションが署名する前に暗号化されたデータを識別できるようになります。 署名を有効にする前にダイジェストの計算をするために、署名後に暗号化されたデータだけが復号されなければなりません（MUST）。

（この例は有益です。）

次の例では、セクション2.2.1「XML暗号化シンタックスおよび処理」を改変して、image.jpegリソースは対称鍵アルゴリズム（AES）とジョン・スミスの非対称鍵アルゴリズム（RSA）の鍵を使って暗号化されます。