Implement real LOGIN auth method for IMAP.
[claws.git] / 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