Browse Prior Art Database

MIME Security with Pretty Good Privacy (PGP) (RFC2015)

IP.com Disclosure Number: IPCOM000002568D
Original Publication Date: 1996-Oct-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 8 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Elkins: AUTHOR

Related Documents

10.17487/RFC2015: DOI

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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

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

Processing...
Loading...