RFC 2015

MIME Security with Pretty Good Privacy (PGP) 🎀

Okay bestie, so this is RFC 2015 ✨, and it's all about using PGP for privacy and authentication inside MIME. It was written by M. Elkins from The Aerospace Corporation, it's on the Standards Track, and it's dated October 1996 🦋. The header doesn't list anything it obsoletes or updates, so it's standing on its own, no cap 💅.

Status of This Memo 🌸

This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜.

Abstract 🦋

This doc explains how Pretty Good Privacy (PGP) can give you privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847 🔐.

1. Introduction ✨

Okay so, earlier attempts to mix PGP with MIME (including the application/pgp content type, which has since been withdrawn 💀) ran into a big problem: you couldn't get the signed message body back out without parsing data structures that are specific to PGP 😭. This work uses the elegant fix proposed in RFC1847, which defines security multipart formats for MIME. Those security multiparts clearly separate the signed message body from the signature, and they have a bunch of other desirable properties 💅. This document is styled after RFC 1848, which defines MIME Object Security Services (MOSS) for providing security and authentication 🧚.

This doc defines three new content types for doing security and privacy with PGP: application/pgp-encrypted, application/pgp-signature and application/pgp-keys 🌈.

1.1. Compliance 🙈

To be compliant with this specification, an implementation is absolutely necessary to obey all items labeled as MUST or REQUIRED. No skipping, bestie 😤.

2. PGP data formats 🍓

PGP can generate either ASCII armor (described in [3]) or 8-bit binary output when it's encrypting data, generating a digital signature, or extracting public key data. ASCII armor is the REQUIRED method for data transfer 🔥. That way, users who don't have the means to interpret the formats described in this document can still extract and use the PGP information in the message 🫶.

When the amount of data to be transmitted means it has to be sent in many parts, the MIME message/partial mechanism should be used instead of the multipart ASCII armor PGP format 🧩.

3. Content-Transfer-Encoding restrictions 🚧

So multipart/signed and multipart/encrypted are supposed to be treated by agents as opaque, which means the data can't be altered in any way [1] 🔒. However, lots of existing mail gateways will check if the next hop doesn't support MIME or 8-bit data, and then they'll convert things to Quoted-Printable or Base64. This is a serious mess for multipart/signed especially, because the signature gets invalidated when that conversion happens 💀. So for this reason, all data signed according to this protocol MUST be constrained to 7 bits (8-bit data should be encoded using either Quoted-Printable or Base64) 🎀. This also covers the case where a signed object is also encrypted (see section 6). This restriction makes the signature way more likely to still be valid when it arrives ✨.

Data that is ONLY going to be encrypted is allowed to have 8-bit characters, so it doesn't need to be converted to a 7-bit format 🌸.

Implementor's note: It cannot be stressed enough that applications using this standard should follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case it means it would be wise for an implementation to accept messages with any content-transfer-encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the Internet SMTP framework becomes 8-bit friendly 🥹.

4. PGP encrypted data 🔐

Before encrypting 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]. It MUST have 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", and this body contains the control information. A message complying with this standard MUST contain a "Version: 1" field in this body 🏷️. Since the PGP packet format already contains all the other information needed for decrypting, no other information is required here 🧠.

The second MIME body part MUST contain the actual encrypted data. It must be labeled with a content type of "application/octet-stream" 🦋.

Here's an 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

     Version: 1

     --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], with a "protocol" parameter which MUST have a value of "application/pgp-signature" (and it MUST be quoted, no exceptions 🙅). The "micalg" parameter MUST have a value of pgp-<hash-symbol>, where <hash-symbol> identifies the message integrity check (MIC) used to generate the signature 🔑. The currently defined values for <hash-symbol> are "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm 🧁.

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, you go through these steps 🪄:

1. The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical <CR><LF> sequence.
2. An appropriate Content-Transfer-Encoding is then applied. Each line of the encoded data MUST end with the canonical <CR><LF> sequence.
3. MIME content headers are then added to the body, each ending with the canonical <CR><LF> sequence.
4. As described in [1], the digital signature MUST be calculated over both the data to be signed and its set of content headers.
5. The signature MUST be generated detached from the signed data so that the process does not alter the signed data in any way.

Here's an 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=iso-8859-1
     & Content-Transfer-Encoding: quoted-printable
     &
     & =A1Hola!
     &
     & Did you know that talking to yourself is a sign of senility?
     &
     & It's generally a good idea to encode lines that begin with
     & From=20because some mail transport agents will insert a greater-
     & than (>) sign, thus invalidating the signature.
     &
     & Also, in some cases it might be desirable to encode any   =20
     &railing whitespace that occurs on lines in order to ensure  =20
     & that the message signature is not invalidated when passing =20
     & a gateway that modifies such whitespace (like BITNET). =20
     &
     & 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 that example are how you can spot the exact portion of the data that the signature was calculated over 🔍.

Though it's not required, it's 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". That way an MTA won't insert a ">" in front of the line and invalidate the signature! 😱

Upon receipt of a signed message, an application MUST:

1. Convert line endings to the canonical <CR><LF> sequence before the signature can be verified. This is necessary since the local MTA may have converted to a local end of line convention 📏.
2. Pass both the signed data and its associated content headers along with the PGP signature to the signature verification service 🛎️.

7. Distribution of PGP public keys ✨

okay so this section is short but it's giving main character energy 💅 when you want to pass around PGP public key blocks, you use the content type application/pgp-keys 🔑

here's the lowdown:

Content-Type: application/pgp-keys
Required parameters: none
Optional parameters: none

no required params, no optional params, just vibes 🫶 and this is the content type that should be used for relaying public key blocks. iykyk 🌸

8. Notes 📝

PGP and Pretty Good Privacy are trademarks of Philip Zimmermann. ™️ we love a legend 👑

9. Security Considerations 🔐

okay bestie, this part is SUPER important so pay attention 🥺

Use of this protocol has the same security considerations as PGP, and is not known to either increase or decrease the security of messages using it; see [3] for more information.

so basically this protocol is exactly as secure as PGP is, and it's not known to make messages safer OR less safer 😭 for the full tea, go check out [3] 💜

10. Author's Address 📮

Michael Elkins 🎀

P.O. Box 92957 - M1/102
Los Angeles, CA 90009-2957

Phone: +1 310 336 8040
Fax: +1 310 336 4402

References 📚

[1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
     Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
     RFC 1847, October 1995.

[2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
     Security Services", RFC 1848, October 1995.

[3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
     Exchange Formats", RFC 1991, August 1996.

that's a wrap on RFC 2015! 🦋🌈