[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PGP Partitioned Encoding Format

To: ietf-openpgp@xxxxxxx
Subject: PGP Partitioned Encoding Format
From: hal@xxxxxxxxxx ("Hal Finney")
Date: Mon, 28 Feb 2005 15:35:57 -0800 (PST)
List-archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-id: <ietf-openpgp.imc.org>
List-unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
Sender: owner-ietf-openpgp@xxxxxxxxxxxx
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@xxxxxxx
> From: Damon Cokenias <dcokenias@xxxxxxx>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> Soylent Green is PEOPLE!


Signed

> To: dcokenias@xxxxxxxxxxx
> From: Damon Cokenias <dcokenias@xxxxxxxxxxx>
> 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@xxxxxxx
> From: Damon Cokenias <dcokenias@xxxxxxx>
> 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@xxxxxxx
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@xxxxxxx>
> 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@xxxxxxx
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@xxxxxxx>
> 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@xxxxxxx
> Content-Type: multipart/mixed;
> 	boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@xxxxxxx>
> 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@xxxxxxx
> From: Damon Cokenias <dcokenias@xxxxxxx>
> 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@xxxxxxx
> From: Damon Cokenias <dcokenias@xxxxxxx>
> 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
Follow-Ups:
- Re: PGP Partitioned Encoding Format
  - From: Ingo Luetkebohle
Prev by Date: Re: Forward Secrecy
Next by Date: Re: PGP Partitioned Encoding Format
Previous by thread: OpenPGP Agenda for IETF-62
Next by thread: Re: PGP Partitioned Encoding Format
Index(es):
- Date
- Thread