MIME Security with Pretty Good Privacy (PGP)
updated by
- rfc-3156 — MIME Security with OpenPGP
Extracted elements (22)
ASCII armor is required (rather than binary) so that users without PGP software can still extract and use the PGP data embedded in a message. When large data must be split into parts, MIME message/partial should be used instead of PGP's own multipart ASCII armor format.
PGP 2.x supports a combined sign-and-encrypt operation in a single pass, which is an acceptable shortcut with less overhead than RFC 1847 encapsulation. The resulting data is formatted as a multipart/encrypted object; an agent may later rewrite it as multipart/signed using the embedded signature.
Previous work integrating PGP with MIME suffered from the inability to recover signed message bodies without parsing PGP-specific data structures. RFC 2015 addresses this by using the RFC 1847 security multipart formats, which cleanly separate the signed body from the signature.
Lines beginning with 'From ' in signed data should have the 'F' encoded (e.g., using Quoted-Printable) to prevent MTAs from inserting a '>' prefix, which would invalidate the signature. Trailing whitespace should also be encoded to survive BITNET-style gateways.
Many existing mail gateways will convert data to Quoted-Printable or Base64 when the next hop does not support MIME or 8-bit data. This conversion invalidates multipart/signed signatures, which is why signed data must be restricted to 7 bits.
All data signed according to this protocol MUST be constrained to 7 bits; 8-bit data must be encoded using Quoted-Printable or Base64. This applies even when a signed object is also encrypted.
ASCII armor output is the REQUIRED method for PGP data transfer in MIME messages. This allows recipients without PGP capabilities to extract and use the PGP information.
Messages encrypted and signed using PGP's combined method are REQUIRED to follow the same canonicalization rules as for multipart/signed objects.
The multipart/encrypted body MUST consist of exactly two parts: the first with content type application/pgp-encrypted containing a 'Version: 1' field, and the second with content type application/octet-stream containing the actual encrypted data.
The multipart/encrypted content type MUST have a 'protocol' parameter value of "application/pgp-encrypted" (the value MUST be enclosed in quotes).
The multipart/signed body MUST consist of exactly two parts: the first containing the signed data in MIME canonical form with appropriate content headers, and the second labeled application/pgp-signature containing the PGP digital signature.
The multipart/signed 'protocol' parameter MUST have a value of "application/pgp-signature" (MUST be quoted), and the 'micalg' parameter MUST have a value of "pgp-<hash-symbol>" where defined values are "pgp-md5" and "pgp-sha1".
The PGP digital signature MUST be calculated over both the data to be signed and its set of MIME content headers. Each line of encoded data MUST end with the canonical <CR><LF> sequence.
The PGP signature MUST be generated detached from the signed data so that the signing process does not alter the signed data in any way.
Upon receipt of a signed message, an application MUST convert line endings to canonical <CR><LF> before verifying the signature, since the local MTA may have converted to a local line-ending convention.
For combined sign-then-encrypt per RFC 1847, the data is first signed as multipart/signed, then that entire multipart is encrypted to form the outer multipart/encrypted body. This is the preferred encapsulation order.
RFC 2015 defines three new MIME content types for PGP security: application/pgp-encrypted (for encrypted data control and payload), application/pgp-signature (for detached digital signatures), and application/pgp-keys (for public key distribution).
The application/pgp-keys content type is defined for relaying PGP public key blocks. It has no required or optional parameters.
This document registers three new MIME content types: application/pgp-encrypted, application/pgp-signature, and application/pgp-keys. It also defines micalg values 'pgp-md5' and 'pgp-sha1' for use in multipart/signed.
Use of this protocol has the same security considerations as PGP itself and is not known to increase or decrease the security of messages using it. Implementors are referred to RFC 1991 (PGP Message Exchange Formats) for details.
Signing procedure: (1) convert data to canonical form with <CR><LF> line endings; (2) apply Content-Transfer-Encoding with <CR><LF> per line; (3) prepend MIME content headers each ending with <CR><LF>; (4) compute detached PGP signature over headers+body; (5) encode signature as ASCII armor in second body part.
The multipart/encrypted message consists of two body parts: part one is application/pgp-encrypted containing only 'Version: 1'; part two is application/octet-stream containing the ASCII-armored PGP ciphertext (BEGIN PGP MESSAGE ... END PGP MESSAGE).