brian@ucsd.EDU (Brian Kantor) (05/03/88)
Network Working Group J. Linn (BBNCC)
Request for Comments: 1040 IAB Privacy Task Force
Obsoletes RFCs: 989 January 1988
Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encipherment and Authentication Procedures
STATUS OF THIS MEMO
This RFC suggests a proposed protocol for the Internet community, and
requests discussion and suggestions for improvements. Distribution
of this memo is unlimited.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of IAB Privacy Task Force
meetings and of internal working papers distributed for those
meetings. I would like to thank the following Privacy Task Force
members and meeting guests for their comments and contributions at
the meetings which led to the preparation of this RFC: David
Balenson, Curt Barker, Matt Bishop, Danny Cohen, Tom Daniel, Charles
Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner,
Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker,
and Steve Wilbur.
1. Executive Summary
This RFC defines message encipherment and authentication procedures,
as the initial phase of an effort to provide privacy enhancement
services for electronic mail transfer in the Internet. Detailed key
management mechanisms to support these procedures will be defined in
a subsequent RFC. As a goal of this initial phase, it is intended
that the procedures defined here be compatible with a wide range of
key management approaches, including both conventional (symmetric)
and public-key (asymmetric) approaches for encryption of data
encrypting keys. Use of conventional cryptography for message text
encryption and/or integrity check computation is anticipated.
Privacy enhancement services (confidentiality, authentication, and
message integrity assurance) are offered through the use of
end-to-end cryptography between originator and recipient User Agent
processes, with no special processing requirements imposed on the
Message Transfer System at endpoints or at intermediate relay
sites. This approach allows privacy enhancement facilities to be
incorporated on a site-by-site or user-by-user basis without impact
on other Internet entities. Interoperability among heterogeneous
Linn [Page 1]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
components and mail transport facilities is supported.
2. Terminology
For descriptive purposes, this RFC uses some terms defined in the OSI
X.400 Message Handling System Model per the 1984 CCITT
Recommendations. This section replicates a portion of X.400's
Section 2.2.1, "Description of the MHS Model: Overview" in order to
make the terminology clear to readers who may not be familiar with
the OSI MHS Model.
In the [MHS] model, a user is a person or a computer application. A
user is referred to as either an originator (when sending a message)
or a recipient (when receiving one). MH Service elements define the
set of message types and the capabilities that enable an originator
to transfer messages of those types to one or more recipients.
An originator prepares messages with the assistance of his User
Agent. A User Agent (UA) is an application process that interacts
with the Message Transfer System (MTS) to submit messages. The MTS
delivers to one or more recipient UAs the messages submitted to it.
Functions performed solely by the UA and not standardized as part of
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 the
intended recipient UAs, which then make the messages available to the
intended recipients.
The collection of UAs and MTAs is called the Message Handling System
(MHS). The MHS and all of its users are collectively referred to as
the Message Handling Environment.
3. Services, Constraints, and Implications
This RFC defines mechanisms to enhance privacy for electronic mail
transferred in the Internet. The facilities discussed in this RFC
provide privacy enhancement services on an end-to-end basis between
sender and recipient UAs. No privacy enhancements are offered for
message fields which are added or transformed by intermediate relay
points.
Authentication and integrity facilities are always applied to the
entirety of a message's text. No facility for confidentiality
service without authentication is provided. Encryption facilities
may be applied selectively to portions of a message's contents; this
allows less sensitive portions of messages (e.g., descriptive fields)
to be processed by a recipient's delegate in the absence of the
Linn [Page 2]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
recipient's personal cryptographic keys. In the limiting case, where
the entirety of message text is excluded from encryption, this
feature can be used to yield the effective combination of
authentication and integrity services without confidentiality.
In keeping with the Internet's heterogeneous constituencies and usage
modes, the measures defined here are applicable to a broad range of
Internet hosts and usage paradigms. In particular, it is worth
noting the following attributes:
1. The mechanisms defined in this RFC are not restricted to a
particular host or operating system, but rather allow
interoperability among a broad range of systems. All
privacy enhancements are implemented at the application
layer, and are not dependent on any privacy features at
lower protocol layers.
2. The defined mechanisms are compatible with non-enhanced
Internet components. Privacy enhancements are implemented
in an end-to-end fashion which does not impact mail
processing by intermediate relay hosts which do not
incorporate privacy enhancement facilities. It is
necessary, however, for a message's sender to be cognizant
of whether a message's intended recipient implements privacy
enhancements, in order that encoding and possible
encipherment will not be performed on a message whose
destination is not equipped to perform corresponding inverse
transformations.
3. The defined mechanisms are compatible with a range of mail
transport facilities (MTAs). Within the Internet,
electronic mail transport is effected by a variety of SMTP
implementations. Certain sites, accessible via SMTP,
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must be
able to operate across the SMTP realm; it is desirable that
they also be compatible with protection of electronic mail
sent between the SMTP environment and other connected
environments.
4. The defined mechanisms offer compatibility with a broad
range of electronic mail user agents (UAs). A large variety
of electronic mail user agent programs, with a corresponding
broad range of user interface paradigms, is used in the
Internet. In order that an electronic mail privacy
enhancement be available to the broadest possible user
community, the selected mechanism should be usable with the
widest possible variety of existing UA programs. For
Linn [Page 3]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
purposes of pilot implementation, it is desirable that
privacy enhancement processing be incorporable into a
separate program, applicable to a range of UAs, rather than
requiring internal modifications to each UA with which
enhanced privacy services are to be provided.
5. The defined mechanisms allow electronic mail privacy
enhancement processing to be performed on personal computers
(PCs) separate from the systems on which UA functions are
implemented. Given the expanding use of PCs and the limited
degree of trust which can be placed in UA implementations on
many multi-user systems, this attribute can allow many users
to process privacy-enhanced mail with a higher assurance
level than a strictly UA-based approach would allow.
6. The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists.
In order to achieve applicability to the broadest possible range of
Internet hosts and mail systems, and to facilitate pilot
implementation and testing without the need for prior modifications
throughout the Internet, three basic restrictions are imposed on the
set of measures to be considered in this RFC:
1. Measures will be restricted to implementation at endpoints
and will be amenable to integration at the user agent (UA)
level or above, rather than necessitating integration into
the message transport system (e.g., SMTP servers).
2. The set of supported measures enhances rather than restricts
user capabilities. Trusted implementations, incorporating
integrity features protecting software from subversion by
local users, cannot be assumed in general. In the absence
of such features, it appears more feasible to provide
facilities which enhance user services (e.g., by protecting
and authenticating inter-user traffic) than to enforce
restrictions (e.g., inter-user access control) on user
actions.
3. The set of supported measures focuses on a set of functional
capabilities selected to provide significant and tangible
benefits to a broad user community. By concentrating on the
most critical set of services, we aim to maximize the added
privacy value that can be provided with a modest level of
implementation effort.
Linn [Page 4]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
As a result of these restrictions, the following facilities can be
provided:
1. disclosure protection,
2. sender authenticity, and
3. message integrity measures,
but the following privacy-relevant concerns are not addressed:
1. access control,
2. traffic flow confidentiality,
3. address list accuracy,
4. routing control,
5. issues relating to the serial reuse of PCs by multiple
users,
6. assurance of message receipt and non-deniability of
receipt,
7. automatic association of acknowledgments with the
messages to which they refer, and
8. message duplicate detection, replay prevention, or other
stream-oriented services.
An important goal is that privacy enhancement mechanisms impose a
minimum of burden on the users they serve. In particular, this goal
suggests eventual automation of the key management mechanisms
supporting message encryption and authentication. In order to
facilitate deployment and testing of pilot privacy enhancement
implementations in the near term, however, compatibility with
out-of-band (e.g., manual) key distribution must also be supported.
A message's sender will determine whether privacy enhancements are to
be performed on a particular message. Therefore, a sender must be
able to determine whether particular recipients are equipped to
process privacy-enhanced mail. In a general architecture, these
mechanisms will be based on server queries; thus, the query function
could be integrated into a UA to avoid imposing burdens or
inconvenience on electronic mail users.
Linn [Page 5]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
4. Processing of Messages
4.1 Message Processing Overview
This subsection provides a high-level overview of the components and
processing steps involved in electronic mail privacy enhancement
processing. Subsequent subsections will define the procedures in
more detail.
A two-level keying hierarchy is used to support privacy-enhanced
message transmission:
1. Data Encrypting Keys (DEKs) are used for encryption of
message text and (with certain choices among a set of
alternative algorithms) for computation of message integrity
check quantities (MICs). DEKs are generated individually
for each transmitted message; no predistribution of DEKs is
needed to support privacy-enhanced message transmission.
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission within messages. An IK may be a single
symmetric cryptographic key or, where asymmetric
(public-key) cryptography is used to encrypt DEKs, the
composition of a public component used by an originator and
a secret component used by a recipient. Ordinarily, the
same IK will be used for all messages sent between a given
originator-recipient pair over a period of time. Each
transmitted message includes a representation of the DEK(s)
used for message encryption and/or authentication,
encrypted under an individual IK per named recipient. This
representation is associated with sender and recipient
identification header fields, which enable recipients to
identify the IKs used. With this information, the recipient
can decrypt the transmitted DEK representation, yielding
the DEK required for message text decryption and/or MIC
verification.
When privacy enhancement processing is to be performed on an outgoing
message, a DEK is generated [1] for use in message encryption and a
variant of the DEK is formed (if the chosen MIC algorithm requires a
key) for use in MIC computation. An "X-Sender-ID:" field is included
in the header to provide one identification component for the IK(s)
used for message processing. An IK is selected for each individually
identified recipient; a corresponding "X-Recipient-ID:" field,
interpreted in the context of a prior "X-Sender-ID:" field, serves to
identify each IK. Each "X-Recipient-ID:" field is followed by an
"X-Key-Info:" field, which transfers the DEK and computed MIC. The
DEK and MIC are encrypted for transmission under the appropriate IK.
Linn [Page 6]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
A four-phase transformation procedure is employed in order to
represent encrypted message text in a universally transmissible form
and to enable messages encrypted on one type of system to be
decrypted on a different type. A plaintext message is accepted in
local form, using the host's native character set and line
representation. The local form is converted to a canonical message
text representation, defined as equivalent to the inter-SMTP
representation of message text. This canonical representation forms
the input to the encryption and MIC computation processes.
For encryption purposes, the canonical representation is padded as
required by the encryption algorithm. The padded canonical
representation is encrypted (except for any regions explicitly
excluded from encryption). The canonically encoded representation is
encoded, after encryption, into a printable form. The printable form
is composed of a restricted character set which is chosen to be
universally representable across sites, and which will not be
disrupted by processing within and between MTS entities.
The output of the encoding procedure is combined with a set of header
fields carrying cryptographic control information. The result is
passed to the electronic mail system to be encapsulated as the text
portion of a transmitted message.
When a privacy-enhanced message is received, the cryptographic
control fields within its text portion provide the information
required for the authorized recipient to perform MIC verification and
decryption of the received message text. First, the printable
encoding is converted to a bitstring. The MIC is verified.
Encrypted portions of the transmitted message are decrypted, and the
canonical representation is converted to the recipient's local form,
which need not be the same as the sender's local form.
4.2 Encryption Algorithms and Modes
For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined
in ISO draft international standard DIS 8227 [2] shall be used for
encryption of message text. The DEA-1 is equivalent to the Data
Encryption Standard (DES), as defined in FIPS PUB 46 [3]. When used
for encryption of text, the DEA-1 shall be used in the Cipher Block
Chaining (CBC) mode, as defined in ISO DIS 8372 [4]. The CBC mode
definition in DIS 8372 is equivalent to that provided in FIPS PUB 81
[5]. A unique initializing vector (IV) will be generated for and
transmitted with each privacy-enhanced electronic mail message.
Linn [Page 7]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
An algorithm other than DEA-1 may be employed, provided that it
satisfies the following requirements:
1. It must be a 64-bit block cipher, enciphering and
deciphering in 8-octet blocks.
2. It is usable in the ECB and CBC modes defined in DIS
8372.
3. It is able to be keyed using the procedures and
parameters defined in this RFC.
4. It is appropriate for MIC computation, if the selected
MIC computation algorithm is eCcryption-based.
5. Cryptographic key field lengths are limited to 16 octets
in length.
Certain operations require that one key be encrypted under another
key (interchange key) for purposes of transmission. This encryption
may be performed using symmetric cryptography by using DEA-1 in
Electronic Codebook (ECB) mode. A header facility is available to
indicate that an associated key is to be used for encryption in
another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used for
key encryption and decryption with pairs of 64-bit keys, as described
by ASC X3T1 [6], or public-key algorithms).
Support of public key algorithms for key encryption is under active
consideration, and it is intended that the procedures defined in this
RFC be appropriate to allow such usage. Support of key encryption
modes other than ECB is optional for implementations, however.
Therefore, in support of universal interoperability, interchange key
providers should not specify other modes in the absence of a priori
information indicating that recipients are equipped to perform key
encryption in other modes.
4.3 Privacy Enhancement Message Transformations
4.3.1 Constraints
An electronic mail encryption mechanism must be compatible with the
transparency constraints of its underlying electronic mail
facilities. These constraints are generally established based on
expected user requirements and on the characteristics of anticipated
endpoint transport facilities. An encryption mechanism must also be
compatible with the local conventions of the computer systems which
it interconnects. In our approach, a canonicalization step is
performed to abstract out local conventions and a subsequent encoding
Linn [Page 8]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
step is performed to conform to the characteristics of the underlying
mail transport medium (SMTP). The encoding conforms to SMTP
constraints, established to support interpersonal messaging. SMTP's
rules are also used independently in the canonicalization process.
RFC-821's [7] Section 4.5 details SMTP's transparency constraints.
To encode a message for SMTP transmission, the following requirements
must be met:
1. All characters must be members of the 7-bit ASCII
character set.
2. Text lines, delimited by the character pair <CR><LF>,
must be no more than 1000 characters long.
3. Since the string <CR><LF>.<CR><LF> indicates the end of a
message, it must not occur in text prior to the end of a
message.
Although SMTP specifies a standard representation for line delimiters
(ASCII <CR><LF>), numerous systems use a different native
representation to delimit lines. For example, the <CR><LF> sequences
delimiting lines in mail inbound to UNIX(tm) systems are transformed
to single <LF>s as mail is written into local mailbox files. Lines
in mail incoming to record-oriented systems (such as VAX VMS) may be
converted to appropriate records by the destination SMTP [8] server.
As a result, if the encryption process generated <CR>s or <LF>s,
those characters might not be accessible to a recipient UA program at
a destination which uses different line delimiting conventions. It
is also possible that conversion between tabs and spaces may be
performed in the course of mapping between inter-SMTP and local
format; this is a matter of local option. If such transformations
changed the form of transmitted ciphertext, decryption would fail to
regenerate the transmitted plaintext, and a transmitted MIC would
fail to compare with that computed at the destination.
The conversion performed by an SMTP server at a system with EBCDIC as
a native character set has even more severe impact, since the
conversion from EBCDIC into ASCII is an information-losing
transformation. In principle, the transformation function mapping
between inter-SMTP canonical ASCII message representation and local
format could be moved from the SMTP server up to the UA, given a
means to direct that the SMTP server should no longer perform that
transformation. This approach has a major disadvantage: internal
file (e.g., mailbox) formats would be incompatible with the native
forms used on the systems where they reside. Further, it would
require modification to SMTP servers, as mail would be passed to SMTP
in a different representation than it is passed at present.
Linn [Page 9]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
4.3.2 Approach
Our approach to supporting privacy-enhanced mail across an
environment in which intermediate conversions may occur encodes mail
in a fashion which is uniformly representable across the set of
privacy-enhanced UAs regardless of their systems' native character
sets. This encoded form is used to represent mail text from sender
to recipient, but the encoding is not applied to enclosing mail
transport headers or to encapsulated headers inserted to carry
control information between privacy-enhanced UAs. The encoding's
characteristics are such that the transformations anticipated between
sender and recipient UAs will not prevent an encoded message from
being decoded properly at its destination.
A sender may exclude one or more portions of a message from
encryption processing. Authentication processing is always applied
to the entirety of message text. Explicit action is required to
exclude a portion of a message from encryption processing; by
default, encryption is applied to the entirety of message text. The
user-level delimiter which specifies such exclusion is a local
matter, and hence may vary between sender and recipient, but all
systems should provide a means for unambiguous identification of
areas excluded from encryption processing.
An outbound privacy-enhanced message undergoes four transformation
steps, described in the following four subsections.
4.3.2.1 Step 1: Local Form
The message text is created in the system's native character set,
with lines delimited in accordance with local convention.
4.3.2.2 Step 2: Canonical Form
The entire message text, including both those portions subject to
encipherment processing and those portions excluded from such
processing, is converted to the universal canonical form,
equivalent to the inter-SMTP representation [9] as defined in
RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line
delimiters). The processing required to perform this conversion is
minimal on systems whose native character set is ASCII. Since a
message is converted to a standard character set and representation
before encryption, it can be decrypted and its MIC can be verified
at any destination system before any conversion necessary to
transform the message into a destination-specific local form is
performed.
Linn [Page 10]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
4.3.2.3 Step 3: Authentication and Encipherment
The canonical form is input to the selected MIC computation algorithm
in order to compute an integrity check quantity for the message. No
padding is added to the canonical form before submission to the MIC
computation algorithm, although certain MIC algorithms will apply
their own padding in the course of computing a MIC.
Padding is applied to the canonical form as needed to perform
encryption in the DEA-1 CBC mode, as follows: The number of octets
to be encrypted is determined by subtracting the number of octets
excluded from encryption from the total length of the encapsulated
text. Octets with the hexadecimal value FF (all ones) are appended
to the canonical form as needed so that the text octets to be
encrypted, along with the added padding octets, fill an integral
number of 8-octet encryption quanta. No padding is applied if the
number of octets to be encrypted is already an integral multiple of
8. The use of hexadecimal FF (a value outside the 7-bit ASCII set)
as a padding value allows padding octets to be distinguished from
valid data without inclusion of an explicit padding count indicator.
The regions of the message which have not been excluded from
encryption are encrypted. To support selective encipherment
processing, an implementation must retain internal indications of the
positions of excluded areas excluded from encryption with relation to
non-excluded areas, so that those areas can be properly delimited in
the encoding procedure defined in step 4. If a region excluded from
encryption intervenes between encrypted regions, cryptographic state
(e.g., IVs and accumulation of octets into encryption quanta) is
preserved and continued after the excluded region.
4.3.2.4 Step 4: Printable Encoding
The bit string resulting from step 3 is encoded into characters which
are universally representable at all sites, though not necessarily
with the same bit patterns (e.g., although the character "E" is
represented in an ASCII-based system as hexadecimal 45 and as
hexadecimal C5 in an EBCDIC-based system, the local significance of
the two representations is equivalent). This encoding step is
performed for all privacy-enhanced messages.
A 64-character subset of International Alphabet IA5 is used, enabling
6-bits to be represented per printable character. (The proposed
subset of characters is represented identically in IA5 and ASCII.)
Two additional characters, "=" and "*", are used to signify special
processing functions. The character "=" is used for padding within
the printable encoding procedure. The character "*" is used to
delimit the beginning and end of a region which has been excluded
Linn [Page 11]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
from encipherment processing. The encoding function's output is
delimited into text lines (using local conventions), with each line
containing 64 printable characters.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right across
a 24-bit input group extracted from the output of step 3, each 6-bit
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 be
universally representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
Special processing is performed if fewer than 24-bits are available
in an input group, either at the end of a message or (when the
selective encryption facility is invoked) at the end of an encrypted
region or an excluded region. In other words, a full encoding
quantum is always completed at the end of a message and before the
delimiter "*" is output to initiate or terminate the representation
of a block excluded from encryption. When fewer than 24 input bits
are available in an input group, zero bits are added (on the right)
to form an integral number of 6-bit groups. Output character
positions which are not required to represent actual input data are
set to the character "=". Since all canonically encoded output is
an integral number of octets, only the following cases can arise:
(1) the final quantum of encoding input is an integral multiple of
24-bits; here, the final unit of encoded output will be an integral
multiple of 4 characters with no "=" padding, (2) the final quantum
of encoding input is exactly 8-bits; here, the final unit of encoded
output will be two characters followed by two "=" padding
characters, or (3) the final quantum of encoding input is exactly
16-bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
In summary, the outbound message is subjected to the following
composition of transformations:
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
The inverse transformations are performed, in reverse order, to
process inbound privacy-enhanced mail:
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
Note that the local form and the functions to transform messages to
and from canonical form may vary between the sender and recipient
systems without loss of information.
Linn [Page 12]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
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 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y (1) *
(1) The character "*" is used to delimit portions of an encoded
message to which encryption processing has not been applied.
Printable Encoding Characters
Table 1
4.4 Encapsulation Mechanism
Encapsulation of privacy-enhanced messages within an enclosing layer
of headers interpreted by the electronic mail transport system offers
a number of advantages in comparison to a flat approach in which
certain fields within a single header are encrypted and/or carry
cryptographic control information. 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. Further, privacy enhancement processing can be
applied recursively. As far as the MTS is concerned, information
incorporated into cryptographic authentication or encryption
processing will reside in a message's text portion, not its header
portion.
Linn [Page 13]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
The encapsulation mechanism to be used for privacy-enhanced mail is
derived from that described in RFC-934 [11] which is, in turn, based
on precedents in the processing of message digests in the Internet
community. To prepare a user message for encrypted or authenticated
transmission, it will be transformed into the representation shown in
Figure 1.
Enclosing Header Portion
(Contains header fields per RFC-822)
Blank Line
(Separates Enclosing Header from Encapsulated Message)
Encapsulated Message
Pre-Encapsulation Boundary (Pre-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Encapsulated Header Portion
(Contains encryption control fields inserted in plaintext.
Examples include "X-IV:", "X-Sender-ID:", and "X-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 encoded
Encapsulated Text Portion)
Encapsulated Text Portion
(Contains message data encoded as specified in Section 4.3;
may incorporate protected copies of "Subject:", etc.)
Post-Encapsulation Boundary (Post-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Message Encapsulation
Figure 1
As a general design principle, sensitive data is protected by
incorporating the data within the encapsulated text rather than by
applying measures selectively to fields in the enclosing header.
Examples of potentially sensitive header information may include
fields such as "Subject:", with contents which are significant on an
end-to-end, inter-user basis. The (possibly empty) set of headers to
which protection is to be applied is a user option. It is strongly
recommended, however, that all implementations should replicate
Linn [Page 14]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the
encapsulated text and include those replicated fields in encryption
and MIC computations.
If a user wishes disclosure protection for header fields, they must
occur only in the encapsulated text and not in the enclosing or
encapsulated header. If disclosure protection is desired for a
message's subject indication, it is recommended that the enclosing
header contain a "Subject:" field indicating that "Encrypted Mail
Follows".
If an authenticated version of header information is desired, that
data can be replicated within the encapsulated text portion in
addition to its inclusion in the enclosing header. For example, a
sender wishing to provide recipients with a protected indication of a
message's position in a series of messages could include a copy of a
timestamp or message counter field within the encapsulated text.
A specific point regarding the integration of privacy-enhanced mail
facilities with the message encapsulation mechanism is worthy of
note. The subset of IA5 selected for transmission encoding
intentionally excludes the character "-", so encapsulated text can be
distinguished unambiguously from a message's closing encapsulation
boundary (Post-EB) without recourse to character stuffing.
4.5 Mail for Mailing Lists
When mail is addressed to mailing lists, two different methods of
processing can be applicable: the IK-per-list method and the IK-
perrecipient method. The choice depends on the information available
to the sender and on the sender's preference.
If a message's sender addresses a message to a list name or alias,
use of an IK associated with that name or alias as a entity (IK-
perlist), rather than resolution of the name or alias to its
constituent destinations, is implied. Such an IK must, therefore, be
available to all list members. For the case of public-key
cryptography, the secret component of the composite IK must be
available to all list members. This alternative will be the normal
case for messages sent via remote exploder sites, as a sender to such
lists may not be cognizant of the set of individual recipients.
Unfortunately, it implies an undesirable level of exposure for the
shared IK or component, and makes its revocation difficult.
Moreover, use of the IK-per-list method allows any holder of the
list's IK to masquerade as another sender to the list for
authentication purposes.
Linn [Page 15]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
If, in contrast, a message's sender is equipped to expand the
destination mailing list into its individual constituents and elects
to do so (IK-per-recipient), the message's DEK and MIC will be
encrypted under each per-recipient IK and all such encrypted
representations will be incorporated into the transmitted message.
Note that per-recipient encryption is required only for the
relatively small DEK and MIC quantities carried in the X-Key-Info
field, not for the message text which is, in general, much larger.
Although more IKs are involved in processing under the IK-
perrecipient method, the pairwise IKs can be individually revoked and
possession of one IK does not enable a successful masquerade of
another user on the list.
4.6 Summary of Added Header and Control Fields
This section summarizes the syntax and semantics of the new
encapsulated header fields to be added to messages in the course of
privacy enhancement processing. In certain indicated cases, it is
recommended that the fields be replicated within the encapsulated
text portion as well. Figure 2 shows the appearance of a small
example encapsulated message using these fields. The example assumes
the use of symmetric cryptography; no "X-Certificate:" field is
carried. In all cases, hexadecimal quantities are represented as
contiguous strings of digits, where each digit is represented by a
character from the ranges "0"-"9" or upper case "A"-"F". Unless
otherwise specified, all arguments are to be processed in a
casesensitive fashion.
Although the encapsulated header fields resemble RFC-822 header
fields, they are a disjoint set and will not in general be processed
by the same parser which operates on enclosing header fields. The
complexity of lexical analysis needed and appropriate for
encapsulated header field processing is significantly less than that
appropriate to RFC-822 header processing. For example, many
characters with special significance to RFC-822 at the syntactic
level have no such significance within encapsulated header fields.
When the length of an encapsulated header field is longer than the
size conveniently printable on a line, whitespace may be used between
the subfields of these fields to fold them in the manner of RFC-822,
section 3.1.1. Any such inserted whitespace is not to be interpreted
as a part of a subfield.
Linn [Page 16]