unique user IDs. An additional issue arises with regard to mailing
list support: name servers do not currently perform (potentially
recursive) expansion of lists into users. ISO and CSNet are working
on user-level directory service mechanisms, which may also bear
consideration.
7 Example User Interface and Implementation
In order to place the mechanisms and approaches discussed in this RFC
into context, this section presents an overview of a prototype
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 be
used in conjunction with a range of UA programs, rather than being
compatible only with a particular UA. When a user wishes to apply
privacy enhancements to an outgoing message, the user prepares the
message's text and invokes the standalone program (interacting with
the program in order to provide address information and other data
required to perform privacy enhancement processing), which in turn
generates output suitable for transmission via the UA. When a user
receives a privacy-enhanced message, the UA delivers the message in
encrypted form, suitable for decryption and associated processing by
the standalone program.
In this prototype implementation, a cache of IKs is maintained in a
local file, with entries managed manually based on pairwise
agreements between originators and recipients. This cache is,
effectively, a simple database. IKs are selected for transmitted
messages based on recipient names, and corresponding IK IDs are
placed into the message's encapsulated header. When a message is
received, the IK ID is used as a basis for a lookup in the database,
yielding the appropriate IK entry. DEKs and IVs are generated
dynamically within the program.
Options (e.g., authentication only vs. authentication with
confidentiality service) are selected by command line arguments to
the standalone program. Destination addresses are specified in the
same fashion. The function of specifying destination addresses to
the privacy enhancement program is logically distinct from the
function of specifying the corresponding addresses to the UA for use
by the MTS. This separation results from the fact that, in many
cases, the local form of an address as specified to a UA differs from
the Internet global form as used for IK ID fields.
8 Areas For Further Study
The procedures defined in this RFCare sufficient to support pilot
implementation of privacy-enhanced electronic mail transmission among
cooperating parties in the Internet. Further effort will be needed,
however, to enhance robustness, generality, and interoperability. In
particular, further work is needed in the following areas:
1. User naming techniques, and their relationship to the domain
system, name servers, directory services, and key management
functions
2. Standardization of Issuing Authority functions, including
protocols for communications among IAs and between User Agents
and IAs
3. Use of public key encryption algorithms to encrypt data
encrypting keys
4. Interoperability with X.400 mail
We anticipate generation of subsequent RFCs which will address these
topics.
9 References
This section identifies background references which may be useful to
those contemplating use of the mechanisms defined in this RFC.
ISO 7498/Part 2 - Security Architecture, prepared by ISO.TC97/SC
21/WG 1 Ad hoc group on Security, extends the OSI Basic
Reference Model to cover security aspects which are general
architectural elements of communications protocols, and
provides an annex with tutorial and background information.
US Federal Information Processing Standards Publication (FIPS PUB)
46, Data Encryption Standard, 15 January 1977, defines the
encipherment algorithm used for message text encryption and
MAC computation.
FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
specific modes in which the Data Encryption Standard algorithm
is to be used to perform encryption and MAC computation.
NOTES:
[1] Information Processing Systems: Data Encipherment: Block
Cipher Algorithm DEA 1.
[2] Federal Information Processing Standards Publication 46, Data
Encryption Standard, 15 January 1977.
[3] Information Processing Systems: Data Encipherment: Modes of
Operation of a 64-bit Block Cipher
[4] Federal Information Processing Standards Publication 81, DES
Modes of Operation, 2 December 1980.
[5] Addendum to the Transport Layer Protocol Definition for
Providing Connection Oriented End to End Cryptographic Data
Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft of
19 December 1985, Gaithersburg, MD, p. 15.
[6] This transformation should occur only at an SMTP endpoint, not
at an intervening relay, but may take place at a gateway
system linking the SMTP realm with other environments.
[7] Crocker, D. Standard for the Format of ARPA Internet Text
Messages (RFC822), August 1982.
[8] Rose, M. T., and Stefferud, E. A., Proposed Standard for
Message Encapsulation, January 1985.
[9] Key generation for authentication and message text encryption
may either be performed by the sending host or by a
centralized server. This RFCdoes not constrain this design
alternative. Section 5.1.1 identifies possible advantages of
a centralized server approach.
[10] Note that in the UNIX(tm) system, and possibly in other
environments as well, such a program can be invoked as a
"filter" within an electronic mail UA or a text editor,
simplifying the sequence of operations which must be performed
by the user.