INTERNET DRAFT Michael Elkins
draft-elkins-pem-pgp-01.txt The Aerospace Corporation
elkins@aero.org
September 1995
MIME Security with Pretty Good Privacy (PGP)
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 describes how Pretty Good Privacy (PGP) can be used to
provide privacy and authentication using the Multipurpose Internet
Mail Extensions (MIME) security content types described in RFCXXXX
(draft-ietf-pem-sigenc-03.txt).
1. Introduction
This document is based on RFCXXXX [1] which defines security
mechanisms for MIME messages, and specifically addresses how PGP can
be used within this framework in order to effect it. This document
is styled after RFCXXXX [2], which defines MIME Object Security
Services (MOSS) for providing security and authentication. This
work was prompted by the fact that implementations of MOSS may not
be available outside of the U.S. because of export restrictions.
PGP, on the other hand, is widely available throughout the world
(with a few notable exceptions), and is gaining support as the de-
facto standard for electronic mail privacy. This document defines
three new content types form implementing security and privacy with
Elkins Expires: March 1996 [Page 1]
INTERNET DRAFT MIME Security with PGP September, 1995
PGP: application/pgp-encrypted, application/pgp-signature and
application/pgp-keys.
2. PGP data formats
PGP can generate either ascii armor (described in [3]) or 8 bit
binary output when encrypting data, generating a digital signature,
or extracting public key data. Except where noted, the ascii armor
output is the preferred method for data transfer. This allows those
users who do not have the means to interpret the formats described
in this document to be able extract and use the PGP information in
the message.
Ascii armor output should NEVER be BASE64 or QUOTED-PRINTABLE
encoded since it is already in 7 bit format.
When 8 bit to 7 bit conversion of PGP data is necessary, BASE64
encoding is the preferred method.
3. PGP encrypted data
Before encryption with PGP, the data should be written in MIME
canonical format (body and headers). This MIME body is constrained
to 7 bit format.
PGP encrypted data is denoted by the "multipart/encrypted" content
type, described in [1], and REQUIRES a "protocol" parameter value of
"application/pgp-encrypted". Note that the value of the parameter
MUST be enclosed in quotes. The "multipart/encrypted" data is
constrained to 7 bit format.
The multipart/encrypted MUST consist of exactly two parts. The
first MIME body part must have a content type of "application/pgp-
encrypted". The data portion of the body may be zero length or
contain human readable information about the encrypted data.
The second MIME body part MUST contain the actual encrypted data.
It must be labeled with a content type of "application/octet-
stream", and is REQUIRED to be in 7 bit format.
Example message:
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=foo;
protocol="application/pgp-encrypted"
Content-Transfer-Encoding: 7bit
Elkins Expires: March 1996 [Page 2]
INTERNET DRAFT MIME Security with PGP September, 1995
--foo
Content-Type: application/pgp-encrypted
--foo
Content-Type: application/octet-stream
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----
--foo--
4. PGP signed data
Prior to generating the PGP signature, the following steps MUST be
taken to ensure a valid signature:
(1) The data to be signed MUST be written in MIME canonical format,
including the appropriate set of of headers.
(2) The data MUST be constrained to 7 bit format.
(3) The data MUST use the canonical CRLF sequence to denote the end
of a line, regardless of the local newline convention.
PGP signed messages are denoted by the "multipart/signed" content
type, described in [1], and REQUIRE the "protocol" parameter to have
a value of "application/pgp-signature" (MUST be quoted), and the
"micalg" parameter to have a value of "pgp-md5".
The multipart/signed body MUST consist of exactly two parts, the
first of which MUST be the signed data in the form described above.
The second body MUST contain the PGP digital signature. It MUST be
labeled with a content type of "application/pgp-signature", and is
REQUIRED to be in 7 bit format.
When the PGP digital signature is generated:
(1) As described in [1], the digital signature MUST be calculated
over both the headers AND the data to be signed.
(2) The signature MUST be generated detached from the signed data
so that the process does not alter the signed data in any way.
Example message:
From: Michael Elkins <elkins@aero.org>
Elkins Expires: March 1996 [Page 3]
INTERNET DRAFT MIME Security with PGP September, 1995
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary=bar; micalg=pgp-md5
--bar
Content-Type: text/plain; charset=us-ascii
Did you know that talking to yourself is a sign of senility?
--bar
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
iQCVAwUAMGoCuGN9oWBghPDJAQEiDAP9HEO6X+lKvZ67gsg9i/VPOaroF4+FS/6L92oy
Kmk0+i75joY/3KZdmwhhEPr+qMxbJROmsAhH294zPzftv6OwATbe2UkBJwv7gtsJxU/8
i07ZMA4m 6ALBRHu7qrF3aOK6bSS4qDqlss+2JLZ0CjgQysxAeDT9x7WNl567mht
+uiw=
--bar--
Implementor's note: when verifying a digital signature, it is VERY
important that the message uses the canonical CRLF as the end line
sequence. Depending on your local convention, the CRLF may have
been converted to a different sequence during transmission, which
could cause the signature verification to fail. Therefore, if the
message has been altered, it MUST be written in the canonical form
before the signature is checked in order to ensure verification.
Though not required, it is generally a good idea to use QUOTED-
PRINTABLE encoding in the first step (writing out the data to be
signed in MIME canonical format) if any of the lines in the data
begin with "From ", and encode the "F". This will avoid an MTA
inserting a ">" in front of the line, thus invalidating the
signature!
5. Encrypted and Signed Data
Sometimes it is desirable to to both digitally sign and then encrypt
a message to be sent. In [1], it is stated that the data should
first be signed as a multipart/signature body, and then encrypted to
form the final multipart/encrypted body, ie.,
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted"; boundary=foo
--foo
Content-Type: application/pgp-encrypted
Elkins Expires: March 1996 [Page 4]
INTERNET DRAFT MIME Security with PGP September, 1995
--foo
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
& Content-Type: multipart/signed; micalg=pgp-md5
& protocol="application/pgp-signature"; boundary=bar
&
& --bar
& Content-Type: text/plain
&
& This message was first signed, and then encrypted.
&
& --bar
& Content-Type: application/pgp-signature
& Content-Transfer-Encoding: base64
&
& iQCVAwUAMGoCuGN9oWBghPDJAQEiDAP9HEO6X+lKvZ67gsg9i/VPOaroF4+F
& S/6L92oyKmk0+i75joY/3KZdmwhhEPr+qMxbJROmsAhH294zPzftv6OwATbe
& 2UkBJwv7gtsJxU/8i07ZMA4m 6ALBRHu7qrF3aOK6bSS4qDqlss+2JLZ0Cjg
& ysxAeDT9x7WNl567mht+uiw=
& --bar--
--foo--
(The text preceded by '&' indicates that it is really
encrypted, but presented as text for clarity.)
6. Distribution of PGP public keys
Content-Type: application/pgp-keys
Required parameters: none
Optional parameters: none
This is the content type which should be used for relaying public
key blocks. Ascii armor output and 7BIT encoding are HIGHLY
recommended.
7. Notes
PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
References
[1] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
RFCXXXX (draft-ietf-pem-sigenc-03.txt), 1994
[2] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. MIME Object
Elkins Expires: March 1996 [Page 5]
INTERNET DRAFT MIME Security with PGP September, 1995
Security Services. RFCXXXX (draft-ietf-pem-mime-08.txt), 1995
[3] Derek Atkins, William Stallings, Philip Zimmermann. PGP Message
Exchange Formats. draft-pgp-pgpformat-00.txt, 1995
Elkins Expires: March 1996 [Page 6]