Network Working Group E. Taft Internet-Draft J. Pravetz Expires: April 19, 2004 S. Zilles Adobe Systems October 20, 2003 The application/pdf Media Type draft-zilles-pdf-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. Taft, et al. Expires April 19, 2004 [Page 1] Internet-Draft The application/pdf Media Type October 2003 1. Introduction This is a preliminary draft that is intended for disucssion and comment. Comments should be sent to . Since PDF was introduced in 1993, it has grown to be the major format for capturing and exchanging formatted documents electronically, across the Web, via e-mail and virtually every other document exchange mechanism. For example, RFC3297 [11] on content negotiation for Facsimile, voice and other message services shows how PDF can be sent in to a recipient that identifies his ability to accept the PDF. And byte range retrieval is illustrated in the HTTP 1.1 specification RFC2616 [12]. There is even RFC2346 [13] on how to better structure PDF files for international exchange of documents where different paper sizes are used. Within the Prepress community, ISO 15930-1:2001 PDF/X [14] has been adopted as the exchange standard for electronic documents. PDF/X is a profile of PDF that references the PDF Reference, Third edition [2] as the source specification. Based on the work on PDF/X, a committee was formed by NPES, The Association for Suppliers of Printing, Publishing and Converting Technologies, and AIIM, Association for Information and Image Management, International in August, 2002 to pursue an international standard, PDF/A, that defines the use of PDF for archiving and preserving documents. AIIM is the secretariat for ISO/TC 171 SC2, Document Imaging Applications. This document is intended to provide updated information on the registration of the MIME Media Type "application/pdf" as envisaged in Appendix A of RFC2048 [17], with particular focus on the features that help mitigate security concerns. This document refers to features documented in the PDF References versions 1 [1], 1.3 [2], 1.4 [3] and 1.5 [4]. PDF is a format for representing formatted documents. These documents may be structured or simple. They may contain text, images, graphics and other multimedia content, such as video and audio. There is support for annotations, metadata, hypertext links, and bookmarks. Two of the key features of PDF are the support for encryption and digital signatures. These help resolve some of the security considerations in transmitting sensitive information and in identifying the signers and what can be trusted therefore. The encryption capability is also combined with a rights management capability that controls the uses that a recipient can make of a PDF file. This is described in more detail below. Taft, et al. Expires April 19, 2004 [Page 2] Internet-Draft The application/pdf Media Type October 2003 2. History PDF was originally envisioned as a universal way to communicate and view printed information electronically reliably across a wide variety of machine configurations, operating systems and communication networks. PDF relies on the same imaging model as the PostScript page description language to render complex text, images and graphics in a device and resolution-independent manner, bringing this feature to the screen as well as the printer. To improve performance for interactive viewing, PDF defines a more structured format than that used by most PostScript language programs. PDF also includes objects, such as hypertext links and annotations, that are not part of the page itself but are useful for building collections of related documents and for reviewing and commenting on documents. The application/pdf media type was first registered in 1993 by Paul Lindner for use by the gopher protocol; the registration was subsequently updated in 1994 by Steve Zilles. Taft, et al. Expires April 19, 2004 [Page 3] Internet-Draft The application/pdf Media Type October 2003 3. Fragment identifiers The handling of fragment identifiers [5] is not defined in the PDF Reference. The handling of these is defined by the User Agent that interprets a PDF file. One such agent has the following semantics for the fragment identifies [6]: A fragment identifier consists of one or more PDF-open parameters in a single URL, separated by the ampersand (&) or pound (#) character. Each parameter implies an action to be performed and the value to be used for that action. Actions are processed and executed from left to right as they appear in the character string that makes up the fragment identifier. The PDF-open parameters allow the specification of a particular page or named destination to open. Named destinations are similar to the "anchors" used in HTML or the IDs used in XML. Once the target is specified, the view of the page in which it occurs can be specified, either by specifying the position of a viewing rectangle and its scale or size coordinates or by specifying a view relative to the viewing window in which the chosen page is to be presented. The list of PDF-open parameters and the action they imply is: o nameddest=name action is to open to specified destination (which includes a view) Figure 1 o page=pagenum action is to open the specified page Figure 2 o zoom=scale,left,top action is to set the "scale" and scrolling factors. "left" and "top" are measured from the top left corner of the page independent of the size of the page. The pair "left" and "top" are optional but both must appear if present. Figure 3 Taft, et al. Expires April 19, 2004 [Page 4] Internet-Draft The application/pdf Media Type October 2003 o view=keyword,position action is to set the view to show some specified portion of the page or its bounding box. The keywords are defined by Table 8.2 of the PDF Reference, version 1.5. The "position" value is required for some of the keywords and not allow for others. See Table 8.2 Figure 4 o viewrect=left,top,wd,ht The view rectangle the is mapped into the viewing window is position as for the zoom parameter, but an explicit width and height are given instead of a scale percentage. Figure 5 o highlight=lt,rt,top,btm Highlight a rectangle on the chosen page where lt,rt,top and btm are the coordinates of the sides of the rectangle measured from the top left corner of the page. Figure 6 Because all specified actions are executed, it is possible that later actions will override the effects of previous actions, so be aware of the order. For example, page actions should appear before zoom actions. Commands are not case sensitive (except for the value of a named destination). Taft, et al. Expires April 19, 2004 [Page 5] Internet-Draft The application/pdf Media Type October 2003 4. Encryption PDF files allow access to be controlled using encryption and permission settings. The keys to decrypt document data, and permission settings for a document, are provided by encryption handlers. An 'Encryption Dictionary' is provided in the document trailer to enable encryption handlers to store document-specific information. Different encryption handlers can provide for different sets of rights. The PDF encoding rules for password and public key encryption handlers is specified in the PDF Reference. A person that is able to 'access' a document is said to be able to open and view the document. Access is possible when a person can provide the key with which to decrypt the document. The key is protected and provided by the encryption handler. Encryption handlers will normally require some sort of authentication before a person can access the document decryption key. Encryption of PDF files is applied to all string and stream data in the document, and only to string and stream data. By encrypting only data portions of the PDF file, random access to PDF file contents is maintained. The data is encrypted using 40 to 128-bit RC4 [7] encryption algorithm. The person that has access to a document will be given certain rights or permissions for the document. A person that has full rights, including the right to save a document without encryption, is said to be an 'owner'. A person that has restricted rights is said to be a 'user'. Example rights include the ability to copy text and other content from the PDF file, the ability to fill in form field data, and the ability to print the PDF file. Enforcement of rights is the responsibility of the viewing application. Password encryption allows the possibility of two different passwords to be used when providing access to the document. The 'author' password allows access to the document and full permissions, including the permission to save the document without encryption. The 'user' password allows access to the document but access rights are restricted by a set of permissions. Public key encryption of PDF files uses one or more PKCS#7 [8] objects to store information regarding recipients that are able to open a document. Each PKCS#7 object contains a list of recipients, a document decryption key, and permission settings that apply to all recipients listed for that PKCS#7 object. The document decryption key is protected with a triple-DES key that is encrypted once with the public key of each listed recipient. Taft, et al. Expires April 19, 2004 [Page 6] Internet-Draft The application/pdf Media Type October 2003 5. Digital Signatures A digital signature can be used to authenticate the identity of a user and the validity of a document's contents. The nature of PDF ideally lends itself to digital signature applications because PDF provides a container within which to embed a complete record that is needed to reproduce a visual representation of what a person saw when they signed the PDF file. Additionally, PDF digital signature support allows for multiple signers to sign the same document and the ability to view the exact state of the document at the point when any individual signature was applied. These are positive characteristics when considering the legal implications of signed PDF files. To avoid redundancy in the specification of the digital signature features of PDF, the reader is referred to the full specification in the PDF Reference. The PDF Reference [4] section 8.7 and Appendix I specifies a syntax for representing digital signatures of PDF files using public key cryptography. An overview is provided here to indicate the nature of the information that is collected and how it is used. A signature digest is always of all bytes of the PDF file being signed, beginning at the first byte of the file and ending at the last byte of the file following the %EOF, but excluding the signature value because the signature value must be added after the signing process is complete. The offset values of the byte ranges that are signed are stored in the signature and are covered by the signature value. When verifying signatures these byte range values are used to determine which bytes to digest. Verification software must also ensure that the signature value is the only data that is not covered by the signature digest. Multiple signatures are supported using the incremental save capabilities of PDF. When changes to a file are made and a new signature is applied to the document, the changes are appended after the last byte of the previously existing document and then the new signature digest is of all bytes of the new file. In this manner changes can be made to a document and new signatures added to a document without invalidating earlier signatures that have been applied to the PDF file. Any change to a document is detected because all bytes of the PDF file are digested. The state of a signed document, when an earlier signature of a multiple signature document was applied, can be viewed by extracting the earlier set of bytes of the file and opening them in a PDF viewing application. This process is called 'rollback' and allows viewing of the exact state of the document when it was signed. Taft, et al. Expires April 19, 2004 [Page 7] Internet-Draft The application/pdf Media Type October 2003 PDF syntax allows for 'author' and 'user' signatures. Under normal circumstances the first signature of a document is considered an author signature and all other signatures are considered user signatures. Authors can specify what changes are to be allowed to the PDF file before the author's signature is presented as invalid. Example changes include the ability to fill in form field data, the ability to add comments to a document, the ability to make no changes, and the ability to make any changes. Changes are detected by opening the existing document and the author's version of the document and performing a complete object compare of the two documents. Change detection is not a substitute for the legal value of document rollback. PDF public key digital signature syntax is specified for PKCS#1 [10] and PKCS#7 signatures. In both cases, all bytes of the PDF file are signed, with the exclusion of the PKCS#1 or PKCS#7, signature value, objects. PKCS#7, when used in this manner, acts in its detached signature mode. When using PKCS#7, the certificate chain of the signer is included in the PKCS#7 object. When using PKCS#1, the certificate chain of the signer is included with other signature information in the signed document. Taft, et al. Expires April 19, 2004 [Page 8] Internet-Draft The application/pdf Media Type October 2003 6. Intellectual Property The following is copied verbatim from the PDF Reference [4]: The general idea of using an interchange format for electronic documents is in the public domain. Anyone is free to devise a set of unique data structures and operators that define an interchange format for electronic documents. However, Adobe Systems Incorporated owns the copyright for the particular data structures and operators and the written specification constituting the interchange format called the Portable Document Format. Thus, these elements of the Portable Document Format may not be copied without Adobe's permission. Adobe will enforce its copyright. Adobe's intention is to maintain the integrity of the Portable Document Format standard. This enables the public to distinguish between the Portable Document Format and other interchange formats for electronic documents. However, Adobe desires to promote the use of the Portable Document Format for information interchange among diverse products and applications. Accordingly, Adobe gives anyone copyright permission, subject to the conditions stated below, to: o Prepare files whose content conforms to the Portable Document Format o Write drivers and applications that produce output represented in the Portable Document Format o Write software that accepts input in the form of the Portable Document Format and displays, prints, or otherwise interprets the contents o Copy Adobe's copyrighted list of data structures and operators, as well as the example code and PostScript language function definitions in the written specification, to the extent necessary to use the Portable Document Format for the purposes above The conditions of such copyright permission are: o Authors of software that accepts input in the form of the Portable Document Format must make reasonable efforts to ensure that the software they create respects the access permissions and permissions controls listed in Table 3.20 of this specification, to the extent that they are used in any particular document. o Anyone who uses the copyrighted list of data structures and operators, as stated above, must include an appropriate copyright Taft, et al. Expires April 19, 2004 [Page 9] Internet-Draft The application/pdf Media Type October 2003 notice. o Accessing the document in ways not permitted by the document's access permissions is a violation of the document author's copyright. This limited right to use the copyrighted list of data structures and operators does not include the right to copy this book, other copyrighted material from Adobe, or the software in any of Adobe's products that use the Portable Document Format, in whole or in part, nor does it include the right to use any Adobe patents, except as may be permitted by an official Adobe Patent Clarification Notice (see the Bibliography). Acrobat, Acrobat Capture, Adobe Reader, ePaper, the "Get Adobe Reader" Web logo, the "Adobe PDF" Web logo, and all other trademarks, service marks, and logos used by Adobe (the "Marks") are the registered trademarks or trademarks of Adobe Systems Incorporated in the United States and other countries. Nothing in this book is intended to grant you any right or license to use the Marks for any purpose. Taft, et al. Expires April 19, 2004 [Page 10] Internet-Draft The application/pdf Media Type October 2003 7. PDF implementations There are multiple, independent, interoperable implementations of PDF. In addition, there are more than 1800 tools that work on application/pdf files. For example, see Planet PDF [15] or PDFzone.com [16] for lists of applicable tools. Note that it is not the case that all implementations implement all features. Therefore care in choosing tools is advised; check if the features you require are provided. There is good interoperability among implementations that do implement the same features. Taft, et al. Expires April 19, 2004 [Page 11] Internet-Draft The application/pdf Media Type October 2003 8. Security considerations An "application/pdf" resource contains information to be parsed and processed by the recipient's PDF system. Because PDF is both a representation of formatted documents and a container system for the resources need to reproduce or view said documents, it is possible that a PDF file has embedded resources not described in the PDF Reference. Although it is not a defined feature of PDF, a PDF processor could extract these resources and store them on the recipients system. Furthermore, PDF processor may accept and execute "plug-in" modules accessible to the recipient. These may also access material in the PDF file or on the recipients system. Therefore, care in establishing the source, security and reliability of such plug-ins is recommended. Message-sending software should not make use of arbitrary plug-ins without prior agreement on their presence at the intended recipients. Message-receiving and -displaying software should make sure that any non-standard plug-ins are secure and do not present a security threat. PDF may contain "scripts" to customize the displaying and processing of PDF files. These scripts are expressed in a version of JavaScript [9] based on JavaScript version 1.5 of ISO-16262 (formerly known as ECMAScript). These scripts have access to an API that is similar to the "plug-in" API. They are intended for execution by the PDF processor. Some such script might compromise the security of the system when executed. In general, any information stored outside of the direct control of the user -- including referenced application software or plug-ins and embedded files, scripts or other material not covered in the PDF reference -- can be a source of insecurity, by either obvious or subtle means. For example, a script can modify the content of a document prior to its being displayed. Thus, the security of any PDF document may be dependent on the resources referenced by that document. As noted above, PDF provides mechanism for helping insure the integrity of a PDF file, Encryption (Section 4), and to be able to digitally sign (Section 5) a PDF file. The latter capability allows a recipient to decide if he is willing to trust the file. Where there is concern that tampering with the PDF file might be a problem it is recommended that the encryption and digital signature features be used to protect and authoritate the PDF. In addition, PDF processors may have mechanisms that track the source Taft, et al. Expires April 19, 2004 [Page 12] Internet-Draft The application/pdf Media Type October 2003 of scripts or plug-ins and will execute only those scripts or plug-ins that meet the processors requirements for trustworthiness of the sources. Taft, et al. Expires April 19, 2004 [Page 13] Internet-Draft The application/pdf Media Type October 2003 9. IANA considerations IANA update the registration of 'application/pdf'. This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [17] MIME media type name: application MIME subtype name: pdf Required parameters: none Optional parameter: none Encoding considerations: PDF files frequently contain binary data, and thus must be encoded in non-binary contexts. Security considerations: See Security Considerations section of this document Interoperability considerations: See PDF Implementations section of this document Published specification: Adobe Systems Incorporated, "PDF Reference, Fourth Edition", Version 1.5, August 2003 http://partners.adobe.com/asn/tech/pdf/specifications.jsp, Applications which use this media type: See PDF Implementations section of this document Additional information: Magic number(s): All PDF files start with the characters '%PDF-' using the PDF version number, e.g., '%PDF-1.4'. These characters are in US-ASCII encoding. File extension(s): .pdf Macintosh File Type Code(s): "PDF" For further information: Adobe Developer Support %lt;dev-support@adobe.com%gt; 345 Park Ave San Jose, CA 95110 (408) 536-xxxx http://www.adobe.com/xxxxx Intended usage: COMMON Author/Change controller: Adobe Systems Incorporated Attn: Adobe Developer Support .... Taft, et al. Expires April 19, 2004 [Page 14] Internet-Draft The application/pdf Media Type October 2003 10. Registration form for application/pdf media type Taft, et al. Expires April 19, 2004 [Page 15] Internet-Draft The application/pdf Media Type October 2003 References [1] Adobe Systems Incorporated, "Portable Document Format Reference Manual", Version 1.0, ISBN: 0-201-62628-4, Addison-Wesley, New York NY, 1993. [2] Adobe Systems Incorporated, "PDF Reference, Second Edition", Version 1.3, ISBN: 0-201-61588-6, Addison-Wesley, New York NY, 2000. [3] Adobe Systems Incorporated, "PDF Reference, Third Edition", Version 1.4, ISBN: 0-201-75839-3, Addison-Wesley, New York NY, November 2001. [4] Adobe Systems Incorporated, "PDF Reference, Fourth Edition", Version 1.5, http://partners.adobe.com/asn/tech/pdf/ specifications.jsp, August 2003. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Adobe Systems Incorporated, "PDF Open Parameters", Technical Note 5428, http://partners.adobe.com/asn/acrobat/sdk/public/ docs/PDFOpenParams.pdf, May 2003. [7] Rivest, R., "RC4 - an unpublished, trade secret encryption algorithm", http://theory.lcs.mit.edu/~rivest/faq.html, http://www.rsasecurity.com/rsalabs/faq/3-6-3.html, November 1993. [8] RSA Laboratories, "PKCS #7 - Cryptographic Message Syntax Standard", Version 1.5, http://www.rsasecurity.com/rsalabs/ pkcs/pkcs-7/index.html, November 1993. [9] Adobe Systems Incorporated, "Acrobat JavaScript Scripting Reference", Technical Note 5431, http://partners.adobe.com/ asn/acrobat/sdk/public/docs/AcroJS.pdf, September 2003. [10] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. Taft, et al. Expires April 19, 2004 [Page 16] Internet-Draft The application/pdf Media Type October 2003 Informative References [11] Klyne, G., Iwazaki, R. and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002. [12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [13] Palme, J., "Making Postscript and PDF International", RFC 2346, May 1998. [14] International Standards Organization, "Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 1: Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a)", ISO 15930-1:2001, November 2002. [15] Planet PDF, "Planet PDF Tools List", http://www.planetpdf.com/ mainpage.asp?MenuID=193&WebPageID=612. [16] InternetBiz.net, LLC, "PDF Toolbox", http://www.pdfzone.com/ toolbox/. [17] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. Authors' Addresses Edward A. Taft Adobe Systems 345 Park Ave San Jose, CA 95110 US EMail: taft@adobe.com James D. Pravetz Adobe Systems 345 Park Ave San Jose, CA 95110 US EMail: jpravetz@adobe.com Taft, et al. Expires April 19, 2004 [Page 17] Internet-Draft The application/pdf Media Type October 2003 Stephen Zilles Adobe Systems 345 Park Ave San Jose, CA 95110 US Phone: +1 408 356 7692 EMail: szilles@adobe.com URI: http:// Taft, et al. Expires April 19, 2004 [Page 18] Internet-Draft The application/pdf Media Type October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Taft, et al. Expires April 19, 2004 [Page 19] Internet-Draft The application/pdf Media Type October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Taft, et al. Expires April 19, 2004 [Page 20]