MIME Security with Pretty Good Privacy (PGP)
RFC 2015

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                          M. Elkins
Request for Comments: 2015                     The Aerospace Corporation
Category: Standards Track                                   October 1996

              MIME Security with Pretty Good Privacy (PGP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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 RFC1847.

1.  Introduction

   Previous work on integrating PGP with MIME (including the since
   withdrawn application/pgp content type) has suffered from a number of
   problems, the most significant of which is the inability to recover
   signed message bodies without parsing data structures specific to
   PGP.  This work makes use of the elegant solution proposed in
   RFC1847, which defines security multipart formats for MIME. The
   security multiparts clearly separate the signed message body from the
   signature, and have a number of other desirable properties. This
   document is styled after RFC 1848, which defines MIME Object Security
   Services (MOSS) for providing security and authentication.

   This document defines three new content types for implementing
   security and privacy with PGP: application/pgp-encrypted,
   application/pgp-signature and application/pgp-keys.

1.1  Compliance

   In order for an implementation to be compliant with this
   specification, is it absolutely necessary for it to obey all items
   labeled as MUST or REQUIRED.

Elkins                      Standards Track                     [Page 1]
RFC 2015                 MIME Security with PGP             October 1996

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.  The ASCII armor output is the
   REQUIRED 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.

   When the amount of data to be transmitted requires that it be sent in
   many parts, the MIME message/partial mechanism should be used rather
   than the multipart ASCII armor PGP format.

3.  Content-Transfer-Encoding restrictions

   Multipart/signed and multipart/encrypted are to be treated by agents
   as opaque, meaning that the data is not to be altered in any way [1].
   However, many existing mail gateways will detect if the next hop does
   not support MIME or 8-bit data and perform conversion to either
   Quoted-Printable or Base64.  This presents serious problems for
   multipart/signed, in particular, where the signature is invalidated
   when such an operation occurs.  For this reason all data signed
   according to this protocol MUST be constrained to 7 bits (8- bit data
   should be encoded using either Quoted-Printable or Base64).  Note
   that this also includes the case where a signed object is also
   encrypted (see section 6).  This restriction will increase the
   likelihood that the signature will be valid upon receipt.

   Data that is ONLY to be encrypted is allowed to contain 8-bit
   characters and therefore need not be converted to a 7-bit format.

     Implementor's note: It cannot be stressed enough that applications
     using this standard should follow MIME's suggestion that you "be
     conservative in what you generate, and liberal in what you accept."
     In this particular case it means it would be wise for an
     implementation to accept messages with any content-transfer-
     encoding, but restrict generation to the 7-bit format required by
     this memo.  This will allow future compatibility in the event the
     Internet SMTP framework becomes 8-bit friendly.

4.  PGP encrypted data

   Before encryption with PGP, the data should be written in MIME
   canonical format (body and headers).

   PGP encrypted data is denoted by the "multipart/encrypted" content
   type, described in [1], and MUST have a "protocol" parameter value of

Elkins                      Standards Track                     [Page 2]
RFC 2015                 MIME Security with PGP             October 1996

   "application/pgp-encrypted".  Note that the value of the parameter
   MUST be enclosed in quotes.

   The multipart/encrypted MUST consist of exactly two parts.  The first
   MIME body part must have a content type of "application/pgp-
   encrypted".  This body contains the control information.  A message