doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc3156.txt b/doc/rfc/rfc3156.txt
new file mode 100644
index 0000000..070c27c
--- /dev/null
+++ b/doc/rfc/rfc3156.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          M. Elkins
+Request for Comments: 3156                      Network Associates, Inc.
+Updates: 2015                                               D. Del Torto
+Category: Standards Track                        CryptoRights Foundation
+                                                               R. Levien
+                                    University of California at Berkeley
+                                                             T. Roessler
+                                                             August 2001
+
+
+                       MIME Security with OpenPGP
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes how the OpenPGP Message Format can be used to
+   provide privacy and authentication using the Multipurpose Internet
+   Mail Extensions (MIME) security content types described in RFC 1847.
+
+1.  Introduction
+
+   Work on integrating PGP (Pretty Good Privacy) with MIME [3]
+   (including the since withdrawn "application/pgp" content type) prior
+   to RFC 2015 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.  RFC 2015 makes use of the
+   elegant solution proposed in RFC 1847, 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 revises RFC 2015 to adopt
+   the integration of PGP and MIME to the needs which emerged during the
+   work on the OpenPGP specification.
+
+   This document defines three content types for implementing security
+   and privacy with OpenPGP: "application/pgp-encrypted",
+   "application/pgp-signature" and "application/pgp-keys".
+
+
+
+
+Elkins, et al.              Standards Track                     [Page 1]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+2.  OpenPGP data formats
+
+   OpenPGP implementations can generate either ASCII armor (described in
+   [1]) 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 to extract and use the OpenPGP 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 multi-part ASCII armor OpenPGP 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 [2],
+   [7].  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 MUST 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.
+
+   Additionally, implementations MUST make sure that no trailing
+   whitespace is present after the MIME encoding has been applied.
+
+      Note: In most cases, trailing whitespace can either be removed, or
+      protected by applying an appropriate content-transfer-encoding.
+      However, special care must be taken when any header lines - either
+      in MIME entity headers, or in embedded RFC 822 headers - are
+      present which only consist of whitespace: Such lines must be
+      removed entirely, since replacing them by empty lines would turn
+      them into header delimiters, and change the semantics of the
+      message.  The restrictions on whitespace are necessary in order to
+      make the hash calculated invariant under the text and binary mode
+      signature mechanisms provided by OpenPGP [1].  Also, they help to
+      avoid compatibility problems with PGP implementations which
+      predate the OpenPGP specification.
+
+
+
+Elkins, et al.              Standards Track                     [Page 2]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      Note: If any line begins with the string "From ", it is strongly
+      suggested that either the Quoted-Printable or Base64 MIME encoding
+      be applied.  If Quoted-Printable is used, at least one of the
+      characters in the string should be encoded using the hexadecimal
+      coding rule.  This is because many mail transfer and delivery
+      agents treat "From " (the word "from" followed immediately by a
+      space character) as the start of a new message and thus insert a
+      right angle-bracket (>) in front of any line beginning with
+      "From " to distinguish this case, invalidating the signature.
+
+   Data that is ONLY to be encrypted is allowed to contain 8-bit
+   characters and trailing whitespace and therefore need not undergo the
+   conversion to a 7bit format, and the stripping of whitespace.
+
+      Implementor's note: It cannot be stressed enough that applications
+      using this standard 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.  OpenPGP encrypted data
+
+   Before OpenPGP encryption, the data is written in MIME canonical
+   format (body and headers).
+
+   OpenPGP encrypted data is denoted by the "multipart/encrypted"
+   content type, described in [2], and MUST have a "protocol" parameter
+   value of "application/pgp-encrypted".  Note that the value of the
+   parameter MUST be enclosed in quotes.
+
+   The multipart/encrypted MIME body MUST consist of exactly two body
+   parts, the first with content type "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
+   OpenPGP 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
+
+
+
+Elkins, et al.              Standards Track                     [Page 3]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      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.  OpenPGP signed data
+
+   OpenPGP signed messages are denoted by the "multipart/signed" content
+   type, described in [2], with a "protocol" parameter which MUST have a
+   value of "application/pgp-signature" (MUST be quoted).
+
+   The "micalg" parameter for the "application/pgp-signature" protocol
+   MUST contain exactly one hash-symbol of the format "pgp-<hash-
+   identifier>", where <hash-identifier> identifies the Message
+   Integrity Check (MIC) algorithm used to generate the signature.
+   Hash-symbols are constructed from the text names registered in [1] or
+   according to the mechanism defined in that document by converting the
+   text name to lower case and prefixing it with the four characters
+   "pgp-".
+
+   Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160",
+   "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160".
+
+   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 OpenPGP digital signature.  It MUST
+   be labeled with a content type of "application/pgp-signature".
+
+
+
+Elkins, et al.              Standards Track                     [Page 4]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      Note: Implementations can either generate "signatures of a
+      canonical text document" or "signatures of a binary document", as
+      defined in [1].  The restrictions on the signed material put forth
+      in section 3 and in this section will make sure that the various
+      MIC algorithm variants specified in [1] and [5] will all produce
+      the same result.
+
+   When the OpenPGP digital signature is generated:
+
+   (1)   The data to be signed MUST first be converted to its content-
+         type 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; see
+         section 3.  In particular, line endings in the encoded data
+         MUST use the canonical <CR><LF> sequence where appropriate
+         (note that the canonical line ending may or may not be present
+         on the last line of encoded data and MUST NOT be included in
+         the signature if absent).
+
+   (3)   MIME content headers are then added to the body, each ending
+         with the canonical <CR><LF> sequence.
+
+   (4)   As described in section 3 of this document, any trailing
+         whitespace MUST then be removed from the signed material.
+
+   (5)   As described in [2], the digital signature MUST be calculated
+         over both the data to be signed and its set of content headers.
+
+   (6)   The signature MUST be generated detached from the signed data
+         so that the process does not alter the signed data in any way.
+
+      Note: The accepted OpenPGP convention is for signed data to end
+      with a <CR><LF> sequence.  Note that the <CR><LF> sequence
+      immediately preceding a MIME boundary delimiter line is considered
+      to be part of the delimiter in [3], 5.1.  Thus, it is not part of
+      the signed data preceding the delimiter line.  An implementation
+      which elects to adhere to the OpenPGP convention has to make sure
+      it inserts a <CR><LF> pair on the last line of the data to be
+      signed and transmitted (signed message and transmitted message
+      MUST be identical).
+
+   Example message:
+
+         From: Michael Elkins <elkins@aero.org>
+         To: Michael Elkins <elkins@aero.org>
+         Mime-Version: 1.0
+
+
+
+Elkins, et al.              Standards Track                     [Page 5]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+         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?
+      &
+      & 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
+      & trailing 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.
+
+   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.
+
+
+
+
+
+Elkins, et al.              Standards Track                     [Page 6]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+   (2)   Pass both the signed data and its associated content headers
+         along with the OpenPGP signature to the signature verification
+         service.
+
+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.  RFC 1847 Encapsulation
+
+   In [2], it is stated that the data is first signed as a
+   multipart/signature body, and then encrypted to form the final
+   multipart/encrypted body.  This is most useful for standard MIME-
+   compliant message forwarding.
+
+   Example:
+
+         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
+
+
+
+Elkins, et al.              Standards Track                     [Page 7]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+      & HOxEa44b+EI=
+      & =ndaj
+      & -----END PGP MESSAGE-----
+      &
+      & --bar--
+        -----END PGP MESSAGE-----
+
+        --foo--
+
+   (The text preceded by '&' indicates that it is really encrypted, but
+   presented as text for clarity.)
+
+6.2.  Combined method
+
+   The OpenPGP packet format [1] describes a method for signing and
+   encrypting data in a single OpenPGP message.  This method is allowed
+   in order to reduce processing overhead and increase compatibility
+   with non-MIME implementations of OpenPGP.  The resulting data is
+   formatted as a "multipart/encrypted" object as described in Section
+   4.
+
+   Messages which are encrypted and signed in this combined fashion are
+   REQUIRED to follow the same canonicalization rules as
+   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 OpenPGP public keys
+
+   Content-Type: application/pgp-keys
+   Required parameters: none
+   Optional parameters: none
+
+   A MIME body part of the content type "application/pgp-keys" contains
+   ASCII-armored transferable Public Key Packets as defined in [1],
+   section 10.1.
+
+8.  Security Considerations
+
+   Signatures of a canonical text document as defined in [1] ignore
+   trailing white space in signed material.  Implementations which
+   choose to use signatures of canonical text documents will not be able
+   to detect the addition of whitespace in transit.
+
+   See [3], [4] for more information on the security considerations
+   concerning the underlying protocols.
+
+
+
+Elkins, et al.              Standards Track                     [Page 8]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+9.  IANA Considerations
+
+   This document defines three media types: "application/pgp-encrypted",
+   "application/pgp-signature" and "application/pgp-keys".  The
+   following sections specify the IANA registrations for these types.
+
+9.1.  Registration of the application/pgp-encrypted media type
+
+   MIME media type name: application
+   MIME subtype name: pgp-encrypted
+   Required parameters: none
+   Optional parameters: none
+
+   Encoding considerations:
+
+      Currently this media type always consists of a single 7bit text
+      string.
+
+   Security considerations:
+
+      See Section 8 and RFC 2440 Section 13.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+      This document.
+
+   Additional information:
+
+      Magic number(s): none
+      File extension(s): none
+      Macintosh File Type Code(s): none
+
+   Person & email address to contact for further information:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+   Intended usage: common
+
+   Author/Change controller:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+
+
+
+
+
+Elkins, et al.              Standards Track                     [Page 9]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+9.2.  Registration of the application/pgp-signature media type
+
+   MIME media type name: application
+   MIME subtype name: pgp-signature
+   Required parameters: none
+   Optional parameters: none
+
+   Encoding considerations:
+
+      The content of this media type always consists of 7bit text.
+
+   Security considerations:
+
+      See Section 8 and RFC 2440 Section 13.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+      RFC 2440 and this document.
+
+   Additional information:
+
+      Magic number(s): none
+      File extension(s): asc, sig
+      Macintosh File Type Code(s): pgDS
+
+   Person & email address to contact for further information:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+   Intended usage: common
+
+   Author/Change controller:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+9.3.  Registration of the application/pgp-keys media type
+
+   MIME media type name: application
+   MIME subtype name: pgp-keys
+   Required parameters: none
+   Optional parameters: none
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 10]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+   Encoding considerations:
+
+      The content of this media type always consists of 7bit text.
+
+   Security considerations:
+
+      See Section 8 and RFC 2440 Section 13.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+      RFC 2440 and this document.
+
+   Additional information:
+
+      Magic number(s): none
+      File extension(s): asc
+      Macintosh File Type Code(s): none
+
+   Person & email address to contact for further information:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+   Intended usage: common
+
+   Author/Change controller:
+
+      Michael Elkins
+      Email: me@cs.hmc.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 11]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+10.  Notes
+
+   "PGP" and "Pretty Good Privacy" are registered trademarks of Network
+   Associates, Inc.
+
+11.  Acknowledgements
+
+   This document relies on the work of the IETF's OpenPGP Working
+   Group's definitions of the OpenPGP Message Format.  The OpenPGP
+   message format is currently described in RFC 2440 [1].
+
+   Special thanks are due: to Philip Zimmermann for his original and
+   ongoing work on PGP; to Charles Breed, Jon Callas and Dave Del Torto
+   for originally proposing the formation of the OpenPGP Working Group;
+   and to Steve Schoenfeld for helpful feedback during the draft
+   process.  The authors would also like to thank the engineers at
+   Pretty Good Privacy, Inc (now Network Associates, Inc), including
+   Colin Plumb, Hal Finney, Jon Callas, Mark Elrod, Mark Weaver and
+   Lloyd Chambers, for their technical commentary.
+
+   Additional thanks are due to Jeff Schiller and Derek Atkins for their
+   continuing support of strong cryptography and PGP freeware at MIT; to
+   Rodney Thayer of Sable Technology; to John Noerenberg, Steve Dorner
+   and Laurence Lundblade of the Eudora team at QUALCOMM, Inc; to Bodo
+   Moeller for proposing the approach followed with respect to trailing
+   whitespace; to John Gilmore, Hugh Daniel and Fred Ringel (at
+   Rivertown) and Ian Bell (at Turnpike) for their timely critical
+   commentary; and to the international members of the IETF's OpenPGP
+   mailing list, including William Geiger, Lutz Donnerhacke and Kazu
+   Yamamoto.  The idea to use multipart/mixed with multipart/signed has
+   been attributed to James Galvin.  Finally, our gratitude is due to
+   the many members of the "Cypherpunks," "Coderpunks" and "pgp-users"
+   <http://cryptorights.org/pgp-users> mailing lists and the many users
+   of PGP worldwide for helping keep the path to privacy open.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 12]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+12.  Addresses of the Authors and OpenPGP Working Group Chair
+
+   The OpenPGP working group can be contacted via the current chair:
+
+   John W. Noerenberg II
+   Qualcomm, Inc.
+   5775 Morehouse Dr.
+   San Diego, CA 92121 USA
+
+   Phone: +1 619 658 3510
+   EMail: jwn2@qualcomm.com
+
+   The principal authors of this document are:
+
+   Dave Del Torto
+   CryptoRights Foundation
+   80 Alviso Street, Mailstop: CRF
+   San Francisco, CA 94127 USA
+
+   Phone: +1.415.334.5533, vm: #2
+   EMail: ddt@cryptorights.org, ddt@openpgp.net
+
+
+   Michael Elkins
+   Network Associates, Inc.
+   3415 S. Sepulveda Blvd Suite 700
+   Los Angeles, CA 90034 USA
+
+   Phone: +1.310.737.1663
+   Fax:   +1.310.737.1755
+   Email: me@cs.hmc.edu, Michael_Elkins@NAI.com
+
+
+   Raph Levien
+   University of California at Berkeley
+   579 Soda Hall
+   Berkeley, CA 94720 USA
+
+   Phone: +1.510.642.6509
+   EMail: raph@acm.org
+
+
+   Thomas Roessler
+   Nordstrasse 99
+   D-53111 Bonn, Germany
+
+   Phone: +49-228-638007
+   EMail: roessler@does-not-exist.org
+
+
+
+Elkins, et al.              Standards Track                    [Page 13]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+References
+
+   [1]   Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
+         Message Format", RFC 2440, November 1998.
+
+   [2]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security
+         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+         RFC 1847, October 1995.
+
+   [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part Two: Media Types", RFC 2046, November
+         1996.
+
+   [4]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "MIME Object
+         Security Services", RFC 1848, October 1995.
+
+   [5]   Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
+         Exchange Formats", RFC 1991, August 1996.
+
+   [6]   Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
+         2015, October 1996.
+
+   [7]   Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
+         January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 14]
+
+RFC 3156               MIME Security with OpenPGP            August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elkins, et al.              Standards Track                    [Page 15]
+