OCF  is a technology which is well-suited to package OPF/OPS-compliant  electronic publications. Since OCF is fundamentally a zip file, commonly available zip tools can be used to extract any unencrypted content stream from the package. On some systems, the contents of the zip file may appear like any other native container (e.g. a folder). While the ability to do this is quite useful, it can pose a problem for an author of the publication 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 that OPF/OPS provides.
In order to discourage reuse of the font, some font vendors may allow use of their fonts in OCF containers if those fonts are bound in some way to the publication. That is, if the font file can not be installed directly for use on an operating system with the built-in tools of that computing device, and it can not be directly used by other OPF/OPS publications. It is beyond the scope of this document to provide a digital rights management or enforcement system for font files. It will instead propose 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. However, 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 proposed 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 the original OCF publication, it is possible to apply the algorithms described in this document to extract the raw font file. Whether this satisfies the requirements of individual font licenses remains a question for the licensor and licensee.
To tie a font to a particular publication, it is necessary to bind to a unique property of that publication. Such a value is required by the OPF 2.0 specification, as detailed in its section 2.1"Package Identity". Every compliant OPF file has a dc:identifier element which uniquely identifies the publication. The OPF 2.0 specification details finding this element by examining the unique-identifier attribute of the package files package element. This element provides the required characteristic of being unique to a publication, however it is not suitable for use directly as the obfuscation key (for instance, its length is not defined).
In order to create a suitable key that is tied to the publication, a SHA-1 digest of the unique identifier should be generated as specified by the Secure Hash Standard. Before generating the digest, all white space characters as defined by the XML 1.0 specification, section 2.3 are removed. Specifically the Unicode code points 0x20, 0x09, 0x0D and 0x0A will be stripped from the string before the digest is computed. This digest is then directly used as the key for the algorithm described in the "Obfuscation Algorithm" section.
All encrypted data in an OCF must have an entry in the encryption.xml file accompanying the publication, per section 3.5.5 of the OCF specification. The EncryptionMethod element child of the EncryptedData must have an Algorithm attribute with the value "http://www.idpf.org/2008/embedding". The presence of this attribute signals the use of the algorithm described in this specification. All resource that have been obfuscated using this approach must be listed in the CipherData element.
An example encryption file might look like this:
To prevent trivial copying of the embedded font to other publications, the explicit key must not be provided in the encryption.xml file. Reading systems that implement this specification must derive the key from the packages unique identifier.
latest draft is
 SHA-1: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
 XML 1.0: http://www.w3.org/TR/REC-xml/