doc/src/rfc2015.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          M. Elkins
   8 Request for Comments: 2015                     The Aerospace Corporation
   9 Category: Standards Track                                   October 1996
  10
  11
  12               MIME Security with Pretty Good Privacy (PGP)
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Abstract
  23
  24    This document describes how Pretty Good Privacy (PGP) can be used to
  25    provide privacy and authentication using the Multipurpose Internet
  26    Mail Extensions (MIME) security content types described in RFC1847.
  27
  28 1.  Introduction
  29
  30    Previous work on integrating PGP with MIME (including the since
  31    withdrawn application/pgp content type) has suffered from a number of
  32    problems, the most significant of which is the inability to recover
  33    signed message bodies without parsing data structures specific to
  34    PGP.  This work makes use of the elegant solution proposed in
  35    RFC1847, which defines security multipart formats for MIME. The
  36    security multiparts clearly separate the signed message body from the
  37    signature, and have a number of other desirable properties. This
  38    document is styled after RFC 1848, which defines MIME Object Security
  39    Services (MOSS) for providing security and authentication.
  40
  41    This document defines three new content types for implementing
  42    security and privacy with PGP: application/pgp-encrypted,
  43    application/pgp-signature and application/pgp-keys.
  44
  45 1.1  Compliance
  46
  47    In order for an implementation to be compliant with this
  48    specification, is it absolutely necessary for it to obey all items
  49    labeled as MUST or REQUIRED.
  50
  51
  52
  53
  54
  55
  56
  57
  58 Elkins                      Standards Track                     [Page 1]
  59 \f
  60 RFC 2015                 MIME Security with PGP             October 1996
  61
  62
  63 2.  PGP data formats
  64
  65    PGP can generate either ASCII armor (described in [3]) or 8-bit
  66    binary output when encrypting data, generating a digital signature,
  67    or extracting public key data.  The ASCII armor output is the
  68    REQUIRED method for data transfer.  This allows those users who do
  69    not have the means to interpret the formats described in this
  70    document to be able extract and use the PGP information in the
  71    message.
  72
  73    When the amount of data to be transmitted requires that it be sent in
  74    many parts, the MIME message/partial mechanism should be used rather
  75    than the multipart ASCII armor PGP format.
  76
  77 3.  Content-Transfer-Encoding restrictions
  78
  79    Multipart/signed and multipart/encrypted are to be treated by agents
  80    as opaque, meaning that the data is not to be altered in any way [1].
  81    However, many existing mail gateways will detect if the next hop does
  82    not support MIME or 8-bit data and perform conversion to either
  83    Quoted-Printable or Base64.  This presents serious problems for
  84    multipart/signed, in particular, where the signature is invalidated
  85    when such an operation occurs.  For this reason all data signed
  86    according to this protocol MUST be constrained to 7 bits (8- bit data
  87    should be encoded using either Quoted-Printable or Base64).  Note
  88    that this also includes the case where a signed object is also
  89    encrypted (see section 6).  This restriction will increase the
  90    likelihood that the signature will be valid upon receipt.
  91
  92    Data that is ONLY to be encrypted is allowed to contain 8-bit
  93    characters and therefore need not be converted to a 7-bit format.
  94
  95      Implementor's note: It cannot be stressed enough that applications
  96      using this standard should follow MIME's suggestion that you "be
  97      conservative in what you generate, and liberal in what you accept."
  98      In this particular case it means it would be wise for an
  99      implementation to accept messages with any content-transfer-
 100      encoding, but restrict generation to the 7-bit format required by
 101      this memo.  This will allow future compatibility in the event the
 102      Internet SMTP framework becomes 8-bit friendly.
 103
 104 4.  PGP encrypted data
 105
 106    Before encryption with PGP, the data should be written in MIME
 107    canonical format (body and headers).
 108
 109    PGP encrypted data is denoted by the "multipart/encrypted" content
 110    type, described in [1], and MUST have a "protocol" parameter value of
 111
 112
 113
 114 Elkins                      Standards Track                     [Page 2]
 115 \f
 116 RFC 2015                 MIME Security with PGP             October 1996
 117
 118
 119    "application/pgp-encrypted".  Note that the value of the parameter
 120    MUST be enclosed in quotes.
 121
 122    The multipart/encrypted MUST consist of exactly two parts.  The first
 123    MIME body part must have a content type of "application/pgp-
 124    encrypted".  This body contains the control information.  A message
 125    complying with this standard MUST contain a "Version: 1" field in
 126    this body.  Since the PGP packet format contains all other
 127    information necessary for decrypting, no other information is
 128    required here.
 129
 130    The second MIME body part MUST contain the actual encrypted data.  It
 131    must be labeled with a content type of "application/octet- stream".
 132
 133    Example message:
 134
 135      From: Michael Elkins <elkins@aero.org>
 136      To: Michael Elkins <elkins@aero.org>
 137      Mime-Version: 1.0
 138      Content-Type: multipart/encrypted; boundary=foo;
 139         protocol="application/pgp-encrypted"
 140
 141      --foo
 142      Content-Type: application/pgp-encrypted
 143
 144      Version: 1
 145
 146      --foo
 147      Content-Type: application/octet-stream
 148
 149      -----BEGIN PGP MESSAGE-----
 150      Version: 2.6.2
 151
 152      hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
 153      eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
 154      g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
 155      AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
 156      1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
 157      =zzaA
 158      -----END PGP MESSAGE-----
 159
 160      --foo--
 161
 162 5.  PGP signed data
 163
 164    PGP signed messages are denoted by the "multipart/signed" content
 165    type, described in [1], with a "protocol" parameter which MUST have a
 166    value of "application/pgp-signature" (MUST be quoted).  The "micalg"
 167
 168
 169
 170 Elkins                      Standards Track                     [Page 3]
 171 \f
 172 RFC 2015                 MIME Security with PGP             October 1996
 173
 174
 175    parameter MUST have a value of "pgp-<hash-symbol>", where <hash-
 176    symbol> identifies the message integrity check (MIC) used to generate
 177    the signature.  The currently defined values for <hash-symbol> are
 178    "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
 179
 180    The multipart/signed body MUST consist of exactly two parts.  The
 181    first part contains the signed data in MIME canonical format,
 182    including a set of appropriate content headers describing the data.
 183
 184    The second body MUST contain the PGP digital signature.  It MUST be
 185    labeled with a content type of "application/pgp-signature".
 186
 187    When the PGP digital signature is generated:
 188
 189    (1)  The data to be signed must first be converted to its
 190         type/subtype specific canonical form.  For text/plain, this
 191         means conversion to an appropriate character set and conversion
 192         of line endings to the canonical <CR><LF> sequence.
 193
 194    (2)  An appropriate Content-Transfer-Encoding is then applied. Each
 195         line of the encoded data MUST end with the canonical <CR><LF>
 196         sequence.
 197
 198    (3)  MIME content headers are then added to the body, each ending
 199         with the canonical <CR><LF> sequence.
 200
 201    (4)  As described in [1], the digital signature MUST be calculated
 202         over both the data to be signed and its set of content headers.
 203
 204    (5)  The signature MUST be generated detached from the signed data
 205         so that the process does not alter the signed data in any way.
 206
 207    Example message:
 208
 209      From: Michael Elkins <elkins@aero.org>
 210      To: Michael Elkins <elkins@aero.org>
 211      Mime-Version: 1.0
 212      Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
 213      protocol="application/pgp-signature"
 214
 215      --bar
 216      & Content-Type: text/plain; charset=iso-8859-1
 217      & Content-Transfer-Encoding: quoted-printable
 218      &
 219      & =A1Hola!
 220      &
 221      & Did you know that talking to yourself is a sign of senility?
 222      &
 223
 224
 225
 226 Elkins                      Standards Track                     [Page 4]
 227 \f
 228 RFC 2015                 MIME Security with PGP             October 1996
 229
 230
 231      & It's generally a good idea to encode lines that begin with
 232      & From=20because some mail transport agents will insert a greater-
 233      & than (>) sign, thus invalidating the signature.
 234      &
 235      & Also, in some cases it might be desirable to encode any   =20
 236      &railing whitespace that occurs on lines in order to ensure  =20
 237      & that the message signature is not invalidated when passing =20
 238      & a gateway that modifies such whitespace (like BITNET). =20
 239      &
 240      & me
 241
 242      --bar
 243      Content-Type: application/pgp-signature
 244
 245     -----BEGIN PGP MESSAGE-----
 246    Version: 2.6.2
 247
 248    iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
 249    jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
 250    uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
 251    HOxEa44b+EI=
 252    =ndaj
 253    -----END PGP MESSAGE-----
 254
 255    --bar--
 256
 257    The "&"s in the previous example indicate the portion of the data
 258    over which the signature was calculated.
 259
 260    Though not required, it is generally a good idea to use Quoted-
 261    Printable encoding in the first step (writing out the data to be
 262    signed in MIME canonical format) if any of the lines in the data
 263    begin with "From ", and encode the "F".  This will avoid an MTA
 264    inserting a ">" in front of the line, thus invalidating the
 265    signature!
 266
 267    Upon receipt of a signed message, an application MUST:
 268
 269    (1)  Convert line endings to the canonical <CR><LF> sequence before
 270         the signature can be verified.  This is necessary since the
 271         local MTA may have converted to a local end of line convention.
 272
 273    (2)  Pass both the signed data and its associated content headers
 274         along with the PGP signature to the signature verification
 275         service.
 276
 277
 278
 279
 280
 281
 282 Elkins                      Standards Track                     [Page 5]
 283 \f
 284 RFC 2015                 MIME Security with PGP             October 1996
 285
 286
 287 6.  Encrypted and Signed Data
 288
 289    Sometimes it is desirable to both digitally sign and then encrypt a
 290    message to be sent.  This protocol allows for two methods of
 291    accomplishing this task.
 292
 293 6.1  RFC1847 Encapsulation
 294
 295    [1], it is stated that the data should first be signed as a
 296    multipart/signature body, and then encrypted to form the final
 297    multipart/encrypted body, i.e.,
 298
 299     Content-Type: multipart/encrypted;
 300        protocol="application/pgp-encrypted"; boundary=foo
 301
 302     --foo
 303     Content-Type: application/pgp-encrypted
 304
 305     Version: 1
 306
 307     --foo
 308     Content-Type: application/octet-stream
 309
 310     -----BEGIN PGP MESSAGE-----
 311     & Content-Type: multipart/signed; micalg=pgp-md5
 312     &     protocol="application/pgp-signature"; boundary=bar
 313     &
 314     & --bar
 315     & Content-Type: text/plain; charset=us-ascii
 316     &
 317     & This message was first signed, and then encrypted.
 318     &
 319     & --bar
 320     & Content-Type: application/pgp-signature
 321     &
 322     & -----BEGIN PGP MESSAGE-----
 323     & Version: 2.6.2
 324     &
 325     & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
 326     & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
 327     & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
 328     & HOxEa44b+EI=
 329     & =ndaj
 330     & -----END PGP MESSAGE-----
 331     &
 332     & --bar--
 333     -----END PGP MESSAGE-----
 334
 335
 336
 337
 338 Elkins                      Standards Track                     [Page 6]
 339 \f
 340 RFC 2015                 MIME Security with PGP             October 1996
 341
 342
 343     --foo--
 344
 345     (The text preceded by '&' indicates that it is really
 346     encrypted, but presented as text for clarity.)
 347
 348 6.2  Combined method
 349
 350    Versions 2.x of PGP also allow data to be signed and encrypted in one
 351    operation.  This method is an acceptable shortcut, and has the
 352    benefit of less overhead.  The resulting data should be formed as a
 353    "multipart/encrypted" object as described above.
 354
 355    Messages which are encrypted and signed in this combined fashion are
 356    REQUIRED to follow the same canonicalization rules as for
 357    multipart/signed objects.
 358
 359    It is explicitly allowed for an agent to decrypt a combined message
 360    and rewrite it as a multipart/signed object using the signature data
 361    embedded in the encrypted version.
 362
 363 7.  Distribution of PGP public keys
 364
 365    Content-Type: application/pgp-keys
 366    Required parameters: none
 367    Optional parameters: none
 368
 369    This is the content type which should be used for relaying public key
 370    blocks.
 371
 372 8.  Notes
 373
 374    PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
 375
 376 9.  Security Considerations
 377
 378    Use of this protocol has the same security considerations as PGP, and
 379    is not known to either increase or decrease the security of messages
 380    using it; see [3] for more information.
 381
 382 10.  Author's Address
 383
 384         Michael Elkins
 385         P.O. Box 92957 - M1/102
 386         Los Angeles, CA 90009-2957
 387
 388         Phone: +1 310 336 8040
 389         Fax: +1 310 336 4402
 390
 391
 392
 393
 394 Elkins                      Standards Track                     [Page 7]
 395 \f
 396 RFC 2015                 MIME Security with PGP             October 1996
 397
 398
 399 References
 400
 401    [1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
 402         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
 403         RFC 1847, October 1995.
 404
 405    [2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
 406         Security Services", RFC 1848, October 1995.
 407
 408    [3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
 409         Exchange Formats", RFC 1991, August 1996.
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Elkins                      Standards Track                     [Page 8]
 451 \f