One document matched: draft-elkins-pem-pgp-02.txt
Differences from draft-elkins-pem-pgp-01.txt
INTERNET DRAFT Michael Elkins
draft-elkins-pem-pgp-02.txt The Aerospace Corporation
elkins@aero.org
November 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 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.
Elkins Expires: May 1996 [Page 1]
INTERNET DRAFT MIME Security with PGP November, 1995
This document defines three new content types for implementing
security and privacy with PGP: application/pgp-encrypted,
application/pgp-signature and application/pgp-keys.
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 it is
necessary to REQUIRE that ALL data encrypted OR signed according to
this protocol be constrained to 7-bits (8-bit data should be encoded
using either Quoted-Printable or Base64). This restriction will
increase the likelihood that the signature will be valid upon
receipt.
4. PGP encrypted data
Before encryption with PGP, the data should be written in MIME
canonical format (body and headers).
PGP encrypted data is denoted by the "multipart/encrypted" content
type, described in [1], and REQUIRES a "protocol" parameter value of
"application/pgp-encrypted". Note that the value of the parameter
MUST be enclosed in quotes.
The multipart/encrypted MUST consist of exactly two parts. The
first MIME body part must have a content type of "application/pgp-
encrypted". The data portion of the body may be zero length or
contain human readable information about the encrypted data.
Elkins Expires: May 1996 [Page 2]
INTERNET DRAFT MIME Security with PGP November, 1995
The second MIME body part MUST contain the actual encrypted data.
It must be labeled with a content type of "application/octet-
stream".
Example message:
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=foo;
protocol="application/pgp-encrypted"
--foo
Content-Type: application/pgp-encrypted
--foo
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
-----END PGP MESSAGE-----
--foo--
5. PGP signed data
PGP signed messages are denoted by the "multipart/signed" content
type, described in [1], and REQUIRE the "protocol" parameter to have
a value of "application/pgp-signature" (MUST be quoted), and the
"micalg" parameter to have a value of "pgp-md5".
The multipart/signed body MUST consist of exactly two parts. The
first part contains the signed data in MIME canonical format,
including a set of appropriate content headers describing the data.
The second body MUST contain the PGP digital signature. It MUST be
labeled with a content type of "application/pgp-signature".
When the PGP digital signature is generated:
Elkins Expires: May 1996 [Page 3]
INTERNET DRAFT MIME Security with PGP November, 1995
(1) Each line of data MUST NOT contain any trailing whitespace, and
MUST end with a <CR><LF> sequence. When it is necessary to
preserve trailing whitespace, quoted-printable encoding of data
is recommended (the last whitespace octet will be encoded, thus
assuring compliance with this rule).
(2) As described in [1], the digital signature MUST be calculated
over both the data to be signed and its set of content headers.
(3) The signature MUST be generated detached from the signed data
so that the process does not alter the signed data in any way.
Example message:
From: Michael Elkins <elkins@aero.org>
To: Michael Elkins <elkins@aero.org>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
protocol="application/pgp-signature"
--bar
& Content-Type: text/plain; charset=us-ascii
& Content-Transfer-Encoding: 7bit
&
& Did you know that talking to yourself is a sign of senility?
&
& me
--bar
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
=ndaj
-----END PGP MESSAGE-----
--bar--
The "&"s in the previous example indicate the portion of the data
over which the signature was calculated.
Upon receipt of a signed message, trailing whitespace in lines MUST
be removed. It is assumed to be added during transmission since
Elkins Expires: May 1996 [Page 4]
INTERNET DRAFT MIME Security with PGP November, 1995
this protocol does not allow for it.
Though not required, it is generally a good idea to use Quoted-
Printable encoding in the first step (writing out the data to be
signed in MIME canonical format) if any of the lines in the data
begin with "From ", and encode the "F". This will avoid an MTA
inserting a ">" in front of the line, thus invalidating the
signature!
6. Encrypted and Signed Data
Sometimes it is desirable to to both digitally sign and then encrypt
a message to be sent. This protocol allows for two methods of
accomplishing this task.
6.1 RFC1847 Encapsulation
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, i.e.,
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted"; boundary=foo
--foo
Content-Type: application/pgp-encrypted
--foo
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
& Content-Type: multipart/signed; micalg=pgp-md5
& protocol="application/pgp-signature"; boundary=bar
&
& --bar
& Content-Type: text/plain; charset=us-ascii
&
& This message was first signed, and then encrypted.
&
& --bar
& Content-Type: application/pgp-signature
&
& -----BEGIN PGP MESSAGE-----
& ...
& -----END PGP MESSAGE-----
&
& --bar--
Elkins Expires: May 1996 [Page 5]
INTERNET DRAFT MIME Security with PGP November, 1995
-----END PGP MESSAGE-----
--foo--
(The text preceded by '&' indicates that it is really
encrypted, but presented as text for clarity.)
6.2 Combined method
Versions 2.x of PGP also allow data to be signed and encrypted in
one operation. This method is an acceptable shortcut, and has the
benefit of less overhead. The resulting data should be formed as a
"multipart/encrypted" object as described above.
Messages which are encrypted and signed in this combined fashion are
REQUIRED to follow the same canonicalization rules as for
multipart/signed objects (lines contain no trailing whitespace and
end with <CR><LF>).
It is explicitly allowed for an agent to decrypt a combined message
and rewrite it as a multipart/signed object using the signature data
embedded in the encrypted version.
7. 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.
8. Notes
PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
References
[1] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
RFC1847, 1994
[2] James Galvin, Gale Murphy, Steve Crocker, Ned Freed. MIME Object
Security Services. RFC1848, 1995
[3] Derek Atkins, William Stallings, Philip Zimmermann. PGP Message
Exchange Formats. draft-pgp-pgpformat-00.txt, 1995
Elkins Expires: May 1996 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 08:26:34 |