GENWiki

Network Working Group M. Elkins Request for Comments: 2015 The Aerospace Corporation Category: Standards Track October 1996

            MIME Security with Pretty Good Privacy (PGP)

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 This document describes how Pretty Good Privacy (PGP) can be used to
 provide privacy and authentication using the Multipurpose Internet
 Mail Extensions (MIME) security content types described in RFC1847.

1. Introduction

 Previous work on integrating PGP with MIME (including the since
 withdrawn application/pgp content type) has suffered from a number of
 problems, the most significant of which is the inability to recover
 signed message bodies without parsing data structures specific to
 PGP.  This work makes use of the elegant solution proposed in
 RFC1847, which defines security multipart formats for MIME. The
 security multiparts clearly separate the signed message body from the
 signature, and have a number of other desirable properties. This
 document is styled after RFC 1848, which defines MIME Object Security
 Services (MOSS) for providing security and authentication.

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

1.1 Compliance

 In order for an implementation to be compliant with this
 specification, is it absolutely necessary for it to obey all items
 labeled as MUST or REQUIRED.

Elkins Standards Track [Page 1] 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 [Page 2] RFC 2015 MIME Security with PGP October 1996

 "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".  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 contains all other
 information necessary 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".

 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" (MUST be quoted).  The "micalg"

Elkins Standards Track [Page 3] RFC 2015 MIME Security with PGP October 1996

 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:

 (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.

 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?
   &

Elkins Standards Track [Page 4] RFC 2015 MIME Security with PGP October 1996

   & 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 the previous example indicate the portion of the data
 over which the signature was calculated.

 Though not required, it is 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".  This will avoid an MTA
 inserting a ">" in front of the line, thus invalidating 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.

Elkins Standards Track [Page 5] RFC 2015 MIME Security with PGP October 1996

6. Encrypted and Signed Data

 Sometimes it is desirable to both digitally sign and then encrypt a
 message to be sent.  This protocol allows for two methods of
 accomplishing this task.

6.1 RFC1847 Encapsulation

 [1], it is stated that the data should first be signed as a
 multipart/signature body, and then encrypted to form the final
 multipart/encrypted body, i.e.,

  Content-Type: multipart/encrypted;
     protocol="application/pgp-encrypted"; boundary=foo

-foo

Content-Type: application/pgp-encrypted

  Version: 1

-foo

Content-Type: application/octet-stream

—-BEGIN PGP MESSAGE—–

& Content-Type: multipart/signed; micalg=pgp-md5

  &     protocol="application/pgp-signature"; boundary=bar
  &
  & --bar
  & Content-Type: text/plain; charset=us-ascii
  &
  & This message was first signed, and then encrypted.
  &
  & --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--
  -----END PGP MESSAGE-----

Elkins Standards Track [Page 6] RFC 2015 MIME Security with PGP October 1996

-foo–

  (The text preceded by '&' indicates that it is really
  encrypted, but presented as text for clarity.)

6.2 Combined method

 Versions 2.x of PGP also allow data to be signed and encrypted in one
 operation.  This method is an acceptable shortcut, and has the
 benefit of less overhead.  The resulting data should be formed as a
 "multipart/encrypted" object as described above.

 Messages which are encrypted and signed in this combined fashion are
 REQUIRED to follow the same canonicalization rules as for
 multipart/signed objects.

 It is explicitly allowed for an agent to decrypt a combined message
 and rewrite it as a multipart/signed object using the signature data
 embedded in the encrypted version.

7. Distribution of PGP public keys

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

 This is the content type which should be used for relaying public key
 blocks.

8. Notes

 PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.

9. Security Considerations

 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.

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

Elkins Standards Track [Page 7] RFC 2015 MIME Security with PGP October 1996

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.

Elkins Standards Track [Page 8]