MIME Security with OpenPGP
RFC 3156
Document | Type |
RFC - Proposed Standard
(August 2001; No errata)
Updates RFC 2015
|
|
---|---|---|---|
Authors | Thomas Roessler , Michael Elkins , Raph Levien , Dave Torto | ||
Last updated | 2020-07-29 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3156 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group M. Elkins Request for Comments: 3156 Network Associates, Inc. Updates: 2015 D. Del Torto Category: Standards Track CryptoRights Foundation R. Levien University of California at Berkeley T. Roessler August 2001 MIME Security with OpenPGP 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. 1. Introduction Work on integrating PGP (Pretty Good Privacy) with MIME [3] (including the since withdrawn "application/pgp" content type) prior to RFC 2015 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. RFC 2015 makes use of the elegant solution proposed in RFC 1847, 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 revises RFC 2015 to adopt the integration of PGP and MIME to the needs which emerged during the work on the OpenPGP specification. This document defines three content types for implementing security and privacy with OpenPGP: "application/pgp-encrypted", "application/pgp-signature" and "application/pgp-keys". Elkins, et al. Standards Track [Page 1] RFC 3156 MIME Security with OpenPGP August 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. OpenPGP data formats OpenPGP implementations can generate either ASCII armor (described in [1]) 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 to extract and use the OpenPGP 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 multi-part ASCII armor OpenPGP 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 [2], [7]. 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 MUST 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. Additionally, implementations MUST make sure that no trailing whitespace is present after the MIME encoding has been applied. Note: In most cases, trailing whitespace can either be removed, or protected by applying an appropriate content-transfer-encoding. However, special care must be taken when any header lines - either in MIME entity headers, or in embedded RFC 822 headers - are present which only consist of whitespace: Such lines must be removed entirely, since replacing them by empty lines would turn them into header delimiters, and change the semantics of the message. The restrictions on whitespace are necessary in order to make the hash calculated invariant under the text and binary mode signature mechanisms provided by OpenPGP [1]. Also, they help toShow full document text