MIME Security with Pretty Good Privacy (PGP) (RFC2015)
Original Publication Date: 1996-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
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.
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.
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.
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.
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.
2. PGP data formats
PGP can generate either ASCII armor (described in ) 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
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 .
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 op...