As per Relevance of the word encapsulate, we have this rfc below:
Network Working Group J.
Request for Comments: 1421 IAB IRTF PSRG, IETF PEM
Obsoletes: 1113 February 1993
Privacy Enhancement for Internet Electronic Mail
Part I: Message Encryption and Authentication
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This document is the outgrowth of a series of meetings of the
and Security Research Group (PSRG) of the IRTF and the PEM
Group of the IETF. I would like to thank the members of the PSRG
the IETF PEM WG, as well as all participants in discussions on
"pem-dev@tis.com" mailing list, for their contributions to
document
1. Executive
This document defines message encryption and
procedures, in order to provide privacy-enhanced mail (PEM)
for electronic mail transfer in the Internet. It is intended
become one member of a related set of four RFCs. The
defined in the current document are intended to be compatible with
wide range of key management approaches, including both
(secret-key) and asymmetric (public-key) approaches for encryption
data encrypting keys. Use of symmetric cryptography for message
encryption and/or integrity check computation is anticipated.
1422 specifies supporting key management mechanisms based on the
of public-key certificates. RFC 1423 specifies algorithms, modes
and associated identifiers relevant to the current RFC and to
1422. RFC 1424 provides details of paper and electronic formats
procedures for the key management infrastructure being established
support of these services
Privacy enhancement services (confidentiality, authentication
message integrity assurance, and non-repudiation of origin)
offered through the use of end-to-end cryptography between
and recipient processes at or above the User Agent level. No
processing requirements are imposed on the Message Transfer System
Linn [Page 1]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
endpoints or at intermediate relay sites. This approach
privacy enhancement facilities to be incorporated selectively on
site-by-site or user-by-user basis without impact on other
entities. Interoperability among heterogeneous components and
transport facilities is supported
The current specification's scope is confined to PEM
procedures for the RFC-822 textual mail environment, and defines
Content-Domain indicator value "RFC822" to signify this usage
Follow-on work in integration of PEM capabilities with
messaging environments (e.g., MIME) is anticipated and will
addressed in separate and/or successor documents, at which
additional Content-Domain indicator values will be defined
2.
For descriptive purposes, this RFC uses some terms defined in the
X.400 Message Handling System Model per the CCITT Recommendations
This section replicates a portion of (1984) X.400's Section 2.2.1,
"Description of the MHS Model: Overview" in order to make
terminology clear to readers who may not be familiar with the OSI
Model
In the [MHS] model, a user is a person or a computer application.
user is referred to as either an originator (when sending a message
or a recipient (when receiving one). MH Service elements define
set of message types and the capabilities that enable an
to transfer messages of those types to one or more recipients
An originator prepares messages with the assistance of his or
User Agent (UA). A UA is an application process that interacts
the Message Transfer System (MTS) to submit messages. The
delivers to one or more recipient UAs the messages submitted to it
Functions performed solely by the UA and not standardized as part
the MH Service elements are called local UA functions
The MTS is composed of a number of Message Transfer Agents (MTAs).
Operating together, the MTAs relay messages and deliver them to
intended recipient UAs, which then make the messages available to
intended recipients
The collection of UAs and MTAs is called the Message Handling
(MHS). The MHS and all of its users are collectively referred to
the Message Handling Environment
Linn [Page 2]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
3. Services, Constraints, and
This RFC defines mechanisms to enhance privacy for electronic
transferred in the Internet. The facilities discussed in this
provide privacy enhancement services on an end-to-end basis
originator and recipient processes residing at the UA level or above
No privacy enhancements are offered for message fields which
added or transformed by intermediate relay points between
processing components
If an originator elects to perform PEM processing on an
message, all PEM-provided security services are applied to the
message's body in its entirety; selective application to portions
a PEM message is not supported. Authentication, integrity, and (
asymmetric key management is employed) non-repudiation of
services are applied to all PEM messages; confidentiality
are optionally selectable
In keeping with the Internet's heterogeneous constituencies and
modes, the measures defined here are applicable to a broad range
Internet hosts and usage paradigms. In particular, it is
noting the following attributes
1. The mechanisms defined in this RFC are not restricted to
particular host or operating system, but rather
interoperability among a broad range of systems.
privacy enhancements are implemented at the
layer, and are not dependent on any privacy features
lower protocol layers
2. The defined mechanisms are compatible with non-
Internet components. Privacy enhancements are
in an end-to-end fashion which does not impact
processing by intermediate relay hosts which do
incorporate privacy enhancement facilities. It
necessary, however, for a message's originator to
cognizant of whether a message's intended
implements privacy enhancements, in order that encoding
possible encryption will not be performed on a message
destination is not equipped to perform corresponding
transformations. (Section 4.6.1.1.3 of this RFC describes
PEM message type ("MIC-CLEAR") which represents a signed
unencrypted PEM message in a form readable without
processing capabilities yet validatable by PEM-
recipients.)
3. The defined mechanisms are compatible with a range of
transport facilities (MTAs). Within the Internet
Linn [Page 3]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
electronic mail transport is effected by a variety of
[2] implementations. Certain sites, accessible via SMTP
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must
able to operate across the SMTP realm; it is desirable
they also be compatible with protection of electronic
sent between the SMTP environment and other
environments
4. The defined mechanisms are compatible with a broad range
electronic mail user agents (UAs). A large variety
electronic mail user agent programs, with a
broad range of user interface paradigms, is used in
Internet. In order that electronic mail
enhancements be available to the broadest possible
community, selected mechanisms should be usable with
widest possible variety of existing UA programs.
purposes of pilot implementation, it is desirable
privacy enhancement processing be incorporable into
separate program, applicable to a range of UAs, rather
requiring internal modifications to each UA with which
services are to be provided
5. The defined mechanisms allow electronic mail
enhancement processing to be performed on personal
(PCs) separate from the systems on which UA functions
implemented. Given the expanding use of PCs and the
degree of trust which can be placed in UA implementations
many multi-user systems, this attribute can allow many
to process PEM with a higher assurance level than a
UA-integrated approach would allow
6. The defined mechanisms support privacy protection
electronic mail addressed to mailing lists (
lists, in ISO parlance).
7. The mechanisms defined within this RFC are compatible with
variety of supporting key management approaches,
(but not limited to) manual pre-distribution,
key distribution based on symmetric cryptography, and
use of public-key certificates per RFC 1422.
key management mechanisms may be used for
recipients of a multicast message. For two
implementations to interoperate, they must share a
key management mechanism; support for the mechanism
in RFC 1422 is strongly encouraged
Linn [Page 4]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
In order to achieve applicability to the broadest possible range
Internet hosts and mail systems, and to facilitate
implementation and testing without the need for prior and
modifications throughout the Internet, the following
principles were applied in selecting the set of features specified
this RFC
1. This RFC's measures are restricted to implementation
endpoints and are amenable to integration with
Internet mail protocols at the user agent (UA) level
above, rather than necessitating modifications to
mail protocols or integration into the message
system (e.g., SMTP servers).
2. The set of supported measures enhances rather than
user capabilities. Trusted implementations,
integrity features protecting software from subversion
local users, cannot be assumed in general. No
are assumed to prevent users from sending, at
discretion, messages to which no PEM processing has
applied. In the absence of such features, it appears
feasible to provide facilities which enhance user
(e.g., by protecting and authenticating inter-user traffic
than to enforce restrictions (e.g., inter-user
control) on user actions
3. The set of supported measures focuses on a set of
capabilities selected to provide significant and
benefits to a broad user community. By concentrating on
most critical set of services, we aim to maximize the
privacy value that can be provided with a modest level
implementation effort
Based on these principles, the following facilities are provided
1. disclosure protection
2. originator authenticity
3. message integrity measures,
4. (if asymmetric key management is used) non-repudiation
origin
but the following privacy-relevant concerns are not addressed
1. access control
Linn [Page 5]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
2. traffic flow confidentiality
3. address list accuracy
4. routing control
5. issues relating to the casual serial reuse of PCs
multiple users
6. assurance of message receipt and non-deniability of receipt
7. automatic association of acknowledgments with the
to which they refer,
8. message duplicate detection, replay prevention, or
stream-oriented
4. Processing of
4.1 Message Processing
This subsection provides a high-level overview of the components
processing steps involved in electronic mail privacy
processing. Subsequent subsections will define the procedures
more detail
4.1.1 Types of
A two-level keying hierarchy is used to support PEM transmission
1. Data Encrypting Keys (DEKs) are used for encryption
message text and (with certain choices among a set
alternative algorithms) for computation of message
check (MIC) quantities. In the asymmetric key
environment, DEKs are also used to encrypt the
representations of MICs in PEM messages to
confidentiality has been applied. DEKs are
individually for each transmitted message;
predistribution of DEKs is needed to support
transmission
2. Interchange Keys (IKs) are used to encrypt DEKs
transmission within messages. Ordinarily, the same IK
be used for all messages sent from a given originator to
given recipient over a period of time. Each
message includes a representation of the DEK(s) used
message encryption and/or MIC computation, encrypted
an individual IK per named recipient. The representation
Linn [Page 6]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
associated with Originator-ID and Recipient-ID
(defined in different forms so as to distinguish
from asymmetric cases), which allow each
recipient to identify the IK used to encrypt DEKs and/
MICs for that recipient's use. Given an appropriate IK,
recipient can decrypt the corresponding transmitted
representation, yielding the DEK required for message
decryption and/or MIC validation. The definition of an
differs depending on whether symmetric or
cryptography is used for DEK encryption
2a. When symmetric cryptography is used for
encryption, an IK is a single symmetric key
between an originator and a recipient. In
case, the same IK is used to encrypt MICs as
as DEKs for transmission. Version/
information and IA identification associated
the originator and with the recipient must
concatenated in order to fully qualify a
IK
2b. When asymmetric cryptography is used, the
component used for DEK encryption is the
component [8] of the recipient. The IK
used for MIC encryption is the private component
the originator, and therefore only one
MIC representation need be included per message
rather than one per recipient. Each of these
components can be fully qualified in a Recipient-
or Originator-ID field, respectively
Alternatively, an originator's IK component may
determined from a certificate carried in
"Originator-Certificate:" field
4.1.2 Processing
When PEM processing is to be performed on an outgoing message, a
is generated [1] for use in message encryption and (if a chosen
algorithm requires a key) a variant of the DEK is formed for use
MIC computation. DEK generation can be omitted for the case of
message where confidentiality is not to be applied, unless a
MIC computation algorithm requires a DEK. Other parameters (e.g.,
Initialization Vectors (IVs)) as required by selected
algorithms are also generated
One or more Originator-ID and/or "Originator-Certificate:" fields
included in a PEM message's encapsulated header to provide
with an identification component for the IK(s) used for
Linn [Page 7]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
processing. All of a message's Originator-ID and/or "Originator
Certificate:" fields are assumed to correspond to the same principal
the facility for inclusion of multiple such fields accomodates
prospect that different keys, algorithms, and/or certification
may be required for processing by different recipients. When
message includes recipients for which asymmetric key management
employed as well as recipients for which symmetric key management
employed, a separate Originator-ID or "Originator-Certificate:"
precedes each set of recipients
In the symmetric case, per-recipient IK components are applied
each individually named recipient in preparation of ENCRYPTED, MIC
ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID
Symmetric:" field, interpreted in the context of the most
preceding "Originator-ID-Symmetric:" field, serves to identify
IK. In the asymmetric case, per-recipient IK components are
only for ENCRYPTED messages, are independent of originator-
header elements, and are identified by "Recipient-ID-Asymmetric:"
fields. Each Recipient-ID field is followed by a "Key-Info:" field
which transfers the message's DEK encrypted under the IK
for the specified recipient
When symmetric key management is used for a given recipient,
"Key-Info:" field following the corresponding "Recipient-ID
Symmetric:" field also transfers the message's computed MIC
encrypted under the recipient's IK. When asymmetric key management
used, a "MIC-Info:" field associated with an "Originator-ID
Asymmetric:" or "Originator-Certificate:" field carries the message'
MIC, asymmetrically signed using the private component of
originator. If the PEM message is of type ENCRYPTED (as defined
Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC
symmetrically encrypted using the same DEK, algorithm,
mode and other cryptographic parameters as used to encrypt
message text, prior to inclusion in the "MIC-Info:" field
4.1.2.1 Processing
A four-phase transformation procedure is employed in order
represent encrypted message text in a universally transmissible
and to enable messages encrypted on one type of host computer to
decrypted on a different type of host computer. A plaintext
is accepted in local form, using the host's native character set
line representation. The local form is converted to a
message text representation, defined as equivalent to the inter-
representation of message text. This canonical representation
the input to the MIC computation step (applicable to ENCRYPTED, MIC
ONLY, and MIC-CLEAR messages) and the encryption process (
to ENCRYPTED messages only).
Linn [Page 8]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
For ENCRYPTED PEM messages, the canonical representation is padded
required by the encryption algorithm, and this padded
representation is encrypted. The encrypted text (for an
message) or the unpadded canonical form (for a MIC-ONLY message)
then encoded into a printable form. The printable form is
of a restricted character set which is chosen to be
representable across sites, and which will not be disrupted
processing within and between MTS entities. MIC-CLEAR PEM
omit the printable encoding step
The output of the previous processing steps is combined with a set
header fields carrying cryptographic control information.
resulting PEM message is passed to the electronic mail system to
included within the text portion of a transmitted message. There
no requirement that a PEM message comprise the entirety of an
message's text portion; this allows PEM-protected information to
accompanied by (unprotected) annotations. It is also permissible
multiple PEM messages (and associated unprotected text, outside
PEM message boundaries) to be represented within the
text of a higher-level PEM message. PEM message signatures
forwardable when asymmetric key management is employed; an
recipient of a PEM message with confidentiality applied can
that message to a signed but unencrypted form for forwarding
or can re-encrypt that message for subsequent transmission
When a PEM message is received, the cryptographic control
within its encapsulated header provide the information required
each authorized recipient to perform MIC validation and decryption
the received message text. For ENCRYPTED and MIC-ONLY messages,
printable encoding is converted to a bitstring. Encrypted
of the transmitted message are decrypted. The MIC is validated
Then, the recipient PEM process converts the canonical
to its appropriate local form
4.1.2.2 Error
A variety of error cases may occur and be detected in the course
processing a received PEM message. The specific actions to be
in response to such conditions are local matters, varying
functions of user preferences and the type of user interface
by a particular PEM implementation, but certain
recommendations are appropriate. Syntactically invalid PEM
should be flagged as such, preferably with collection of
information to support debugging of incompatibilities or
failures. RFC 1422 defines specific error processing
relevant to the certificate-based key management mechanisms
therein
Linn [Page 9]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Syntactically valid PEM messages which yield MIC failures
special concern, as they may result from attempted attacks or
messages. As such, it is unsuitable to display their contents
recipient users without first indicating the fact that the contents
authenticity and integrity cannot be guaranteed and then
positive user confirmation of such a warning. MIC-CLEAR
(discussed in Section 4.6.1.1.3 of this RFC) raise special concerns
as MIC failures on such messages may occur for a broader range
benign causes than are applicable to other PEM message types
4.2 Encryption Algorithms, Modes, and
For use in conjunction with this RFC, RFC 1423 defines
appropriate algorithms, modes, and associated identifiers to be
for encryption of message text with DEKs
The mechanisms defined in this RFC incorporate facilities
transmission of cryptographic parameters (e.g.,
Initializing Vectors (IVs)) with PEM messages to which
confidentiality service is applied, when required by
message encryption algorithms and modes specified in RFC 1423.
Certain operations require encryption of DEKs, MICs, and
signatures under an IK for purposes of transmission. A
facility indicates the mode in which the IK is used for encryption
RFC 1423 specifies encryption algorithm and mode identifiers
minimum essential support requirements for key encryption processing
RFC 1422 specifies asymmetric, certificate-based key
procedures based on CCITT Recommendation X.509 to support the
processing procedures defined in this document. Support for the
management approach defined in RFC 1422 is strongly recommended.
message processing procedures can also be used with symmetric
management, given prior distribution of suitable symmetric IKs,
no current RFCs specify key distribution procedures for such IKs
4.3 Privacy Enhancement Message
4.3.1
An electronic mail encryption mechanism must be compatible with
transparency constraints of its underlying electronic
facilities. These constraints are generally established based
expected user requirements and on the characteristics of
endpoint and transport facilities. An encryption mechanism must
be compatible with the local conventions of the computer
which it interconnects. Our approach uses a canonicalization step
abstract out local conventions and a subsequent encoding step
Linn [Page 10]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
conform to the characteristics of the underlying mail
medium (SMTP). The encoding conforms to SMTP constraints.
4.5 of RFC 821 [2] details SMTP's transparency constraints
To prepare a message for SMTP transmission, the
requirements must be met
1. All characters must be members of the 7-bit ASCII
set
2. Text lines, delimited by the character pair ,
be no more than 1000 characters long
3. Since the string . indicates the end of
message, it must not occur in text prior to the end of
message
Although SMTP specifies a standard representation for line
(ASCII ), numerous systems in the Internet use a
native representation to delimit lines. For example, the
sequences delimiting lines in mail inbound to UNIX systems
transformed to single s as mail is written into local
files. Lines in mail incoming to record-oriented systems (such
VAX VMS) may be converted to appropriate records by the
SMTP server [3]. As a result, if the encryption process
s or s, those characters might not be accessible to
recipient UA program at a destination which uses different
delimiting conventions. It is also possible that conversion
tabs and spaces may be performed in the course of mapping
inter-SMTP and local format; this is a matter of local option.
such transformations changed the form of transmitted ciphertext
decryption would fail to regenerate the transmitted plaintext, and
transmitted MIC would fail to compare with that computed at
destination
The conversion performed by an SMTP server at a system with EBCDIC
a native character set has even more severe impact, since
conversion from EBCDIC into ASCII is an information-
transformation. In principle, the transformation function
between inter-SMTP canonical ASCII message representation and
format could be moved from the SMTP server up to the UA, given
means to direct that the SMTP server should no longer perform
transformation. This approach has a major disadvantage:
file (e.g., mailbox) formats would be incompatible with the
forms used on the systems where they reside. Further, it
require modification to SMTP servers, as mail would be passed to
in a different representation than it is passed at present
Linn [Page 11]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.3.2
Our approach to supporting PEM across an environment in
intermediate conversions may occur defines an encoding for mail
is uniformly representable across the set of PEM UAs regardless
their systems' native character sets. This encoded form is used (
specified PEM message types) to represent mail text in transit
originator to recipient, but the encoding is not applied to
MTS headers or to encapsulated headers inserted to carry
information between PEM UAs. The encoding's characteristics are
that the transformations anticipated between originator and
UAs will not prevent an encoded message from being decoded
at its destination
Four transformation steps, described in the following
subsections, apply to outbound PEM message processing
4.3.2.1 Step 1: Local
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY,
MIC-CLEAR. The message text is created in the system's
character set, with lines delimited in accordance with
convention
4.3.2.2 Step 2: Canonical
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY,
MIC-CLEAR. The message text is converted to a universal
form, similar to the inter-SMTP representation [4] as defined in
821 [2] and RFC 822 [5]. The procedures performed in order
accomplish this conversion are dependent on the characteristics
the local form and so are not specified in this RFC
PEM canonicalization assures that the message text is
with the ASCII character set and "" line delimiters, but
not perform the dot-stuffing transformation discussed in RFC 821,
Section 4.5.2. Since a message is converted to a standard
set and representation before encryption, a transferred PEM
can be decrypted and its MIC can be validated at any type
destination host computer. Decryption and MIC validation
performed before any conversions which may be necessary to
the message into a destination-specific local form
4.3.2.3 Step 3: Authentication and
Authentication processing is applicable to PEM message
ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input
the selected MIC computation algorithm in order to compute
Linn [Page 12]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
integrity check quantity for the message. No padding is added to
canonical form before submission to the MIC computation algorithm
although certain MIC algorithms will apply their own padding in
course of computing a MIC
Encryption processing is applicable only to PEM message
ENCRYPTED. RFC 1423 defines the padding technique used to
encryption of the canonically-encoded message text
4.3.2.4 Step 4: Printable
This printable encoding step is applicable to PEM message
ENCRYPTED and MIC-ONLY. The same processing is also employed
representation of certain specifically identified PEM
header field quantities as cited in Section 4.6. Proceeding
left to right, the bit string resulting from step 3 is encoded
characters which are universally representable at all sites,
not necessarily with the same bit patterns (e.g., although
character "E" is represented in an ASCII-based system as
45 and as hexadecimal C5 in an EBCDIC-based system, the
significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used,
6 bits to be represented per printable character. (The
subset of characters is represented identically in IA5 and ASCII.)
The character "=" signifies a special processing function used
padding within the printable encoding procedure
To represent the encapsulated text of a PEM message, the
function's output is delimited into text lines (using
conventions), with each line except the last containing exactly 64
printable characters and the final line containing 64 or
printable characters. (This line length is easily printable and
guaranteed to satisfy SMTP's 1000-character transmitted line
limit.) This folding requirement does not apply when the
procedure is used to represent PEM header field quantities;
4.6 discusses folding of PEM encapsulated header fields
The encoding process represents 24-bit groups of input bits as
strings of 4 encoded characters. Proceeding from left to right
a 24-bit input group extracted from the output of step 3, each 6-
group is used as an index into an array of 64 printable characters
The character referenced by the index is placed in the output string
These characters, identified in Table 1, are selected so as to
universally representable, and the set excludes characters
particular significance to SMTP (e.g., ".", "", "").
Linn [Page 13]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Special processing is performed if fewer than 24 bits are
in an input group at the end of a message. A full encoding
is always completed at the end of a message. When fewer than 24
input bits are available in an input group, zero bits are added (
the right) to form an integral number of 6-bit groups.
character positions which are not required to represent actual
data are set to the character "=". Since all canonically
output is an integral number of octets, only the following cases
arise: (1) the final quantum of encoding input is an
multiple of 24 bits; here, the final unit of encoded output will
an integral multiple of 4 characters with no "=" padding, (2)
final quantum of encoding input is exactly 8 bits; here, the
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input
exactly 16 bits; here, the final unit of encoded output will be
characters followed by one "=" padding character
Value Encoding Value Encoding Value Encoding Value
0 A 17 R 34 i 51
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47
14 O 31 f 48 w (pad) =
15 P 32 g 49
16 Q 33 h 50
Printable Encoding
Table 1
4.3.2.5 Summary of
In summary, the outbound message is subjected to the
composition of transformations (or, for some PEM message types,
subset thereof):
Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))
Linn [Page 14]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
The inverse transformations are performed, in reverse order,
process inbound PEM messages
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
Note that the local form and the functions to transform messages
and from canonical form may vary between the originator and
systems without loss of information
4.4 Encapsulation
The encapsulation techniques defined in RFC-934 [6] are adopted
encapsulation of PEM messages within separate enclosing MTS
carrying associated MTS headers. This approach offers a number
advantages relative to a flat approach in which certain fields
a single header are encrypted and/or carry cryptographic
information. As far as the MTS is concerned, the entirety of a
message will reside in an MTS message's text portion, not the
message's header portion. Encapsulation provides generality
segregates fields with user-to-user significance from
transformed in transit. All fields inserted in the course
encryption/authentication processing are placed in the
header. This facilitates compatibility with mail handling
which accept only text, not header fields, from input files or
other programs
The encapsulation techniques defined in RFC-934 are consistent
existing Internet mail forwarding and bursting mechanisms.
techniques are designed so that they may be used in a nested manner
The encapsulation techniques may be used to encapsulate one or
PEM messages for forwarding to a third party, possibly in
with interspersed (non-PEM) text which serves to annotate the
messages
Two encapsulation boundaries (EB's) are defined for
encapsulated PEM messages and for distinguishing encapsulated
messages from interspersed (non-PEM) text. The pre-EB is the
"-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that
encapsulated PEM message follows. The post-EB is either (1)
pre-EB indicating that another encapsulated PEM message follows,
(2) the string "-----END PRIVACY-ENHANCED MESSAGE-----"
that any text that immediately follows is non-PEM text. A
point must be noted for the case of MIC-CLEAR messages, the
portions of which may contain lines which begin with the "-"
character and which are therefore subject to special processing
RFC-934 forwarding procedures. When the string "- " must
prepended to such a line in the course of a forwarding operation
order to distinguish that line from an encapsulation boundary,
Linn [Page 15]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
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
encapsulation may be nested nor on the number of PEM messages
may be grouped in this fashion at a single nesting level
forwarding. A implementation compliant with this RFC must
preclude a user from submitting or receiving PEM messages
exploit this encapsulation capability. However, no
requirements are levied upon implementations with regard to how
capability is made available to the user. Thus, for example,
compliant PEM implementation is not required to automatically
and process encapsulated PEM messages
In using this encapsulation facility, it is important to note that
is inappropriate to forward directly to a third party a message
is ENCRYPTED because recipients of such a message would not
access to the DEK required to decrypt the message. Instead, the
forwarding the message must transform the ENCRYPTED message into
MIC-ONLY or MIC-CLEAR form prior to forwarding. Thus, in order
comply with this RFC, a PEM implementation must provide a facility
enable a user to perform this transformation, while preserving
MIC associated with the original message
If a user wishes PEM-provided confidentiality protection
transmitted information, such information must occur in
encapsulated text of an ENCRYPTED PEM message, not in the
MTS header or PEM encapsulated header. If a user wishes to
Linn [Page 16]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Encapsulated
Pre-Encapsulation Boundary (Pre-EB
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Encapsulated Header
(Contains encryption control fields inserted in plaintext
Examples include "DEK-Info:" and "Key-Info:".
Note that, although these control fields have line-
representations similar to RFC 822 header fields, the
of fields valid in this context is disjoint from those
in RFC 822 processing.)
Blank
(Separates Encapsulated Header from
Encapsulated Text Portion
Encapsulated Text
(Contains message data encoded as specified in Section 4.3.)
Post-Encapsulation Boundary (Post-EB
-----END PRIVACY-ENHANCED MESSAGE-----
Encapsulated Message
Figure 1
disclosing the actual subject of a message to unintended parties,
is suggested that the enclosing MTS header contain a "Subject:"
indicating that "Encrypted Mail Follows".
If an integrity-protected representation of information which
within an enclosing header (not necessarily in the same format
that in which it occurs within that header) is desired, that data
be included within the encapsulated text portion in addition to
inclusion in the enclosing MTS header. For example, an
wishing to provide recipients with a protected indication of
message's position in a series of messages could include within
encapsulated text a copy of a timestamp or message counter
possessing end-to-end significance and extracted from an
MTS header field. (Note: mailbox specifiers as entered by end
incorporate local conventions and are subject to modification
intermediaries, so inclusion of such specifiers within
text should not be regarded as a suitable alternative to
authentication semantics defined in RFC 1422 and based on X.500
Distinguished Names.) The set of header information (if any)
within the encapsulated text of messages is a local matter, and
Linn [Page 17]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
RFC does not specify formatting conventions to distinguish
header fields from other encapsulated text
4.5 Mail for Mailing
When mail is addressed to mailing lists, two different methods
processing can be applicable: the IK-per-list method and the IK-per
recipient method. Hybrid approaches are also possible, as in
case of IK-per-list protection of a message on its path from
originator to a PEM-equipped mailing list exploder, followed by IK
per-recipient protection from the exploder to individual
recipients
If a message's originator is equipped to expand a destination
list into its individual constituents and elects to do so (IK-per
recipient), the message's DEK (and, in the symmetric key
case, MIC) will be encrypted under each per-recipient IK and all
encrypted representations will be incorporated into the
message. Note that per-recipient encryption is required only for
relatively small DEK and MIC quantities carried in the "Key-Info:"
field, not for the message text which is, in general, much larger
Although more IKs are involved in processing under the IK-per
recipient method, the pairwise IKs can be individually revoked
possession of one IK does not enable a successful masquerade
another user on the list
If a message's originator addresses a message to a list name
alias, use of an IK associated with that name or alias as a
(IK-per-list), rather than resolution of the name or alias to
constituent destinations, is implied. Such an IK must, therefore,
available to all list members. Unfortunately, it implies
undesirable level of exposure for the shared IK, and makes
revocation difficult. Moreover, use of the IK-per-list method
any holder of the list's IK to masquerade as another originator
the list for authentication purposes
Pure IK-per-list key management in the asymmetric case (with a
private key shared among multiple list members) is
disadvantageous in the asymmetric environment, as it fails
preserve the forwardable authentication and non-
characteristics which are provided for other messages in
environment. Use of a hybrid approach with a PEM-capable exploder
therefore particularly recommended for protection of mailing
traffic when asymmetric key management is used; such an
would reduce (per discussion in Section 4.4 of this RFC)
ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before
them (perhaps re-encrypted under individual, per-recipient keys)
list members
Linn [Page 18]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.6 Summary of Encapsulated Header
This section defines the syntax and semantics of the
header fields to be added to messages in the course of
enhancement processing
The fields are presented in three groups. Normally, the groups
appear in encapsulated headers in the order in which they are shown
though not all fields in each group will appear in all messages.
following figures show the appearance of small example
messages. Figure 2 assumes the use of symmetric cryptography for
management. Figure 3 illustrates an example encapsulated
message in which asymmetric key management is used
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A
B70665BB9BF7CBCDA60195DB94F727D
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720
dXd/H5LMDWnonNvPCwQUHt==
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated Message (Symmetric Case
Figure 2
Figure 4 illustrates an example encapsulated MIC-ONLY message
which asymmetric key management is used; since no per-recipient
are involved in preparation of asymmetric-case MIC-ONLY messages
this example should be processable for test purposes by arbitrary
implementations
Fully-qualified domain names (FQDNs) for hosts, appearing in
mailbox names found in entity identifier subfields of "Originator
ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed
a case-insensitive fashion. Unless specified to the contrary,
field arguments (including the user name components of mailbox names
Linn [Page 19]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
are to be processed in a case-sensitive fashion
In most cases, numeric quantities are represented in header fields
contiguous strings of hexadecimal digits, where each digit
represented by a character from the ranges "0"-"9" or upper
"A"-"F". Since public-key certificates and quantities
Linn [Page 20]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,
Content-Domain: RFC822
DEK-Info: DES-CBC,BFF968AA74691AC
Originator-Certificate
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Key-Info: RSA
I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
wGrtiUm/ovtKdinz6ZQ/aQ==
Issuer-Certificate
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5
MIC-Info: RSA-MD5,RSA
UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9
AjRFbHoNPzBuxwmOAFeA0HJszL4
Recipient-ID-Asymmetric
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,
66
Key-Info: RSA
O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8
7x0Z3Jx2vTAhOYHMcqqCjA==
qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3
jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated ENCRYPTED Message (Asymmetric Case
Figure 3
Linn [Page 21]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
using asymmetric algorithms are large in size, use of a more space
efficient encoding technique is appropriate for such quantities,
the encoding mechanism defined in Section 4.3.2.4 of this RFC
representing 6 bits per printed character, is adopted for
purpose
Encapsulated headers of PEM messages are folded using whitespace
RFC 822 header folding conventions; no PEM-specific conventions
defined for encapsulated header folding. The example shown in
4 shows (in its "MIC-Info:" field) an asymmetrically
quantity in its printably encoded representation, illustrating
use of RFC 822 folding
In contrast to the encapsulated header representations defined in
1113 and its precursors, the field identifiers adopted in this RFC
not begin with the prefix "X-" (for example, the field
denoted "X-Key-Info:" is now denoted "Key-Info:") and such
are not to be emitted by implementations conformant to this RFC.
simplify transition and interoperability with
implementations, it is suggested that implementations based on
RFC accept incoming encapsulated header fields carrying the "X-"
prefix and act on such fields as if the "X-" were not present
Linn [Page 22]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-
Content-Domain: RFC822
Originator-Certificate
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Issuer-Certificate
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5
MIC-Info: RSA-MD5,RSA
jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr
EtE7K2QDeVMCyXsdJlA8fA==
LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3
YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated MIC-ONLY Message (Asymmetric Case
Figure 4
4.6.1 Per-Message Encapsulated Header
This group of encapsulated header fields contains fields which
no more than once in a PEM message, generally preceding all
encapsulated header fields
4.6.1.1 Proc-Type
The "Proc-Type:" encapsulated header field, required for all
messages, identifies the type of processing performed on
transmitted message. Only one "Proc-Type:" field occurs in
message; the "Proc-Type:" field must be the first encapsulated
Linn [Page 23]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
field in the message
The "Proc-Type:" field has two subfields, separated by a comma.
first subfield is a decimal number which is used to distinguish
incompatible encapsulated header field interpretations which
arise as changes are made to this standard. Messages
according to this RFC will carry the subfield value "4"
distinguish them from messages processed in accordance with prior
RFCs. The second subfield assumes one of a set of string values
defined in the following subsections
4.6.1.1.1
The "ENCRYPTED" specifier signifies that confidentiality
authentication, integrity, and (given use of asymmetric
management) non-repudiation of origin security services have
applied to a PEM message's encapsulated text. ENCRYPTED
require a "DEK-Info:" field and individual Recipient-ID and "Key
Info:" fields for all message recipients
4.6.1.1.2 MIC-
The "MIC-ONLY" specifier signifies that all of the security
specified for ENCRYPTED messages, with the exception
confidentiality, have been applied to a PEM message's
text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC
to protect their encapsulated text against modifications at
transfer or relay points
Specification of MIC-ONLY, when applied in conjunction with
combinations of key management and MIC algorithm options,
certain fields which are superfluous in the absence of encryption
be omitted from the encapsulated header. In particular, when
keyless MIC computation is employed for recipients for
asymmetric cryptography is used, "Recipient-ID-Asymmetric:"
"Key-Info:" fields can be omitted. The "DEK-Info:" field can
omitted for all "MIC-ONLY" messages
4.6.1.1.3 MIC-
The "MIC-CLEAR" specifier represents a PEM message with the
security service selection as for a MIC-ONLY message. The set
encapsulated header fields required in a MIC-CLEAR message is
same as that required for a MIC-ONLY message
MIC-CLEAR message processing omits the encoding step defined
Section 4.3.2.4 of this RFC to protect a message's encapsulated
against modifications within the MTS. As a result, a MIC-
Linn [Page 24]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
message's text can be read by recipients lacking access to
software, even though such recipients cannot validate the message'
signature. The canonical encoding discussed in Section 4.3.2.2
performed, so interoperation among sites with different
character sets and line representations is not precluded so long
those native formats are unambiguously translatable to and from
canonical form. (Such interoperability is feasible only for
characters which are included in the canonical representation set.)
Omission of the printable encoding step implies that MIC-
message MICs will be validatable only in environments where the
does not modify messages in transit, or where the
performed can be determined and inverted before MIC
processing. Failed MIC validation on a MIC-CLEAR message does not
therefore, necessarily signify a security-relevant event; as
result, it is recommended that PEM implementations reflect to
users (in a suitable local fashion) the type of PEM message
processed when reporting a MIC validation failure
A case of particular relevance arises for inbound SMTP processing
systems which delimit text lines with local native
other than the SMTP-conventional . When mail is delivered
a UA on such a system and presented for PEM processing, the
has already been translated to local form. In order to validate
MIC-CLEAR message's MIC in this situation, the PEM module
recanonicalize the incoming message in order to determine the inter
SMTP representation of the canonically encoded message (as defined
Section 4.3.2.2 of this RFC), and must compute the reference
base