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 <CR><LF> 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 <CR><LF>.
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 <CR><LF> by MIME
interfaces.
Example
+++ +++ +++
Content-Type: Audio/Basic<CR><LF>
<CR><LF>
[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]