As per Relevance of the word encapsulated, we have this rfc below:
Network Working Group J. Linn (BBNCC
Request for Comments: 1040 IAB Privacy Task
Obsoletes RFCs: 989 January 1988
Privacy Enhancement for Internet Electronic Mail
Part I: Message Encipherment and Authentication
STATUS OF THIS
This RFC suggests a proposed protocol for the Internet community,
requests discussion and suggestions for improvements.
of this memo is unlimited
This RFC is the outgrowth of a series of IAB Privacy Task
meetings and of internal working papers distributed for
meetings. I would like to thank the following Privacy Task
members and meeting guests for their comments and contributions
the meetings which led to the preparation of this RFC:
Balenson, Curt Barker, Matt Bishop, Danny Cohen, Tom Daniel,
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
This RFC defines message encipherment and authentication procedures
as the initial phase of an effort to provide privacy
services for electronic mail transfer in the Internet. Detailed
management mechanisms to support these procedures will be defined
a subsequent RFC. As a goal of this initial phase, it is
that the procedures defined here be compatible with a wide range
key management approaches, including both conventional (symmetric
and public-key (asymmetric) approaches for encryption of
encrypting keys. Use of conventional cryptography for message
encryption and/or integrity check computation is anticipated
Privacy enhancement services (confidentiality, authentication,
message integrity assurance) are offered through the use
end-to-end cryptography between originator and recipient User
processes, with no special processing requirements imposed on
Message Transfer System at endpoints or at intermediate
sites. This approach allows privacy enhancement facilities to
incorporated on a site-by-site or user-by-user basis without
on other Internet entities. Interoperability among
Linn [Page 1]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
components and mail transport facilities is supported
2.
For descriptive purposes, this RFC uses some terms defined in the
X.400 Message Handling System Model per the 1984
Recommendations. This section replicates a portion of X.400'
Section 2.2.1, "Description of the MHS Model: Overview" in order
make the terminology clear to readers who may not be familiar
the OSI MHS 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
Agent. A User Agent (UA) is an application process that
with 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
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
sender and recipient UAs. No privacy enhancements are offered
message fields which are added or transformed by intermediate
points
Authentication and integrity facilities are always applied to
entirety of a message's text. No facility for
service without authentication is provided. Encryption
may be applied selectively to portions of a message's contents;
allows less sensitive portions of messages (e.g., descriptive fields
to be processed by a recipient's delegate in the absence of
Linn [Page 2]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
recipient's personal cryptographic keys. In the limiting case,
the entirety of message text is excluded from encryption,
feature can be used to yield the effective combination
authentication and integrity services without confidentiality
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 sender to be
of whether a message's intended recipient implements
enhancements, in order that encoding and
encipherment will not be performed on a message
destination is not equipped to perform corresponding
transformations
3. The defined mechanisms are compatible with a range of
transport facilities (MTAs). Within the Internet
electronic mail transport is effected by a variety of
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 offer compatibility with a
range of electronic mail user agents (UAs). A large
of electronic mail user agent programs, with a
broad range of user interface paradigms, is used in
Internet. In order that an electronic mail
enhancement be available to the broadest possible
community, the selected mechanism should be usable with
widest possible variety of existing UA programs.
Linn [Page 3]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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
enhanced privacy 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 privacy-enhanced mail with a higher
level than a strictly UA-based approach would allow
6. The defined mechanisms support privacy protection
electronic mail addressed to mailing lists
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
throughout the Internet, three basic restrictions are imposed on
set of measures to be considered in this RFC
1. Measures will be restricted to implementation at
and will be amenable to integration at the user agent (UA
level or above, rather than necessitating integration
the message transport 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. In the
of such features, it appears more feasible to
facilities which enhance user services (e.g., by
and authenticating inter-user traffic) than to
restrictions (e.g., inter-user access control) on
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
Linn [Page 4]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
As a result of these restrictions, the following facilities can
provided
1. disclosure protection
2. sender authenticity,
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
users
6. assurance of message receipt and non-deniability
receipt
7. automatic association of acknowledgments with
messages to which they refer,
8. message duplicate detection, replay prevention, or
stream-oriented services
An important goal is that privacy enhancement mechanisms impose
minimum of burden on the users they serve. In particular, this
suggests eventual automation of the key management
supporting message encryption and authentication. In order
facilitate deployment and testing of pilot privacy
implementations in the near term, however, compatibility
out-of-band (e.g., manual) key distribution must also be supported
A message's sender will determine whether privacy enhancements are
be performed on a particular message. Therefore, a sender must
able to determine whether particular recipients are equipped
process privacy-enhanced mail. In a general architecture,
mechanisms will be based on server queries; thus, the query
could be integrated into a UA to avoid imposing burdens
inconvenience on electronic mail users
Linn [Page 5]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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
A two-level keying hierarchy is used to support privacy-
message 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 quantities (MICs). DEKs are generated
for each transmitted message; no predistribution of DEKs
needed to support privacy-enhanced message transmission
2. Interchange Keys (IKs) are used to encrypt DEKs
transmission within messages. An IK may be a
symmetric cryptographic key or, where
(public-key) cryptography is used to encrypt DEKs,
composition of a public component used by an originator
a secret component used by a recipient. Ordinarily,
same IK will be used for all messages sent between a
originator-recipient pair over a period of time.
transmitted message includes a representation of the DEK(s
used for message encryption and/or authentication
encrypted under an individual IK per named recipient.
representation is associated with sender and
identification header fields, which enable recipients
identify the IKs used. With this information, the
can decrypt the transmitted DEK representation,
the DEK required for message text decryption and/or
verification
When privacy enhancement processing is to be performed on an
message, a DEK is generated [1] for use in message encryption and
variant of the DEK is formed (if the chosen MIC algorithm requires
key) for use in MIC computation. An "X-Sender-ID:" field is
in the header to provide one identification component for the IK(s
used for message processing. An IK is selected for each
identified recipient; a corresponding "X-Recipient-ID:" field
interpreted in the context of a prior "X-Sender-ID:" field, serves
identify each IK. Each "X-Recipient-ID:" field is followed by
"X-Key-Info:" field, which transfers the DEK and computed MIC.
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
represent encrypted message text in a universally transmissible
and to enable messages encrypted on one type of system to
decrypted on a different type. A plaintext message is accepted
local form, using the host's native character set and
representation. The local form is converted to a canonical
text representation, defined as equivalent to the inter-
representation of message text. This canonical representation
the input to the encryption and MIC computation processes
For encryption purposes, the canonical representation is padded
required by the encryption algorithm. The padded
representation is encrypted (except for any regions
excluded from encryption). The canonically encoded representation
encoded, after encryption, into a printable form. The printable
is composed of a restricted character set which is chosen to
universally representable across sites, and which will not
disrupted by processing within and between MTS entities
The output of the encoding procedure is combined with a set of
fields carrying cryptographic control information. The result
passed to the electronic mail system to be encapsulated as the
portion of a transmitted message
When a privacy-enhanced message is received, the
control fields within its text portion provide the
required for the authorized recipient to perform MIC verification
decryption of the received message text. First, the
encoding is converted to a bitstring. The MIC is verified
Encrypted portions of the transmitted message are decrypted, and
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
For purposes of this RFC, the Block Cipher Algorithm DEA-1,
in ISO draft international standard DIS 8227 [2] shall be used
encryption of message text. The DEA-1 is equivalent to the
Encryption Standard (DES), as defined in FIPS PUB 46 [3]. When
for encryption of text, the DEA-1 shall be used in the Cipher
Chaining (CBC) mode, as defined in ISO DIS 8372 [4]. The CBC
definition in DIS 8372 is equivalent to that provided in FIPS PUB 81
[5]. A unique initializing vector (IV) will be generated for
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
satisfies the following requirements
1. It must be a 64-bit block cipher, enciphering
deciphering in 8-octet blocks
2. It is usable in the ECB and CBC modes defined in
8372.
3. It is able to be keyed using the procedures
parameters defined in this RFC
4. It is appropriate for MIC computation, if the
MIC computation algorithm is eCcryption-based
5. Cryptographic key field lengths are limited to 16
in length
Certain operations require that one key be encrypted under
key (interchange key) for purposes of transmission. This
may be performed using symmetric cryptography by using DEA-1
Electronic Codebook (ECB) mode. A header facility is available
indicate that an associated key is to be used for encryption
another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used
key encryption and decryption with pairs of 64-bit keys, as
by ASC X3T1 [6], or public-key algorithms).
Support of public key algorithms for key encryption is under
consideration, and it is intended that the procedures defined in
RFC be appropriate to allow such usage. Support of key
modes other than ECB is optional for implementations, however
Therefore, in support of universal interoperability, interchange
providers should not specify other modes in the absence of a
information indicating that recipients are equipped to perform
encryption in other modes
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 transport facilities. An encryption mechanism must also
compatible with the local conventions of the computer systems
it interconnects. In our approach, a canonicalization step
performed to abstract out local conventions and a subsequent
Linn [Page 8]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
step is performed to conform to the characteristics of the
mail transport medium (SMTP). The encoding conforms to
constraints, established to support interpersonal messaging. SMTP'
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
must be met
1. All characters must be members of the 7-bit
character set
2. Text lines, delimited by the character pair ,
must 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 use a different
representation to delimit lines. For example, the
delimiting lines in mail inbound to UNIX(tm) systems are
to single s as mail is written into local mailbox files.
in mail incoming to record-oriented systems (such as VAX VMS) may
converted to appropriate records by the destination SMTP [8] server
As a result, if the encryption process generated s or s
those characters might not be accessible to a recipient UA program
a destination which uses different line delimiting conventions.
is also possible that conversion between tabs and spaces may
performed in the course of mapping between inter-SMTP and
format; this is a matter of local option. If such
changed the form of transmitted ciphertext, decryption would fail
regenerate the transmitted plaintext, and a transmitted MIC
fail to compare with that computed at the 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 9]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
4.3.2
Our approach to supporting privacy-enhanced mail across
environment in which intermediate conversions may occur encodes
in a fashion which is uniformly representable across the set
privacy-enhanced UAs regardless of their systems' native
sets. This encoded form is used to represent mail text from
to recipient, but the encoding is not applied to enclosing
transport headers or to encapsulated headers inserted to
control information between privacy-enhanced UAs. The encoding'
characteristics are such that the transformations anticipated
sender and recipient UAs will not prevent an encoded message
being decoded properly at its destination
A sender may exclude one or more portions of a message
encryption processing. Authentication processing is always
to the entirety of message text. Explicit action is required
exclude a portion of a message from encryption processing;
default, encryption is applied to the entirety of message text.
user-level delimiter which specifies such exclusion is a
matter, and hence may vary between sender and recipient, but
systems should provide a means for unambiguous identification
areas excluded from encryption processing
An outbound privacy-enhanced message undergoes four
steps, described in the following four subsections
4.3.2.1 Step 1: Local
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
The entire message text, including both those portions subject
encipherment processing and those portions excluded from
processing, is converted to the universal canonical form
equivalent to the inter-SMTP representation [9] as defined
RFC-821 and RFC-822 [10] (ASCII character set,
delimiters). The processing required to perform this conversion
minimal on systems whose native character set is ASCII. Since
message is converted to a standard character set and
before encryption, it can be decrypted and its MIC can be
at any destination system before any conversion necessary
transform the message into a destination-specific local form
performed
Linn [Page 10]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
4.3.2.3 Step 3: Authentication and
The canonical form is input to the selected MIC computation
in order to compute an integrity check quantity for the message.
padding is added to the canonical form before submission to the
computation algorithm, although certain MIC algorithms will
their own padding in the course of computing a MIC
Padding is applied to the canonical form as needed to
encryption in the DEA-1 CBC mode, as follows: The number of
to be encrypted is determined by subtracting the number of
excluded from encryption from the total length of the
text. Octets with the hexadecimal value FF (all ones) are
to the canonical form as needed so that the text octets to
encrypted, along with the added padding octets, fill an
number of 8-octet encryption quanta. No padding is applied if
number of octets to be encrypted is already an integral multiple
8. The use of hexadecimal FF (a value outside the 7-bit ASCII set
as a padding value allows padding octets to be distinguished
valid data without inclusion of an explicit padding count indicator
The regions of the message which have not been excluded
encryption are encrypted. To support selective
processing, an implementation must retain internal indications of
positions of excluded areas excluded from encryption with relation
non-excluded areas, so that those areas can be properly delimited
the encoding procedure defined in step 4. If a region excluded
encryption intervenes between encrypted regions, cryptographic
(e.g., IVs and accumulation of octets into encryption quanta)
preserved and continued after the excluded region
4.3.2.4 Step 4: Printable
The bit string resulting from step 3 is encoded into characters
are universally representable at all sites, though not
with the same bit patterns (e.g., although the character "E"
represented in an ASCII-based system as hexadecimal 45 and
hexadecimal C5 in an EBCDIC-based system, the local significance
the two representations is equivalent). This encoding step
performed for all privacy-enhanced messages
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.)
Two additional characters, "=" and "*", are used to signify
processing functions. The character "=" is used for padding
the printable encoding procedure. The character "*" is used
delimit the beginning and end of a region which has been
Linn [Page 11]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
from encipherment processing. The encoding function's output
delimited into text lines (using local conventions), with each
containing 64 printable characters
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., ".", "", "").
Special processing is performed if fewer than 24-bits are
in an input group, either at the end of a message or (when
selective encryption facility is invoked) at the end of an
region or an excluded region. In other words, a full
quantum is always completed at the end of a message and before
delimiter "*" is output to initiate or terminate the
of a block excluded from encryption. When fewer than 24 input
are available in an input group, zero bits are added (on the right
to form an integral number of 6-bit groups. Output
positions which are not required to represent actual input data
set to the character "=". Since all canonically encoded output
an integral number of octets, only the following cases can arise
(1) the final quantum of encoding input is an integral multiple
24-bits; here, the final unit of encoded output will be an
multiple of 4 characters with no "=" padding, (2) the final
of encoding input is exactly 8-bits; here, the final unit of
output will be two characters followed by two "="
characters, or (3) the final quantum of encoding input is
16-bits; here, the final unit of encoded output will be
characters followed by one "=" padding character
In summary, the outbound message is subjected to the
composition of transformations
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
The inverse transformations are performed, in reverse order,
process inbound privacy-enhanced mail
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 sender and
systems without loss of information
Linn [Page 12]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 y (1) *
(1) The character "*" is used to delimit portions of an
message to which encryption processing has not been applied
Printable Encoding
Table 1
4.4 Encapsulation
Encapsulation of privacy-enhanced messages within an enclosing
of headers interpreted by the electronic mail transport system
a number of advantages in comparison to a flat approach in
certain fields within a single header are encrypted and/or
cryptographic control information. Encapsulation provides
and 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. Further, privacy enhancement processing can
applied recursively. As far as the MTS is concerned,
incorporated into cryptographic authentication or
processing will reside in a message's text portion, not its
portion
Linn [Page 13]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
The encapsulation mechanism to be used for privacy-enhanced mail
derived from that described in RFC-934 [11] which is, in turn,
on precedents in the processing of message digests in the
community. To prepare a user message for encrypted or
transmission, it will be transformed into the representation shown
Figure 1.
Enclosing Header
(Contains header fields per RFC-822)
Blank
(Separates Enclosing Header from Encapsulated Message
Encapsulated
Pre-Encapsulation Boundary (Pre-EB
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Encapsulated Header
(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-
representations similar to RFC-822 header fields, the set
fields valid in this context is disjoint from those used
RFC-822 processing.)
Blank
(Separates Encapsulated Header from subsequent
Encapsulated Text Portion
Encapsulated Text
(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
Figure 1
As a general design principle, sensitive data is protected
incorporating the data within the encapsulated text rather than
applying measures selectively to fields in the enclosing header
Examples of potentially sensitive header information may
fields such as "Subject:", with contents which are significant on
end-to-end, inter-user basis. The (possibly empty) set of headers
which protection is to be applied is a user option. It is
recommended, however, that all implementations should
Linn [Page 14]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within
encapsulated text and include those replicated fields in
and MIC computations
If a user wishes disclosure protection for header fields, they
occur only in the encapsulated text and not in the enclosing
encapsulated header. If disclosure protection is desired for
message's subject indication, it is recommended that the
header contain a "Subject:" field indicating that "Encrypted
Follows".
If an authenticated version of header information is desired,
data can be replicated within the encapsulated text portion
addition to its inclusion in the enclosing header. For example,
sender wishing to provide recipients with a protected indication of
message's position in a series of messages could include a copy of
timestamp or message counter field within the encapsulated text
A specific point regarding the integration of privacy-enhanced
facilities with the message encapsulation mechanism is worthy
note. The subset of IA5 selected for transmission
intentionally excludes the character "-", so encapsulated text can
distinguished unambiguously from a message's closing
boundary (Post-EB) without recourse to character stuffing
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
perrecipient method. The choice depends on the information
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
constituent destinations, is implied. Such an IK must, therefore,
available to all list members. For the case of public-
cryptography, the secret component of the composite IK must
available to all list members. This alternative will be the
case for messages sent via remote exploder sites, as a sender to
lists may not be cognizant of the set of individual recipients
Unfortunately, it implies an undesirable level of exposure for
shared IK or component, and makes its revocation difficult
Moreover, use of the IK-per-list method allows any holder of
list's IK to masquerade as another sender to the list
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
destination mailing list into its individual constituents and
to do so (IK-per-recipient), the message's DEK and MIC will
encrypted under each per-recipient IK and all such
representations will be incorporated into the transmitted message
Note that per-recipient encryption is required only for
relatively small DEK and MIC quantities carried in the X-Key-
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
possession of one IK does not enable a successful masquerade
another user on the list
4.6 Summary of Added Header and Control
This section summarizes the syntax and semantics of the
encapsulated header fields to be added to messages in the course
privacy enhancement processing. In certain indicated cases, it
recommended that the fields be replicated within the
text portion as well. Figure 2 shows the appearance of a
example encapsulated message using these fields. The example
the use of symmetric cryptography; no "X-Certificate:" field
carried. In all cases, hexadecimal quantities are represented
contiguous strings of digits, where each digit is represented by
character from the ranges "0"-"9" or upper case "A"-"F".
otherwise specified, all arguments are to be processed in
casesensitive fashion
Although the encapsulated header fields resemble RFC-822
fields, they are a disjoint set and will not in general be
by the same parser which operates on enclosing header fields.
complexity of lexical analysis needed and appropriate
encapsulated header field processing is significantly less than
appropriate to RFC-822 header processing. For example,
characters with special significance to RFC-822 at the
level have no such significance within encapsulated header fields
When the length of an encapsulated header field is longer than
size conveniently printable on a line, whitespace may be used
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
as a part of a subfield
Linn [Page 16]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 2
X-IV: F8143EDE5960C597
X-Sender-ID: linn@ccy.bbn.com:::
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3:BMAC:
X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7
X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4:BMAC:
X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated
Figure 2
4.6.1 X-Certificate
The X-Certificate encapsulated header field is used only
public-key certificate key management is employed. It transfers
sender's certificate as a string of hexadecimal digits.
semantics of a certificate are discussed in Section 5.3,
Certificates. The certificate carried in an X-Certificate field
used in conjunction with all subsequent X-Sender-ID and X-
fields until another X-Certificate field occurs; the ordinary
will be that only a single X-Certificate field will occur, prior
any X-Sender-ID and X-Recipient-ID fields
Due to the length of a certificate, it may need to be folded
multiple printed lines. In order to enable such folding to
performed, the hexadecimal digits representing the contents of
certificate are to be divided into an ordered set (with
significant digits first) of zero or more 64-digit groups,
by a final digit group which may be any length up to 64-digits.
single whitespace character is interposed between each pair of
so that folding (per RFC-822, section 3.1.1) may take place;
whitespace is ignored in parsing the received digit string
4.6.2 X-IV
The X-IV encapsulated header field carries the Initializing
used for message encryption. Only one X-IV field occurs in
message. It appears in all messages, even if the entirety of
text is excluded from encryption. Following the field name, and
or more delimiting whitespace characters, a 64-bit
Vector is represented as a contiguous string of 16
Linn [Page 17]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
digits
4.6.3 X-Key-Info
The X-Key-Info encapsulated header field transfers two items: a
and a MIC. One X-Key-Info field is included for each of a message'
named recipients. The DEK and MIC are encrypted under the
identified by a preceding X-Recipient-ID field and prior X-Sender-
field; they are represented as two strings of contiguous
digits, separated by a comma. For DEA-1, the DEK representation
be 16 hexadecimal digits (corresponding to a 64-bit key);
subfield can be extended to 32 hexadecimal digits (corresponding to
128-bit key), if required to support other algorithms. MICs are
represented as contiguous strings of hexadecimal digits. The size
a MIC is dependent on the choice of MIC algorithm as specified in
X-Recipient-ID field corresponding to a given recipient
4.6.4 X-Proc-Type
The X-Proc-Type encapsulated header field identifies the type
processing performed on the transmitted message. Only one X-
field occurs in a message. It has one subfield, a decimal
which is used to distinguish among incompatible encapsulated
field interpretations which may arise as changes are made to
standard. Messages processed according to this RFC will carry
subfield value "2".
4.6.5 X-Sender-ID
The X-Sender-ID encapsulated header field provides the sender'
interchange key identification component. It should be
within the encapsulated text. The interchange key
component carried in an X-Sender-ID field is used in conjunction
all subsequent X-Recipient-ID fields until another X-Sender-ID
occurs; the ordinary case will be that only a single X-Sender-
field will occur, prior to any X-Recipient-ID fields
The X-Sender-ID field contains (in order) an Entity
subfield, an (optional) Issuing Authority subfield, an (optional
Version/Expiration subfield, and an (optional) IK Use
subfield. The optional subfields are omitted if their use
rendered redundant by information carried in subsequent X-
fields; this will ordinarily be the case where symmetric
is used for key management. The subfields are delimited by the
character (":"), optionally followed by whitespace
Section 5.2, Interchange Keys, discusses the semantics of
subfields and specifies the alphabet from which they are chosen
Linn [Page 18]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
Note that multiple X-Sender-ID fields may occur within a
encapsulated header. All X-Recipient-ID fields are interpreted
the context of the most recent preceding X-Sender-ID field; it
illegal for an X-Recipient-ID field to occur in a header before
X-Sender-ID has been provided
4.6.6 X-Recipient-ID
The X-Recipient-ID encapsulated header field provides the recipient'
interchange key identification component. One X-Recipient-ID
is included for each of a message's named recipients. It should
replicated within the encapsulated text. The field contains (
order) an Entity Identifier subfield, an Issuing Authority subfield
a Version/Expiration subfield, a MIC algorithm indicator subfield
and an IK Use Indicator subfield. The subfields are delimited by
colon character (":"), optionally followed by whitespace
The MIC algorithm indicator is an ASCII string, selected from
values defined in Appendix A of this RFC. Section 5.2,
Keys, discusses the semantics of the other subfields and
the alphabet from which they are chosen. All X-Recipient-
fields are interpreted in the context of the most recent
XSender-ID field; it is illegal for an X-Recipient-ID field
occur in a header before an X-Sender-ID has been provided
5. Key
Several cryptographic constructs are involved in supporting
privacy-enhanced message processing procedure. While (as noted
the Executive Summary section of this RFC), key management
have not yet been fully defined, a set of fundamental elements
assumed. Data Encrypting Keys (DEKs) are used to encrypt
text and in the message integrity check (MIC) computation process
Interchange Keys (IKs) are used to encrypt DEKs for transmission
messages. In an asymmetric key management architecture,
are used as a means to provide entities' public key components
other information in a fashion which is securely bound by a
authority. The remainder of this section provides more
about these constructs
5.1 Data Encrypting Keys (DEKs
Data Encrypting Keys (DEKs) are used for encryption of message
and for computation of message integrity check quantities (MICs).
is strongly recommended that DEKs be generated and used on a one-
basis. A transmitted message will incorporate a representation
the DEK encrypted under an appropriate interchange key (IK) for
the authorized recipient
Linn [Page 19]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
DEK generation can be performed either centrally by key
centers (KDCs) or by endpoint systems. Dedicated KDC systems may
able to implement better algorithms for random DEK generation
can be supported in endpoint systems. On the other hand
decentralization allows endpoints to be relatively self-sufficient
reducing the level of trust which must be placed in components
than a message's originator and recipient. Moreover,
DEK generation at endpoints reduces the frequency with which
must make real-time queries of (potentially unique) servers in
to send mail, enhancing communications availability
When symmetric cryptography is used, one advantage of
KDC-based generation is that DEKs can be returned to
already encrypted under the IKs of message recipients rather
providing the IKs to the senders. This reduces IK exposure
simplifies endpoint key management requirements. This approach
less value if asymmetric cryptography is used for key management
since per-recipient public IK components are assumed to be
available and per-sender secret IK components need not necessarily
shared with a KDC
5.2 Interchange Keys (IKs
Interchange Keys (IKs) are used to encrypt Data Encrypting Keys.
general, IK granularity is at the pairwise per-user level except
mail sent to address lists comprising multiple users. In order
two principals to engage in a useful exchange of privacy-
electronic mail using conventional cryptography, they must
share a common interchange key. When symmetric cryptography is used
the interchange key consists of a single component. When
cryptography is used, an originator and recipient must possess
asymmetric key's public and secret components, as appropriate.
pair of components, when composed, constitute an interchange key
While this RFC does not prescribe the means by which interchange
are provided to appropriate parties, it is useful to note that
means may be centralized (e.g., via key management servers)
decentralized (e.g., via pairwise agreement and direct
among users). In any case, any given IK component is associated
a responsible Issuing Authority (IA). When an IA generates
distributes an IK, associated control information is provided
direct how that IK is to be used. In order to select the
IK to use in message encryption, a sender must retain
correspondence between IK components and the recipients with
they are associated. Expiration date information must also
retained, in order that cached entries may be invalidated
replaced as appropriate
Linn [Page 20]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
Since a message may be sent with multiple IK
representations, corresponding to multiple intended recipients,
recipient must be able to determine which IK component is
for it. Moreover, if no corresponding IK component is available
the recipient's database when a message arrives, the recipient
be able to determine which IK component to request and to
that IK component's associated IA. Note that different IKs may
used for different messages between a pair of communicants
Consider, for example, one message sent from A to B and
message sent (using the IK-per-list method) from A to a mailing
of which B is a member. The first message would use IK
associated individually with A and B, but the second would use an
component shared among list members
When a privacy-enhanced message is transmitted, an indication of
IK components used for DEK encryption must be included. To this end
the "X-Sender-ID:" and "X-Recipient-ID:" encapsulated header
provide the following data
1. Identification of the relevant Issuing Authority (
subfield).
2. Identification of an entity with which a particular
component is associated (Entity Identifier or
subfield).
3. Indicator of IK usage mode (IK use indicator subfield).
4. Version/Expiration subfield
The colon character (":") is used to delimit the subfields within
"X-Sender-ID:" or "X-Recipient-ID:". The IA, EI,
version/expiration subfields are generated from a
character set, as prescribed by the following BNF (using notation
defined in RFC-822, sections 2 and 3.3):
IKsubfld := 1*ia-
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"," / "." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
An example X-Recipient-ID: field is as follows
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2:BMAC:
This example field indicates that IA "ptf-kmc" has issued an
component for use on messages sent to "linn@ccy.bbn.com", that the
Linn [Page 21]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
has provided the number 2 as a version indicator for that
component, that the BMAC MIC computation algorithm is to be used
the recipient, and that the IK component is to be used in ECB mode
5.2.1 Subfield
The following subsections define the subfields of "X-Sender-ID:"
"X-Recipient-ID:" fields
5.2.1.1 Entity Identifier
An entity identifier is constructed as an IKsubfld.
restrictively, an entity identifier subfield assumes the
form
@qualified-host
In order to support universal interoperability, it is necessary
assume a universal form for the naming information. For the case
installations which transform local host names before
into the broader Internet, it is strongly recommended that the
name as presented to the Internet be employed
5.2.1.2 Issuing Authority
An IA identifier subfield is constructed as an IKsubfld.
identifiers must be assigned in a manner which assures uniqueness
This can be done on a centralized or hierarchic basis
5.2.1.3 Version/Expiration
A version/expiration subfield is constructed as an IKsubfld.
version/expiration subfield format may vary among different IAs,
must satisfy certain functional constraints. An IA'
version/expiration subfields must be sufficient to distinguish
the set of IK components issued by that IA for a given
entity. Use of a monotonically increasing number is sufficient
distinguish among the IK components provided for an entity by an IA
use of a timestamp additionally allows an expiration time or date
be prescribed for an IK component
5.2.1.4 MIC Algorithm Identifier
The MIC algorithm identifier, which occurs only within X-Recipient-
fields, is used to identify the choice of message integrity
algorithm for a given recipient. Appendix A of this RFC
the defined values for this subfield
Linn [Page 22]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
5.2.1.5 IK Use Indicator
The IK use indicator subfield is an optional facility, provided
identify the encryption mode in which an IK component is to be used
Currently, this subfield may assume the following reserved
values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the
value is "ECB".
5.2.2 IK Cryptoperiod
An IK component's cryptoperiod is dictated in part by a
between key management overhead and revocation responsiveness.
would be undesirable to delete an IK component permanently
receipt of a message encrypted using that IK component, as this
render the message permanently undecipherable. Access to an
IK component would be needed, for example, to process mail
by a user (or system) which had been inactive for an extended
of time. In order to enable very old IK components to be deleted,
message's recipient desiring encrypted local long term storage
transform the DEK used for message text encryption via re-
under a locally maintained IK, rather than relying on IA
of old IK components for indefinite periods
5.3
In an asymmetric key management architecture, a certificate binds
entity's public key component to a representation of the entity'
identity and other attributes of the entity. A certificate's
authority signs the certificate, vouching for the
between the entity's identity, attributes, and associated public
component. Once signed, certificate copies may be posted on
servers in order to make recipients' certificates directly
to originators at dispersed locations. This allows privacy-
mail to be sent between an originator and a recipient without
placement of a pairwise key at the originator and recipient,
enhancing mail system flexibility. The properties of a certificate'
authority-applied signature make it unnecessary to be concerned
the prospect that servers, or other entities, could
modify certificate contents so as to associate a public key with
inappropriate entity
Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13],
subject's certificate is defined to contain the following parameters
1. A signature algorithm identifier, identifying
algorithm used by the certificate's issuer to compute
signature applied to the certificate
Linn [Page 23]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
2. Issuer identification, identifying the certificate'
issuer with an O/R name
3. Validity information, providing date and time
before and after which the certificate should not
used
4. Subject identification, identifying the certificate'
subject with an O/R name
5. Subject's public key
6. Algorithm identifier, identifying the algorithm
which the subject's public key is to be used
7. Signature, an asymmetrically encrypted, hashed version
the above parameters, computed by the certificate'
issuer
The Recommendations specify an ASN.1 encoding to define
certificate. Pending further study, it is recommended
electronic mail privacy enhancement implementations using
cryptography for key management employ this encoding
certificates. Section 4.2.3 of RFC-987 [14] specifies a
for mappin