As per Relevance of the word processing, we have this rfc below:
Network Working Group John Linn (BBNCC
Request for Comments: 989 IAB Privacy Task
February 1987
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, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox,
Gasser, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett
Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and
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 authentication is anticipated
Privacy enhancement services (confidentiality, authentication,
message integrity assurance) are offered through the use of 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 relay 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
components and mail transport facilities is supported
Linn, Privacy Task Force [Page 1]
RFC 989 February 1987
2
For descriptive purposes, this RFC uses some terms defined in the
X.400 Message Handling System Model. This section replicates
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
not be familiar with 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's goal is to define mechanisms to enhance privacy
electronic mail transferred in the Internet. The
discussed in this RFC provide privacy enhancement services on
end-to-end basis between sender and recipient UAs. No
enhancements are offered for message fields which are added
transformed by intermediate relay points. Two distinct
enhancement service options are supported
1. an option providing sender authentication and
2. an option providing sender authentication and
verification in addition to confidentiality service
No facility for confidentiality service in the absence
authentication is provided. Encryption and authentication
may be applied selectively to portions of a message's contents;
allows less sensitive portions of messages (e.g., descriptive fields
Linn, Privacy Task Force [Page 2]
RFC 989 February 1987
to be processed by a recipient's delegate in the absence of
recipient's personal cryptographic keys
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 offer compatibility with non
enhanced Internet components. Privacy enhancements will
implemented in an end-to-end fashion which does not
mail 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
privacy enhancements, in order that encoding and
encipherment will not be performed on a message
destination is not equipped to perform
inverse transformations
3. The defined mechanisms offer compatibility with a range
mail 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
variety of electronic mail user agent programs, with
corresponding broad range of user interface paradigms,
used in the Internet. In order that an electronic
privacy enhancement be available to the broadest
user community, it is desirable that the selected
be usable with the widest possible variety of existing
programs. For purposes of pilot implementation, it
desirable that privacy enhancement processing
incorporable into a separate program, applicable to a
of UAs, rather than requiring internal modifications
Linn, Privacy Task Force [Page 3]
RFC 989 February 1987
each UA with which enhanced privacy services are to
provided
5. The defined mechanisms allow electronic mail
enhancement processing to be performed on
computers (PCs) separate from the systems on which
functions are implemented. Given the expanding use of
and the limited degree of trust which can be placed in
implementations on many multi-user systems, this
can allow many users to process privacy-enhanced mail
a higher assurance level than a strictly UA-based
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
endpoints and will be amenable to integration at the
agent (UA) level or above, rather than
integration into the message transport system (e.g.,
servers).
2. The set of supported measures enhances rather
restricts user capabilities. Trusted implementations
incorporating integrity features protecting software
subversion by local users, cannot be assumed in general
In the absence of such features, it appears more
to provide facilities which enhance user services (e.g.,
by protecting and authenticating inter-user traffic)
to enforce restrictions (e.g., inter-user access control
on user actions
3. The set of supported measures focuses on a set
functional capabilities selected to provide
and tangible benefits to a broad user community.
concentrating on the most critical set of services,
aim to maximize the added privacy value that can
provided with a modest level of implementation effort
As a result of these restrictions, the following facilities can
provided
-- disclosure protection
Linn, Privacy Task Force [Page 4]
RFC 989 February 1987
-- sender authenticity,
-- message integrity measures
but the following privacy-relevant concerns are not addressed
-- access control
-- traffic flow security
-- address list accuracy
-- routing control
-- issues relating to the serial reuse of PCs by multiple users
-- assurance of message receipt and non-deniability of receipt,
-- automatic association of acknowledgments with the messages
which they
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 with 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. This will
mechanisms by which a sender can determine whether
recipients are equipped to process privacy-enhanced mail. In
general architecture, these mechanisms will be based on
queries; thus, the query function could be integrated into a UA
avoid imposing burdens or inconvenience on electronic mail users
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 of
Linn, Privacy Task Force [Page 5]
RFC 989 February 1987
text and for computation of message authentication
(MACs). DEKs are generated individually for each
message; no predistribution of DEKs is needed to
privacy-enhanced message transmission
2. Interchange Keys (IKs) are used to encrypt DEKs
transmission. An IK may either be a single
cryptographic key or, where asymmetric (public-key
cryptography is used for DEK encryption, the composition of
public component used by an originator and a secret
used by a recipient. Ordinarily, the same IK will be used
all messages sent between a given originator-recipient
over a period of time. Each transmitted message includes
representation of the DEK(s) used for message
and/or authentication, encrypted under an individual IK
named recipient. This representation is accompanied by
identifier (IK ID) to enable the recipient to determine
IK was used, and so to decrypt the representation yielding
DEK required for message text decryption and/or
verification
An encoding procedure is employed in order to represent
message text in a universally transmissible form and to
messages encrypted on one type of system to be decrypted on
different type. Four phases are involved in this process.
plaintext message is accepted in local form, using the host's
character set and line representation. The local form is
to a canonical message text representation, defined as equivalent
the inter-SMTP representation of message text. The
representation is padded to an integral multiple of eight octets,
required by the encryption algorithm. MAC computation is performed
and (if disclosure protection is required), the padded
representation is encrypted. The output of this step is encoded
a printable form. The printable form is composed of a
character set which is chosen to be universally representable
sites, and which will not be disrupted by processing within
between MTS entities
The output of the encoding procedure is combined with a set of
fields (to be defined in Section 4.8) carrying cryptographic
information. The result is passed to the electronic mail system
be encapsulated as the text 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 MAC verification
decryption on the received message text. First, the
encoding is converted to a bitstring. If the transmitted message
encrypted, it is decrypted into the canonical representation. If
message was not encrypted, decoding from the printable form
the canonical representation directly. The MAC is verified, and
Linn, Privacy Task Force [Page 6]
RFC 989 February 1987
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 [1] shall be used
encryption of message text and for computation of
codes on messages. The DEA-1 is equivalent to the Data
Standard (DES), as defined in FIPS PUB 46 [2]. When used for
purposes, the DEA-1 shall be used in the Cipher Block Chaining (CBC
mode, as defined in ISO DIS 8372 [3]. The CBC mode definition in
8372 is equivalent to that provided in FIPS PUB 81 [4]. A
initializing vector (IV) will be generated for and transmitted
each encrypted electronic mail message
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 and
in 8 octet
2. it is usable in the ECB and CBC modes defined in DIS8372
3. it is able to be keyed using the procedures and
defined in this
4. it is appropriate for MAC
5. cryptographic key field lengths are limited to 16
in
Certain operations require that one key be encrypted under
key (interchange key) for purposes of transmission. For purposes
this RFC, such encryption will be performed using DEA-1 in
Codebook (ECB) mode. An optional facility is available to
interchange key provider to indicate that an associated key is to
used for encryption in another mode (e.g., the Encrypt-Decrypt
Encrypt (EDE) mode used for key encryption and decryption with
of 64-bit keys, as described [5] by ASC X3T1).
Future support of public key algorithms for key encryption is
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
Linn, Privacy Task Force [Page 7]
RFC 989 February 1987
4.3 Canonical
Any encryption scheme must be compatible with the
constraints of its underlying electronic mail facilities.
constraints are generally established based on expected
requirements and on the characteristics of anticipated
transport facilities. SMTP, designed primarily for
messages and anticipating systems and transport media which may
restricted to a 7-bit character set, can transmit any 7-
characters (but not arbitrary 8-bit binary data) in message text
SMTP introduces other transparency constraints related to
lengths and message delimiters. Message text may not contain
string "." in sequence before the end of a message
and must contain the string "" at least every 1000
characters. Another important SMTP transparency issue must be noted
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 [6] 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 using different line delimiting conventions. It
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 MAC
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 the disadvantage that it
imply internal file (e.g., mailbox) formats which would
incompatible with the systems on which they reside, an
prospect. Further, it would require modification to SMTP servers,
mail would be passed to SMTP in a different representation than it
passed at present
Our approach to this problem selects a canonical character set
uniformly representable across privacy-enhanced UAs regardless
their systems' native character sets, to transport encrypted
text (but not electronic mail transport headers!) between endpoints
Linn, Privacy Task Force [Page 8]
RFC 989 February 1987
In this approach, an outbound privacy-enhanced message is
between four forms, in sequence
1. (Local_Form) The message text is created (e.g., via an editor
in the system's native character set, with lines delimited
accordance with local convention
2. (Canonicalize) The message text is converted to the
canonical form, equivalent to the inter-SMTP representation
defined in RFC822 [7] (ASCII character set,
delimiters). (The processing required to perform
conversion is relatively small, at least on systems
native character set is ASCII.)
3. (Encipher/Authenticate) A padded version of the
plaintext representation is created by appending zero-
octets to the end of the representation until the length is
integral multiple of 8 octets, as is required to
encryption in the DEA-1 CBC mode. No padding is applied
the canonical plaintext representation's length is already
multiple of 8 octets. This padded representation is used
the input to the encryption function and to the
computation function
4. (Encode to Printable Form) The bits resulting from
encryption operation are encoded into characters which
universally representable at all sites, though not
with the same bit patterns (e.g., although the character "E
is represented in an ASCII-based system as hexadecimal 45
as hexadecimal C5 in an EBCDIC-based system, the
significance of the two representations is equivalent).
of a 64-character subset of International Alphabet IA5
proposed, enabling 6 bits to be represented per
character. (The proposed subset of characters is
identically in IA5 and ASCII.) Two additional characters, "="
and "*", are used to signify special processing functions
The encoding function's output is delimited into text
(using local conventions), with each line containing 64
printable characters. The encoding process is performed
follows, transforming strings of 3 arbitrary (8-bit
characters to strings of 4 encoded characters
4a. Proceeding from left to right across the input
(considered as a contiguous bitstring), each group of 6
bits is used as an index into an array of 64
characters; the character referenced by the index
placed in the output string. These characters
identified in Table 1, are selected so as to
universally representable, and the set
characters with particular significance to SMTP e.g.,
Linn, Privacy Task Force [Page 9]
RFC 989 February 1987
".", "", "").
4b. If fewer than 3 input characters are available in a
quantum, zero bits are added (on the right) to form
integral number of 6-bit groups. Output
positions which are not required to represent
input data are set to a 65th reserved,
representable character ("="). Use of a
character for padding allows compensatory processing
be performed by a recipient, allowing the decoded
text's length to be precisely the same as the
message's length. A final 3-octet input quantum will
represented as a 4 octet encoding with no terminal "=",
2-octet input quantum will be represented as 3
followed by one terminal "=", and a 1-octet input
will be represented as 2 octets followed by
occurrences of "=".
A sender may exclude one or more portions of a message
encryption/authentication processing. Explicit action is required
exclude a portion of a message from such processing; by default
encryption/authentication is applied to the entirety of message text
The 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/authentication processing.
excluded area is represented in the inter-SMTP transmission
(universal across communicating systems) by bracketing with
reserved delimiter "*". Cryptographic state is
transparently across an excluded area and continued after the end
the excluded area. A printable encoding quantum (per step 4b)
completed before the delimiter "*" is output to initiate or
the representation of an excluded block. Note that
canonicalizing transformation (step 2 above) and the encoding
printable form (step 4 above) are applied to all portions of
text, even those excluded from encryption and authentication
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, Privacy Task Force [Page 10]
RFC 989 February 1987
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
encoded 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. As far as the MTS is concerned,
incorporated into cryptographic authentication or
processing will reside in a message's text portion, not its
portion
The encapsulation mechanism to be used for privacy-enhanced mail
derived from that described in RFC934 [8] which is, in turn, based
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. Note that, while encryption and/or
processing of transmitted mail may depend on information contained
the enclosing header (e.g., "To:"), all fields inserted in the
of encryption/authentication processing are placed in
encapsulated header. This facilitates compatibility with
handling programs which accept only text, not header fields,
input files or from other programs. Further, privacy
Linn, Privacy Task Force [Page 11]
RFC 989 February 1987
processing can be applied recursively
Sensitive data should be protected by incorporating the data
the encapsulated text rather than by applying measures selectively
fields in the enclosing header. Examples of potentially
header information may include fields such as "Subject:",
contents which are significant on an end-to-end, inter-user basis
The (possibly empty) set of headers to which protection is to
applied is a user option. If an authenticated version of
information is desired, that data can be replicated within
encapsulated text portion in addition to its inclusion in
enclosing header. If a user wishes disclosure protection for
fields, they must occur only in the encapsulated text and not in
enclosing or encapsulated header. If disclosure protection
desired for the "Subject:" field, it is recommended that
enclosing header contain a "Subject:" field indicating
"Encrypted Mail Follows".
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 Processing for Authentication Without
When a message is to be authenticated without
service, a DEK is generated [9] for use in MAC computation, and a
is computed using that DEK. For each individually
recipient, an IK is selected and identified with an "X-IK-ID:" field
Each "X-IK-ID:" field is followed by an "X-Key-Info:" field
transfers the key under which MAC computation was performed
encrypted under the IK identified by the preceding "X-IK-ID:" field
along with a representation of the MAC encrypted under the same IK
The encapsulated text portion following the encapsulated header
canonically encoded, and coded into printable characters
transmission, but not encrypted
Linn, Privacy Task Force [Page 12]
RFC 989 February 1987
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-IK-ID:", "X-Key-Info:",
and "X-Pad-Count:". Note that, although these
fields have line-oriented representations similar
RFC-822 header fields, the set of fields valid in
context is disjoint from those used in 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
4.6 Processing for Authentication and
When a message is to be authenticated with confidentiality service,
DEK is generated for use in MAC computation and a variant of the
is formed for use in message encryption. For each
identified recipient, an IK is selected and identified with an "X
IK-ID:" field. Each "X-IK-ID:" field is followed by an "X-Key-Info:"
field, which transfers the DEK and computed MAC, each encrypted
the IK identified in the preceding "X-IK-ID:" field.
encapsulated text portion following the encapsulated header
canonically encoded, encrypted, and coded into printable
Linn, Privacy Task Force [Page 13]
RFC 989 February 1987
for transmission
4.7 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. The choice depends on the information available
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-per
list), rather than resolution of the name or alias to its
destinations, is implied. Such an IK must, therefore, be
to all list members. This alternative will be the normal case
messages sent via remote exploder sites, as a sender to such
may not be cognizant of the set of individual recipients
Unfortunately, it implies an undesirable level of exposure for
shared IK, and makes its revocation difficult. Moreover, use of
IK-per-list method allows any holder of the list's IK to
as another sender to the list for authentication purposes
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 MAC 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 MAC 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-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
4.8 Summary of Added Header and Control
This section summarizes the syntax and semantics of the new
and control fields to be added to messages in the course of
enhancement processing, indicating whether a particular field
in a message's encapsulated header portion or its encapsulated
portion. Figure 2 shows the appearance of a small
encapsulated message using these fields. In all cases,
quantities are represented as contiguous strings of digits,
each digit is represented by a character from the ranges "0"-"9"
upper case "A"-"F". Unless otherwise specified, all arguments are
be processed in a case-sensitive 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
Linn, Privacy Task Force [Page 14]
RFC 989 February 1987
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
The "X-IK-ID" and "X-Key-Info" fields are the only
header fields with lengths which can vary beyond a size
printable on a line. Whitespace may be used between the subfields
these fields to fold them in the manner of RFC-822; such
is not to be interpreted as a part of a subfield
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 1,
X-Pad-Count: 1
X-IV: F8143EDE5960C597
X-IK-ID: JL:3:
X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7
X-IK-ID: JL:1:
X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated
Figure 2
X-IK-ID: This field is placed in the encapsulated
portion of a message to identify the Interchange
used for encryption of an associated Data
Key or keys (used for message text encryption and/
MAC computation). This field is used for
authenticated without confidentiality service and
messages authenticated with confidentiality service
The field contains (in order) an Issuing
subfield and an IK Qualifier subfield, and may
contain an optional IK Use Indicator subfield.
subfields are delimited by the colon character (":"),
optionally followed by whitespace. Section 5.1.2,
Interchange Keys, discusses the semantics of
subfields and specifies the alphabet from which
are chosen. Note that multiple X-IK-ID fields
occur within a single encapsulated header. Each X
IK-ID field is associated with an
subsequent X-Key-Info field
X-IV: This field is placed in the encapsulated
portion of a message to carry the Initializing
Linn, Privacy Task Force [Page 15]
RFC 989 February 1987
used for message encryption. It is used only
messages where confidentiality service is applied
Following the field name, and one or more
whitespace characters, a 64-bit Initializing
is represented as a contiguous string of 16
hexadecimal digits
X-Key-Info: This field is placed in a message's
header portion to transfer two items: a DEK and
MAC. Both items are encrypted under the
identified by a preceding X-IK-ID field; they
represented as two strings of contiguous
digits, separated by a comma. For DEA-1, the
representation will be 16 hexadecimal
(corresponding to a 64-bit key); this subfield can
extended to 32 hexadecimal digits (corresponding to
128-bit key) if required to support other algorithms
The MAC is a 64-bit quantity, represented as 16
hexadecimal digits. The MAC is computed under
unmodified version of the DEK. Message encryption
performed using a variant of the DEK, formed
modulo-2 addition of the hexadecimal
F0F0F0F0F0F0F0F0 to the DEK
X-Pad-Count: This field is placed in the encapsulated
portion of a message to indicate the number of zero
valued octets which were added to pad the
stream to the encryption function to an
multiple of eight octets, as required by the DEA-1
CBC encryption mode. A decimal number in the
0-7 follows the field name, and one or
delimiting whitespace characters. Inclusion of
field allows disambiguation between terminal zero
valued octets in message text (admittedly,
relatively unlikely prospect) and zero-valued
inserted for padding purposes
X-Proc-Type: This field is placed in the encapsulated
portion of a message to identify the type
processing performed on the transmitted message.
first subfield is a decimal version number,
will be used if future developments make it
to redefine the interpretation of encapsulated
fields. At present, this field may assume only
value "1". The second subfield, delimited by
comma, assumes one of two single-character
values: "A" and "E", to signify, respectively, (1)
authentication processing only and (2)
combination of authentication and
service through encryption
Linn, Privacy Task Force [Page 16]
RFC 989 February 1987
5 Key
5.1 Types of
5.1.1 Data Encrypting Keys (DEKs
Data Encrypting Keys (DEKs) are used for encryption of message
and for computation of message authentication codes (MACs). It
strongly recommended that DEKs be generated and used on a one-
basis. A transmitted message will incorporate a representation
the DEK encrypted under an interchange key (IK) known to
authorized recipient
DEK generation can be performed either centrally by key
centers (KDCs) or by endpoint systems. One advantage of
KDC-based generation is that DEKs can be returned to
already encrypted under the IKs of message recipients. This
IK exposure and simplifies endpoint key management requirements
Further, dedicated KDC systems may be able to implement
algorithms for random key generation than can be supported
endpoint systems. On the other hand, decentralization
endpoints to be relatively self-sufficient, reducing the level
trust which must be placed in components other than a message'
originator and recipient. Moreover, decentralized DEK generation
endpoints reduces the frequency with which senders must make real
time queries of (potentially unique) servers in order to send mail
enhancing communications availability
5.1.2 Interchange Keys (IKs
Interchange Keys (IKs) are used to encrypt Data Encrypting Keys.
general, the granularity of IK usage is at the pairwise per-
level except for mail sent to address lists comprising
users. In order for two principals to engage in a useful exchange
privacy-enhanced electronic mail using conventional cryptography
they must first share a common interchange key. When
cryptography is used, an originator and recipient must
appropriate public and secret components which, in composition
constitute an interchange key
The means by which interchange keys are provided to
parties are outside the scope of this RFC, but may be
(e.g., via key management servers) or decentralized (e.g., via
distribution among users). In any case, a given IK is
with a responsible Issuing Authority (IA). When an IA generates
distributes an IK, associated control information must be 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 IKs and the recipients with which they
associated. Expiration date information must also be retained,
order that cached entries may be invalidated and replaced
Linn, Privacy Task Force [Page 17]
RFC 989 February 1987
appropriate
When a privacy-enhanced message is transmitted, an indication of
IK (or IKs, in the case of a message sent to multiple recipients
used for DEK encryption must be included. To this end, the IK
construct is defined to provide the following data
1. Identification of the relevant Issuing Authority (
subfield
2. Qualifier string to distinguish the particular IK
the set of IKs distributed by the IA (IK
subfield
3. (Optional) Indicator of IK usage mode (IK use
subfield
The subfields of an IK ID are delimited with the colon
(":"). The IA and IK qualifier subfields are generated from
restricted character set, as prescribed by the following BNF (
notation as defined in RFC-822, sections 2 and 3.3):
IAorIKQual := 1*ia-
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"," / "." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
The IK use indicator subfield assumes a value from a small set
reserved strings, described later in this section
IA identifiers must be assigned in a manner which assures uniqueness
This can be done on a centralized or hierarchic basis
The IK qualifier string format may vary among different IAs, but
satisfy certain functional constraints. An IA's IK qualifiers
be sufficient to distinguish among the set of IKs issued by that IA
Since a message may be sent with multiple IK IDs, corresponding
multiple intended recipients, each recipient must be able
determine which IK is intended for it. Moreover, if no
IK is available in the recipient's database when a message arrives
the recipient must be able to determine which IK to request and
identify that IK'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 an IK
between A and B, but the second would use an IK shared among
members
Linn, Privacy Task Force [Page 18]
RFC 989 February 1987
While use of a monotonically increasing number as an IK qualifier
sufficient to distinguish among the set of IKs distributed by an IA
it offers no facility for a recipient lacking a matching IK
determine the appropriate IK to request. This suggests that
and recipient name information should be incorporated into an
qualifier, along with a number to distinguish among multiple IKs
between a sender/recipient pair. In order to support
interoperability, it is necessary to assume a universal form for
naming information. General definition of such a form
further study; issues and possible approaches will be noted
Section 6. As an interim measure, the following IK qualifier
is suggested
/<recipient-name>/
where and <recipient-name> are in the following form
@qualified-host
For the case of installations which transform local host names
transmission into the broader Internet, it is strongly
that the host name as presented to the Internet be employed.
is a contiguous string of decimal digits
The IK use indicator subfield is an optional facility, provided
identify the encryption mode in which the IK is to be used
Currently, this subfield may assume the following reserved
values: "ECB" and "EDE"; the default value is ECB
An example IK ID adhering to this recommendation is as follows
ptf-kmc:linn@CCY.BBN.COM/privacy-tf@C.ISI.EDU/2:
This IK ID would indicate that IA "ptf-kmc" has issued an IK for
on messages sent from "linn@CCY.BBN.COM" to "privacy-tf@C.ISI.EDU",
that the IA has associated number 2 with that IK, and that the IK
to be used in ECB mode
IKs will remain valid for a period which will be longer than a
message and will be identified by an expiration time
along with the IK; IK cryptoperiod is dictated in part by a
between key management overhead and revocation responsiveness.
would be undesirable to delete an IK permanently before receipt of
message encrypted using that IK, as this would render the
permanently undecipherable. Access to an expired IK would be needed
for example, to process mail received by a user (or system) which
been inactive for an extended period of time. In order to
very old IKs to be deleted, a message's recipient desiring
local long term storage should transform the DEK used for
text encryption via re-encryption under a locally maintained IK
rather than relying on IA maintenance of old IKs for
Linn, Privacy Task Force [Page 19]
RFC 989 February 1987
periods
6 User
Unique naming of electronic mail users, as is needed in order
select corresponding keys correctly, is an important topic and
requiring significant study. A logical association exists
key distribution and name/directory server functions;
relationship is a topic deserving further consideration.
issues have not been fully resolved at this writing. The
architecture relies on association of IKs with user names
in a universal form, which has the following properties
1. The universal form must be specifiable by an IA as
distributes IKs and known to a UA as it
received IKs and IK IDs. If a UA or IA uses addresses
a local form which is different from the universal form
it must be able to perform an unambiguous mapping
the universal form into the local representation
2. The universal form, when processed by a sender UA,
have a recognizable correspondence with the form of
recipient address as specified by a user (
following local transformation from an alias into
universal form
It is difficult to ensure these properties throughout the Internet
For example, an MTS which transforms address representations
the local form used within an organization and the global form
for Internet mail transmission may cause property 2 to be violated
The use of flat (non-hierarchic) electronic mail user identifiers
which are unrelated to the hosts on which the users reside,
useful. Personal characteristics, like social security numbers
might be considered. Individually-selected identifiers could
registered with a central authority, but a means to resolve
conflicts would be necessary
A point of particular note is the desire to accommodate
names for a single individual, in order to represent and
delegation of various roles in which that individual may act.
naming mechanism that binds user roles to keys is needed.
cannot be immutable since roles sometimes change (e.g.,
comptroller of a corporation is fired).
It may be appropriate to examine the prospect of extending the
Name System and its associated name servers to resolve user names
unique user IDs. An additional issue arises with regard to
list support: name servers do not currently perform (
recursive) expansion of lists into users. ISO and CSNet are
on user-level directory service mechanisms, which may also
Linn, Privacy Task Force [Page 20]
RFC 989 February 1987
consideration
7 Example User Interface and
In order to place the mechanisms and approaches discussed in this
into context, this section presents an overview of a
implementation. This implementation is a standalone program [10]
which is invoked by a user, and lies above the existing UA sublayer
This form of integration offers the advantage that the program can
used in conjunction with a range of UA programs, rather than
compatible only with a particular UA. When a user wishes to
privacy enhancements to an outgoing message, the user prepares
message's text and invokes the standalone program (interacting
the program in order to provide address information and other
required to perform privacy enhancement processing), which in
generates output suitable for transmission via the UA. When a
receives a privacy-enhanced message, the UA delivers the message
encrypted form, suitable for decryption and associated processing
the standalone program
In this prototype implementation, a cache of IKs is maintained in
local file, with entries managed manually based on
agreements between originators and recipients. This cache is
effectively, a simple database. IKs are selected for
messages based on recipient names, and corresponding IK IDs
placed into the message's encapsulated header. When a message
received, the IK ID is used as a basis for a lookup in the database
yielding the appropriate IK entry. DEKs and IVs are
dynamically within the program
Options (e.g., authentication only vs. authentication
confidentiality service) are selected by command line arguments
the standalone program. Destination addresses are specified in
same fashion. The function of specifying destination addresses
the privacy enhancement program is logically distinct from
function of specifying the corresponding addresses to the UA for
by the MTS. This separation results from the fact that, in
cases, the local form of an address as specified to a UA differs
the Internet global form as used for IK ID fields
8 Areas For Further
The procedures defined in this RFC are sufficient to support
implementation of privacy-enhanced electronic mail transmission
cooperating parties in the Internet. Further effort will be needed
however, to enhance robustness, generality, and interoperability.
particular, further work is needed in the following areas
1. User naming techniques, and their relationship to the
system, name servers, directory services, and key
Linn, Privacy Task Force [Page 21]
RFC 989 February 1987
2. Standardization of Issuing Authority functions,
protocols for communications among IAs and between User
and
3. Use of public key encryption algorithms to encrypt
encrypting
4. Interoperability with X.400
We anticipate generation of subsequent RFCs which will address
topics
9
This section identifies background references which may be useful
those contemplating use of the mechanisms defined in this RFC
ISO 7498/Part 2 - Security Architecture, prepared by ISO.TC97/
21/WG 1 Ad hoc group on Security, extends the OSI
Reference Model to cover security aspects which are
architectural elements of communications protocols,
provides an annex with tutorial and background information
US Federal Information Processing Standards Publication (FIPS PUB
46, Data Encryption Standard, 15 January 1977, defines
encipherment algorithm used for message text encryption
MAC computation
FIPS PUB 81, DES Modes of Operation, 2 December 1980,
specific modes in which the Data Encryption Standard
is to be used to perform encryption and MAC computation
NOTES
[1] Information Processing Systems: Data Encipherment:
Cipher Algorithm DEA 1.
[2] Federal Information Processing Standards Publication 46,
Encryption Standard, 15 January 1977.
[3] Information Processing Systems: Data Encipherment: Modes
Operation of a 64-bit Block
[4] Federal Information Processing Standards Publication 81,
Modes of Operation, 2 December 1980.
Linn, Privacy Task Force [Page 22]
RFC 989 February 1987
[5] Addendum to the Transport Layer Protocol Definition
Providing Connection Oriented End to End Cryptographic
Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft
19 December 1985, Gaithersburg, MD, p. 15.
[6] This transformation should occur only at an SMTP endpoint,
at an intervening relay, but may take place at a
system linking the SMTP realm with other environments
[7] Crocker, D. Standard for the Format of ARPA Internet
Messages (RFC822), August 1982.
[8] Rose, M. T., and Stefferud, E. A., Proposed Standard
Message Encapsulation, January 1985.
[9] Key generation for authentication and message text
may either be performed by the sending host or by
centralized server. This RFC does not constrain this
alternative. Section 5.1.1 identifies possible advantages
a centralized server approach
[10] Note that in the UNIX(tm) system, and possibly in
environments as well, such a program can be invoked as
"filter" within an electronic mail UA or a text editor
simplifying the sequence of operations which must be
by the user
Linn, Privacy Task Force [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
