4.4 Encapsulation Mechanism

The encapsulation techniques defined in RFC-934 [6] are adopted for encapsulation of PEM messages within separate enclosing MTS messages carrying associated MTS headers. This approach offers a number of advantages relative to a flat approach in which certain fields within a single header are encrypted and/or carry cryptographic control information. As far as the MTS is concerned, the entirety of a PEM message will reside in an MTS message's text portion, not the MTS message's header portion. Encapsulation provides generality and segregates fields with user-to-user significance from those transformed in transit. All fields inserted in the course of encryption/authentication processing are placed in the encapsulated header. This facilitates compatibility with mail handling programs which accept only text, not header fields, from input files or from other programs.

The encapsulation techniques defined in RFC-934 are consistent with existing Internet mail forwarding and bursting mechanisms. These techniques are designed so that they may be used in a nested manner. The encapsulation techniques may be used to encapsulate one or more PEM messages for forwarding to a third party, possibly in conjunction with interspersed (non-PEM) text which serves to annotate the PEM messages.

Two encapsulation boundaries (EB's) are defined for delimiting encapsulated PEM messages and for distinguishing encapsulated PEM messages from interspersed (non-PEM) text. The pre-EB is the string "-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an encapsulated PEM message follows. The post-EB is either (1) another pre-EB indicating that another encapsulated PEM message follows, or (2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating that any text that immediately follows is non-PEM text. A special point must be noted for the case of MIC-CLEAR messages, the text portions of which may contain lines which begin with the "-" character and which are therefore subject to special processing per RFC-934 forwarding procedures. When the string "- " must be prepended to such a line in the course of a forwarding operation in order to distinguish that line from an encapsulation boundary, MIC computation is to be performed prior to prepending the "- " string. Figure 1 depicts the encapsulation of a single PEM message.

This RFC places no a priori limits on the depth to which such encapsulation may be nested nor on the number of PEM messages which may be grouped in this fashion at a single nesting level for forwarding. A implementation compliant with this RFC must not preclude a user from submitting or receiving PEM messages which exploit this encapsulation capability. However, no specific requirements are levied upon implementations with regard to how this capability is made available to the user. Thus, for example, a compliant PEM implementation is not required to automatically detect and process encapsulated PEM messages.

In using this encapsulation facility, it is important to note that it is inappropriate to forward directly to a third party a message that is ENCRYPTED because recipients of such a message would not have access to the DEK required to decrypt the message. Instead, the user forwarding the message must transform the ENCRYPTED message into a MIC-ONLY or MIC-CLEAR form prior to forwarding. Thus, in order to comply with this RFC, a PEM implementation must provide a facility to enable a user to perform this transformation, while preserving the MIC associated with the original message.

If a user wishes PEM-provided confidentiality protection for transmitted information, such information must occur in the encapsulated text of an ENCRYPTED PEM message, not in the enclosing MTS header or PEM encapsulated header. If a user wishes to avoid

   Encapsulated Message

       Pre-Encapsulation Boundary (Pre-EB)
           -----BEGIN PRIVACY-ENHANCED MESSAGE-----

       Encapsulated Header Portion
           (Contains encryption control fields inserted in plaintext.
           Examples include "DEK-Info:" and "Key-Info:".
           Note that, although these control fields have line-oriented
           representations similar to RFC 822 header fields, the set
           of fields valid in this context is disjoint from those used
           in RFC 822 processing.)

       Blank Line
           (Separates Encapsulated Header from subsequent
           Encapsulated Text Portion)

       Encapsulated Text Portion
           (Contains message data encoded as specified in Section 4.3.)

       Post-Encapsulation Boundary (Post-EB)
           -----END PRIVACY-ENHANCED MESSAGE-----

                   Encapsulated Message Format
                            Figure 1

disclosing the actual subject of a message to unintended parties, it is suggested that the enclosing MTS header contain a "Subject:" field indicating that "Encrypted Mail Follows".

If an integrity-protected representation of information which occurs within an enclosing header (not necessarily in the same format as that in which it occurs within that header) is desired, that data can be included within the encapsulated text portion in addition to its inclusion in the enclosing MTS header. For example, an originator wishing to provide recipients with a protected indication of a message's position in a series of messages could include within the encapsulated text a copy of a timestamp or message counter value possessing end-to-end significance and extracted from an enclosing MTS header field. (Note: mailbox specifiers as entered by end users incorporate local conventions and are subject to modification at intermediaries, so inclusion of such specifiers within encapsulated text should not be regarded as a suitable alternative to the authentication semantics defined in RFC 1422 and based on X.500 Distinguished Names.) The set of header information (if any) included within the encapsulated text of messages is a local matter, and this RFC does not specify formatting conventions to distinguish replicated header fields from other encapsulated text.