Professional Documents
Culture Documents
Linn
Request for Comments: 1113 DEC
Obsoletes RFCs: 989, 1040 IAB Privacy Task Force
August 1989
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
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
1. Executive Summary
Linn [Page 2]
RFC 1113 Mail Privacy: Procedures August 1989
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.
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.
Linn [Page 3]
RFC 1113 Mail Privacy: Procedures August 1989
Linn [Page 4]
RFC 1113 Mail Privacy: Procedures August 1989
Linn [Page 5]
RFC 1113 Mail Privacy: Procedures August 1989
1. disclosure protection,
2. sender authenticity,
1. access control,
4. routing control,
Linn [Page 6]
RFC 1113 Mail Privacy: Procedures August 1989
stream-oriented services.
4. Processing of Messages
Linn [Page 7]
RFC 1113 Mail Privacy: Procedures August 1989
Linn [Page 8]
RFC 1113 Mail Privacy: Procedures August 1989
For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined
in ANSI X3.92-1981 [2] shall be used for encryption of message text.
The DEA-1 is equivalent to the Data Encryption Standard (DES), as
defined in FIPS PUB 46 [3]. When used for encryption of text, the
DEA-1 shall be used in the Cipher Block Chaining (CBC) mode, as
defined in ISO IS 8372 [4]. The identifier string "DES-CBC", defined
in RFC-1115, signifies this algorithm/mode combination. The CBC mode
definition in IS 8372 is equivalent to that provided in FIPS PUB 81
[5] and in ANSI X3.106-1983 [16]. Use of other algorithms and/or
modes for message text processing will require case-by-case study to
determine applicability and constraints. Additional algorithms and
modes approved for use in this context will be specified in
successors to RFC-1115.
Linn [Page 9]
RFC 1113 Mail Privacy: Procedures August 1989
4.3.1 Constraints
4.3.2 Approach
The regions of the message which have not been excluded from
encryption are encrypted. To support selective encipherment
processing, an implementation must retain internal indications of the
positions of excluded areas excluded from encryption with relation to
non-excluded areas, so that those areas can be properly delimited in
the encoding procedure defined in step 4. If a region excluded from
encryption intervenes between encrypted regions, cryptographic state
(e.g., IVs and accumulation of octets into encryption quanta) is
preserved and continued after the excluded region.
Proceeding from left to right, the bit string resulting from step 3
is encoded into characters which are universally representable at all
sites, though not necessarily with the same bit patterns (e.g.,
although the character "E" is represented in an ASCII-based system as
hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the
local significance of the two representations is equivalent). This
encoding step is performed for all privacy-enhanced messages, even if
an entire message is excluded from encryption.
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
Note that the local form and the functions to transform messages to
and from canonical form may vary between the sender and recipient
systems without loss of information.
Blank Line
(Separates Enclosing Header from Encapsulated Message)
Encapsulated Message
Blank Line
(Separates Encapsulated Header from subsequent encoded
Encapsulated Text Portion)
Message Encapsulation
Figure 1
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Key-Info: RSA,
lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
X-Recipient-ID: privacy-tf@venera.isi.edu:RSADSI:4
X-Key-Info: RSA,
NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
The second subfield may assume one of two string values: "ENCRYPTED"
or "MIC-ONLY". Unless all of a message's encapsulated text is
excluded from encryption, the "X-Proc-Type:" field's second subfield
must specify "ENCRYPTED". Specification of "MIC-ONLY", when applied
in conjunction with certain combinations of key management and MIC
algorithm options, permits certain fields which are superfluous in
the absence of encryption to be omitted from the encapsulated header.
In particular, "X-Recipient-ID:" and "X-Key-Info:" fields can be
omitted for recipients for whom asymmetric cryptography is used,
assuming concurrent use of a keyless MIC computation algorithm. The
"X-DEK-Info:" field can be omitted for all "MIC-ONLY" messages.
Throughout this RFC we have adopted the terms "private component" and
"public component" to refer to the quantities which are,
respectively, kept secret and made publically available in asymmetric
cryptosystems. This convention is adopted to avoid possible
confusion arising from use of the term "secret key" to refer to
either the former quantity or to a key in a symmetric cryptosystem.
5. Key Management
Data Encrypting Keys (DEKs) are used for encryption of message text
and (with some MIC computation algorithms) for computation of message
integrity check quantities (MICs). It is strongly recommended that
DEKs be generated and used on a one-time, per-message, basis. A
transmitted message will incorporate a representation of the DEK
encrypted under an appropriate interchange key (IK) for each of the
named recipients.
Interchange Key (IK) components are used to encrypt DEKs and MICs.
While this RFC does not prescribe the means by which interchange keys
are provided to appropriate parties, it is useful to note that such
means may be centralized (e.g., via key management servers) or
decentralized (e.g., via pairwise agreement and direct distribution
among users). In any case, any given IK component is associated with
a responsible Issuing Authority (IA). When certificate-based
asymmetric key management, as discussed in RFC-1114, is employed, the
IA function is performed by a Certification Authority (CA).
3. Version/Expiration subfield
IKsubfld := 1*ia-char
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2
<user>@<domain-qualified-host>
6. User Naming
functions.
9. References
NOTES:
[1] Key generation for MIC computation and message text encryption
may either be performed by the sending host or by a centralized
server. This RFC does not constrain this design alternative.
Section 5.1 identifies possible advantages of a centralized
server approach if symmetric key management is employed.
[10] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC-822, August 1982.
[14] Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June
1986.
Author's Address
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
Phone: 508-264-5491
EMail: Linn@ultra.enet.dec.com