Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
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: 2000-Sep-13
Document File: 7 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Elkins: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 23% 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.

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