





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]
