replace doc-src/rfc2015.txt with updated verion doc-src/rfc3156.txt
authorChristoph Hohmann <reboot@gmx.ch>
Tue, 25 Feb 2003 12:39:52 +0000 (12:39 +0000)
committerChristoph Hohmann <reboot@gmx.ch>
Tue, 25 Feb 2003 12:39:52 +0000 (12:39 +0000)
doc/src/readme.txt
doc/src/rfc2015.txt [deleted file]
doc/src/rfc3156.txt [new file with mode: 0644]

index 71fe149..a2ea186 100644 (file)
@@ -1,6 +1,5 @@
 rfc977.txt     NNTP
 rfc1939.txt    POP3
-rfc2015.txt    MIME Security with Pretty Good Privacy (PGP)
 rfc2045.txt    MIME 1
 rfc2046.txt    MIME 2
 rfc2047.txt    MIME 3
@@ -14,3 +13,4 @@ rfc2487.txt   SMTP Service Extension for Secure SMTP over TLS
 rfc2821.txt    SMTP
 rfc2822.txt    Internet Message Format
 rfc2980.txt    Common NNTP Extensions
+rfc3156.txt    MIME Security with OpenPGP
diff --git a/doc/src/rfc2015.txt b/doc/src/rfc2015.txt
deleted file mode 100644 (file)
index 747335d..0000000
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Elkins
-Request for Comments: 2015                     The Aerospace Corporation
-Category: Standards Track                                   October 1996
-
-
-              MIME Security with Pretty Good Privacy (PGP)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes how Pretty Good Privacy (PGP) can be used to
-   provide privacy and authentication using the Multipurpose Internet
-   Mail Extensions (MIME) security content types described in RFC1847.
-
-1.  Introduction
-
-   Previous work on integrating PGP with MIME (including the since
-   withdrawn application/pgp content type) has suffered from a number of
-   problems, the most significant of which is the inability to recover
-   signed message bodies without parsing data structures specific to
-   PGP.  This work makes use of the elegant solution proposed in
-   RFC1847, which defines security multipart formats for MIME. The
-   security multiparts clearly separate the signed message body from the
-   signature, and have a number of other desirable properties. This
-   document is styled after RFC 1848, which defines MIME Object Security
-   Services (MOSS) for providing security and authentication.
-
-   This document defines three new content types for implementing
-   security and privacy with PGP: application/pgp-encrypted,
-   application/pgp-signature and application/pgp-keys.
-
-1.1  Compliance
-
-   In order for an implementation to be compliant with this
-   specification, is it absolutely necessary for it to obey all items
-   labeled as MUST or REQUIRED.
-
-
-
-
-
-
-
-
-Elkins                      Standards Track                     [Page 1]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-2.  PGP data formats
-
-   PGP can generate either ASCII armor (described in [3]) or 8-bit
-   binary output when encrypting data, generating a digital signature,
-   or extracting public key data.  The ASCII armor output is the
-   REQUIRED method for data transfer.  This allows those users who do
-   not have the means to interpret the formats described in this
-   document to be able extract and use the PGP information in the
-   message.
-
-   When the amount of data to be transmitted requires that it be sent in
-   many parts, the MIME message/partial mechanism should be used rather
-   than the multipart ASCII armor PGP format.
-
-3.  Content-Transfer-Encoding restrictions
-
-   Multipart/signed and multipart/encrypted are to be treated by agents
-   as opaque, meaning that the data is not to be altered in any way [1].
-   However, many existing mail gateways will detect if the next hop does
-   not support MIME or 8-bit data and perform conversion to either
-   Quoted-Printable or Base64.  This presents serious problems for
-   multipart/signed, in particular, where the signature is invalidated
-   when such an operation occurs.  For this reason all data signed
-   according to this protocol MUST be constrained to 7 bits (8- bit data
-   should be encoded using either Quoted-Printable or Base64).  Note
-   that this also includes the case where a signed object is also
-   encrypted (see section 6).  This restriction will increase the
-   likelihood that the signature will be valid upon receipt.
-
-   Data that is ONLY to be encrypted is allowed to contain 8-bit
-   characters and therefore need not be converted to a 7-bit format.
-
-     Implementor's note: It cannot be stressed enough that applications
-     using this standard should follow MIME's suggestion that you "be
-     conservative in what you generate, and liberal in what you accept."
-     In this particular case it means it would be wise for an
-     implementation to accept messages with any content-transfer-
-     encoding, but restrict generation to the 7-bit format required by
-     this memo.  This will allow future compatibility in the event the
-     Internet SMTP framework becomes 8-bit friendly.
-
-4.  PGP encrypted data
-
-   Before encryption with PGP, the data should be written in MIME
-   canonical format (body and headers).
-
-   PGP encrypted data is denoted by the "multipart/encrypted" content
-   type, described in [1], and MUST have a "protocol" parameter value of
-
-
-
-Elkins                      Standards Track                     [Page 2]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-   "application/pgp-encrypted".  Note that the value of the parameter
-   MUST be enclosed in quotes.
-
-   The multipart/encrypted MUST consist of exactly two parts.  The first
-   MIME body part must have a content type of "application/pgp-
-   encrypted".  This body contains the control information.  A message
-   complying with this standard MUST contain a "Version: 1" field in
-   this body.  Since the PGP packet format contains all other
-   information necessary for decrypting, no other information is
-   required here.
-
-   The second MIME body part MUST contain the actual encrypted data.  It
-   must be labeled with a content type of "application/octet- stream".
-
-   Example message:
-
-     From: Michael Elkins <elkins@aero.org>
-     To: Michael Elkins <elkins@aero.org>
-     Mime-Version: 1.0
-     Content-Type: multipart/encrypted; boundary=foo;
-        protocol="application/pgp-encrypted"
-
-     --foo
-     Content-Type: application/pgp-encrypted
-
-     Version: 1
-
-     --foo
-     Content-Type: application/octet-stream
-
-     -----BEGIN PGP MESSAGE-----
-     Version: 2.6.2
-
-     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
-     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
-     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
-     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
-     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
-     =zzaA
-     -----END PGP MESSAGE-----
-
-     --foo--
-
-5.  PGP signed data
-
-   PGP signed messages are denoted by the "multipart/signed" content
-   type, described in [1], with a "protocol" parameter which MUST have a
-   value of "application/pgp-signature" (MUST be quoted).  The "micalg"
-
-
-
-Elkins                      Standards Track                     [Page 3]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-   parameter MUST have a value of "pgp-<hash-symbol>", where <hash-
-   symbol> identifies the message integrity check (MIC) used to generate
-   the signature.  The currently defined values for <hash-symbol> are
-   "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm.
-
-   The multipart/signed body MUST consist of exactly two parts.  The
-   first part contains the signed data in MIME canonical format,
-   including a set of appropriate content headers describing the data.
-
-   The second body MUST contain the PGP digital signature.  It MUST be
-   labeled with a content type of "application/pgp-signature".
-
-   When the PGP digital signature is generated:
-
-   (1)  The data to be signed must first be converted to its
-        type/subtype specific canonical form.  For text/plain, this
-        means conversion to an appropriate character set and conversion
-        of line endings to the canonical <CR><LF> sequence.
-
-   (2)  An appropriate Content-Transfer-Encoding is then applied. Each
-        line of the encoded data MUST end with the canonical <CR><LF>
-        sequence.
-
-   (3)  MIME content headers are then added to the body, each ending
-        with the canonical <CR><LF> sequence.
-
-   (4)  As described in [1], the digital signature MUST be calculated
-        over both the data to be signed and its set of content headers.
-
-   (5)  The signature MUST be generated detached from the signed data
-        so that the process does not alter the signed data in any way.
-
-   Example message:
-
-     From: Michael Elkins <elkins@aero.org>
-     To: Michael Elkins <elkins@aero.org>
-     Mime-Version: 1.0
-     Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5;
-     protocol="application/pgp-signature"
-
-     --bar
-     & Content-Type: text/plain; charset=iso-8859-1
-     & Content-Transfer-Encoding: quoted-printable
-     &
-     & =A1Hola!
-     &
-     & Did you know that talking to yourself is a sign of senility?
-     &
-
-
-
-Elkins                      Standards Track                     [Page 4]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-     & It's generally a good idea to encode lines that begin with
-     & From=20because some mail transport agents will insert a greater-
-     & than (>) sign, thus invalidating the signature.
-     &
-     & Also, in some cases it might be desirable to encode any   =20
-     &railing whitespace that occurs on lines in order to ensure  =20
-     & that the message signature is not invalidated when passing =20
-     & a gateway that modifies such whitespace (like BITNET). =20
-     &
-     & me
-
-     --bar
-     Content-Type: application/pgp-signature
-
-    -----BEGIN PGP MESSAGE-----
-   Version: 2.6.2
-
-   iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
-   jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
-   uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
-   HOxEa44b+EI=
-   =ndaj
-   -----END PGP MESSAGE-----
-
-   --bar--
-
-   The "&"s in the previous example indicate the portion of the data
-   over which the signature was calculated.
-
-   Though not required, it is generally a good idea to use Quoted-
-   Printable encoding in the first step (writing out the data to be
-   signed in MIME canonical format) if any of the lines in the data
-   begin with "From ", and encode the "F".  This will avoid an MTA
-   inserting a ">" in front of the line, thus invalidating the
-   signature!
-
-   Upon receipt of a signed message, an application MUST:
-
-   (1)  Convert line endings to the canonical <CR><LF> sequence before
-        the signature can be verified.  This is necessary since the
-        local MTA may have converted to a local end of line convention.
-
-   (2)  Pass both the signed data and its associated content headers
-        along with the PGP signature to the signature verification
-        service.
-
-
-
-
-
-
-Elkins                      Standards Track                     [Page 5]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-6.  Encrypted and Signed Data
-
-   Sometimes it is desirable to both digitally sign and then encrypt a
-   message to be sent.  This protocol allows for two methods of
-   accomplishing this task.
-
-6.1  RFC1847 Encapsulation
-
-   [1], it is stated that the data should first be signed as a
-   multipart/signature body, and then encrypted to form the final
-   multipart/encrypted body, i.e.,
-
-    Content-Type: multipart/encrypted;
-       protocol="application/pgp-encrypted"; boundary=foo
-
-    --foo
-    Content-Type: application/pgp-encrypted
-
-    Version: 1
-
-    --foo
-    Content-Type: application/octet-stream
-
-    -----BEGIN PGP MESSAGE-----
-    & Content-Type: multipart/signed; micalg=pgp-md5
-    &     protocol="application/pgp-signature"; boundary=bar
-    &
-    & --bar
-    & Content-Type: text/plain; charset=us-ascii
-    &
-    & This message was first signed, and then encrypted.
-    &
-    & --bar
-    & Content-Type: application/pgp-signature
-    &
-    & -----BEGIN PGP MESSAGE-----
-    & Version: 2.6.2
-    &
-    & iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
-    & jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
-    & uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
-    & HOxEa44b+EI=
-    & =ndaj
-    & -----END PGP MESSAGE-----
-    &
-    & --bar--
-    -----END PGP MESSAGE-----
-
-
-
-
-Elkins                      Standards Track                     [Page 6]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-    --foo--
-
-    (The text preceded by '&' indicates that it is really
-    encrypted, but presented as text for clarity.)
-
-6.2  Combined method
-
-   Versions 2.x of PGP also allow data to be signed and encrypted in one
-   operation.  This method is an acceptable shortcut, and has the
-   benefit of less overhead.  The resulting data should be formed as a
-   "multipart/encrypted" object as described above.
-
-   Messages which are encrypted and signed in this combined fashion are
-   REQUIRED to follow the same canonicalization rules as for
-   multipart/signed objects.
-
-   It is explicitly allowed for an agent to decrypt a combined message
-   and rewrite it as a multipart/signed object using the signature data
-   embedded in the encrypted version.
-
-7.  Distribution of PGP public keys
-
-   Content-Type: application/pgp-keys
-   Required parameters: none
-   Optional parameters: none
-
-   This is the content type which should be used for relaying public key
-   blocks.
-
-8.  Notes
-
-   PGP and Pretty Good Privacy are trademarks of Philip Zimmermann.
-
-9.  Security Considerations
-
-   Use of this protocol has the same security considerations as PGP, and
-   is not known to either increase or decrease the security of messages
-   using it; see [3] for more information.
-
-10.  Author's Address
-
-        Michael Elkins
-        P.O. Box 92957 - M1/102
-        Los Angeles, CA 90009-2957
-
-        Phone: +1 310 336 8040
-        Fax: +1 310 336 4402
-
-
-
-
-Elkins                      Standards Track                     [Page 7]
-\f
-RFC 2015                 MIME Security with PGP             October 1996
-
-
-References
-
-   [1]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "Security
-        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
-        RFC 1847, October 1995.
-
-   [2]  Galvin, J., Murphy, G., Crocker, S., and N. Freed, "MIME Object
-        Security Services", RFC 1848, October 1995.
-
-   [3]  Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
-        Exchange Formats", RFC 1991, August 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elkins                      Standards Track                     [Page 8]
-\f
diff --git a/doc/src/rfc3156.txt b/doc/src/rfc3156.txt
new file mode 100644 (file)
index 0000000..070c27c
--- /dev/null
@@ -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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f