RFC 3156 (rfc3156) - Page 2 of 15


MIME Security with OpenPGP



Alternative Format: Original Text Document



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