Connected: An Internet Encyclopedia
3. Services, Constraints, and Implications
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1421
Prev: 2. Terminology
Next: 4. Processing of Messages
3. Services, Constraints, and Implications
3. Services, Constraints, and Implications
This RFC defines mechanisms to enhance privacy for electronic mail
transferred in the Internet. The facilities discussed in this RFC
provide privacy enhancement services on an end-to-end basis between
originator and recipient processes residing at the UA level or above.
No privacy enhancements are offered for message fields which are
added or transformed by intermediate relay points between PEM
processing components.
If an originator elects to perform PEM processing on an outbound
message, all PEM-provided security services are applied to the PEM
message's body in its entirety; selective application to portions of
a PEM message is not supported. Authentication, integrity, and (when
asymmetric key management is employed) non-repudiation of origin
services are applied to all PEM messages; confidentiality services
are optionally selectable.
In keeping with the Internet's heterogeneous constituencies and usage
modes, the measures defined here are applicable to a broad range of
Internet hosts and usage paradigms. In particular, it is worth
noting the following attributes:
- The mechanisms defined in this RFC are not restricted to a
particular host or operating system, but rather allow
interoperability among a broad range of systems. All
privacy enhancements are implemented at the application
layer, and are not dependent on any privacy features at
lower protocol layers.
- The defined mechanisms are compatible with non-enhanced
Internet components. Privacy enhancements are implemented
in an end-to-end fashion which does not impact mail
processing by intermediate relay hosts which do not
incorporate privacy enhancement facilities. It is
necessary, however, for a message's originator to be
cognizant of whether a message's intended recipient
implements privacy enhancements, in order that encoding and
possible encryption will not be performed on a message whose
destination is not equipped to perform corresponding inverse
transformations. (Section 4.6.1.1.3 of this RFC describes a
PEM message type ("MIC-CLEAR") which represents a signed,
unencrypted PEM message in a form readable without PEM
processing capabilities yet validatable by PEM-equipped
recipients.)
- The defined mechanisms are compatible with a range of mail
transport facilities (MTAs). Within the Internet,
electronic mail transport is effected by a variety of SMTP
[2] implementations. Certain sites, accessible via SMTP,
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must be
able to operate across the SMTP realm; it is desirable that
they also be compatible with protection of electronic mail
sent between the SMTP environment and other connected
environments.
- The defined mechanisms are compatible with a broad range of
electronic mail user agents (UAs). A large variety of
electronic mail user agent programs, with a corresponding
broad range of user interface paradigms, is used in the
Internet. In order that electronic mail privacy
enhancements be available to the broadest possible user
community, selected mechanisms should be usable with the
widest possible variety of existing UA programs. For
purposes of pilot implementation, it is desirable that
privacy enhancement processing be incorporable into a
separate program, applicable to a range of UAs, rather than
requiring internal modifications to each UA with which PEM
services are to be provided.
- The defined mechanisms allow electronic mail privacy
enhancement processing to be performed on personal computers
(PCs) separate from the systems on which UA functions are
implemented. Given the expanding use of PCs and the limited
degree of trust which can be placed in UA implementations on
many multi-user systems, this attribute can allow many users
to process PEM with a higher assurance level than a strictly
UA-integrated approach would allow.
- The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists (distribution
lists, in ISO parlance).
- The mechanisms defined within this RFC are compatible with a
variety of supporting key management approaches, including
(but not limited to) manual pre-distribution, centralized
key distribution based on symmetric cryptography, and the
use of public-key certificates per RFC 1422. Different
key management mechanisms may be used for different
recipients of a multicast message. For two PEM
implementations to interoperate, they must share a common
key management mechanism; support for the mechanism defined
in RFC 1422 is strongly encouraged.
In order to achieve applicability to the broadest possible range of
Internet hosts and mail systems, and to facilitate pilot
implementation and testing without the need for prior and pervasive
modifications throughout the Internet, the following design
principles were applied in selecting the set of features specified in
this RFC:
- This RFC's measures are restricted to implementation at
endpoints and are amenable to integration with existing
Internet mail protocols at the user agent (UA) level or
above, rather than necessitating modifications to existing
mail protocols or integration into the message transport
system (e.g., SMTP servers).
- The set of supported measures enhances rather than restricts
user capabilities. Trusted implementations, incorporating
integrity features protecting software from subversion by
local users, cannot be assumed in general. No mechanisms
are assumed to prevent users from sending, at their
discretion, messages to which no PEM processing has been
applied. In the absence of such features, it appears more
feasible to provide facilities which enhance user services
(e.g., by protecting and authenticating inter-user traffic)
than to enforce restrictions (e.g., inter-user access
control) on user actions.
- The set of supported measures focuses on a set of functional
capabilities selected to provide significant and tangible
benefits to a broad user community. By concentrating on the
most critical set of services, we aim to maximize the added
privacy value that can be provided with a modest level of
implementation effort.
Based on these principles, the following facilities are provided:
- disclosure protection,
- originator authenticity,
- message integrity measures, and
- (if asymmetric key management is used) non-repudiation of
origin,
but the following privacy-relevant concerns are not addressed:
- access control,
- traffic flow confidentiality,
- address list accuracy,
- routing control,
- issues relating to the casual serial reuse of PCs by
multiple users,
- assurance of message receipt and non-deniability of receipt,
- automatic association of acknowledgments with the messages
to which they refer, and
- message duplicate detection, replay prevention, or other
stream-oriented services
Next: 4. Processing of Messages
Connected: An Internet Encyclopedia
3. Services, Constraints, and Implications