INTERNET DRAFT Michael Elkins
draft-elkins-pem-pgp-00.txt The Aerospace Corporation
[email protected]
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]
