doc/src/rfc3156.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          M. Elkins
   8 Request for Comments: 3156                      Network Associates, Inc.
   9 Updates: 2015                                               D. Del Torto
  10 Category: Standards Track                        CryptoRights Foundation
  11                                                                R. Levien
  12                                     University of California at Berkeley
  13                                                              T. Roessler
  14                                                              August 2001
  15
  16
  17                        MIME Security with OpenPGP
  18
  19 Status of this Memo
  20
  21    This document specifies an Internet standards track protocol for the
  22    Internet community, and requests discussion and suggestions for
  23    improvements.  Please refer to the current edition of the "Internet
  24    Official Protocol Standards" (STD 1) for the standardization state
  25    and status of this protocol.  Distribution of this memo is unlimited.
  26
  27 Copyright Notice
  28
  29    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  30
  31 Abstract
  32
  33    This document describes how the OpenPGP Message Format can be used to
  34    provide privacy and authentication using the Multipurpose Internet
  35    Mail Extensions (MIME) security content types described in RFC 1847.
  36
  37 1.  Introduction
  38
  39    Work on integrating PGP (Pretty Good Privacy) with MIME [3]
  40    (including the since withdrawn "application/pgp" content type) prior
  41    to RFC 2015 suffered from a number of problems, the most significant
  42    of which is the inability to recover signed message bodies without
  43    parsing data structures specific to PGP.  RFC 2015 makes use of the
  44    elegant solution proposed in RFC 1847, which defines security
  45    multipart formats for MIME.  The security multiparts clearly separate
  46    the signed message body from the signature, and have a number of
  47    other desirable properties.  This document revises RFC 2015 to adopt
  48    the integration of PGP and MIME to the needs which emerged during the
  49    work on the OpenPGP specification.
  50
  51    This document defines three content types for implementing security
  52    and privacy with OpenPGP: "application/pgp-encrypted",
  53    "application/pgp-signature" and "application/pgp-keys".
  54
  55
  56
  57
  58 Elkins, et al.              Standards Track                     [Page 1]
  59 \f
  60 RFC 3156               MIME Security with OpenPGP            August 2001
  61
  62
  63    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  64    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  65    document are to be interpreted as described in RFC 2119.
  66
  67 2.  OpenPGP data formats
  68
  69    OpenPGP implementations can generate either ASCII armor (described in
  70    [1]) or 8-bit binary output when encrypting data, generating a
  71    digital signature, or extracting public key data.  The ASCII armor
  72    output is the REQUIRED method for data transfer.  This allows those
  73    users who do not have the means to interpret the formats described in
  74    this document to be able to extract and use the OpenPGP information
  75    in the message.
  76
  77    When the amount of data to be transmitted requires that it be sent in
  78    many parts, the MIME message/partial mechanism SHOULD be used rather
  79    than the multi-part ASCII armor OpenPGP format.
  80
  81 3.  Content-Transfer-Encoding restrictions
  82
  83    Multipart/signed and multipart/encrypted are to be treated by agents
  84    as opaque, meaning that the data is not to be altered in any way [2],
  85    [7].  However, many existing mail gateways will detect if the next
  86    hop does not support MIME or 8-bit data and perform conversion to
  87    either Quoted-Printable or Base64.  This presents serious problems
  88    for multipart/signed, in particular, where the signature is
  89    invalidated when such an operation occurs.  For this reason all data
  90    signed according to this protocol MUST be constrained to 7 bits (8-
  91    bit data MUST be encoded using either Quoted-Printable or Base64).
  92    Note that this also includes the case where a signed object is also
  93    encrypted (see section 6).  This restriction will increase the
  94    likelihood that the signature will be valid upon receipt.
  95
  96    Additionally, implementations MUST make sure that no trailing
  97    whitespace is present after the MIME encoding has been applied.
  98
  99       Note: In most cases, trailing whitespace can either be removed, or
 100       protected by applying an appropriate content-transfer-encoding.
 101       However, special care must be taken when any header lines - either
 102       in MIME entity headers, or in embedded RFC 822 headers - are
 103       present which only consist of whitespace: Such lines must be
 104       removed entirely, since replacing them by empty lines would turn
 105       them into header delimiters, and change the semantics of the
 106       message.  The restrictions on whitespace are necessary in order to
 107       make the hash calculated invariant under the text and binary mode
 108       signature mechanisms provided by OpenPGP [1].  Also, they help to
 109       avoid compatibility problems with PGP implementations which
 110       predate the OpenPGP specification.
 111
 112
 113
 114 Elkins, et al.              Standards Track                     [Page 2]
 115 \f
 116 RFC 3156               MIME Security with OpenPGP            August 2001
 117
 118
 119       Note: If any line begins with the string "From ", it is strongly
 120       suggested that either the Quoted-Printable or Base64 MIME encoding
 121       be applied.  If Quoted-Printable is used, at least one of the
 122       characters in the string should be encoded using the hexadecimal
 123       coding rule.  This is because many mail transfer and delivery
 124       agents treat "From " (the word "from" followed immediately by a
 125       space character) as the start of a new message and thus insert a
 126       right angle-bracket (>) in front of any line beginning with
 127       "From " to distinguish this case, invalidating the signature.
 128
 129    Data that is ONLY to be encrypted is allowed to contain 8-bit
 130    characters and trailing whitespace and therefore need not undergo the
 131    conversion to a 7bit format, and the stripping of whitespace.
 132
 133       Implementor's note: It cannot be stressed enough that applications
 134       using this standard follow MIME's suggestion that you "be
 135       conservative in what you generate, and liberal in what you
 136       accept."  In this particular case it means it would be wise for an
 137       implementation to accept messages with any content-transfer-
 138       encoding, but restrict generation to the 7-bit format required by
 139       this memo.  This will allow future compatibility in the event the
 140       Internet SMTP framework becomes 8-bit friendly.
 141
 142 4.  OpenPGP encrypted data
 143
 144    Before OpenPGP encryption, the data is written in MIME canonical
 145    format (body and headers).
 146
 147    OpenPGP encrypted data is denoted by the "multipart/encrypted"
 148    content type, described in [2], and MUST have a "protocol" parameter
 149    value of "application/pgp-encrypted".  Note that the value of the
 150    parameter MUST be enclosed in quotes.
 151
 152    The multipart/encrypted MIME body MUST consist of exactly two body
 153    parts, the first with content type "application/pgp-encrypted".  This
 154    body contains the control information.  A message complying with this
 155    standard MUST contain a "Version: 1" field in this body.  Since the
 156    OpenPGP packet format contains all other information necessary for
 157    decrypting, no other information is required here.
 158
 159    The second MIME body part MUST contain the actual encrypted data.  It
 160    MUST be labeled with a content type of "application/octet-stream".
 161
 162    Example message:
 163
 164       From: Michael Elkins <elkins@aero.org>
 165       To: Michael Elkins <elkins@aero.org>
 166       Mime-Version: 1.0
 167
 168
 169
 170 Elkins, et al.              Standards Track                     [Page 3]
 171 \f
 172 RFC 3156               MIME Security with OpenPGP            August 2001
 173
 174
 175       Content-Type: multipart/encrypted; boundary=foo;
 176          protocol="application/pgp-encrypted"
 177
 178       --foo
 179       Content-Type: application/pgp-encrypted
 180
 181       Version: 1
 182
 183       --foo
 184       Content-Type: application/octet-stream
 185
 186       -----BEGIN PGP MESSAGE-----
 187       Version: 2.6.2
 188
 189       hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
 190       eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
 191       g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
 192       AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
 193       1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
 194       =zzaA
 195       -----END PGP MESSAGE-----
 196
 197       --foo--
 198
 199 5.  OpenPGP signed data
 200
 201    OpenPGP signed messages are denoted by the "multipart/signed" content
 202    type, described in [2], with a "protocol" parameter which MUST have a
 203    value of "application/pgp-signature" (MUST be quoted).
 204
 205    The "micalg" parameter for the "application/pgp-signature" protocol
 206    MUST contain exactly one hash-symbol of the format "pgp-<hash-
 207    identifier>", where <hash-identifier> identifies the Message
 208    Integrity Check (MIC) algorithm used to generate the signature.
 209    Hash-symbols are constructed from the text names registered in [1] or
 210    according to the mechanism defined in that document by converting the
 211    text name to lower case and prefixing it with the four characters
 212    "pgp-".
 213
 214    Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
 215    "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
 216
 217    The multipart/signed body MUST consist of exactly two parts.  The
 218    first part contains the signed data in MIME canonical format,
 219    including a set of appropriate content headers describing the data.
 220
 221    The second body MUST contain the OpenPGP digital signature.  It MUST
 222    be labeled with a content type of "application/pgp-signature".
 223
 224
 225
 226 Elkins, et al.              Standards Track                     [Page 4]
 227 \f
 228 RFC 3156               MIME Security with OpenPGP            August 2001
 229
 230
 231       Note: Implementations can either generate "signatures of a
 232       canonical text document" or "signatures of a binary document", as
 233       defined in [1].  The restrictions on the signed material put forth
 234       in section 3 and in this section will make sure that the various
 235       MIC algorithm variants specified in [1] and [5] will all produce
 236       the same result.
 237
 238    When the OpenPGP digital signature is generated:
 239
 240    (1)   The data to be signed MUST first be converted to its content-
 241          type specific canonical form.  For text/plain, this means
 242          conversion to an appropriate character set and conversion of
 243          line endings to the canonical <CR><LF> sequence.
 244
 245    (2)   An appropriate Content-Transfer-Encoding is then applied; see
 246          section 3.  In particular, line endings in the encoded data
 247          MUST use the canonical <CR><LF> sequence where appropriate
 248          (note that the canonical line ending may or may not be present
 249          on the last line of encoded data and MUST NOT be included in
 250          the signature if absent).
 251
 252    (3)   MIME content headers are then added to the body, each ending
 253          with the canonical <CR><LF> sequence.
 254
 255    (4)   As described in section 3 of this document, any trailing
 256          whitespace MUST then be removed from the signed material.
 257
 258    (5)   As described in [2], the digital signature MUST be calculated
 259          over both the data to be signed and its set of content headers.
 260
 261    (6)   The signature MUST be generated detached from the signed data
 262          so that the process does not alter the signed data in any way.
 263
 264       Note: The accepted OpenPGP convention is for signed data to end
 265       with a <CR><LF> sequence.  Note that the <CR><LF> sequence
 266       immediately preceding a MIME boundary delimiter line is considered
 267       to be part of the delimiter in [3], 5.1.  Thus, it is not part of
 268       the signed data preceding the delimiter line.  An implementation
 269       which elects to adhere to the OpenPGP convention has to make sure
 270       it inserts a <CR><LF> pair on the last line of the data to be
 271       signed and transmitted (signed message and transmitted message
 272       MUST be identical).
 273
 274    Example message:
 275
 276          From: Michael Elkins <elkins@aero.org>
 277          To: Michael Elkins <elkins@aero.org>
 278          Mime-Version: 1.0
 279
 280
 281
 282 Elkins, et al.              Standards Track                     [Page 5]
 283 \f
 284 RFC 3156               MIME Security with OpenPGP            August 2001
 285
 286
 287          Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
 288            protocol="application/pgp-signature"
 289
 290          --bar
 291       & Content-Type: text/plain; charset=iso-8859-1
 292       & Content-Transfer-Encoding: quoted-printable
 293       &
 294       & =A1Hola!
 295       &
 296       & Did you know that talking to yourself is a sign of senility?
 297       &
 298       & It's generally a good idea to encode lines that begin with
 299       & From=20because some mail transport agents will insert a greater-
 300       & than (>) sign, thus invalidating the signature.
 301       &
 302       & Also, in some cases it might be desirable to encode any   =20
 303       & trailing whitespace that occurs on lines in order to ensure  =20
 304       & that the message signature is not invalidated when passing =20
 305       & a gateway that modifies such whitespace (like BITNET). =20
 306       &
 307       & me
 308
 309       --bar
 310
 311       Content-Type: application/pgp-signature
 312
 313       -----BEGIN PGP MESSAGE-----
 314       Version: 2.6.2
 315
 316       iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
 317       jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
 318       uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
 319       HOxEa44b+EI=
 320       =ndaj
 321       -----END PGP MESSAGE-----
 322
 323       --bar--
 324
 325    The "&"s in the previous example indicate the portion of the data
 326    over which the signature was calculated.
 327
 328    Upon receipt of a signed message, an application MUST:
 329
 330    (1)   Convert line endings to the canonical <CR><LF> sequence before
 331          the signature can be verified.  This is necessary since the
 332          local MTA may have converted to a local end of line convention.
 333
 334
 335
 336
 337
 338 Elkins, et al.              Standards Track                     [Page 6]
 339 \f
 340 RFC 3156               MIME Security with OpenPGP            August 2001
 341
 342
 343    (2)   Pass both the signed data and its associated content headers
 344          along with the OpenPGP signature to the signature verification
 345          service.
 346
 347 6.  Encrypted and Signed Data
 348
 349    Sometimes it is desirable to both digitally sign and then encrypt a
 350    message to be sent.  This protocol allows for two methods of
 351    accomplishing this task.
 352
 353 6.1.  RFC 1847 Encapsulation
 354
 355    In [2], it is stated that the data is first signed as a
 356    multipart/signature body, and then encrypted to form the final
 357    multipart/encrypted body.  This is most useful for standard MIME-
 358    compliant message forwarding.
 359
 360    Example:
 361
 362          Content-Type: multipart/encrypted;
 363             protocol="application/pgp-encrypted"; boundary=foo
 364
 365          --foo
 366          Content-Type: application/pgp-encrypted
 367
 368          Version: 1
 369
 370          --foo
 371          Content-Type: application/octet-stream
 372
 373          -----BEGIN PGP MESSAGE-----
 374       & Content-Type: multipart/signed; micalg=pgp-md5
 375       &     protocol="application/pgp-signature"; boundary=bar
 376       &
 377       & --bar
 378       & Content-Type: text/plain; charset=us-ascii
 379       &
 380       & This message was first signed, and then encrypted.
 381       &
 382       & --bar
 383       & Content-Type: application/pgp-signature
 384       &
 385       & -----BEGIN PGP MESSAGE-----
 386       & Version: 2.6.2
 387       &
 388       & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
 389       & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
 390       & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
 391
 392
 393
 394 Elkins, et al.              Standards Track                     [Page 7]
 395 \f
 396 RFC 3156               MIME Security with OpenPGP            August 2001
 397
 398
 399       & HOxEa44b+EI=
 400       & =ndaj
 401       & -----END PGP MESSAGE-----
 402       &
 403       & --bar--
 404         -----END PGP MESSAGE-----
 405
 406         --foo--
 407
 408    (The text preceded by '&' indicates that it is really encrypted, but
 409    presented as text for clarity.)
 410
 411 6.2.  Combined method
 412
 413    The OpenPGP packet format [1] describes a method for signing and
 414    encrypting data in a single OpenPGP message.  This method is allowed
 415    in order to reduce processing overhead and increase compatibility
 416    with non-MIME implementations of OpenPGP.  The resulting data is
 417    formatted as a "multipart/encrypted" object as described in Section
 418    4.
 419
 420    Messages which are encrypted and signed in this combined fashion are
 421    REQUIRED to follow the same canonicalization rules as
 422    multipart/signed objects.
 423
 424    It is explicitly allowed for an agent to decrypt a combined message
 425    and rewrite it as a multipart/signed object using the signature data
 426    embedded in the encrypted version.
 427
 428 7.  Distribution of OpenPGP public keys
 429
 430    Content-Type: application/pgp-keys
 431    Required parameters: none
 432    Optional parameters: none
 433
 434    A MIME body part of the content type "application/pgp-keys" contains
 435    ASCII-armored transferable Public Key Packets as defined in [1],
 436    section 10.1.
 437
 438 8.  Security Considerations
 439
 440    Signatures of a canonical text document as defined in [1] ignore
 441    trailing white space in signed material.  Implementations which
 442    choose to use signatures of canonical text documents will not be able
 443    to detect the addition of whitespace in transit.
 444
 445    See [3], [4] for more information on the security considerations
 446    concerning the underlying protocols.
 447
 448
 449
 450 Elkins, et al.              Standards Track                     [Page 8]
 451 \f
 452 RFC 3156               MIME Security with OpenPGP            August 2001
 453
 454
 455 9.  IANA Considerations
 456
 457    This document defines three media types: "application/pgp-encrypted",
 458    "application/pgp-signature" and "application/pgp-keys".  The
 459    following sections specify the IANA registrations for these types.
 460
 461 9.1.  Registration of the application/pgp-encrypted media type
 462
 463    MIME media type name: application
 464    MIME subtype name: pgp-encrypted
 465    Required parameters: none
 466    Optional parameters: none
 467
 468    Encoding considerations:
 469
 470       Currently this media type always consists of a single 7bit text
 471       string.
 472
 473    Security considerations:
 474
 475       See Section 8 and RFC 2440 Section 13.
 476
 477    Interoperability considerations: none
 478
 479    Published specification:
 480
 481       This document.
 482
 483    Additional information:
 484
 485       Magic number(s): none
 486       File extension(s): none
 487       Macintosh File Type Code(s): none
 488
 489    Person & email address to contact for further information:
 490
 491       Michael Elkins
 492       Email: me@cs.hmc.edu
 493
 494    Intended usage: common
 495
 496    Author/Change controller:
 497
 498       Michael Elkins
 499       Email: me@cs.hmc.edu
 500
 501
 502
 503
 504
 505
 506 Elkins, et al.              Standards Track                     [Page 9]
 507 \f
 508 RFC 3156               MIME Security with OpenPGP            August 2001
 509
 510
 511 9.2.  Registration of the application/pgp-signature media type
 512
 513    MIME media type name: application
 514    MIME subtype name: pgp-signature
 515    Required parameters: none
 516    Optional parameters: none
 517
 518    Encoding considerations:
 519
 520       The content of this media type always consists of 7bit text.
 521
 522    Security considerations:
 523
 524       See Section 8 and RFC 2440 Section 13.
 525
 526    Interoperability considerations: none
 527
 528    Published specification:
 529
 530       RFC 2440 and this document.
 531
 532    Additional information:
 533
 534       Magic number(s): none
 535       File extension(s): asc, sig
 536       Macintosh File Type Code(s): pgDS
 537
 538    Person & email address to contact for further information:
 539
 540       Michael Elkins
 541       Email: me@cs.hmc.edu
 542
 543    Intended usage: common
 544
 545    Author/Change controller:
 546
 547       Michael Elkins
 548       Email: me@cs.hmc.edu
 549
 550 9.3.  Registration of the application/pgp-keys media type
 551
 552    MIME media type name: application
 553    MIME subtype name: pgp-keys
 554    Required parameters: none
 555    Optional parameters: none
 556
 557
 558
 559
 560
 561
 562 Elkins, et al.              Standards Track                    [Page 10]
 563 \f
 564 RFC 3156               MIME Security with OpenPGP            August 2001
 565
 566
 567    Encoding considerations:
 568
 569       The content of this media type always consists of 7bit text.
 570
 571    Security considerations:
 572
 573       See Section 8 and RFC 2440 Section 13.
 574
 575    Interoperability considerations: none
 576
 577    Published specification:
 578
 579       RFC 2440 and this document.
 580
 581    Additional information:
 582
 583       Magic number(s): none
 584       File extension(s): asc
 585       Macintosh File Type Code(s): none
 586
 587    Person & email address to contact for further information:
 588
 589       Michael Elkins
 590       Email: me@cs.hmc.edu
 591
 592    Intended usage: common
 593
 594    Author/Change controller:
 595
 596       Michael Elkins
 597       Email: me@cs.hmc.edu
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Elkins, et al.              Standards Track                    [Page 11]
 619 \f
 620 RFC 3156               MIME Security with OpenPGP            August 2001
 621
 622
 623 10.  Notes
 624
 625    "PGP" and "Pretty Good Privacy" are registered trademarks of Network
 626    Associates, Inc.
 627
 628 11.  Acknowledgements
 629
 630    This document relies on the work of the IETF's OpenPGP Working
 631    Group's definitions of the OpenPGP Message Format.  The OpenPGP
 632    message format is currently described in RFC 2440 [1].
 633
 634    Special thanks are due: to Philip Zimmermann for his original and
 635    ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto
 636    for originally proposing the formation of the OpenPGP Working Group;
 637    and to Steve Schoenfeld for helpful feedback during the draft
 638    process.  The authors would also like to thank the engineers at
 639    Pretty Good Privacy, Inc (now Network Associates, Inc), including
 640    Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and
 641    Lloyd Chambers, for their technical commentary.
 642
 643    Additional thanks are due to Jeff Schiller and Derek Atkins for their
 644    continuing support of strong cryptography and PGP freeware at MIT; to
 645    Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner
 646    and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; to Bodo
 647    Moeller for proposing the approach followed with respect to trailing
 648    whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at
 649    Rivertown) and Ian Bell (at Turnpike) for their timely critical
 650    commentary; and to the international members of the IETF's OpenPGP
 651    mailing list, including William Geiger, Lutz Donnerhacke and Kazu
 652    Yamamoto.  The idea to use multipart/mixed with multipart/signed has
 653    been attributed to James Galvin.  Finally, our gratitude is due to
 654    the many members of the "Cypherpunks," "Coderpunks" and "pgp-users"
 655    <http://cryptorights.org/pgp-users> mailing lists and the many users
 656    of PGP worldwide for helping keep the path to privacy open.
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Elkins, et al.              Standards Track                    [Page 12]
 675 \f
 676 RFC 3156               MIME Security with OpenPGP            August 2001
 677
 678
 679 12.  Addresses of the Authors and OpenPGP Working Group Chair
 680
 681    The OpenPGP working group can be contacted via the current chair:
 682
 683    John W. Noerenberg II
 684    Qualcomm, Inc.
 685    5775 Morehouse Dr.
 686    San Diego, CA 92121 USA
 687
 688    Phone: +1 619 658 3510
 689    EMail: jwn2@qualcomm.com
 690
 691    The principal authors of this document are:
 692
 693    Dave Del Torto
 694    CryptoRights Foundation
 695    80 Alviso Street, Mailstop: CRF
 696    San Francisco, CA 94127 USA
 697
 698    Phone: +1.415.334.5533, vm: #2
 699    EMail: ddt@cryptorights.org, ddt@openpgp.net
 700
 701
 702    Michael Elkins
 703    Network Associates, Inc.
 704    3415 S. Sepulveda Blvd Suite 700
 705    Los Angeles, CA 90034 USA
 706
 707    Phone: +1.310.737.1663
 708    Fax:   +1.310.737.1755
 709    Email: me@cs.hmc.edu, Michael_Elkins@NAI.com
 710
 711
 712    Raph Levien
 713    University of California at Berkeley
 714    579 Soda Hall
 715    Berkeley, CA 94720 USA
 716
 717    Phone: +1.510.642.6509
 718    EMail: raph@acm.org
 719
 720
 721    Thomas Roessler
 722    Nordstrasse 99
 723    D-53111 Bonn, Germany
 724
 725    Phone: +49-228-638007
 726    EMail: roessler@does-not-exist.org
 727
 728
 729
 730 Elkins, et al.              Standards Track                    [Page 13]
 731 \f
 732 RFC 3156               MIME Security with OpenPGP            August 2001
 733
 734
 735 References
 736
 737    [1]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
 738          Message Format", RFC 2440, November 1998.
 739
 740    [2]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security
 741          Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
 742          RFC 1847, October 1995.
 743
 744    [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 745          Extensions (MIME) Part Two: Media Types", RFC 2046, November
 746          1996.
 747
 748    [4]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object
 749          Security Services", RFC 1848, October 1995.
 750
 751    [5]   Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
 752          Exchange Formats", RFC 1991, August 1996.
 753
 754    [6]   Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
 755          2015, October 1996.
 756
 757    [7]   Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
 758          January 1999.
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Elkins, et al.              Standards Track                    [Page 14]
 787 \f
 788 RFC 3156               MIME Security with OpenPGP            August 2001
 789
 790
 791 Full Copyright Statement
 792
 793    Copyright (C) The Internet Society (2001).  All Rights Reserved.
 794
 795    This document and translations of it may be copied and furnished to
 796    others, and derivative works that comment on or otherwise explain it
 797    or assist in its implementation may be prepared, copied, published
 798    and distributed, in whole or in part, without restriction of any
 799    kind, provided that the above copyright notice and this paragraph are
 800    included on all such copies and derivative works.  However, this
 801    document itself may not be modified in any way, such as by removing
 802    the copyright notice or references to the Internet Society or other
 803    Internet organizations, except as needed for the purpose of
 804    developing Internet standards in which case the procedures for
 805    copyrights defined in the Internet Standards process must be
 806    followed, or as required to translate it into languages other than
 807    English.
 808
 809    The limited permissions granted above are perpetual and will not be
 810    revoked by the Internet Society or its successors or assigns.
 811
 812    This document and the information contained herein is provided on an
 813    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 814    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 815    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 816    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 817    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 818
 819 Acknowledgement
 820
 821    Funding for the RFC Editor function is currently provided by the
 822    Internet Society.
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Elkins, et al.              Standards Track                    [Page 15]
 843 \f