This file is reserved for digital rights management DRM information for trusted exchange of EPUB Publications among rights holders, intermediaries, and users. The rights. When the rights. An optional signatures.
This file is an XML document whose root element is signatures. The signatures. When the signatures. It is possible that digital signing exists within any of the contained Renditions, however.
The schema for signatures. When an OCF agent creates a signature of data in a container, it should add the new signature as the last child Signature element of the signatures element in the signatures. Each Signature in the signatures.
Individual contained files may be signed separately or together. Separately signing each file creates a digest value for the resource that can be validated independently. This approach may make a Signature element larger. If files are signed together, the set of signed files can be listed in a single XML Signature Manifest element and referenced by one or more Signature elements. Any or all files in the container can be signed in their entirety with the exception of the signatures.
Whether and how the signatures. This transform would sign all previous signatures, and it would become invalid if a subsequent signature was added to the package. This is only a suggestion. XML-Signature does not associate any semantics with a signature; an agent may include semantic information, for example, by adding information to the Signature element that describes the signature.
XML Signature describes how additional information can be added to a signature for example, by using the SignatureProperties element. The following XML expression shows the content of an example signatures.
OCF Processors must treat any other values as being in error. The contents of the mimetype file must not contain any leading padding or whitespace, must not begin with the Unicode signature or Byte Order Mark , and the case of the MIME type string must be exactly as presented above. The mimetype file additionally must not be compressed or encrypted, and there must not be an extra field in its ZIP header. Moreover, the nature of ZIP files means that their contents may appear like any other native container on some systems e.
While this simplicity of ZIP files is quite useful, it also poses a problem when ease of extraction of resources is not a desired side-effect of not encrypting them. An Author who wishes to include a third-party font, for example, typically does not want that font extracted and re-used by others.
More critically, many commercial fonts allow embedding, but embedding a font implies making it an integral part of the EPUB Publication, not just providing the original font file along with the content. Since integrated ZIP support is so ubiquitous in modern operating systems, simply placing a font in the ZIP archive is insufficient to signify that it is not intended to be reused in other contexts.
This uncertainty can undermine the otherwise very useful font embedding capability of EPUB Publications. That is, if the font file cannot be installed directly for use on an operating system with the built-in tools of that computing device, and it cannot be directly used by other EPUB Publications. It is beyond the scope of this specification to provide a digital rights management or enforcement system for such resources.
This section instead defines a method of obfuscation that will require additional work on the part of the final OCF recipient to gain general access to any obfuscated resources. Note that no claim is made in this specification, or by the IDPF, that this constitutes encryption, nor does it guarantee that the resource will be secure from copyright infringement.
It is the hope of the IDPF, however, that this algorithm will meet the requirements of most vendors who require some assurance that their resources cannot simply be extracted by unzipping the Container. In the case of fonts, the primary use case for obfuscation, the defined mechanism will simply provide a stumbling block for those who are unaware of the license details.
It will not prevent a determined user from gaining full access to the font. Given an OCF Container, it is possible to apply the algorithms defined to extract the raw font file. Whether this method of obfuscation satisfies the requirements of individual font licenses remains a question for the licensor and licensee.
The key used in the obfuscation algorithm is derived from the Unique Identifier of the Default Rendition. All whitespace characters, as defined by the XML 1. This digest is then directly used as the key for the algorithm. In the unlikely event that the file is less than bytes, then the entire file will be modified. To obfuscate the original data, the result of performing a logical exclusive or XOR on the first byte of the raw file and the first byte of the obfuscation key is stored as the first byte of the embedded resource.
This process is repeated with the next byte of source and key, and continues until all bytes in the key have been used. At this point, the process continues starting with the first byte of the key and 21st byte of the source. Once bytes have been encoded in this way or the end of the source is reached , any remaining data in the source is directly copied to the destination. Obfuscation of resources must occur before they are compressed and added to the OCF Container.
To get the original font data back, the process is simply reversed: the source file becomes the obfuscated data and the destination file will contain the raw data. The obfuscation of fonts was allowed prior to EPUB 3. As a result, invalid fonts might be encountered after decompression and de-obfuscation. In such instances, de-obfuscating the data before inflating it may return a valid font.
Supporting this method of retrieval is optional, as it is not compliant with this version of this specification, but needs to be considered when supporting EPUB 3 content generally. Although not technically encrypted data, all obfuscated resources must have an entry in the encryption. This may appear a weird constraint, but as a matter of fact this constraint originates in the Open Document file format which was the source of the EPUB file format.
This can replace the detection of the format in case the file extension. A practical issue with this requirement is that one cannot create a proper EPUB file with a simple zip tool: generic tools cannot guarantee that the mimetype file will be first in the archive. It simply contains the relative location of the. If the content.
Using this information, the reading system will be able to open the. You may find for instance a fixed-layout rendition and a reflowable rendition packaged in the same EPUB file. In such a case, container. Apart from container. This XML file carries bibliographic and structural metadata about an EPUB publication or an EPUB rendition , and is thus the primary source of information about how to process and display that publication.
Diverse sets of metadata e. Onyx can be expressed as XML elements, from different schemes. Rights expressions might exist within the contained Renditions. If the rights. Adding a digital signature is not a guarantee that an EPUB cannot be tampered with, since Reading Systems are not required to check signatures.
The root element of the signatures. Signatures can be applied to an EPUB Publication as a whole or to its parts, and can specify the signing of any kind of data i. When the signatures. When a data signature is created for the container, the signature SHOULD be added as the last child Signature element of the signatures element. Each Signature in the signatures. Individual contained files might be signed separately or together. Separately signing each file creates a digest value for the resource that can be validated independently.
This approach might make a Signature element larger. If files are signed together, the set of signed files can be listed in a single XML Signature Manifest element and referenced by one or more Signature elements. Any or all files in the container can be signed in their entirety with the exception of the signatures. Whether and how the signatures.
This transform would sign all previous signatures, and it would become invalid if a subsequent signature was added to the package. The details of such a transform are outside the scope of this specification, however. The [ XMLDSIG-CORE1 ] specification does not associate any semantics with a signature; an agent might include semantic information, for example, by adding information to the Signature element that describes the signature. The Container is used:. Moreover, the nature of ZIP files means that their contents might appear like any other native container on some systems e.
While this simplicity of ZIP files is quite useful, it also poses a problem when ease of extraction of resources is not a desired side-effect of not encrypting them. An Author who wishes to include a third-party font, for example, typically does not want that font extracted and re-used by others. More critically, many commercial fonts allow embedding, but embedding a font implies making it an integral part of the EPUB Publication, not just providing the original font file along with the content.
Since integrated ZIP support is so ubiquitous in modern operating systems, simply placing a font in the ZIP archive is insufficient to signify that it is not intended to be reused in other contexts. This uncertainty can undermine the otherwise very useful font embedding capability of EPUB Publications. That is, if the font file cannot be installed directly for use on an operating system with the built-in tools of that computing device, and it cannot be directly used by other EPUB Publications.
It is beyond the scope of this specification to provide a digital rights management or enforcement system for such resources. This section instead defines a method of obfuscation that will require additional work on the part of the final OCF recipient to gain general access to any obfuscated resources.
The mimetype file additionally must be neither compressed nor encrypted, and there must not be an extra field in its ZIP header. On some systems, the contents of the ZIP file may appear like any other native container e. While the ability to do this is quite useful, it can pose a problem for an Author who wishes to include a third-party font.
Many commercial fonts allow embedding, but embedding a font implies making it an integral part of the Publication, not providing the original font file along with the content. Since integrated ZIP support is so ubiquitous in modern operating systems, simply placing the font in the ZIP archive is insufficient to signify that the font is not intended to be reused in other contexts. This uncertainty can undermine the otherwise very useful font embedding capability of EPUB Publications.
In order to discourage reuse of the font, some font vendors may allow use of their fonts in EPUB Publications if those fonts are bound in some way to the Publication. That is, if the font file cannot be installed directly for use on an operating system with the built-in tools of that computing device, and it cannot be directly used by other EPUB Publications. It is beyond the scope of this document to provide a digital rights management or enforcement system for font files.
It instead defines a method of obfuscation that will require additional work on the part of the final OCF recipient to gain general access to any included fonts.
It is the hope of the IDPF that this will meet the requirements of most font vendors. No claim is made in this document or by the IDPF, that this constitutes encryption, nor does it guarantee that the font file will be secure from copyright infringement. The defined mechanism will simply provide a stumbling block for those who are unaware of the license details of the supplied font.
It will not prevent a determined user from gaining full access to the font. Given an OCF Container, it is possible to apply the algorithms defined to extract the raw font file. Whether this satisfies the requirements of individual font licenses remains a question for the licensor and licensee.
In the unlikely event that the file is less than bytes, then the entire file will be modified. The key for the algorithm is generated using the instructions as given in the section Generating the Obfuscation Key. To obfuscate the original data, the result of performing a logical exclusive or XOR on the first byte of the raw file and the first byte of the key is stored as the first byte of the embedded font file. This process is repeated with the next byte of source and key, until all bytes in the key have been used.
At this point, the process continues starting with the first byte of the key and 21st byte of the source. Once bytes have been encoded in this way or the end of the source is reached , any remaining data in the source is directly copied to the destination. In pseudo-code, this is the algorithm:.
To get the original font data back, the process is simply reversed. That is, the source file becomes the obfuscated data and the destination file will contain the raw font data. The key used in the obfuscation algorithm is derived from unique identifer s of the Publication s in the Container, as required by the EPUB Publications 3. In order to create the key, the unique identifiers of all Publications contained in the container must be concatenated in the order that the Publications appear in container.
Before generating this string, all whitespace characters as defined by the XML 1. This digest is then directly used as the key for the algorithm described in Obfuscation Algorithm. For such obfuscated fonts, in the encryption. The presence of this attribute signals the use of the algorithm described in this specification. All resources that have been obfuscated using this approach must be listed in the CipherData element. To prevent trivial copying of the embedded font to other Publications, the explicit key must not be provided in the encryption.
Reading systems must derive the key from the package's Unique Identifier. Example B. The contents of the mimetype file. All processors that read OCF files should rigorously check the size and validity of data retrieved. However, only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise.
And in that case, they would fall outside the domain of this registration document. This media type is in wide use for the distribution of ebooks in the EPUB format. The following list of applications is not exhaustive. EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards. March Berners-Lee, et al. January M Duerst, et al.
October Mark Davis, et al. The Unicode Standard, Version 5. ISBN
0コメント