A few weeks ago I sent a message describing PGP Corporation's new
notation packet, used to distinguish PGP-MIME support from the legacy
"partitioned" format. I got some feedback from that, but I need to make
it clear that this is an informative comment and that PGP is using its
own private namespace for notation packets. PGP is trying to "play nice"
by using this namespace and not the global namespace which the working
group manages.
PGP-MIME is well documented but the partitioned format used by earlier
versions of PGP has not been clearly described. I am providing more
detailed documentation of the partitioned format which has been used by
previous and current versions of PGP software in this message. The new
notation packet can be used to indicate support for this partitioned
format and/or for PGP-MIME.
Hal Finney
PGP Corporation
======================================================================
PGP Partitioned Encoding Format Technote
Copyright 2004-2005 PGP Corporation
All Rights Reserved
Introduction
"Partitioned Encoding" refers generally to the way PGP software
encrypted email in the days before the PGP/MIME specification. No
equivalent specification exists for messages encoded with PGP software
from that era. Partitioned Encoding is a term given to the evolved form
of this method of encoding. The primary goals of all additions to the
Partitioned Encoding format are backwards compatibility and email client
compatibility. Whereas PGP/MIME represents "correct" Internet standard
behavior resulting in efficient but potentially incompatible behavior,
Partitioned Encoding holds as its only goal the ability for all that
came before to decrypt the format either automatically or manually. This
document describes the general format of such messages and details a
few special cases.
Although the preferred encoding for new messages is PGP/MIME, Partitioned
Encoding is still in use, and in some scenarios is the most desirable
format. Because all PGP software can decrypt Partitioned Encoding
messages, this format is the best choice when backward compatibility is
important. Partitioned encoding has evolved over the years, the dialect
described here is the format used by current PGP products (PGP Universal).
One other example where Partitioned Encoding is often the best encoding to
use is when sending PGP email to mobile devices. Because the two primary
standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
body of an email including attachments as one part, a mobile device is
prevented from downloading only specific segments of the message which
can be very desirable in low-bandwidth scenarios.
Partitioned Encoding Overview
Each MIME part of a message is processed individually resulting in an
encoded MIME message much like the original but with encrypted/signed
content. The overall structure of a message is generally retained. A
text message with three attachments encrypts to an encrypted text message
with three encrypted attachments. An email follows Partitioned Encoding
via the following algorithm:
For every MIME part in a message, starting with the first:
If the part is a multipart container:
recursively encode the sub-parts.
For all other part types>
If the part is text/plain
encrypt/sign the part.
If the part is binary or a text type other than plain:
encrypt/sign the part as an attachment
when encrypting, headers are X- prefixed to prevent mail clients from
interpreting them
when clear signing, corresponding <filename>.sig attachments are created
Each of these steps is further described below, with examples. For sake
of simplicity, not shown above is the special handling for the "Outlook
Plugin" dialect of Partitioned Encoding. This format is covered in a
separate section, below.
Example 1 shows a simple RFC-822 message and the resulting messages
after signing and encrypting. The straight-forward method used to encode
the email should be apparent. In both instances, the message content is
replaced by the PGP SDK output.
Example 1. A simple message
To: dcokenias(_at_)pgp(_dot_)com
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: Simple Message
Date: Mon, 1 Nov 2004 16:21:00 -0800
Soylent Green is PEOPLE!
Signed
To: dcokenias(_at_)pgp(_dot_)com(_dot_)com
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com(_dot_)com>
Subject: Simple Message
Date: Mon, 1 Nov 2004 16:21:00 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Soylent Green is PEOPLE!
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 1.2.2
iQA/AwUBQYwc3wNUXR15SGMCEQJQfACfYFtobpQgt7/U2FTsHyiLOVQB6tgAni3T
+Es5k0Bz4RGryRpM7CqxLqnw
=LC7J
-----END PGP SIGNATURE-----
Signed and Encrypted
To: dcokenias(_at_)pgp(_dot_)com
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: Simple Message
Date: Mon, 1 Nov 2004 16:21:00 -0800
-----BEGIN PGP MESSAGE-----
Version: PGP Universal 1.2.2
qANQR1DBwU4DjrZ+IglRIpQQB/4gPDVMliQnlJDeQmCiYe1iP56nZ476z0MB9vbI
OP3z0lypOxJ871vh2EXf3EGITSkay+KdEY2CpSV2alqiBf21S5GS0llZ61IvDGo1
gDyGiNGBkfNazAyNGYAYYkvNvjamPLmHfyqZqHEfCDDhqiIfXEIykUMImrFEHMsH
UIvc1aPKxoaFsmzsSinIRYYSOZ/Gx29xXhrJhxJMXaSsnMp2Np/cOqcH6gK8wDrN
FuurFRnW+up/O9iAw2moeOUqR2DocvRI7MJMkxArLCaGJL2zUxpIzRtedYlI8lRu
ZE5ROP2rdinDnNf4JoI+2TMigA1R8GZiEKNcWIko+dQlMBqdB/4nghxYYW/PMm/B
K47yrAqza8GxQEtzGDaOTsDioiH7bQThGG5qlna7odUTY4elHjNiT0qCHg0FCGZN
iE+uIMBOBFFmZFzDOnmMtp9vuPLmI1+YpaHDfbwX3tQV3hdj2RFC2ofHB5Eh5Mzm
9T+5QPV9iUQDcDkus0/+3P/TPmtvAL/QB5WPUuNX7piZbsp7pvQn9BvT2i/ulZDn
wPSoREhllnRjs3aTg5XrWkHFQ8I3QFfFhIVam9jHITwlAGkMmV7oK4flllAyK4Ui
vJ+PsCVejuC1ZmSBbb97sw26+jSvr+PLO5ftvAi0FFb6Q2Dx1nYaE9UbAHX9JbC2
0qneMzIS0lYBjO7LVgoBDD4ayRqwAuu3RXqAzm02/JSpsIbD5Gr3bcLdvdKVCrCT
IsCV2QEMYx4wiy3HjarYEO+z5Pztwcdx7PiTF8GAvMyfhmVxBpdqROM+Y6Jx0w==
=JZf0
-----END PGP MESSAGE-----
The second example, below, is more complex, showing a multipart message
composed of a text part and two binary attachments. Each MIME part
in the message is signed/encrypted separately. The text portion is
signed/encrypted exactly as in the first example. The binary attachments
get special treatment, however.
Signing/Encrypting Binary Parts
If the binary attachment being signed/encrypted does not have a filename,
it is given one. The attachment's name is "Attachment" + a number +
an extension. The number is a simple counter, starting at one, used to
ensure uniqueness. The extension is a three letter code inferred from
the part's MIME type. An anonymous binary attachment with Content-Type
of image/jpeg might be named "Attachment1.jpg", for example.
When a binary part is encrypted, the part's file name is hidden in
the encrypted data. The publicly-viewable name of an encrypted binary
part is always a generic name. Encrypted binary have a MIME type of
application/octet-stream. An encrypted part's headers are prefixed with
"X-Content-PGP-Universal-Saved-" to prevent them from being interpreted
by mail clients. When the part is decrypted, the process is reversed
and the original headers are reunited with the content. PGP products
before PGP Universal do not preserve these headers, but also generally
required manual opening of the attachments to decrypt them and thus no
functionality is lost for those scenarios.
When a binary part is clear-signed, a new attachment is created
to hold the signature. The MIME type of this attachment is
application/octet-stream. The signature attachment has the same name
as the signed part with ".sig" appended. These "detached signatures"
are base64 encoded.
Example 2. A more complex message
Mime-Version: 1.0
To: dcokenias(_at_)pgp(_dot_)com
Content-Type: multipart/mixed;
boundary="BOUNDARY-0000-1234"
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: New Products
Date: Mon, 1 Nov 2004 16:01:00 -0700
--BOUNDARY-0000-1234
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII
All,
Marketing materials for our new product line are enclosed. Please have
feedback ready by Thursday lunch!
--BOUNDARY-0000-1234
Content-Transfer-Encoding: base64
Content-Type: image/gif;
x-unix-mode=0644;
name="soylent-beige.gif"
Content-Disposition: inline;
filename=soylent-beige.gif
R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
. . . (cut) . . .
a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
Ow==
--BOUNDARY-0000-1234
Content-Transfer-Encoding: base64
Content-Type: image/gif;
x-unix-mode=0644;
name="soylent-taupe.gif"
Content-Disposition: inline;
filename=soylent-taupe.gif
R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
. . . (cut) . . .
a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
Ow==
--BOUNDARY-0000-1234--
Signed
Mime-Version: 1.0
To: dcokenias(_at_)pgp(_dot_)com
Content-Type: multipart/mixed;
boundary="BOUNDARY-0000-1234"
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: New Products
Date: Mon, 1 Nov 2004 16:01:00 -0700
--BOUNDARY-0000-1234
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
Marketing materials for our new product line are enclosed. Please have
feedback ready by Thursday lunch!
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 1.2.2
iQA/AwUBQZEXQmMQlGdKg9VZEQLl6QCgwFM2xtYzN0mJWcK9eYkU0ejiUqsAoOr6esBx8e1X
mGBERfNK9ff0adY7
-----END PGP SIGNATURE-----
--BOUNDARY-0000-1234
Content-Transfer-Encoding: base64
Content-Type: image/gif;
x-unix-mode=0644;
name="soylent-beige.gif"
Content-Disposition: attachment;
filename=soylent-beige.gif
R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
. . . (cut) . . .
a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
Ow==
--BOUNDARY-0000-1234
Content-Transfer-Encoding: base64
Content-Type: image/gif;
x-unix-mode=0644;
name="soylent-taupe.gif"
Content-Disposition: attachment;
filename=soylent-taupe.gif
R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
. . . (cut) . . .
Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
Ow==
--BOUNDARY-0000-1234
Content-Type: application/octet-stream;
name="soylent-beige.gif.sig"
Content-Disposition: attachment;
filename="soylent-beige.gif.sig"
Content-Transfer-Encoding: base64
iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5dMjmJEnqAHpUrCKP/Xu8pB8JCgAn2shn2AKp913
HAJt+LwN0AdtSDn3
--BOUNDARY-0000-1234
Content-Type: application/octet-stream;
name="soylent-taupe.gif.sig"
Content-Disposition: attachment;
filename="soylent-taupe.gif.sig"
Content-Transfer-Encoding: base64
iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5BusKlATEhfNiRbGhSlrUYlbPg4AnRLoX03Vo48H
NoWukVfqSGyiQFV+
--BOUNDARY-0000-1234--
Signed and Encrypted
Mime-Version: 1.0
To: dcokenias(_at_)pgp(_dot_)com
Content-Type: multipart/mixed;
boundary="BOUNDARY-0000-1234"
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: New Products
Date: Mon, 1 Nov 2004 16:01:00 -0700
--BOUNDARY-0000-1234
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII
-----BEGIN PGP MESSAGE-----
Version: 0
qANQR1DBwEwD42FWyEinTuQBB/wKGj60HNiMWCFZckprmNCIFSkfD0ZpRyYg0L65
bbydP5KnPo266C5CEy4T11E2Xp11tMh6WjvRqalV8FDONpFLhV89k2JvX+rQ6W+o
nbd5cW5XiflO2+5t/IlMdzSrdpr2Wn9GgZss0T/5FA7E1ayj2SNjffIVfKuXHDEk
. . . (cut) . . .
Td3A+VZ7VWkJPQKruA+IMnShEUsaFcfVSkpylSzwrcL1g5M7We1LGHgtGXT/ejJ0
H3FeNtDw97dsmcc9oNFOHqwvQPt+h5dQfi3fGsT8Lw45VAePRjezZOn1zfVlf3Rc
idkUaO2aW9A=
=RqCL
-----END PGP MESSAGE-----
--BOUNDARY-0000-1234
X-Content-PGP-Universal-Saved-Content-Disposition: inline;
filename="Attachment1.pgp"
X-Content-PGP-Universal-Saved-Content-Type: image/gif;
x-unix-mode=0644;
name="Attachment1.pgp"
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
Content-Type: application/octet-stream;
name="Attachment1.pgp"
Content-Disposition: attachment;
filename="Attachment1.pgp"
-----BEGIN PGP MESSAGE-----
Version: 0
qANQR1DBwEwD42FWyEinTuQBB/9yRpLW7rIulg2VxJTZps+MghHEaBptaYfA24Rf
RvGv0y0xQDEpFYB5BY4BBbgUK+124K4c4ulaMGRMqsbqwTtzedUvqzuWEIqLdrhE
437c3hev2b3MiG/gVLz07O9S0FgZ1GxzTywWiCJSNIO1pKSRXN1BwDD2Yy7MLh9m
4uxYZzMMr0QTonzf1RoDCWm0tPL8n2sSR4D96yw+c0+FaFmPUEWtdHl43D1n752Y
. . . (cut) . . .
1p5271ir9IBuQnHGd9azBhAxV+MndAcwhW006FF0H2Aw1DUWwJGA8ebXyVs8/Lp+
nQYVAc88tl6seKo3dPCMGlTaBbVbmSHoqJadhqf6zl5+6nnFAlT31UmPlfOz
=h4y5
-----END PGP MESSAGE-----
--BOUNDARY-0000-1234
X-Content-PGP-Universal-Saved-Content-Disposition: inline;
filename="Attachment2.pgp"
X-Content-PGP-Universal-Saved-Content-Type: image/gif;
x-unix-mode=0644;
name="Attachment2.pgp"
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
Content-Type: application/octet-stream;
name="Attachment2.pgp"
Content-Disposition: attachment;
filename="Attachment2.pgp"
-----BEGIN PGP MESSAGE-----
Version: 0
qANQR1DBwEwD42FWyEinTuQBB/0bA0TCswweIaDGLJXpTsrlMpEhCmNjGh53qeek
/4r1XEwYPRVho/lUAaxtDNJ3mcAXekdlLxAtxdDRpypdRUz7yjPtcEB7P9wN8uWf
7AylCYd7ABvFmerenRZZ7Bc9TjHJWxnuoUWDsKlfeaOxqNgeiSZY4Q20HY0YZnTI
. . . (cut) . . .
D0urDVE2fFlpxjLPrPBrKf7wbo1+3ZUHjOgeElQTgChMOF5SgizEJlk2OLZoq/IO
Ktu7v7jcQGPsKEyOC0Dzzhn33AeB06cU1sJV7gha6vrn0qfIXZQmGk3mzf4=
=N7Wi
-----END PGP MESSAGE-----
--BOUNDARY-0000-1234--
HTML and RTF Encoding
PGP messages created by the PGP Plugin for Outlook (Windows) originally
defined a special attachment for storing HTML and RTF content for
compatibility purposes. PGP Universal has adopted this same formatting
for all HTML and RTF messages when using Partitioned Encoding. These
messages are readily identified by the presence of an attachment
called "PGPexch.htm.pgp", "PGPexch.htm.asc", "PGPexch.rtf.pgp" or
"PGPexch.rtf.asc". The attachment contains the encrypted RTF or HTML
portion of a multipart/alternative message.
This encoding should be used when signing/encrypting a
multipart/alternative message composed of exactly one plain text part and
one HTML part. Doing so ensures maximum compatibility for Windows users
with older PGP software. A multipart/alternative part with plain/html
subparts will become a multipart/mixed with an encrypted plain subpart
and an encrypted HTML attachment. A special header ("X-PGP-MIME-Structure:
alternative") is added to indicate this transformation was performed. This
header is not required for proper decoding.
When decrypting such messages, the "PGPexch.htm.pgp" or "PGPexch.htm.asc"
attachment will become the HTML alternative for the main body
text. Because RTF is not used for Internet mail, do not make RTF
attachments part of the message body. The RTF should be decrypted, but
should remain an attachment. The RTF attachment is useful only to Outlook.
Example 3. A multipart/alternative message with html and text parts
Mime-Version: 1.0
To: dcokenias(_at_)pgp(_dot_)com
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: Outlook Encoding
Date: Mon, 1 Nov 2004 16:21:00 -0800
Content-Type: multipart/alternative;
boundary="BOUNDARY-0000-1234"
This is a multipart message in MIME format.
--BOUNDARY-0000-1234
Content-Type: text/plain
Soylent Green is PEOPLE!
--BOUNDARY-0000-1234
Content-Type: text/html;
charset=US-ASCII
<html><body bgcolor="black" text="green">
Soylent Green is <b>PEOPLE!</b>
</body></html>
--BOUNDARY-0000-1234--
Signed and Encrypted
Mime-Version: 1.0
To: dcokenias(_at_)pgp(_dot_)com
From: Damon Cokenias <dcokenias(_at_)pgp(_dot_)com>
Subject: Outlook Encoding
Date: Mon, 1 Nov 2004 16:21:00 -0800
Content-Type: multipart/mixed;
boundary="BOUNDARY-0000-1234"
This is a multipart message in MIME format.
--BOUNDARY-0000-1234
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
Version: 0
qANQR1DBwEwD42FWyEinTuQBB/9KEBufHfz139ZuQCBushTxOenNzF5QzgqLkfTB
h1a6y9XOfp1lox0Unx2s0cDcD1Vq2Ca/1kJvpYuPdnKyhwHSUZK9sE1RMSLM9sj/
ng1FMHemyNb5NN+8T5jYFEE8KQlrNwpJfHXTgOkmeBrH749I2oHV/yhezYI9YqKI
. . . (cut) . . .
yIbvwHvS6HJeLjUylmRX+hplo2k/31JVg4b52z9Od3XEPptMYpvEKkpJUve6b3P2
uLdxaT3vKep15UcdqitsbVVISxr6XZ+DZq4NKkrR73tt4eLhQlTWgZoYgac6QLuM
Cg==
=NOiI
-----END PGP MESSAGE-----
--BOUNDARY-0000-1234
X-Content-PGP-Universal-Saved-Content-Type: text/html;
charset=US-ASCII
Content-Type: application/octet-stream;
name="PGPexch.htm.pgp"
Content-Disposition: attachment
X-PGP-MIME-Structure: alternative
-----BEGIN PGP MESSAGE-----
Version: 0
qANQR1DBwEwD42FWyEinTuQBB/467rWcjfuimgRk44ifIqog/CpjSlitDbv/T+Kr
JZqgEBP5CxwiO8G/Bgf2PpYOz2iiTDRycfFgwOktmkBvAYSatipSCwAWJ/UPcXXA
uqQEnKyq+tZIibE9fDrbzObvgIHbe2M7HofiobQ0UAVb3/KaQphRM2sJ0ATotIbp
. . . (cut) . . .
TjQiuNqJfYlyWUrPUg7dTeSdSOnIm/zqLVQxm/+NB9SWaY+G3eqqBg6M/ytNaUwd
jjBHOHh+6wPfkegmWP/8wxI58n6SV9d5OQ==
=aD+v
-----END PGP MESSAGE-----
--BOUNDARY-0000-1234--
References
RFC 2440 OpenPGP Message Format
RFC 3156 MIME Security with Pretty Good Privacy