RFC 2015 (rfc2015) - Page 2 of 8
MIME Security with Pretty Good Privacy (PGP)
Alternative Format: Original Text Document
RFC 2015 MIME Security with PGP October 1996
2. PGP data formats
PGP can generate either ASCII armor (described in [3]) or 8-bit
binary output when encrypting data, generating a digital signature,
or extracting public key data. The ASCII armor output is the
REQUIRED method for data transfer. This allows those users who do
not have the means to interpret the formats described in this
document to be able extract and use the PGP information in the
message.
When the amount of data to be transmitted requires that it be sent in
many parts, the MIME message/partial mechanism should be used rather
than the multipart ASCII armor PGP format.
3. Content-Transfer-Encoding restrictions
Multipart/signed and multipart/encrypted are to be treated by agents
as opaque, meaning that the data is not to be altered in any way [1].
However, many existing mail gateways will detect if the next hop does
not support MIME or 8-bit data and perform conversion to either
Quoted-Printable or Base64. This presents serious problems for
multipart/signed, in particular, where the signature is invalidated
when such an operation occurs. 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). Note
that this also includes the case where a signed object is also
encrypted (see section 6). This restriction will increase the
likelihood that the signature will be valid upon receipt.
Data that is ONLY to be encrypted is allowed to contain 8-bit
characters and therefore need not 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 encryption 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], and MUST have a "protocol" parameter value of
Elkins Standards Track