MIME Security with Pretty Good Privacy (PGP)
RFC 2015
Document | Type |
RFC - Proposed Standard
(October 1996; Errata)
Updated by RFC 3156
Was draft-elkins-pem-pgp (individual)
|
|
---|---|---|---|
Author | Michael Elkins | ||
Last updated | 2020-01-21 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2015 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 messageShow full document text