MIME Security with OpenPGP
updates
- rfc-2015 — MIME Security with Pretty Good Privacy (PGP)
Extracted elements (25)
The 7-bit restriction and trailing whitespace removal are necessary to make the hash invariant under both text and binary mode signature mechanisms provided by OpenPGP, and to avoid compatibility problems with pre-OpenPGP PGP implementations.
The combined sign+encrypt method is allowed (in addition to RFC 1847 encapsulation) to reduce processing overhead and increase compatibility with non-MIME implementations of OpenPGP.
The use of multipart/signed and multipart/encrypted (from RFC 1847) cleanly separates the signed message body from the signature, enabling recovery of signed message bodies without parsing PGP-specific data structures — a key deficiency in earlier PGP/MIME approaches predating RFC 2015.
If any line begins with "From ", it is strongly suggested that Quoted-Printable or Base64 encoding be applied, because many MTAs insert a ">" before such lines, which would invalidate the signature.
All data signed according to this protocol MUST be constrained to 7 bits; 8-bit data MUST be encoded using either Quoted-Printable or Base64. This applies even when the signed object is also encrypted.
ASCII armor output is the REQUIRED method for data transfer when encrypting data, generating a digital signature, or extracting public key data. This allows users without OpenPGP-aware tools to extract and use the information.
Implementations MUST ensure that no trailing whitespace is present after the MIME encoding has been applied to signed data. Whitespace-only header lines must be removed entirely rather than replaced by empty lines.
Messages which are encrypted and signed in the combined OpenPGP fashion are REQUIRED to follow the same canonicalization rules as multipart/signed objects.
OpenPGP encrypted data MUST use the multipart/encrypted content type with a "protocol" parameter value of "application/pgp-encrypted" (enclosed in quotes).
OpenPGP signed messages MUST use multipart/signed with a "protocol" parameter value of "application/pgp-signature" (MUST be quoted). The "micalg" parameter MUST contain exactly one hash-symbol of the format "pgp-<hash-identifier>".
The OpenPGP digital 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: (1) convert line endings to the canonical <CR><LF> sequence before verifying the signature; (2) pass both the signed data, its content headers, and the OpenPGP signature to the signature verification service.
When data to be transmitted must be sent in many parts, the MIME message/partial mechanism SHOULD be used rather than multi-part ASCII armor OpenPGP format.
When generating an OpenPGP digital signature: (1) data MUST first be converted to canonical form; (2) Content-Transfer-Encoding applied with <CR><LF> line endings; (3) MIME content headers added; (4) trailing whitespace MUST be removed; (5) signature MUST be calculated over both data and its content headers.
For sign-then-encrypt using RFC 1847 encapsulation, the data is first signed as a multipart/signed body and then encrypted to form the final multipart/encrypted body. This method is most useful for standard MIME-compliant message forwarding.
The application/pgp-keys content type carries ASCII-armored transferable Public Key Packets as defined in RFC 2440 section 10.1. It has no required or optional parameters.
The combined method allows signing and encrypting data in a single OpenPGP message (as defined in the OpenPGP packet format), formatted as a multipart/encrypted object. An agent MAY decrypt a combined message and rewrite it as a multipart/signed object.
The multipart/encrypted MIME body MUST consist of exactly two body parts: the first with content type "application/pgp-encrypted" containing a "Version: 1" control field, and the second with content type "application/octet-stream" containing the actual encrypted data.
The multipart/signed body MUST consist of exactly two parts: the first containing the signed data in MIME canonical format with appropriate content headers, and the second labeled application/pgp-signature containing the OpenPGP digital signature.
This document registers the "application/pgp-encrypted" MIME media type. It always consists of a single 7-bit text string (the "Version: 1" control information), has no required or optional parameters, and is intended for common use.
This document registers the "application/pgp-keys" MIME media type for conveying ASCII-armored OpenPGP public keys. Content always consists of 7-bit text; file extension is .asc. Intended for common use.
This document registers the "application/pgp-signature" MIME media type. Content always consists of 7-bit text; file extensions are .asc and .sig; Macintosh File Type Code is pgDS. Intended for common use.
Signatures of a canonical text document (as defined in the OpenPGP specification) ignore trailing white space in signed material. Implementations using canonical text document signatures will not be able to detect the addition of whitespace in transit.
The application/pgp-encrypted body part contains only the line "Version: 1". The application/octet-stream body part contains the ASCII-armored OpenPGP encrypted message beginning with "-----BEGIN PGP MESSAGE-----".
The micalg hash-symbol for application/pgp-signature is formed by converting the OpenPGP text name to lower case and prefixing with "pgp-". Defined values include "pgp-md5", "pgp-sha1", "pgp-ripemd160", "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".