Internet-Draft Kazuhiko Yamamoto draft-kazu-pgp-mime-00.txt NAIST Expires in six months October, 1995 PGP MIME Integration Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document defines one MIME content type, "Application/PGP" to enclose a PGP object in a MIME object. It also specifies one optional parameter, "format" to embed a text object or a MIME object in a PGP object. Encoding and canonicalizing methods are provided. The mechanism maintains backward compatibility to the current PGP program as well as non-MIME interfaces. Introduction PGP[PGP] is now widely spread, providing privacy enhancements such as confidentiality, message integrity, user authentication and non-repudiation. Since there is no rule to label PGP objects within messages, people used to exchange PGP objects which enclose only text by electronic mail or NetNews. That is, PGP has been used to enhance privacy for a text object. MIME[MIME] provides a labeling mechanism to enclose objects other than US-ASCII text, as well as to embed multiple objects in a multipart structure. It is of recent interest to enhance privacy of MIME messages. This document describes a scheme to provide privacy services to MIME with PGP. Since there are many PGP users, the scheme is designed to maintain backward compatibility to the current PGP program as well as non-MIME interfaces. Yamamoto [Page 1] Internet-Draft PGP/MIME October 1995 Throughout this document, we will call the scheme "PGP/MIME". It should be emphasized that MIME "content transfer encoding" has two meanings, encoding method and its resulting domain. For example, "7bit" means no encoding is applied and its domain is 7BIT. For "base64", its encoding method is base64 and its domain is 7BIT. This document uses double-quoted words for the value of content transfer encoding, whereas capitalized words for domain. Note also that a message header is a special form of content header. Design Goals To integrate PGP and MIME, the following design goals must be obtained. (1) Backward compatibility to the current PGP for text messages. (2) True integration that allows to encrypt, sign, sign-then-encrypt objects other than text, singleparts in a multipart, the entire multipart, etc. (3) Flexibility that never limits those who can decrypt one part to the receivers of the message. To achieve these design goals, "Application/PGP" is defined as a MIME content type to enclose a PGP object into a MIME object. This content type may take one optional "format" parameter to embed a MIME object and a text object to PGP. HISTORICAL NOTE As far as the author knows, this kind of approach was originally found in the withdrawn Internet-Draft entitled "An Alternative PEM MIME Integration" by Schiller in 1993 though it never specified the "format" parameter. This document is based on the withdrawn Internet-Draft entitled "The application/pgp MIME Content-type" by Borenstein et al in 1994, but encoding mechanisms are different. Definition of the "Application/PGP" MIME content type The "Application/PGP" MIME content type is defined as follows; MIME type name: application MIME subtype name: pgp Required parameters: none Optional parameters: format Encoding notes: only "7bit" and "8bit" are permitted. Yamamoto [Page 2] Internet-Draft PGP/MIME October 1995 The "application/pgp" content type is used to enclose one armored PGP object. This document defines only two possible values for the "format" parameter, "text" and "mime". The "format=text" parameter indicates that the result of decrypting, verifying, or decrypting-then-verifying the armored PGP object is localized text, which is not always US-ASCII. Its character set should be decided by a local convention. It should be emphasized that the "format=text" parameter is prepared for backward compatibility. Signed text by PGP, whose character set is other than US-ASCII such as ISO-8859-1 and ISO-2022-JP, has been exchanged as a clear text. So, we must not assume that the decrypted, verified, or decrypted-then-verified PGP object is US-ASCII. To specify the "charset" parameter, the "format=mime" parameter must be used. If the "format" parameter is not present, the content body must be treated as if the "format=text" parameter was specified. The "format=mime" parameter indicates that the result of decrypting, verifying, or decrypting-then-verifying the armored PGP object is a MIME object, which consists of an optional content header, a null line, and a content body. The content type field in the content header specifies the data type of the content body. In the absence of the content type, the content body is assumed as US-ASCII text. When an object other than text is encrypted, signed, or signed-then-encrypted by PGP, first it must be converted into a MIME object whose content header includes content type information. MIME encoding for a binary object is optional at the preparation. In the case to treat multiple objects at the same time, they must be transformed into MIME multipart structure. After the process of the MIME object by PGP, one armored PGP object is produced. The PGP object must be transformed into a MIME object whose content type is "Application/PGP" with the "format=mime" parameter. A text object may be directly processed by PGP to get one PGP object. The PGP object is then transformed to a MIME object whose content type is "Application/PGP" with or without the parameter "format=text". However, there are two possibilities to convert a text object into a MIME object. One is to label its character set and the other is to convert text including 8bit characters or long lines into "message safe" form. In these cases, the text object should be transformed to a MIME object with an appropriate content header. Then the MIME object is treated in the same way as a non-textual object is. IMPLEMENTORS NOTE PGP objects itself contain the information whether they are encrypted, signed, or signed-then-encrypted. Encrypted or signed-then-encrypted objects also include the information who Yamamoto [Page 3] Internet-Draft PGP/MIME October 1995 can decrypt them. So, MIME interfaces do not need to specify any options to decrypt, verify, or decrypt-then-verify an executed PGP program. For this reason, this document does not define any parameters for PGP operations. Encoding Considerations PGP provides radix64 encoding which is syntactically identical to MIME base64 encoding but they are flagged in different manners. The PGP mechanism is self-identifying, while the MIME mechanism uses content transfer encoding to indicate an encoding method. There are two schemes to convert a target object to a "message safe" form. One is to encode an output from PGP by MIME encoding. The other is that PGP itself converts an object to a "message safe" form and content transfer encoding just indicates an encoding domain. Since the content header, whose content body is a PGP object, cannot be protected by PGP/MIME, it is quite possible that someone may forge or modify its content transfer encoding. So, it is safer for MIME interfaces to pass the PGP object in the content body to PGP without MIME decoding. For this reason, this document makes use of PGP's "message safe" features rather than MIME encoding. (Note that the content type in the content header is also under threat of modification. Unfortunately, PGP/MIME is vulnerable to this kind of attack.) PGP objects are categorized into three types: The content transfer encoding of signed objects by PGP are "7bit" or "8bit". For example, 7BIT text such as ISO-2022-JP results in a clear signature in "7bit" whereas 8BIT text such as ISO-8859-1 are tranformed into a clear signature in "8bit". In the same way, the domain of "line based"(i.e. in 7BIT or 8BIT) objects remains after the transformation to a PGP object. A non-line based object(i.e in BINARY) is converted into "7bit" with radix64 encoding after the calculation of its signature. The content transfer encoding of encrypted objects by PGP is always "7bit" with radix64 encoding. The content transfer encoding of signed-then-encrypted objects by PGP is always "7bit" with radix64 encoding. MIME objects whose content body is a PGP object should provide content transfer encoding according to the encoding domain of the PGP object. "7bit" can be omitted but "8bit" must be provided. Canonicalization Procedures Each operating system has their own line break. So, if a target object is "line based", its line breaks must be canonicalized to be exchanged safely in heterogeneous environment. This document Yamamoto [Page 4] Internet-Draft PGP/MIME October 1995 defines as the canonical line break of PGP/MIME, which is exactly the same as that of RFC822. IMPLEMENTORS NOTE The current PGP has an option to treat an input as line based. If the option is specified, PGP first canonicalizes each line break into . If a target object is text, it is possible to pass the object to PGP as line based, without transformation into a MIME object. If a target object is text, it may be transformed into a MIME object preparing an appropriate content header. If a target object is not text, it must be converted to a MIME object. If the MIME object is "text", "application/postscript", "multipart", or "message", it must be passed to PGP as line based. * The domain of "text" must be 7BIT or 8BIT since it supposed not to include "binary". Example +++ +++ +++ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit [ISO-8859-1 text comes here] +++ +++ +++ * The domain of "application/postscript" must be 7BIT. So, if the original object includes 8BIT or BINARY data, it must be encoded to 7BIT domain when it is tranformed to a MIME object. Example +++ +++ +++ Content-Type: application/postscript Content-Transfer-Encoding: quoted-printable [PostScript encoded by quoted-printable comes here] +++ +++ +++ * The domain of "multipart" and "message" must be 7BIT or 8BIT. Since multipart and message types allow recursive structures, MIME prohibits encoding of the entire object. In order to pass multipart and message to PGP as line based, they must not include objects in BINARY domain. Objects in the binary domain must be encoded by MIME encoding before it is enclosed in the multipart or the message. Yamamoto [Page 5] Internet-Draft PGP/MIME October 1995 Example +++ +++ +++ Content-Type: Multipart/Mixed; boundary=simple Content-Transfer-Encoding: 7bit --simple Content-Type: text/plain; charset=iso-2022-jp [ISO-2022-JP text comes here] --simple Content-Type: image/gif Content-Transfer-Encoding: base64 [GIF encoded by base64 comes here] --simple-- +++ +++ +++ An object whose domain is BINARY should be passed to PGP as non-line based. It is not necessary to apply MIME encoding to the original binary object before it is passed to PGP. Since PGP never canonicalizes the MIME object, line breaks of the content header must be canonicalized to by MIME interfaces. Example +++ +++ +++ Content-Type: Audio/Basic [Audio binary stream comes here] +++ +++ +++ Other MIME objects in 7BIT or 8BIT domain must be passed to PGP as line based. +++ +++ +++ Content-Type: Audio/Basic Content-Transfer-Encoding: base64 [Audio data encoded by base64 comes here] +++ +++ +++ Yamamoto [Page 6] Internet-Draft PGP/MIME October 1995 Examples An "application/pgp" whose parameter is not present. Its content body is US-ASCII text signed by PGP. +++ +++ +++ Content-Type: application/pgp -----BEGIN PGP SIGNED MESSAGE----- Was it a cat I saw? -----BEGIN PGP SIGNATURE----- [PGP signature information comes here] -----END PGP SIGNATURE----- +++ +++ +++ An "application/pgp" whose content body is ISO-8859-1 text directly signed by PGP. +++ +++ +++ Content-Type: application/pgp; format=text Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- [ISO-8859-1 text comes here] -----BEGIN PGP SIGNATURE----- [PGP signature information comes here] -----END PGP SIGNATURE----- +++ +++ +++ An "application/pgp" whose content body is any object encrypted or signed-then-encrypted by PGP or a binary object signed by PGP. +++ +++ +++ Content-Type: application/pgp; format=mime -----BEGIN PGP MESSAGE----- [PGP radix64 lines comes here] -----END PGP MESSAGE----- +++ +++ +++ An "application/pgp" whose content body is multipart signed by PGP. The multipart includes ISO-2022-JP text and ISO-8859-1 text encoded by quoted-printable. Yamamoto [Page 7] Internet-Draft PGP/MIME October 1995 +++ +++ +++ Content-Type: application/pgp; format=mime -----BEGIN PGP SIGNED MESSAGE----- Content-Type: Multipart/Mixed; boundary=simple - --simple Content-Type: Text/Plain; charset=iso-2022-jp [ISO-2022-JP comes here] - --simple Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable [ISO-8859-1 encoded by quoted-printable comes here] - --simple-- -----BEGIN PGP SIGNATURE----- [PGP signature information comes here] -----END PGP SIGNATURE----- +++ +++ +++ Design Verifications Backward compatibility An RFC822 message which includes a PGP object in its body can be upgraded to PGP/MIME message with two fields, "MIME-Version: 1.0" and "Content-Type: Application/PGP" with or without the "format=text" parameter. This kind of PGP/MIME message is friendly not only to non-MIME interfaces but also to MIME interfaces. Since this document never requires MIME encoding for 8BIT text to create a clear signature, no modification is required to non-MIME interfaces nor to the current PGP program. Note that if a message contains only one PGP object, those who can decrypt it should be the same as the receivers specified in its message header. True integration Thanks to "application/pgp" content type, a MIME object can embed a PGP object whereas a PGP object can enclose a MIME object with the "format=mime" parameter. This mechanism makes it possible to compose any kind of PGP/MIME message recursively. Yamamoto [Page 8] Internet-Draft PGP/MIME October 1995 Flexibility Since an encrypted object by PGP has the information who can decrypt it, each object in a message can specify their own target people. For example, PGP/MIME allows that one part is encrypted for person A, another part is encrypted for person B, and the entire message is destined to a mailing-list. Security Considerations This document defined a method to enclose PGP objects within the context of MIME. Security for PGP objects depends on PGP. PGP/MIME provides one content type and encoding procedure to PGP objects. Since the content header is not protected by PGP, it is under threat of modification. It is not fatal if the content transfer encoding is altered because it is assumed that no encoding is applied to its content body. But if the content type is modified, MIME interfaces cannot automatically identify the type of its content body. Even in such a case, users can, at least, guess that the content body is a PGP object thanks to its PGP armor. Acknowledgments The author hereby thanks to Jeffrey Schiller, Nathaniel Borenstein, Colin Plumb, and Philip Zimmermann as the pioneers of this kind of approach. Author's Address Kazuhiko YAMAMOTO Graduate School of Information Science Nara Institute of Science and Technology(NAIST) 8916-5 Takayama, Ikoma City 630-01 JAPAN Phone: +81-7437-2-5111 FAX: +81-7437-2-5239 EMail: kazu@is.aist-nara.ac.jp References [PGP] P. Zimmermann, "The Official PGP User's Guide", MIT Press, 1995. [MIME] N. Borenstein and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September, 1993. Yamamoto [Page 9]