📄 rfc1113.txt
字号:
Network Working Group J. Linn
Request for Comments: 1113 DEC
Obsoletes RFCs: 989, 1040 IAB Privacy Task Force
August 1989
Privacy Enhancement for Internet Electronic Mail:
Part I -- Message Encipherment and Authentication Procedures
STATUS OF THIS MEMO
This RFC suggests a draft standard elective protocol for the Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of IAB Privacy Task Force
meetings and of internal working papers distributed for those
meetings. I would like to thank the following Privacy Task Force
members and meeting guests for their comments and contributions at
the meetings which led to the preparation of this RFC: David
Balenson, Curt Barker, Jim Bidzos, Matt Bishop, Danny Cohen, Tom
Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve Kent
(chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob
Shirey, Miles Smid, Steve Walker, and Steve Wilbur.
Table of Contents
1. Executive Summary 2
2. Terminology 3
3. Services, Constraints, and Implications 3
4. Processing of Messages 7
4.1 Message Processing Overview 7
4.1.1 Types of Keys 7
4.1.2 Processing Procedures 8
4.2 Encryption Algorithms and Modes 9
4.3 Privacy Enhancement Message Transformations 10
4.3.1 Constraints 10
4.3.2 Approach 11
4.3.2.1 Step 1: Local Form 12
4.3.2.2 Step 2: Canonical Form 12
4.3.2.3 Step 3: Authentication and Encipherment 12
4.3.2.4 Step 4: Printable Encoding 13
4.3.2.5 Summary of Transformations 15
4.4 Encapsulation Mechanism 15
4.5 Mail for Mailing Lists 17
4.6 Summary of Encapsulated Header Fields 18
Linn [Page 1]
RFC 1113 Mail Privacy: Procedures August 1989
4.6.1 Per-Message Encapsulated Header Fields 20
4.6.1.1 X-Proc-Type Field 20
4.6.1.2 X-DEK-Info Field 21
4.6.2 Encapsulated Header Fields Normally Per-Message 21
4.6.2.1 X-Sender-ID Field 22
4.6.2.2 X-Certificate Field 22
4.6.2.3 X-MIC-Info Field 23
4.6.3 Encapsulated Header Fields with Variable Occurrences 23
4.6.3.1 X-Issuer-Certificate Field 23
4.6.4 Per-Recipient Encapsulated Header Fields 24
4.6.4.1 X-Recipient-ID Field 24
4.6.4.2 X-Key-Info Field 24
4.6.4.2.1 Symmetric Key Management 24
4.6.4.2.2 Asymmetric Key Management 25
5. Key Management 26
5.1 Data Encrypting Keys (DEKs) 26
5.2 Interchange Keys (IKs) 26
5.2.1 Subfield Definitions 28
5.2.1.1 Entity Identifier Subfield 28
5.2.1.2 Issuing Authority Subfield 29
5.2.1.3 Version/Expiration Subfield 29
5.2.2 IK Cryptoperiod Issues 29
6. User Naming 29
6.1 Current Approach 29
6.2 Issues for Consideration 30
7. Example User Interface and Implementation 30
8. Areas For Further Study 31
9. References 32
NOTES 32
1. Executive Summary
This RFC defines message encipherment and authentication procedures,
in order to provide privacy enhancement services for electronic mail
transfer in the Internet. It is one member of a related set of four
RFCs. The procedures defined in the current RFC are intended to be
compatible with a wide range of key management approaches, including
both symmetric (secret-key) and asymmetric (public-key) approaches
for encryption of data encrypting keys. Use of symmetric
cryptography for message text encryption and/or integrity check
computation is anticipated. RFC-1114 specifies supporting key
management mechanisms based on the use of public-key certificates.
RFC-1115 specifies algorithm and related information relevant to the
current RFC and to RFC-1114. A subsequent RFC will provide details
of paper and electronic formats and procedures for the key management
infrastructure being established in support of these services.
Privacy enhancement services (confidentiality, authentication, and
Linn [Page 2]
RFC 1113 Mail Privacy: Procedures August 1989
message integrity assurance) are offered through the use of end-to-
end cryptography between originator and recipient User Agent
processes, with no special processing requirements imposed on the
Message Transfer System at endpoints or at intermediate relay sites.
This approach allows privacy enhancement facilities to be
incorporated on a site-by-site or user-by-user basis without impact
on other Internet entities. Interoperability among heterogeneous
components and mail transport facilities is supported.
2. Terminology
For descriptive purposes, this RFC uses some terms defined in the OSI
X.400 Message Handling System Model per the 1984 CCITT
Recommendations. This section replicates a 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 may not be familiar with
the OSI MHS Model.
In the MHS model, a user is a person or a computer application. A
user is referred to as either an originator (when sending a message)
or a recipient (when receiving one). MH Service elements define the
set of message types and the capabilities that enable an originator
to transfer messages of those types to one or more recipients.
An originator prepares messages with the assistance of his or her
User Agent (UA). A UA is an application process that interacts with
the Message Transfer System (MTS) to submit messages. The MTS
delivers to one or more recipient UAs the messages submitted to it.
Functions performed solely by the UA and not standardized as part of
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 the
intended recipient UAs, which then make the messages available to the
intended recipients.
The collection of UAs and MTAs is called the Message Handling System
(MHS). The MHS and all of its users are collectively referred to as
the Message Handling Environment.
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
sender and recipient UAs. No privacy enhancements are offered for
message fields which are added or transformed by intermediate relay
points.
Linn [Page 3]
RFC 1113 Mail Privacy: Procedures August 1989
Authentication and integrity facilities are always applied to the
entirety of a message's text. No facility for confidentiality
without authentication is provided. Encryption facilities may be
applied selectively to portions of a message's contents; this allows
less sensitive portions of messages (e.g., descriptive fields) to be
processed by a recipient's delegate in the absence of the recipient's
personal cryptographic keys. In the limiting case, where the
entirety of message text is excluded from encryption, this feature
can be used to yield the effective combination of authentication and
integrity services without confidentiality.
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 sender to be cognizant
of whether a message's intended recipient implements privacy
enhancements, in order that encoding and possible
encipherment will not be performed on a message whose
destination is not equipped to perform corresponding inverse
transformations.
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
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
Linn [Page 4]
RFC 1113 Mail Privacy: Procedures August 1989
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
privacy-enhanced 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 privacy-enhanced mail with a higher assurance
level than a strictly UA-based 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. Different key management
mechanisms may be used for different recipients of a
multicast message. While support for a particular key
management mechanism is not a minimum essential requirement
for compatibility with this RFC, adoption of the public-key
certificate approach defined in companion RFC-1114 is
strongly recommended.
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 modifications
throughout the Internet, three basic restrictions are imposed on the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -