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:

1. The mechanisms defined in this RFC are not restricted to a particular host or operating system, but rather allow interoperability among a broad range of systems. All privacy enhancements are implemented at the application layer, and are not dependent on any privacy features at lower protocol layers.

2. The defined mechanisms are compatible with non-enhanced Internet components. Privacy enhancements are implemented in an end-to-end fashion which does not impact mail processing by intermediate relay hosts which do not incorporate privacy enhancement facilities. It is necessary, however, for a message's 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.)

3. The defined mechanisms are compatible with a range of mail transport facilities (MTAs). Within the Internet, electronic mail transport is effected by a variety of SMTP [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.

4. 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.

5. The defined mechanisms allow electronic mail privacy enhancement processing to be performed on personal computers (PCs) separate from the systems on which UA functions are implemented. Given the expanding use of PCs and the limited degree of trust which can be placed in UA implementations on many multi-user systems, this attribute can allow many users to process PEM with a higher assurance level than a strictly UA-integrated approach would allow.

6. The defined mechanisms support privacy protection of electronic mail addressed to mailing lists (distribution lists, in ISO parlance).

7. 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:

1. 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).

2. The set of supported measures enhances rather than restricts user capabilities. Trusted implementations, incorporating integrity features protecting software from subversion by local users, cannot be assumed in general. 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.

3. The set of supported measures focuses on a set of functional capabilities selected to provide significant and tangible benefits to a broad user community. By concentrating on the most critical set of services, we aim to maximize the added privacy value that can be provided with a modest level of implementation effort.

Based on these principles, the following facilities are provided:

1. disclosure protection,

2. originator authenticity,

3. message integrity measures, and

4. (if asymmetric key management is used) non-repudiation of origin,

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 casual serial reuse of PCs by multiple users,

6. assurance of message receipt and non-deniability of receipt,

7. automatic association of acknowledgments with the messages to which they refer, and

8. message duplicate detection, replay prevention, or other stream-oriented services