diff options
Diffstat (limited to 'doc/rfc/rfc1113.txt')
| -rw-r--r-- | doc/rfc/rfc1113.txt | 1907 |
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc1113.txt b/doc/rfc/rfc1113.txt new file mode 100644 index 0000000..b4301cc --- /dev/null +++ b/doc/rfc/rfc1113.txt @@ -0,0 +1,1907 @@ + + + + + + +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 + set of measures to be considered in this RFC: + + 1. Measures will be restricted to implementation at endpoints + and will be amenable to integration at the user agent (UA) + level or above, rather than necessitating integration into + the message transport system (e.g., SMTP servers). + + + + +Linn [Page 5] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + 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. 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. + + As a result of these restrictions, the following facilities can be + provided: + + 1. disclosure protection, + + 2. sender 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 + + + +Linn [Page 6] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + stream-oriented services. + + A message's sender will determine whether privacy enhancements are to + be performed on a particular message. Therefore, a sender must be + able to determine whether particular recipients are equipped to + process privacy-enhanced mail. In a general architecture, these + mechanisms will be based on server queries; thus, the query function + could be integrated into a UA to avoid imposing burdens or + inconvenience on electronic mail users. + +4. Processing of Messages + +4.1 Message Processing Overview + + This subsection provides a high-level overview of the components and + processing steps involved in electronic mail privacy enhancement + processing. Subsequent subsections will define the procedures in + more detail. + +4.1.1 Types of Keys + + A two-level keying hierarchy is used to support privacy-enhanced + message transmission: + + 1. Data Encrypting Keys (DEKs) are used for encryption of + message text and (with certain choices among a set of + alternative algorithms) for computation of message integrity + check (MIC) quantities. DEKs are generated individually for + each transmitted message; no predistribution of DEKs is + needed to support privacy-enhanced message transmission. + + 2. Interchange Keys (IKs) are used to encrypt DEKs for + transmission within messages. Ordinarily, the same IK will + be used for all messages sent from a given originator to a + given recipient over a period of time. Each transmitted + message includes a representation of the DEK(s) used for + message encryption and/or MIC computation, encrypted under + an individual IK per named recipient. The representation is + associated with "X-Sender-ID:" and "X-Recipient-ID:" fields, + which allow each individual recipient to identify the IK + used to encrypt DEKs and/or MICs for that recipient's use. + Given an appropriate IK, a recipient can decrypt the + corresponding transmitted DEK representation, yielding the + DEK required for message text decryption and/or MIC + verification. The definition of an IK differs depending on + whether symmetric or asymmetric cryptography is used for DEK + encryption: + + + + +Linn [Page 7] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + 2a. When symmetric cryptography is used for DEK + encryption, an IK is a single symmetric key shared + between an originator and a recipient. In this + case, the same IK is used to encrypt MICs as well + as DEKs for transmission. Version/expiration + information and IA identification associated with + the originator and with the recipient must be + concatenated in order to fully qualify a symmetric + IK. + + 2b. When asymmetric cryptography is used, the IK + component used for DEK encryption is the public + component of the recipient. The IK component used + for MIC encryption is the private component of the + originator, and therefore only one encrypted MIC + representation need be included per message, rather than + one per recipient. Each of these IK + components can be fully qualified in an + "X-Recipient-ID:" or "X-Sender-ID:" field, + respectively. + +4.1.2 Processing Procedures + + When privacy enhancement processing is to be performed on an outgoing + message, a DEK is generated [1] for use in message encryption and (if + a chosen MIC algorithm requires a key) a variant of the DEK is formed + for use in MIC computation. DEK generation can be omitted for the + case of a message in which all contents are excluded from encryption, + unless a chosen MIC computation algorithm requires a DEK. + + An "X-Sender-ID:" field is included in the header to provide one + identification component for the IK(s) used for message processing. + IK components are selected for each individually named recipient; a + corresponding "X-Recipient-ID:" field, interpreted in the context of + a prior "X-Sender-ID:" field, serves to identify each IK. Each "X- + Recipient-ID:" field is followed by an "X-Key-Info:" field, which + transfers a DEK encrypted under the IK appropriate for the specified + recipient. When symmetric key management is used for a given + recipient, the "X-Key-Info:" field also transfers the message's + computed MIC, encrypted under the recipient's IK. When asymmetric + key management is used, a prior "X-MIC-Info:" field carries the + message's MIC encrypted under the private component of the sender. + + A four-phase transformation procedure is employed in order to + represent encrypted message text in a universally transmissible form + and to enable messages encrypted on one type of host computer to be + decrypted on a different type of host computer. A plaintext message + is accepted in local form, using the host's native character set and + + + +Linn [Page 8] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + line representation. The local form is converted to a canonical + message text representation, defined as equivalent to the inter-SMTP + representation of message text. This canonical representation forms + the input to the MIC computation and encryption processes. + + For encryption purposes, the canonical representation is padded as + required by the encryption algorithm. The padded canonical + representation is encrypted (except for any regions which are + explicitly excluded from encryption). The encrypted text (along with + the canonical representation of regions which were excluded from + encryption) is encoded into a printable form. The printable form is + composed of a restricted character set which is chosen to be + universally representable across sites, and which will not be + disrupted by processing within and between MTS entities. + + The output of the encoding procedure is combined with a set of header + fields carrying cryptographic control information. The result is + passed to the electronic mail system to be encapsulated as the text + portion of a transmitted message. + + When a privacy-enhanced message is received, the cryptographic + control fields within its text portion provide the information + required for the authorized recipient to perform MIC verification and + decryption of the received message text. First, the printable + encoding is converted to a bitstring. Encrypted portions of the + transmitted message are decrypted. The MIC is verified. The + canonical representation is converted to the recipient's local form, + which need not be the same as the sender's local form. + +4.2 Encryption Algorithms and Modes + + 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. + + It is an originator's responsibility to generate a new pseudorandom + initializing vector (IV) for each privacy-enhanced electronic mail + message unless the entirety of the message is excluded from + + + +Linn [Page 9] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + encryption. Section 4.3.1 of [17] provides rationale for this + requirement, even in a context where individual DEKs are generated + for individual messages. The IV will be transmitted with the + message. + + Certain operations require that one key be encrypted under an + interchange key (IK) for purposes of transmission. A header facility + indicates the mode in which the IK is used for encryption. RFC-1115 + specifies encryption algorithm/mode identifiers, including DES-ECB, + DES-EDE, and RSA. All implementations using symmetric key management + should support DES-ECB IK use, and all implementations using + asymmetric key management should support RSA IK use. + + RFC-1114, released concurrently with this RFC, specifies asymmetric, + certificate-based key management procedures to support the message + processing procedures defined in this document. The message + processing procedures can also be used with symmetric key management, + given prior distribution of suitable symmetric IKs through out-of- + band means. Support for the asymmetric approach defined in RFC-1114 + is strongly recommended. + +4.3 Privacy Enhancement Message Transformations + +4.3.1 Constraints + + An electronic mail encryption mechanism must be compatible with the + transparency constraints of its underlying electronic mail + facilities. These constraints are generally established based on + expected user requirements and on the characteristics of anticipated + endpoint and transport facilities. An encryption mechanism must also + be compatible with the local conventions of the computer systems + which it interconnects. In our approach, a canonicalization step is + performed to abstract out local conventions and a subsequent encoding + step is performed to conform to the characteristics of the underlying + mail transport medium (SMTP). The encoding conforms to SMTP + constraints, established to support interpersonal messaging. SMTP's + rules are also used independently in the canonicalization process. + RFC-821's [7] Section 4.5 details SMTP's transparency constraints. + + To prepare a message for SMTP transmission, the following + requirements must be met: + + 1. All characters must be members of the 7-bit ASCII character + set. + + 2. Text lines, delimited by the character pair <CR><LF>, must + be no more than 1000 characters long. + + + + +Linn [Page 10] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + 3. Since the string <CR><LF>.<CR><LF> indicates the end of a + message, it must not occur in text prior to the end of a + message. + + Although SMTP specifies a standard representation for line delimiters + (ASCII <CR><LF>), numerous systems use a different native + representation to delimit lines. For example, the <CR><LF> sequences + delimiting lines in mail inbound to UNIX systems are transformed to + single <LF>s as mail is written into local mailbox files. Lines in + mail incoming to record-oriented systems (such as VAX VMS) may be + converted to appropriate records by the destination SMTP [8] server. + As a result, if the encryption process generated <CR>s or <LF>s, + those characters might not be accessible to a recipient UA program at + a destination which uses different line delimiting conventions. It + is also possible that conversion between tabs and spaces may be + performed in the course of mapping between inter-SMTP and local + format; this is a matter of local option. If such transformations + changed the form of transmitted ciphertext, decryption would fail to + regenerate the transmitted plaintext, and a transmitted MIC would + fail to compare with that computed at the destination. + + The conversion performed by an SMTP server at a system with EBCDIC as + a native character set has even more severe impact, since the + conversion from EBCDIC into ASCII is an information-losing + transformation. In principle, the transformation function mapping + between inter-SMTP canonical ASCII message representation and local + format could be moved from the SMTP server up to the UA, given a + means to direct that the SMTP server should no longer perform that + transformation. This approach has a major disadvantage: internal + file (e.g., mailbox) formats would be incompatible with the native + forms used on the systems where they reside. Further, it would + require modification to SMTP servers, as mail would be passed to SMTP + in a different representation than it is passed at present. + +4.3.2 Approach + + Our approach to supporting privacy-enhanced mail across an + environment in which intermediate conversions may occur encodes mail + in a fashion which is uniformly representable across the set of + privacy-enhanced UAs regardless of their systems' native character + sets. This encoded form is used to represent mail text from sender + to recipient, but the encoding is not applied to enclosing mail + transport headers or to encapsulated headers inserted to carry + control information between privacy-enhanced UAs. The encoding's + characteristics are such that the transformations anticipated between + sender and recipient UAs will not prevent an encoded message from + being decoded properly at its destination. + + + + +Linn [Page 11] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + A sender may exclude one or more portions of a message from + encryption processing, but authentication processing is always + applied to the entirety of message text. Explicit action is required + to exclude a portion of a message from encryption processing; by + default, encryption is applied to the entirety of message text. The + user-level delimiter which specifies such exclusion is a local + matter, and hence may vary between sender and recipient, but all + systems should provide a means for unambiguous identification of + areas excluded from encryption processing. + + An outbound privacy-enhanced message undergoes four transformation + steps, described in the following four subsections. + +4.3.2.1 Step 1: Local Form + + The message text is created in the system's native character set, + with lines delimited in accordance with local convention. + +4.3.2.2 Step 2: Canonical Form + + The entire message text, including both those portions subject to + encipherment processing and those portions excluded from such + processing, is converted to a universal canonical form, analogous to + the inter-SMTP representation [9] as defined in RFC-821 and RFC-822 + [10] (ASCII character set, <CR><LF> line delimiters). The processing + required to perform this conversion is minimal on systems whose + native character set is ASCII. (Note: Since the output of the + canonical encoding process will never be submitted directly to SMTP, + but only to subsequent steps of the privacy enhancement encoding + process, the dot-stuffing transformation discussed in RFC-821, + section 4.5.2, is not required.) Since a message is converted to a + standard character set and representation before encryption, it can + be decrypted and its MIC can be verified at any type of destination + host computer. The decryption and MIC verification is performed + before any conversions which may be necessary to transform the + message into a destination-specific local form. + +4.3.2.3 Step 3: Authentication and Encipherment + + The canonical form is input to the selected MIC computation algorithm + in order to compute an integrity check quantity for the message. No + padding is added to the canonical form before submission to the MIC + computation algorithm, although certain MIC algorithms will apply + their own padding in the course of computing a MIC. + + Padding is applied to the canonical form as needed to perform + encryption in the DEA-1 CBC mode, as follows: The number of octets to + be encrypted is determined by subtracting the number of octets + + + +Linn [Page 12] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + excluded from encryption from the total length of the canonically + encoded text. Octets with the hexadecimal value FF (all ones) are + appended to the canonical form as needed so that the text octets to + be encrypted, along with the added padding octets, fill an integral + number of 8-octet encryption quanta. No padding is applied if the + number of octets to be encrypted is already an integral multiple of + 8. The use of hexadecimal FF (a value outside the 7-bit ASCII set) + as a padding value allows padding octets to be distinguished from + valid data without inclusion of an explicit padding count indicator. + + 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. + +4.3.2.4 Step 4: Printable Encoding + + 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. + + A 64-character subset of International Alphabet IA5 is used, enabling + 6 bits to be represented per printable character. (The proposed + subset of characters is represented identically in IA5 and ASCII.) + Two additional characters, "=" and "*", are used to signify special + processing functions. The character "=" is used for padding within + the printable encoding procedure. The character "*" is used to + delimit the beginning and end of a region which has been excluded + from encipherment processing. The encoding function's output is + delimited into text lines (using local conventions), with each line + except the last containing exactly 64 printable characters and the + final line containing 64 or fewer printable characters. (This line + length is easily printable and is guaranteed to satisfy SMTP's 1000- + character transmitted line length limit.) + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right across + a 24-bit input group extracted from the output of step 3, each 6-bit + + + +Linn [Page 13] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + group is used as an index into an array of 64 printable characters. + The character referenced by the index is placed in the output string. + These characters, identified in Table 0, are selected so as to be + universally representable, and the set excludes characters with + particular significance to SMTP (e.g., ".", "<CR>", "<LF>"). + + Special processing is performed if fewer than 24 bits are available + in an input group, either at the end of a message or (when the + selective encryption facility is invoked) at the end of an encrypted + region or an excluded region. A full encoding quantum is always + completed at the end of a message and before the delimiter "*" is + output to initiate or terminate the representation of a block + excluded from encryption. When fewer than 24 input bits are + available in an input group, zero bits are added (on the right) to + form an integral number of 6-bit groups. Output character positions + which are not required to represent actual input data are set to the + character "=". Since all canonically encoded output is an integral + number of octets, only the following cases can arise: (1) the final + quantum of encoding input is an integral multiple of 24 bits; here, + the final unit of encoded output will be an integral multiple of 4 + characters with no "=" padding, (2) the final quantum of encoding + input is exactly 8 bits; here, the final unit of encoded output will + be two characters followed by two "=" padding characters, or (3) the + final quantum of encoding input is exactly 16 bits; here, the final + unit of encoded output will be three characters followed by one "=" + padding character. + + + + + + + + + + + + + + + + + + + + + + + + + +Linn [Page 14] + +RFC 1113 Mail Privacy: Procedures August 1989 + + +4.3.2.5 Summary of Transformations + + In summary, the outbound message is subjected to the following + composition of transformations: + + Transmit_Form = Encode(Encipher(Canonicalize(Local_Form))) + + The inverse transformations are performed, in reverse order, to + process inbound privacy-enhanced mail: + + + Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form))) + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y (1) * + + (1) The character "*" is used to enclose portions of an + encoded message to which encryption processing has not + been applied. + + + Printable Encoding Characters + Table 1 + + + 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. + +4.4 Encapsulation Mechanism + + Encapsulation of privacy-enhanced messages within an enclosing layer + + + +Linn [Page 15] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + of headers interpreted by the electronic mail transport system offers + a number of advantages in comparison to a flat approach in which + certain fields within a single header are encrypted and/or carry + cryptographic control information. Encapsulation provides generality + and segregates fields with user-to-user significance from those + transformed in transit. All fields inserted in the course of + encryption/authentication processing are placed in the encapsulated + header. This facilitates compatibility with mail handling programs + which accept only text, not header fields, from input files or from + other programs. Further, privacy enhancement processing can be + applied recursively. As far as the MTS is concerned, information + incorporated into cryptographic authentication or encryption + processing will reside in a message's text portion, not its header + portion. + + The encapsulation mechanism to be used for privacy-enhanced mail is + derived from that described in RFC-934 [11] which is, in turn, based + on precedents in the processing of message digests in the Internet + community. To prepare a user message for encrypted or authenticated + transmission, it will be transformed into the representation shown in + Figure 1. + + As a general design principle, sensitive data is protected by + incorporating the data within the encapsulated text rather than by + applying measures selectively to fields in the enclosing header. + Examples of potentially sensitive header information may include + fields such as "Subject:", with contents which are significant on an + end-to-end, inter-user basis. The (possibly empty) set of headers to + which protection is to be applied is a user option. It is strongly + recommended, however, that all implementations should replicate + copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the + encapsulated text. + + If a user wishes disclosure protection for header fields, they must + occur only in the encapsulated text and not in the enclosing or + encapsulated header. If disclosure protection is desired for a + message's subject indication, it is recommended that the enclosing + header contain a "Subject:" field indicating that "Encrypted Mail + Follows". + + If an authenticated version of header information is desired, that + data can be replicated within the encapsulated text portion in + addition to its inclusion in the enclosing header. For example, a + sender wishing to provide recipients with a protected indication of a + message's position in a series of messages could include a copy of a + timestamp or message counter field within the encapsulated text. + + A specific point regarding the integration of privacy-enhanced mail + + + +Linn [Page 16] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + facilities with the message encapsulation mechanism is worthy of + note. The subset of IA5 selected for transmission encoding + intentionally excludes the character "-", so encapsulated text can be + distinguished unambiguously from a message's closing encapsulation + boundary (Post-EB) without recourse to character stuffing. + + Enclosing Header Portion + (Contains header fields per RFC-822) + + Blank Line + (Separates Enclosing Header from Encapsulated Message) + + Encapsulated Message + + Pre-Encapsulation Boundary (Pre-EB) + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + + Encapsulated Header Portion + (Contains encryption control fields inserted in plaintext. + Examples include "X-DEK-Info:", "X-Sender-ID:", and + "X-Key-Info:". + Note that, although these control fields have line-oriented + representations similar to RFC-822 header fields, the set + of fields valid in this context is disjoint from those used + in RFC-822 processing.) + + Blank Line + (Separates Encapsulated Header from subsequent encoded + Encapsulated Text Portion) + + Encapsulated Text Portion + (Contains message data encoded as specified in Section 4.3; + may incorporate protected copies of enclosing and + encapsulated header fields such as "Subject:", etc.) + + Post-Encapsulation Boundary (Post-EB) + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + + + Message Encapsulation + Figure 1 + + +4.5 Mail for Mailing Lists + + When mail is addressed to mailing lists, two different methods of + processing can be applicable: the IK-per-list method and the IK-per- + recipient method. The choice depends on the information available to + + + +Linn [Page 17] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + the sender and on the sender's preference. + + If a message's sender addresses a message to a list name or alias, + use of an IK associated with that name or alias as a entity (IK-per- + list), rather than resolution of the name or alias to its constituent + destinations, is implied. Such an IK must, therefore, be available + to all list members. For the case of asymmetric key management, the + list's private component must be available to all list members. This + alternative will be the normal case for messages sent via remote + exploder sites, as a sender to such lists may not be cognizant of the + set of individual recipients. Unfortunately, it implies an + undesirable level of exposure for the shared IK, and makes its + revocation difficult. Moreover, use of the IK-per-list method allows + any holder of the list's IK to masquerade as another sender to the + list for authentication purposes. + + If, in contrast, a message's sender is equipped to expand the + destination mailing list into its individual constituents and elects + to do so (IK-per-recipient), the message's DEK (and, in the symmetric + key management case, MIC) will be encrypted under each per-recipient + IK and all such encrypted representations will be incorporated into + the transmitted message. Note that per-recipient encryption is + required only for the relatively small DEK and MIC quantities carried + in the "X-Key-Info:" field, not for the message text which is, in + general, much larger. Although more IKs are involved in processing + under the IK-per-recipient method, the pairwise IKs can be + individually revoked and possession of one IK does not enable a + successful masquerade of another user on the list. + +4.6 Summary of Encapsulated Header Fields + + This section summarizes the syntax and semantics of the encapsulated + header fields to be added to messages in the course of privacy + enhancement processing. The fields are presented in three groups. + Normally, the groups will appear in encapsulated headers in the order + in which they are shown, though not all fields in each group will + appear in all messages. In certain indicated cases, it is recommended + that the fields be replicated within the encapsulated text portion as + well as being included within the encapsulated header. Figures 2 and + 3 show the appearance of small example encapsulated messages. Figure + 2 assumes the use of symmetric cryptography for key management. + Figure 3 illustrates an example encapsulated message in which + asymmetric key management is used. + + Unless otherwise specified, all field arguments are processed in a + case-sensitive fashion. In most cases, numeric quantities are + represented in header fields as contiguous strings of hexadecimal + digits, where each digit is represented by a character from the + + + +Linn [Page 18] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + ranges "0"-"9" or upper case "A"-"F". Since public-key certificates + and quantities encrypted using asymmetric algorithms are large in + size, use of a more space-efficient encoding technique is appropriate + for such quantities, and the encoding mechanism defined in Section + 4.3.2.4 of this RFC, representing 6 bits per printed character, is + adopted. The example shown in Figure 3 shows asymmetrically + encrypted quantities (e.g., "X-MIC-Info:", "X-Key-Info:") with 64- + character printed representations, corresponding to 384 bits. The + fields carrying asymmetrically encrypted quantities also illustrate + the use of folding as defined in RFC-822, section 3.1.1. + + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + X-Proc-Type: 3,ENCRYPTED + X-DEK-Info: DES-CBC,F8143EDE5960C597 + X-Sender-ID: linn@ccy.bbn.com:: + X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3 + X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD, + A60195DB94F727D3 + X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4 + X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7, + 9F83A2658132DB47 + + LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M + 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk + J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot + dXd/H5LMDWnonNvPCwQUHt== + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + + + Example Encapsulated Message (Symmetric Case) + Figure 2 + + + -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- + X-Proc-Type: 3,ENCRYPTED + X-DEK-Info: DES-CBC,F8143EDE5960C597 + X-Sender-ID: linn@ccy.bbn.com:: + X-Certificate: + jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk + YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz + agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0 + X-Issuer-Certificate: + TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA + IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX + vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp + X-MIC-Info: RSA-MD2,RSA, + 5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz + X-Recipient-ID: linn@ccy.bbn.com:RSADSI:3 + + + +Linn [Page 19] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + 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----- + + Example Encapsulated Message (Asymmetric Case) + Figure 3 + + + Although the encapsulated header fields resemble RFC-822 header + fields, they are a disjoint set and will not in general be processed + by the same parser which operates on enclosing header fields. The + complexity of lexical analysis needed and appropriate for + encapsulated header field processing is significantly less than that + appropriate to RFC-822 header processing. For example, many + characters with special significance to RFC-822 at the syntactic + level have no such significance within encapsulated header fields. + + When the length of an encapsulated header field is longer than the + size conveniently printable on a line, whitespace may be used to fold + the field in the manner of RFC-822, section 3.1.1. Any such inserted + whitespace is not to be interpreted as a part of a subfield. As a + particular example, due to the length of public-key certificates and + of quantities encrypted using asymmetric algorithms, such quantities + may often need to be folded across multiple printed lines. In order + to facilitate such folding in a uniform manner, the bits representing + such a quantity are to be divided into an ordered set (with leftmost + bits first) of zero or more 384-bit groups (corresponding to 64- + character printed representations), followed by a final group of bits + which may be any length up to 384 bits. + +4.6.1 Per-Message Encapsulated Header Fields + + This group of encapsulated header fields contains fields which occur + no more than once in a privacy-enhanced message, generally preceding + all other encapsulated header fields. + +4.6.1.1 X-Proc-Type Field + + The "X-Proc-Type:" encapsulated header field, required for all + privacy-enhanced messages, identifies the type of processing + + + +Linn [Page 20] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + performed on the transmitted message. Only one "X-Proc-Type:" field + occurs in a message; the "X-Proc-Type:" field must be the first + encapsulated header field in the message. + + The "X-Proc-Type:" field has two subfields, separated by a comma. + The first subfield is a decimal number which is used to distinguish + among incompatible encapsulated header field interpretations which + may arise as changes are made to this standard. Messages processed + according to this RFC will carry the subfield value "3" to + distinguish them from messages processed in accordance with prior + RFCs 989 and 1040. + + 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. + +4.6.1.2 X-DEK-Info Field + + The "X-DEK-Info:" encapsulated header field identifies the message + text encryption algorithm and mode, and also carries the Initializing + Vector used for message encryption. No more than one "X-DEK-Info:" + field occurs in a message; the field is required except for messages + specified as "MIC-ONLY" in the "X-Proc-Type:" field. + + The "X-DEK-Info:" field carries two arguments, separated by a comma. + For purposes of this RFC, the first argument must be the string + "DES-CBC", signifying (as defined in RFC-1115) use of the DES + algorithm in the CBC mode. The second argument represents a 64-bit + Initializing Vector (IV) as a contiguous string of 16 hexadecimal + digits. Subsequent revisions of RFC-1115 will specify any additional + values which may appear as the first argument of this field. + +4.6.2 Encapsulated Header Fields Normally Per-Message + + This group of encapsulated header fields contains fields which + ordinarily occur no more than once per message. Depending on the key + management option(s) employed, some of these fields may be absent + from some messages. The "X-Sender-ID" field may occur more than once + in a message if different sender-oriented IK components (perhaps + corresponding to different versions) must be used for different + + + +Linn [Page 21] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + recipients. In this case later occurrences override prior + occurrences. If a mixture of symmetric and asymmetric key + distribution is used within a single message, the recipients for each + type of key distribution technology should be grouped together to + simplify parsing. + +4.6.2.1 X-Sender-ID Field + + The "X-Sender-ID:" encapsulated header field, required for all + privacy-enhanced messages, identifies a message's sender and provides + the sender's IK identification component. It should be replicated + within the encapsulated text. The IK identification component + carried in an "X-Sender-ID:" field is used in conjunction with all + subsequent "X-Recipient-ID:" fields until another "X-Sender-ID:" + field occurs; the ordinary case will be that only a single "X- + Sender-ID:" field will occur, prior to any "X-Recipient-ID:" fields. + + The "X-Sender-ID:" field contains (in order) an Entity Identifier + subfield, an (optional) Issuing Authority subfield, and an (optional) + Version/Expiration subfield. The optional subfields are omitted if + their use is rendered redundant by information carried in subsequent + "X-Recipient-ID:" fields; this will ordinarily be the case where + symmetric cryptography is used for key management. The subfields are + delimited by the colon character (":"), optionally followed by + whitespace. + + Section 5.2, Interchange Keys, discusses the semantics of these + subfields and specifies the alphabet from which they are chosen. + Note that multiple "X-Sender-ID:" fields may occur within a single + encapsulated header. All "X-Recipient-ID:" fields are interpreted in + the context of the most recent preceding "X-Sender-ID:" field; it is + illegal for an "X-Recipient-ID:" field to occur in a header before an + "X-Sender-ID:" has been provided. + +4.6.2.2 X-Certificate Field + + The "X-Certificate:" encapsulated header field is used only when + asymmetric key management is employed for one or more of a message's + recipients. To facilitate processing by recipients (at least in + advance of general directory server availability), inclusion of this + field in all messages is strongly recommended. The field transfers a + sender's certificate as a numeric quantity, represented with the + encoding mechanism defined in Section 4.3.2.4 of this RFC. The + semantics of a certificate are discussed in RFC-1114. The + certificate carried in an "X-Certificate:" field is used in + conjunction with "X-Sender-ID:" and "X-Recipient-ID:" fields for + which asymmetric key management is employed. + + + + +Linn [Page 22] + +RFC 1113 Mail Privacy: Procedures August 1989 + + +4.6.2.3 X-MIC-Info Field + + The "X-MIC-Info:" encapsulated header field, used only when + asymmetric key management is employed for at least one recipient of a + message, carries three arguments, separated by commas. The first + argument identifies the algorithm under which the accompanying MIC is + computed; RFC-1115 specifies the acceptable set of MIC algorithm + identifiers. The second argument identifies the algorithm under + which the accompanying MIC is encrypted; for purposes of this RFC, + the string "RSA" as described in RFC-1115 must occur, identifying + use of the RSA algorithm. The third argument is a MIC, + asymmetrically encrypted using the originator's private component. + As discussed earlier in this section, the asymmetrically encrypted + MIC is represented using the technique described in Section 4.3.2.4 + of this RFC. + + The "X-MIC-Info:" field will occur immediately following the + message's "X-Sender-ID:" field and any "X-Certificate:" or "X- + Issuer-Certificate:" fields. Analogous to the "X-Sender-ID:" field, + an "X-MIC-Info:" field applies to all subsequent recipients for whom + asymmetric key management is used. + +4.6.3 Encapsulated Header Fields with Variable Occurrences + + This group of encapsulated header fields contains fields which will + normally occur variable numbers of times within a message, with + numbers of occurrences ranging from zero to non-zero values which are + independent of the number of recipients. + +4.6.3.1 X-Issuer-Certificate Field + + The "X-Issuer-Certificate:" encapsulated header field is meaningful + only when asymmetric key management is used for at least one of a + message's recipients. A typical "X-Issuer-Certificate:" field would + contain the certificate containing the public component used to sign + the certificate carried in the message's "X-Certificate:" field, for + recipients' use in chaining through that certificate's certification + path. Other "X-Issuer-Certificate:" fields, typically representing + higher points in a certification path, also may be included by a + sender. The order in which "X-Issuer-Certificate:" fields are + included need not correspond to the order of the certification path; + the order of that path may in general differ from the viewpoint of + different recipients. More information on certification paths can be + found in RFC-1114. + + The certificate is represented in the same manner as defined for the + "X-Certificate:" field, and any "X-Issuer-Certificate:" fields will + ordinarily follow the "X-Certificate:" field directly. Use of the + + + +Linn [Page 23] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + "X-Issuer-Certificate:" field is optional even when asymmetric key + management is employed, although its incorporation is strongly + recommended in the absence of alternate directory server facilities + from which recipients can access issuers' certificates. + +4.6.4 Per-Recipient Encapsulated Header Fields + + This group of encapsulated header fields normally appears once for + each of a message's named recipients. As a special case, these + fields may be omitted in the case of a "MIC-ONLY" message to + recipients for whom asymmetric key management is employed, given that + the chosen MIC algorithm is keyless. + +4.6.4.1 X-Recipient-ID Field + + The "X-Recipient-ID:" encapsulated header field identifies a + recipient and provides the recipient's IK identification component. + One "X-Recipient-ID:" field is included for each of a message's named + recipients. It should be replicated within the encapsulated text. + The field contains (in order) an Entity Identifier subfield, an + Issuing Authority subfield, and a Version/Expiration subfield. The + subfields are delimited by the colon character (":"), optionally + followed by whitespace. + + Section 5.2, Interchange Keys, discusses the semantics of the + subfields and specifies the alphabet from which they are chosen. All + "X-Recipient-ID:" fields are interpreted in the context of the most + recent preceding "X-Sender-ID:" field; it is illegal for an "X- + Recipient-ID:" field to occur in a header before an "X-Sender-ID:" + has been provided. + +4.6.4.2 X-Key-Info Field + + One "X-Key-Info:" field is included for each of a message's named + recipients. Each "X-Key-Info:" field is interpreted in the context + of the most recent preceding "X-Recipient-ID:" field; normally, an + "X-Key-Info:" field will immediately follow its associated "X- + Recipient-ID:" field. The field's argument(s) differ depending on + whether symmetric or asymmetric key management is used for a + particular recipient. + +4.6.4.2.1 Symmetric Key Management + + When symmetric key management is employed for a given recipient, the + "X-Key-Info:" encapsulated header field transfers four items, + separated by commas: an IK Use Indicator, a MIC Algorithm Indicator, + a DEK and a MIC. The IK Use Indicator identifies the algorithm and + mode in which the identified IK was used for DEK encryption for a + + + +Linn [Page 24] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + particular recipient. For recipients for whom symmetric key + management is used, it may assume the reserved string values "DES- + ECB" or "DES-EDE", as defined in RFC-1115. + + The MIC Algorithm Indicator identifies the MIC computation algorithm + used for a particular recipient; values for this subfield are defined + in RFC-1115. The DEK and MIC are encrypted under the IK identified + by a preceding "X-Recipient-ID:" field and prior "X-Sender-ID:" + field; they are represented as two strings of contiguous hexadecimal + digits, separated by a comma. + + When DEA-1 is used for message text encryption, the DEK + representation will be 16 hexadecimal digits (corresponding to a 64- + bit key); this subfield can be extended to 32 hexadecimal digits + (corresponding to a 128-bit key) if required to support other + algorithms. + + Symmetric encryption of MICs is always performed in the same + encryption mode used to encrypt the message's DEK. Encrypted MICs, + like encrypted DEKs, are represented as contiguous strings of + hexadecimal digits. The size of a MIC is dependent on the choice of + MIC algorithm as specified in the MIC Algorithm Indicator subfield. + +4.6.4.2.2 Asymmetric Key Management + + When asymmetric key management is employed for a given recipient, the + "X-Key-Info:" field transfers two quantities, separated by commas. + The first argument is an IK Use Indicator identifying the algorithm + (and mode, if applicable) in which the DEK is encrypted; for purposes + of this RFC, the IK Use Indicator subfield will always assume the + reserved string value "RSA" (as defined in RFC-1115) for recipients + for whom asymmetric key management is employed, signifying use of the + RSA algorithm. The second argument is a DEK, encrypted (using + asymmetric encryption) under the recipient's public component. + + 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. + + As discussed earlier in this section, the asymmetrically encrypted + DEK is represented using the technique described in Section 4.3.2.4 + of this RFC. + + + + + + +Linn [Page 25] + +RFC 1113 Mail Privacy: Procedures August 1989 + + +5. Key Management + + Several cryptographic constructs are involved in supporting the + privacy-enhanced message processing procedure. A set of fundamental + elements is assumed. Data Encrypting Keys (DEKs) are used to encrypt + message text and (for some MIC computation algorithms) in the message + integrity check (MIC) computation process. Interchange Keys (IKs) + are used to encrypt DEKs and MICs for transmission with messages. In + a certificate-based asymmetric key management architecture, + certificates are used as a means to provide entities' public + components and other information in a fashion which is securely bound + by a central authority. The remainder of this section provides more + information about these constructs. + +5.1 Data Encrypting Keys (DEKs) + + 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. + + DEK generation can be performed either centrally by key distribution + centers (KDCs) or by endpoint systems. Dedicated KDC systems may be + able to implement stronger algorithms for random DEK generation than + can be supported in endpoint systems. On the other hand, + decentralization allows endpoints to be relatively self-sufficient, + reducing the level of trust which must be placed in components other + than a message's originator and recipient. Moreover, decentralized + DEK generation at endpoints reduces the frequency with which senders + must make real-time queries of (potentially unique) servers in order + to send mail, enhancing communications availability. + + When symmetric cryptography is used, one advantage of centralized + KDC-based generation is that DEKs can be returned to endpoints + already encrypted under the IKs of message recipients rather than + providing the IKs to the senders. This reduces IK exposure and + simplifies endpoint key management requirements. This approach has + less value if asymmetric cryptography is used for key management, + since per-recipient public IK components are assumed to be generally + available and per-sender private IK components need not necessarily + be shared with a KDC. + +5.2 Interchange Keys (IKs) + + Interchange Key (IK) components are used to encrypt DEKs and MICs. + + + +Linn [Page 26] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + In general, IK granularity is at the pairwise per-user level except + for mail sent to address lists comprising multiple users. In order + for two principals to engage in a useful exchange of privacy-enhanced + electronic mail using conventional cryptography, they must first + possess common IK components (when symmetric key management is used) + or complementary IK components (when asymmetric key management is + used). When symmetric cryptography is used, the IK consists of a + single component, used to encrypt both DEKs and MICs. When + asymmetric cryptography is used, a recipient's public component is + used as an IK to encrypt DEKs (a transformation invertible only by a + recipient possessing the corresponding private component), and the + originator's private component is used to encrypt MICs (a + transformation invertible by all recipients, since the originator's + certificate provides the necessary public component of the + originator). + + 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). + + When an IA generates and distributes an IK component, associated + control information is provided to direct how it is to be used. In + order to select the appropriate IK(s) to use in message encryption, a + sender must retain a correspondence between IK components and the + recipients with which they are associated. Expiration date + information must also be retained, in order that cached entries may + be invalidated and replaced as appropriate. + + Since a message may be sent with multiple IK components identified, + corresponding to multiple intended recipients, each recipient's UA + must be able to determine that recipient's intended IK component. + Moreover, if no corresponding IK component is available in the + recipient's database when a message arrives, the recipient must be + able to identify the required IK component and identify that IK + component's associated IA. Note that different IKs may be used for + different messages between a pair of communicants. Consider, for + example, one message sent from A to B and another message sent (using + the IK-per-list method) from A to a mailing list of which B is a + member. The first message would use IK components associated + individually with A and B, but the second would use an IK component + shared among list members. + + When a privacy-enhanced message is transmitted, an indication of the + + + +Linn [Page 27] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + IK components used for DEK and MIC encryption must be included. To + this end, the "X-Sender-ID:" and "X-Recipient-ID:" encapsulated + header fields provide the following data: + + 1. Identification of the relevant Issuing Authority (IA subfield) + + 2. Identification of an entity with which a particular IK + component is associated (Entity Identifier or EI subfield) + + 3. Version/Expiration subfield + + The colon character (":") is used to delimit the subfields within an + "X-Sender-ID:" or "X-Recipient-ID:". The IA, EI, and + version/expiration subfields are generated from a restricted + character set, as prescribed by the following BNF (using notation as + defined in RFC-822, sections 2 and 3.3): + + IKsubfld := 1*ia-char + + ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" / + "," / "." / "/" / "=" / "?" / "-" / "@" / + "%" / "!" / '"' / "_" / "<" / ">" + An example "X-Recipient-ID:" field is as follows: + + X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2 + + This example field indicates that IA "ptf-kmc" has issued an IK + component for use on messages sent to "linn@ccy.bbn.com", and that + the IA has provided the number 2 as a version indicator for that IK + component. + +5.2.1 Subfield Definitions + + The following subsections define the subfields of "X-Sender-ID:" and + "X-Recipient-ID:" fields. + +5.2.1.1 Entity Identifier Subfield + + An entity identifier is constructed as an IKsubfld. More + restrictively, an entity identifier subfield assumes the following + form: + + <user>@<domain-qualified-host> + + In order to support universal interoperability, it is necessary to + assume a universal form for the naming information. For the case of + installations which transform local host names before transmission + into the broader Internet, it is strongly recommended that the host + + + +Linn [Page 28] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + name as presented to the Internet be employed. + +5.2.1.2 Issuing Authority Subfield + + An IA identifier subfield is constructed as an IKsubfld. IA + identifiers must be assigned in a manner which assures uniqueness. + This can be done on a centralized or hierarchic basis. + +5.2.1.3 Version/Expiration Subfield + + A version/expiration subfield is constructed as an IKsubfld. The + version/expiration subfield format may vary among different IAs, but + must satisfy certain functional constraints. An IA's + version/expiration subfields must be sufficient to distinguish among + the set of IK components issued by that IA for a given identified + entity. Use of a monotonically increasing number is sufficient to + distinguish among the IK components provided for an entity by an IA; + use of a timestamp additionally allows an expiration time or date to + be prescribed for an IK component. + +5.2.2 IK Cryptoperiod Issues + + An IK component's cryptoperiod is dictated in part by a tradeoff + between key management overhead and revocation responsiveness. It + would be undesirable to delete an IK component permanently before + receipt of a message encrypted using that IK component, as this would + render the message permanently undecipherable. Access to an expired + IK component would be needed, for example, to process mail received + by a user (or system) which had been inactive for an extended period + of time. In order to enable very old IK components to be deleted, a + message's recipient desiring encrypted local long term storage should + transform the DEK used for message text encryption via re-encryption + under a locally maintained IK, rather than relying on IA maintenance + of old IK components for indefinite periods. + +6. User Naming + +6.1 Current Approach + + Unique naming of electronic mail users, as is needed in order to + select corresponding keys correctly, is an important topic and one + which has received significant study. Our current architecture + associates IK components with user names represented in a universal + form ("user@domain-qualified-host"), relying on the following + properties: + + 1. The universal form must be specifiable by an IA as it + distributes IK components and known to a UA as it processes + + + +Linn [Page 29] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + received IK components and IK component identifiers. If a + UA or IA uses addresses in a local form which is different + from the universal form, it must be able to perform an + unambiguous mapping from the universal form into the local + representation. + + 2. The universal form, when processed by a sender UA, must have + a recognizable correspondence with the form of a recipient + address as specified by a user (perhaps following local + transformation from an alias into a universal form). + + It is difficult to ensure these properties throughout the Internet. + For example, an MTS which transforms address representations between + the local form used within an organization and the universal form as + used for Internet mail transmission may cause property 2 to be + violated. + +6.2 Issues for Consideration + + The use of flat (non-hierarchic) electronic mail user identifiers, + which are unrelated to the hosts on which the users reside, may offer + value. As directory servers become more widespread, it may become + appropriate for would-be senders to search for desired recipients + based on such attributes. Personal characteristics, like social + security numbers, might be considered. Individually-selected + identifiers could be registered with a central authority, but a means + to resolve name conflicts would be necessary. + + A point of particular note is the desire to accommodate multiple + names for a single individual, in order to represent and allow + delegation of various roles in which that individual may act. A + naming mechanism that binds user roles to keys is needed. Bindings + cannot be immutable since roles sometimes change (e.g., the + comptroller of a corporation is fired). + + It may be appropriate to examine the prospect of extending the + DARPA/DoD domain system and its associated name servers to resolve + user names to 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 which is + + + +Linn [Page 30] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + invoked by a user, and lies above the existing UA sublayer. In the + UNIX 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. 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 (based on symmetric key management), + a cache of IK components is maintained in a local file, with entries + managed manually based on information provided by originators and + recipients. This cache is, effectively, a simple database. IK + components are selected for transmitted messages based on the + sender's identity and on recipient names, and corresponding "X- + Sender-ID:" and "X-Recipient-ID:" fields are placed into the + message's encapsulated header. When a message is received, these + fields are used as a basis for a lookup in the database, yielding the + appropriate IK component entries. DEKs and IVs are generated + dynamically within the program. + + Options and destination addresses are selected by command line + arguments to the standalone program. 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 in "X-Sender-ID:" + and "X-Recipient-ID:" fields. + +8. Areas For Further Study + + The procedures defined in this RFC are sufficient to support + 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 + + + +Linn [Page 31] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + functions. + + 2. Detailed standardization of Issuing Authority and directory + service functions and interactions. + + 3. Privacy-enhanced 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 + Message Authentication Code (MAC) computation. + + FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines + specific modes in which the Data Encryption Standard algorithm + may to be used to perform encryption. + + FIPS PUB 113, Computer Data Authentication, May 1985, defines a + specific procedure for use of the Data Encryption Standard + algorithm to compute a MAC. + +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. + + [2] American National Standard Data Encryption Algorithm (ANSI + X3.92-1981), American National Standards Institute, Approved 30 + December 1980. + + [3] Federal Information Processing Standards Publication 46, Data + Encryption Standard, 15 January 1977. + + + +Linn [Page 32] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + [4] Information Processing Systems: Data Encipherment: Modes of + Operation of a 64-bit Block Cipher. + + [5] Federal Information Processing Standards Publication 81, DES + Modes of Operation, 2 December 1980. + + [6] ANSI X9.17-1985, American National Standard, Financial + Institution Key Management (Wholesale), American Bankers + Association, April 4, 1985, Section 7.2. + + [7] Postel, J., "Simple Mail Transfer Protocol" RFC-821, + USC/Information Sciences Institute, August 1982. + + [8] 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. + + [9] Use of the SMTP canonicalization procedure at this stage was + selected since it is widely used and implemented in the Internet + community, not because SMTP interoperability with this + intermediate result is required; no privacy-enhanced message will + be passed to SMTP for transmission directly from this step in the + four-phase transformation procedure. + + [10] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", RFC-822, August 1982. + + [11] Rose, M. and E. Stefferud, "Proposed Standard for Message + Encapsulation", RFC-934, January 1985. + + [12] CCITT Recommendation X.411 (1988), "Message Handling Systems: + Message Transfer System: Abstract Service Definition and + Procedures". + + [13] CCITT Recommendation X.509 (1988), "The Directory - + Authentication Framework". + + [14] Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June + 1986. + + [15] Federal Information Processing Standards Publication 113, + Computer Data Authentication, May 1985. + + [16] American National Standard for Information Systems - Data + Encryption Algorithm - Modes of Operation (ANSI X3.106-1983), + American National Standards Institute - Approved 16 May 1983. + + [17] Voydock, V. and S. Kent, "Security Mechanisms in High-Level + + + +Linn [Page 33] + +RFC 1113 Mail Privacy: Procedures August 1989 + + + Network Protocols", ACM Computing Surveys, Vol. 15, No. 2, Pages + 135-171, June 1983. + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Linn [Page 34] +
\ No newline at end of file |