INTERNET DRAFT Michael Elkins draft-elkins-pem-pgp-00.txt The Aerospace Corporation elkins@aero.org September 1995 MIME Security with Pretty Good Privacy (PGP) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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 RFCXXXX (draft-ietf-pem-sigenc-03.txt). 1. Introduction This document is based on RFCXXXX [1] which defines security mechanisms for MIME messages, and specifically addresses how PGP can be used within this framework in order to effect it. This document is styled after RFCXXXX [2], which defines MIME Object Security Services (MOSS) for providing security and authentication. This work was prompted by the fact that implementations of MOSS may not be availible outside of the U.S. because of export restrictions. PGP, on the other hand, is widely availible throughout the world (with a few notable exceptions), and is gaining support as the de- facto standard for electronic mail privacy. This document defines three new content types form implementing security and privacy with Elkins Expires: February 1996 [Page 1]
INTERNET DRAFT MIME Security with PGP September, 1995 PGP: application/pgp-encrypted, application/pgp-signature and application/pgp-keys. 2. PGP encrypted data Content-Type: multipart/encrypted Required parameters: boundary, protocol Optional parameters: none <boundary> ::=3D "boundary" "=3D" <message boundary> <protocol> ::=3D "protocol" "=3D" "application/pgp-encrypted" The multipart/encrypted must consist of exactly two parts, as described in [1]. The first MIME body part must have a content type of "application/pgp-encrypted". No other requirements are made of this body. The second MIME body part contains the actual encrypted data. It must be labeled with a content type of "application/octet-stream". Before encryption with PGP, the data should be properly formed into a MIME body (encoded and with headers). In this way, it is possible to nest any type of data within this framework. As specified in [1], if the message is ever to be transmitted over the Internet SMTP infrastructure, the resulting MIME body is constrained to 7 bits. Implementor's note: Since PGP can be made to output either 8bit or 7bit (via an internal BASE64 encoding controlled by the "-a" option) encrypted data, it is completely up to the implementor which method to use. In order to be fully compliant, a client must support decoding of both forms when displaying data to the user. 3. PGP signed data Content-Type: multipart/signed Required parameters: boundary, protocol, micalg Optional parameters: none <boundary> ::=3D "boundary" "=3D" <MIME multipart boundary> <protocol> ::=3D "protocol" "=3D" "application/pgp-signature" <micalg> ::=3D "micalg" "=3D" "none" The multipart/signed content type must consist of exactly two parts. Elkins Expires: February 1996 [Page 2]
INTERNET DRAFT MIME Security with PGP September, 1995 The first MIME body is the data to be signed. It may consist of any legal MIME data. The second body contains the PGP digital signature. It must be labeled with a content type of "application/pgp-signature". As described in [1], the digital signature should be over the complete first MIME body of the multipart/signed data, which includes the MIME headers for that part. It is again important to note that the resulting MIME body is contrained to 7 bits if it is to be delivered via SMTP (see [1] for details). 4. Encrypted and Signed Data Sometimes it is desirable to to both digitally sign and then encrypt a message to be sent. In [1], it is stated that the data should first be signed as a multipart/signature body, and then encrypted to form the final multipart/encrypted body. But PGP also has the ability to embed the signature into the encrypted data block. The end result is the same information, so either method is acceptable. 5. Distribution of PGP public keys Content-Type: application/pgp-keys Required parameters: none Optional parameters: none This is the content type which should be used for relaying public key blocks. Implementor's note: As with PGP encrypted data, you have the option of doing 7bit conversion yourself, or allowing PGP to do it (via the "-a" option). To be fully compliant, a client must support both forms when displaying the data to the user. References [1] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. RFCXXXX (draft-ietf-pem-sigenc-03.txt) 1994 [2] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. MIME Object Security Services. RFCXXXX (draft-ietf-pem-mime-08.txt) 1995 Elkins Expires: February 1996 [Page 3]