Difference between revisions of "RFC1040"
imported>Admin (Created page with "Network Working Group J. Linn (BBNCC)Request for Comments: 1040 IAB Privacy Task ForceObsoletes RFCs: 989 ...") |
|||
Line 1: | Line 1: | ||
− | Network Working Group J. Linn (BBNCC)Request for Comments: 1040 IAB Privacy Task | + | Network Working Group J. Linn (BBNCC) |
+ | Request for Comments: 1040 IAB Privacy Task Force | ||
+ | Obsoletes RFCs: 989 January 1988 | ||
+ | |||
+ | |||
+ | Privacy Enhancement for Internet Electronic Mail: | ||
+ | Part I: Message Encipherment and Authentication Procedures | ||
− | |||
STATUS OF THIS MEMO | STATUS OF THIS MEMO | ||
− | This RFC suggests a proposed protocol for the Internet community, | + | |
+ | This RFC suggests a proposed protocol for the Internet community, and | ||
+ | requests discussion and suggestions for improvements. Distribution | ||
+ | of this memo is unlimited. | ||
+ | |||
ACKNOWLEDGMENT | ACKNOWLEDGMENT | ||
− | |||
− | |||
− | This RFC | + | 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, Matt Bishop, Danny Cohen, Tom Daniel, Charles | |
− | + | Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner, | |
− | + | Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, | |
− | + | and Steve Wilbur. | |
− | |||
− | + | 1. Executive Summary | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | This RFC defines message encipherment and authentication procedures, | ||
+ | as the initial phase of an effort to provide privacy enhancement | ||
+ | services for electronic mail transfer in the Internet. Detailed key | ||
+ | management mechanisms to support these procedures will be defined in | ||
+ | a subsequent RFC. As a goal of this initial phase, it is intended | ||
+ | that the procedures defined here be compatible with a wide range of | ||
+ | key management approaches, including both conventional (symmetric) | ||
+ | and public-key (asymmetric) approaches for encryption of data | ||
+ | encrypting keys. Use of conventional cryptography for message text | ||
+ | encryption and/or integrity check computation is anticipated. | ||
+ | Privacy enhancement services (confidentiality, authentication, and | ||
+ | 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 | ||
− | + | Linn [Page 1] | |
− | + | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 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 User | |
+ | Agent. A User Agent (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. | ||
+ | Authentication and integrity facilities are always applied to the | ||
+ | entirety of a message's text. No facility for confidentiality | ||
+ | service 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 | ||
− | |||
− | |||
− | |||
− | |||
− | + | Linn [Page 2] | |
− | |||
− | |||
− | |||
− | + | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 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 offer compatibility with a broad | ||
+ | range of electronic mail user agents (UAs). A large variety | ||
+ | of electronic mail user agent programs, with a corresponding | ||
+ | broad range of user interface paradigms, is used in the | ||
+ | Internet. In order that an electronic mail privacy | ||
+ | enhancement be available to the broadest possible user | ||
+ | community, the selected mechanism should be usable with the | ||
+ | widest possible variety of existing UA programs. For | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Linn [Page 3] | |
− | |||
− | + | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 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 | |
− | + | enhanced privacy 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. | ||
+ | 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). | ||
+ | 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. | ||
− | |||
− | |||
− | |||
− | |||
− | + | Linn [Page 4] | |
− | + | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | |
− | |||
− | + | As a result of these restrictions, the following facilities can be | |
+ | provided: | ||
− | + | 1. disclosure protection, | |
− | + | 2. sender authenticity, and | |
− | + | 3. message integrity measures, | |
− | |||
− | + | 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 serial reuse of PCs by multiple | ||
+ | users, | ||
+ | 6. assurance of message receipt and non-deniability of | ||
+ | receipt, | ||
+ | 7. automatic association of acknowledgments with the | ||
+ | messages to which they refer, and | ||
+ | 8. message duplicate detection, replay prevention, or other | ||
+ | stream-oriented services. | ||
+ | An important goal is that privacy enhancement mechanisms impose a | ||
+ | minimum of burden on the users they serve. In particular, this goal | ||
+ | suggests eventual automation of the key management mechanisms | ||
+ | supporting message encryption and authentication. In order to | ||
+ | facilitate deployment and testing of pilot privacy enhancement | ||
+ | implementations in the near term, however, compatibility with | ||
+ | out-of-band (e.g., manual) key distribution must also be supported. | ||
+ | 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. | ||
− | + | ||
+ | |||
+ | |||
+ | |||
+ | Linn [Page 5] | ||
+ | |||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
+ | |||
+ | |||
+ | 4. Processing of Messages | ||
4.1 Message Processing Overview | 4.1 Message Processing Overview | ||
− | This subsection provides a high-level overview of the components and | + | This subsection provides a high-level overview of the components and |
− | processing steps involved in electronic mail privacy enhancement | + | processing steps involved in electronic mail privacy enhancement |
− | processing. Subsequent subsections will define the procedures in | + | processing. Subsequent subsections will define the procedures in |
− | more detail. | + | more detail. |
− | A two-level keying hierarchy is used to support privacy-enhanced | + | A two-level keying hierarchy is used to support privacy-enhanced |
− | message transmission: | + | 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 quantities (MICs). 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. An IK may be a single | |
− | + | symmetric cryptographic key or, where asymmetric | |
− | + | (public-key) cryptography is used to encrypt DEKs, the | |
− | + | composition of a public component used by an originator and | |
− | + | a secret component used by a recipient. Ordinarily, the | |
− | + | same IK will be used for all messages sent between a given | |
− | + | originator-recipient pair over a period of time. Each | |
− | + | transmitted message includes a representation of the DEK(s) | |
− | + | used for message encryption and/or authentication, | |
− | + | encrypted under an individual IK per named recipient. This | |
− | + | representation is associated with sender and recipient | |
− | + | identification header fields, which enable recipients to | |
− | + | identify the IKs used. With this information, the recipient | |
− | + | can decrypt the transmitted DEK representation, yielding | |
− | + | the DEK required for message text decryption and/or MIC | |
− | + | verification. | |
− | When privacy enhancement processing is to be performed on an outgoing | + | When privacy enhancement processing is to be performed on an outgoing |
− | message, a DEK is generated [1] for use in message encryption and a | + | message, a DEK is generated [1] for use in message encryption and a |
− | variant of the DEK is formed (if the chosen MIC algorithm requires a | + | variant of the DEK is formed (if the chosen MIC algorithm requires a |
− | key) for use in MIC computation. An "X-Sender-ID:" field is included | + | key) for use in MIC computation. An "X-Sender-ID:" field is included |
− | in the header to provide one identification component for the IK(s) | + | in the header to provide one identification component for the IK(s) |
− | used for message processing. An IK is selected for each individually | + | used for message processing. An IK is selected for each individually |
− | identified recipient; a corresponding "X-Recipient-ID:" field, | + | identified recipient; a corresponding "X-Recipient-ID:" field, |
− | interpreted in the context of a prior "X-Sender-ID:" field, serves to | + | 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 | + | identify each IK. Each "X-Recipient-ID:" field is followed by an |
− | "X-Key-Info:" field, which transfers the DEK and computed MIC. The | + | "X-Key-Info:" field, which transfers the DEK and computed MIC. The |
− | DEK and MIC are encrypted for transmission under the appropriate IK. | + | DEK and MIC are encrypted for transmission under the appropriate IK. |
+ | Linn [Page 6] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 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 system to be | |
− | + | decrypted on a different type. A plaintext message is accepted in | |
− | + | local form, using the host's native character set and line | |
− | is | + | 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 encryption and MIC computation processes. | ||
− | The | + | For encryption purposes, the canonical representation is padded as |
− | + | required by the encryption algorithm. The padded canonical | |
− | + | representation is encrypted (except for any regions explicitly | |
− | + | excluded from encryption). The canonically encoded representation is | |
+ | encoded, after encryption, 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. | ||
− | When a privacy-enhanced message is received, the cryptographic | + | The output of the encoding procedure is combined with a set of header |
− | control fields within its text portion provide the information | + | fields carrying cryptographic control information. The result is |
− | required for the authorized recipient to perform MIC verification and | + | passed to the electronic mail system to be encapsulated as the text |
− | decryption of the received message text. First, the printable | + | portion of a transmitted message. |
− | encoding is converted to a bitstring. The MIC is verified. | + | |
− | Encrypted portions of the transmitted message are decrypted, and the | + | When a privacy-enhanced message is received, the cryptographic |
− | canonical representation is converted to the recipient's local form, | + | control fields within its text portion provide the information |
− | which need not be the same as the sender's local form. | + | 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. The MIC is verified. | ||
+ | Encrypted portions of the transmitted message are decrypted, and 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 | 4.2 Encryption Algorithms and Modes | ||
− | For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined | + | For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined |
− | in ISO draft international standard DIS 8227 [2] shall be used for | + | in ISO draft international standard DIS 8227 [2] shall be used for |
− | encryption of message text. The DEA-1 is equivalent to the Data | + | encryption of message text. The DEA-1 is equivalent to the Data |
− | Encryption Standard (DES), as defined in FIPS PUB 46 [3]. When used | + | 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 | + | for encryption of text, the DEA-1 shall be used in the Cipher Block |
− | Chaining (CBC) mode, as defined in ISO DIS 8372 [4]. The CBC mode | + | Chaining (CBC) mode, as defined in ISO DIS 8372 [4]. The CBC mode |
− | definition in DIS 8372 is equivalent to that provided in FIPS PUB 81 | + | definition in DIS 8372 is equivalent to that provided in FIPS PUB 81 |
− | [5]. A unique initializing vector (IV) will be generated for and | + | [5]. A unique initializing vector (IV) will be generated for and |
− | transmitted with each privacy-enhanced electronic mail message. | + | transmitted with each privacy-enhanced electronic mail message. |
Line 349: | Line 386: | ||
+ | Linn [Page 7] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | + | An algorithm other than DEA-1 may be employed, provided that it | |
− | + | satisfies the following requirements: | |
− | + | 1. It must be a 64-bit block cipher, enciphering and | |
− | + | deciphering in 8-octet blocks. | |
− | + | 2. It is usable in the ECB and CBC modes defined in DIS | |
− | + | 8372. | |
− | + | 3. It is able to be keyed using the procedures and | |
− | + | parameters defined in this RFC. | |
− | + | 4. It is appropriate for MIC computation, if the selected | |
− | + | MIC computation algorithm is eCcryption-based. | |
− | + | 5. Cryptographic key field lengths are limited to 16 octets | |
− | + | in length. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Support of public key algorithms for key encryption is under active | + | Certain operations require that one key be encrypted under another |
− | consideration, and it is intended that the procedures defined in this | + | key (interchange key) for purposes of transmission. This encryption |
− | RFC be appropriate to allow such usage. Support of key encryption | + | may be performed using symmetric cryptography by using DEA-1 in |
− | modes other than ECB is optional for implementations, however. | + | Electronic Codebook (ECB) mode. A header facility is available to |
− | Therefore, in support of universal interoperability, interchange key | + | indicate that an associated key is to be used for encryption in |
− | providers should not specify other modes in the absence of a priori | + | another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used for |
− | information indicating that recipients are equipped to perform key | + | key encryption and decryption with pairs of 64-bit keys, as described |
− | encryption in other modes. | + | by ASC X3T1 [6], or public-key algorithms). |
+ | |||
+ | Support of public key algorithms for key encryption is under active | ||
+ | consideration, and it is intended that the procedures defined in this | ||
+ | RFC be appropriate to allow such usage. Support of key encryption | ||
+ | modes other than ECB is optional for implementations, however. | ||
+ | Therefore, in support of universal interoperability, interchange key | ||
+ | providers should not specify other modes in the absence of a priori | ||
+ | information indicating that recipients are equipped to perform key | ||
+ | encryption in other modes. | ||
4.3 Privacy Enhancement Message Transformations | 4.3 Privacy Enhancement Message Transformations | ||
Line 391: | Line 431: | ||
4.3.1 Constraints | 4.3.1 Constraints | ||
− | An electronic mail encryption mechanism must be compatible with the | + | An electronic mail encryption mechanism must be compatible with the |
− | transparency constraints of its underlying electronic mail | + | transparency constraints of its underlying electronic mail |
− | facilities. These constraints are generally established based on | + | facilities. These constraints are generally established based on |
− | expected user requirements and on the characteristics of anticipated | + | expected user requirements and on the characteristics of anticipated |
− | endpoint transport facilities. An encryption mechanism must also be | + | endpoint transport facilities. An encryption mechanism must also be |
− | compatible with the local conventions of the computer systems which | + | compatible with the local conventions of the computer systems which |
− | it interconnects. In our approach, a canonicalization step is | + | it interconnects. In our approach, a canonicalization step is |
− | performed to abstract out local conventions and a subsequent encoding | + | performed to abstract out local conventions and a subsequent encoding |
+ | Linn [Page 8] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | 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 encode 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. | |
− | |||
− | + | 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 | |
− | a native | + | (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(tm) 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. | ||
+ | |||
+ | Linn [Page 9] | ||
+ | |||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
4.3.2 Approach | 4.3.2 Approach | ||
− | Our approach to supporting privacy-enhanced mail across an | + | Our approach to supporting privacy-enhanced mail across an |
− | environment in which intermediate conversions may occur encodes mail | + | environment in which intermediate conversions may occur encodes mail |
− | in a fashion which is uniformly representable across the set of | + | in a fashion which is uniformly representable across the set of |
− | privacy-enhanced UAs regardless of their systems' native character | + | privacy-enhanced UAs regardless of their systems' native character |
− | sets. This encoded form is used to represent mail text from sender | + | sets. This encoded form is used to represent mail text from sender |
− | to recipient, but the encoding is not applied to enclosing mail | + | to recipient, but the encoding is not applied to enclosing mail |
− | transport headers or to encapsulated headers inserted to carry | + | transport headers or to encapsulated headers inserted to carry |
− | control information between privacy-enhanced UAs. The encoding's | + | control information between privacy-enhanced UAs. The encoding's |
− | characteristics are such that the transformations anticipated between | + | characteristics are such that the transformations anticipated between |
− | sender and recipient UAs will not prevent an encoded message from | + | sender and recipient UAs will not prevent an encoded message from |
− | being decoded properly at its destination. | + | being decoded properly at its destination. |
− | A sender may exclude one or more portions of a message from | + | A sender may exclude one or more portions of a message from |
− | encryption processing. Authentication processing is always applied | + | encryption processing. Authentication processing is always applied |
− | to the entirety of message text. Explicit action is required to | + | to the entirety of message text. Explicit action is required to |
− | exclude a portion of a message from encryption processing; by | + | exclude a portion of a message from encryption processing; by |
− | default, encryption is applied to the entirety of message text. The | + | default, encryption is applied to the entirety of message text. The |
− | user-level delimiter which specifies such exclusion is a local | + | user-level delimiter which specifies such exclusion is a local |
− | matter, and hence may vary between sender and recipient, but all | + | matter, and hence may vary between sender and recipient, but all |
− | systems should provide a means for unambiguous identification of | + | systems should provide a means for unambiguous identification of |
− | areas excluded from encryption processing. | + | areas excluded from encryption processing. |
− | An outbound privacy-enhanced message undergoes four transformation | + | An outbound privacy-enhanced message undergoes four transformation |
− | steps, described in the following four subsections. | + | steps, described in the following four subsections. |
4.3.2.1 Step 1: Local Form | 4.3.2.1 Step 1: Local Form | ||
− | The message text is created in the system's native character set, | + | The message text is created in the system's native character set, |
− | with lines delimited in accordance with local convention. | + | with lines delimited in accordance with local convention. |
4.3.2.2 Step 2: Canonical Form | 4.3.2.2 Step 2: Canonical Form | ||
− | The entire message text, including both those portions subject to | + | The entire message text, including both those portions subject to |
− | encipherment processing and those portions excluded from such | + | encipherment processing and those portions excluded from such |
− | processing, is converted to the universal canonical form, | + | processing, is converted to the universal canonical form, |
− | equivalent to the inter-SMTP representation [9] as defined in | + | equivalent to the inter-SMTP representation [9] as defined in |
− | RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line | + | RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line |
− | delimiters). The processing required to perform this conversion is | + | delimiters). The processing required to perform this conversion is |
− | minimal on systems whose native character set is ASCII. Since a | + | minimal on systems whose native character set is ASCII. Since a |
− | message is converted to a standard character set and representation | + | message is converted to a standard character set and representation |
− | before encryption, it can be decrypted and its MIC can be verified | + | before encryption, it can be decrypted and its MIC can be verified |
− | at any destination system before any conversion necessary to | + | at any destination system before any conversion necessary to |
− | transform the message into a destination-specific local form is | + | transform the message into a destination-specific local form is |
− | performed. | + | performed. |
+ | |||
+ | Linn [Page 10] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
4.3.2.3 Step 3: Authentication and Encipherment | 4.3.2.3 Step 3: Authentication and Encipherment | ||
− | The canonical form is input to the selected MIC computation algorithm | + | The canonical form is input to the selected MIC computation algorithm |
− | in order to compute an integrity check quantity for the message. No | + | in order to compute an integrity check quantity for the message. No |
− | padding is added to the canonical form before submission to the MIC | + | padding is added to the canonical form before submission to the MIC |
− | computation algorithm, although certain MIC algorithms will apply | + | computation algorithm, although certain MIC algorithms will apply |
− | their own padding in the course of computing a MIC. | + | their own padding in the course of computing a MIC. |
− | Padding is applied to the canonical form as needed to perform | + | Padding is applied to the canonical form as needed to perform |
− | encryption in the DEA-1 CBC mode, as follows: The number of octets | + | encryption in the DEA-1 CBC mode, as follows: The number of octets |
− | to be encrypted is determined by subtracting the number of octets | + | to be encrypted is determined by subtracting the number of octets |
− | excluded from encryption from the total length of the encapsulated | + | excluded from encryption from the total length of the encapsulated |
− | text. Octets with the hexadecimal value FF (all ones) are appended | + | text. Octets with the hexadecimal value FF (all ones) are appended |
− | to the canonical form as needed so that the text octets to be | + | to the canonical form as needed so that the text octets to be |
− | encrypted, along with the added padding octets, fill an integral | + | encrypted, along with the added padding octets, fill an integral |
− | number of 8-octet encryption quanta. No padding is applied if the | + | number of 8-octet encryption quanta. No padding is applied if the |
− | number of octets to be encrypted is already an integral multiple of | + | 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) | + | 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 | + | as a padding value allows padding octets to be distinguished from |
− | valid data without inclusion of an explicit padding count indicator. | + | valid data without inclusion of an explicit padding count indicator. |
− | The regions of the message which have not been excluded from | + | The regions of the message which have not been excluded from |
− | encryption are encrypted. To support selective encipherment | + | encryption are encrypted. To support selective encipherment |
− | processing, an implementation must retain internal indications of the | + | processing, an implementation must retain internal indications of the |
− | positions of excluded areas excluded from encryption with relation to | + | positions of excluded areas excluded from encryption with relation to |
− | non-excluded areas, so that those areas can be properly delimited in | + | non-excluded areas, so that those areas can be properly delimited in |
− | the encoding procedure defined in step 4. If a region excluded from | + | the encoding procedure defined in step 4. If a region excluded from |
− | encryption intervenes between encrypted regions, cryptographic state | + | encryption intervenes between encrypted regions, cryptographic state |
− | (e.g., IVs and accumulation of octets into encryption quanta) is | + | (e.g., IVs and accumulation of octets into encryption quanta) is |
− | preserved and continued after the excluded region. | + | preserved and continued after the excluded region. |
4.3.2.4 Step 4: Printable Encoding | 4.3.2.4 Step 4: Printable Encoding | ||
− | The bit string resulting from step 3 is encoded into characters which | + | The bit string resulting from step 3 is encoded into characters which |
− | are universally representable at all sites, though not necessarily | + | are universally representable at all sites, though not necessarily |
− | with the same bit patterns (e.g., although the character "E" is | + | with the same bit patterns (e.g., although the character "E" is |
− | represented in an ASCII-based system as hexadecimal 45 and as | + | represented in an ASCII-based system as hexadecimal 45 and as |
− | hexadecimal C5 in an EBCDIC-based system, the local significance of | + | hexadecimal C5 in an EBCDIC-based system, the local significance of |
− | the two representations is equivalent). This encoding step is | + | the two representations is equivalent). This encoding step is |
− | performed for all privacy-enhanced messages. | + | performed for all privacy-enhanced messages. |
+ | |||
+ | 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 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | Linn [Page 11] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | from encipherment processing. The encoding function's output is | + | from encipherment processing. The encoding function's output is |
− | delimited into text lines (using local conventions), with each line | + | delimited into text lines (using local conventions), with each line |
− | containing 64 printable characters. | + | containing 64 printable characters. |
− | The encoding process represents 24-bit groups of input bits as output | + | The encoding process represents 24-bit groups of input bits as output |
− | strings of 4 encoded characters. Proceeding from left to right across | + | 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 | + | a 24-bit input group extracted from the output of step 3, each 6-bit |
− | group is used as an index into an array of 64 printable characters. | + | 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. | + | The character referenced by the index is placed in the output string. |
− | These characters, identified in Table 1, are selected so as to be | + | These characters, identified in Table 1, are selected so as to be |
− | universally representable, and the set excludes characters with | + | universally representable, and the set excludes characters with |
− | particular significance to SMTP (e.g., ".", "<CR>", "<LF>"). | + | particular significance to SMTP (e.g., ".", "<CR>", "<LF>"). |
− | Special processing is performed if fewer than 24-bits are available | + | 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 | + | 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 | + | selective encryption facility is invoked) at the end of an encrypted |
− | region or an excluded region. In other words, a full encoding | + | region or an excluded region. In other words, a full encoding |
− | quantum is always completed at the end of a message and before the | + | quantum is always completed at the end of a message and before the |
− | delimiter "*" is output to initiate or terminate the representation | + | delimiter "*" is output to initiate or terminate the representation |
− | of a block excluded from encryption. When fewer than 24 input bits | + | 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) | + | are available in an input group, zero bits are added (on the right) |
− | to form an integral number of 6-bit groups. Output character | + | to form an integral number of 6-bit groups. Output character |
− | positions which are not required to represent actual input data are | + | positions which are not required to represent actual input data are |
− | set to the character "=". Since all canonically encoded output is | + | set to the character "=". Since all canonically encoded output is |
− | an integral number of octets, only the following cases can arise: | + | an integral number of octets, only the following cases can arise: |
− | (1) the final quantum of encoding input is an integral multiple of | + | (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 | + | 24-bits; here, the final unit of encoded output will be an integral |
− | multiple of 4 characters with no "=" padding, (2) the final quantum | + | multiple of 4 characters with no "=" padding, (2) the final quantum |
− | of encoding input is exactly 8-bits; here, the final unit of encoded | + | of encoding input is exactly 8-bits; here, the final unit of encoded |
− | output will be two characters followed by two "=" padding | + | output will be two characters followed by two "=" padding |
− | characters, or (3) the final quantum of encoding input is exactly | + | characters, or (3) the final quantum of encoding input is exactly |
− | 16-bits; here, the final unit of encoded output will be three | + | 16-bits; here, the final unit of encoded output will be three |
− | characters followed by one "=" padding character. | + | characters followed by one "=" padding character. |
− | In summary, the outbound message is subjected to the following | + | In summary, the outbound message is subjected to the following |
− | composition of transformations: | + | composition of transformations: |
− | + | Transmit_Form = Encode(Encipher(Canonicalize(Local_Form))) | |
− | The inverse transformations are performed, in reverse order, to | + | The inverse transformations are performed, in reverse order, to |
− | process inbound privacy-enhanced mail: | + | process inbound privacy-enhanced mail: |
− | + | Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form))) | |
− | Note that the local form and the functions to transform messages to | + | Note that the local form and the functions to transform messages to |
− | and from canonical form may vary between the sender and recipient | + | and from canonical form may vary between the sender and recipient |
− | systems without loss of information. | + | systems without loss of information. |
+ | Linn [Page 12] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | (1) | + | 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 delimit portions of an encoded | |
− | + | message to which encryption processing has not been applied. | |
+ | |||
+ | Printable Encoding Characters | ||
+ | Table 1 | ||
4.4 Encapsulation Mechanism | 4.4 Encapsulation Mechanism | ||
− | Encapsulation of privacy-enhanced messages within an enclosing layer | + | Encapsulation of privacy-enhanced messages within an enclosing layer |
− | of headers interpreted by the electronic mail transport system offers | + | of headers interpreted by the electronic mail transport system offers |
− | a number of advantages in comparison to a flat approach in which | + | a number of advantages in comparison to a flat approach in which |
− | certain fields within a single header are encrypted and/or carry | + | certain fields within a single header are encrypted and/or carry |
− | cryptographic control information. Encapsulation provides generality | + | cryptographic control information. Encapsulation provides generality |
− | and segregates fields with user-to-user significance from those | + | and segregates fields with user-to-user significance from those |
− | transformed in transit. All fields inserted in the course of | + | transformed in transit. All fields inserted in the course of |
− | encryption/authentication processing are placed in the encapsulated | + | encryption/authentication processing are placed in the encapsulated |
− | header. This facilitates compatibility with mail handling programs | + | header. This facilitates compatibility with mail handling programs |
− | which accept only text, not header fields, from input files or from | + | which accept only text, not header fields, from input files or from |
− | other programs. Further, privacy enhancement processing can be | + | other programs. Further, privacy enhancement processing can be |
− | applied recursively. As far as the MTS is concerned, information | + | applied recursively. As far as the MTS is concerned, information |
− | incorporated into cryptographic authentication or encryption | + | incorporated into cryptographic authentication or encryption |
− | processing will reside in a message's text portion, not its header | + | processing will reside in a message's text portion, not its header |
− | portion. | + | portion. |
Line 667: | Line 722: | ||
+ | Linn [Page 13] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Enclosing 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. | ||
+ | |||
+ | 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-IV:", "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 "Subject:", etc.) | |
− | + | Post-Encapsulation Boundary (Post-EB) | |
− | + | -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- | |
− | |||
− | + | Message Encapsulation | |
− | + | 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 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | Linn [Page 14] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the | + | copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the |
− | encapsulated text and include those replicated fields in encryption | + | encapsulated text and include those replicated fields in encryption |
− | and MIC computations. | + | and MIC computations. |
− | If a user wishes disclosure protection for header fields, they must | + | If a user wishes disclosure protection for header fields, they must |
− | occur only in the encapsulated text and not in the enclosing or | + | occur only in the encapsulated text and not in the enclosing or |
− | encapsulated header. If disclosure protection is desired for a | + | encapsulated header. If disclosure protection is desired for a |
− | message's subject indication, it is recommended that the enclosing | + | message's subject indication, it is recommended that the enclosing |
− | header contain a "Subject:" field indicating that "Encrypted Mail | + | header contain a "Subject:" field indicating that "Encrypted Mail |
− | Follows". | + | Follows". |
− | If an authenticated version of header information is desired, that | + | If an authenticated version of header information is desired, that |
− | data can be replicated within the encapsulated text portion in | + | data can be replicated within the encapsulated text portion in |
− | addition to its inclusion in the enclosing header. For example, a | + | addition to its inclusion in the enclosing header. For example, a |
− | sender wishing to provide recipients with a protected indication of 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 | + | message's position in a series of messages could include a copy of a |
− | timestamp or message counter field within the encapsulated text. | + | timestamp or message counter field within the encapsulated text. |
− | A specific point regarding the integration of privacy-enhanced mail | + | A specific point regarding the integration of privacy-enhanced mail |
− | facilities with the message encapsulation mechanism is worthy of | + | facilities with the message encapsulation mechanism is worthy of |
− | note. The subset of IA5 selected for transmission encoding | + | note. The subset of IA5 selected for transmission encoding |
− | intentionally excludes the character "-", so encapsulated text can be | + | intentionally excludes the character "-", so encapsulated text can be |
− | distinguished unambiguously from a message's closing encapsulation | + | distinguished unambiguously from a message's closing encapsulation |
− | boundary (Post-EB) without recourse to character stuffing. | + | boundary (Post-EB) without recourse to character stuffing. |
4.5 Mail for Mailing Lists | 4.5 Mail for Mailing Lists | ||
− | When mail is addressed to mailing lists, two different methods of | + | When mail is addressed to mailing lists, two different methods of |
− | processing can be applicable: the IK-per-list method and the IK- | + | processing can be applicable: the IK-per-list method and the IK- |
− | perrecipient method. The choice depends on the information available | + | perrecipient method. The choice depends on the information available |
− | to the sender and on the sender's preference. | + | to the sender and on the sender's preference. |
− | If a message's sender addresses a message to a list name or alias, | + | 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- | + | use of an IK associated with that name or alias as a entity (IK- |
− | perlist), rather than resolution of the name or alias to its | + | perlist), rather than resolution of the name or alias to its |
− | constituent destinations, is implied. Such an IK must, therefore, be | + | constituent destinations, is implied. Such an IK must, therefore, be |
− | available to all list members. For the case of public-key | + | available to all list members. For the case of public-key |
− | cryptography, the secret component of the composite IK must be | + | cryptography, the secret component of the composite IK must be |
− | available to all list members. This alternative will be the normal | + | available to all list members. This alternative will be the normal |
− | case for messages sent via remote exploder sites, as a sender to such | + | case for messages sent via remote exploder sites, as a sender to such |
− | lists may not be cognizant of the set of individual recipients. | + | lists may not be cognizant of the set of individual recipients. |
− | Unfortunately, it implies an undesirable level of exposure for the | + | Unfortunately, it implies an undesirable level of exposure for the |
− | shared IK or component, and makes its revocation difficult. | + | shared IK or component, and makes its revocation difficult. |
− | Moreover, use of the IK-per-list method allows any holder of the | + | 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 | + | list's IK to masquerade as another sender to the list for |
− | authentication purposes. | + | authentication purposes. |
Line 773: | Line 834: | ||
+ | Linn [Page 15] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | If, in contrast, a message's sender is equipped to expand the | + | |
− | destination mailing list into its individual constituents and elects | + | If, in contrast, a message's sender is equipped to expand the |
− | to do so (IK-per-recipient), the message's DEK and MIC will be | + | destination mailing list into its individual constituents and elects |
− | encrypted under each per-recipient IK and all such encrypted | + | to do so (IK-per-recipient), the message's DEK and MIC will be |
− | representations will be incorporated into the transmitted message. | + | encrypted under each per-recipient IK and all such encrypted |
− | Note that per-recipient encryption is required only for the | + | representations will be incorporated into the transmitted message. |
− | relatively small DEK and MIC quantities carried in the X-Key-Info | + | Note that per-recipient encryption is required only for the |
− | field, not for the message text which is, in general, much larger. | + | relatively small DEK and MIC quantities carried in the X-Key-Info |
− | Although more IKs are involved in processing under the IK- | + | field, not for the message text which is, in general, much larger. |
− | perrecipient method, the pairwise IKs can be individually revoked and | + | Although more IKs are involved in processing under the IK- |
− | possession of one IK does not enable a successful masquerade of | + | perrecipient method, the pairwise IKs can be individually revoked and |
− | another user on the list. | + | possession of one IK does not enable a successful masquerade of |
+ | another user on the list. | ||
4.6 Summary of Added Header and Control Fields | 4.6 Summary of Added Header and Control Fields | ||
− | This section summarizes the syntax and semantics of the new | + | This section summarizes the syntax and semantics of the new |
− | encapsulated header fields to be added to messages in the course of | + | encapsulated header fields to be added to messages in the course of |
− | privacy enhancement processing. In certain indicated cases, it is | + | privacy enhancement processing. In certain indicated cases, it is |
− | recommended that the fields be replicated within the encapsulated | + | recommended that the fields be replicated within the encapsulated |
− | text portion as well. Figure 2 shows the appearance of a small | + | text portion as well. Figure 2 shows the appearance of a small |
− | example encapsulated message using these fields. The example assumes | + | example encapsulated message using these fields. The example assumes |
− | the use of symmetric cryptography; no "X-Certificate:" field is | + | the use of symmetric cryptography; no "X-Certificate:" field is |
− | carried. In all cases, hexadecimal quantities are represented as | + | carried. In all cases, hexadecimal quantities are represented as |
− | contiguous strings of digits, where each digit is represented by a | + | contiguous strings of digits, where each digit is represented by a |
− | character from the ranges "0"-"9" or upper case "A"-"F". Unless | + | character from the ranges "0"-"9" or upper case "A"-"F". Unless |
− | otherwise specified, all arguments are to be processed in a | + | otherwise specified, all arguments are to be processed in a |
− | casesensitive fashion. | + | casesensitive fashion. |
+ | |||
+ | 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 between | |
− | + | the subfields of these fields to fold them 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. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 825: | Line 890: | ||
+ | Linn [Page 16] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- | + | -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- |
− | X-Proc-Type: 2 | + | X-Proc-Type: 2 |
− | X-IV: F8143EDE5960C597 | + | X-IV: F8143EDE5960C597 |
− | X-Sender-ID: [email protected]::: | + | X-Sender-ID: [email protected]::: |
− | X-Recipient-ID: [email protected]:ptf-kmc:3:BMAC:ECB | + | X-Recipient-ID: [email protected]:ptf-kmc:3:BMAC:ECB |
− | X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD | + | X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD |
− | X-Recipient-ID: [email protected]:ptf-kmc:4:BMAC:ECB | + | X-Recipient-ID: [email protected]:ptf-kmc:4:BMAC:ECB |
− | X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7 | + | X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7 |
− | LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M | + | LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M |
− | 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk | + | 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk |
− | J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot | + | J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot |
− | dXd/H5LMDWnonNvPCwQUHt== | + | dXd/H5LMDWnonNvPCwQUHt== |
− | + | -----PRIVACY-ENHANCED MESSAGE BOUNDARY----- | |
− | + | Example Encapsulated Message | |
− | + | Figure 2 | |
4.6.1 X-Certificate Field | 4.6.1 X-Certificate Field | ||
− | The X-Certificate encapsulated header field is used only when | + | The X-Certificate encapsulated header field is used only when |
− | public-key certificate key management is employed. It transfers a | + | public-key certificate key management is employed. It transfers a |
− | sender's certificate as a string of hexadecimal digits. The | + | sender's certificate as a string of hexadecimal digits. The |
− | semantics of a certificate are discussed in Section 5.3, | + | semantics of a certificate are discussed in Section 5.3, |
− | Certificates. The certificate carried in an X-Certificate field is | + | Certificates. The certificate carried in an X-Certificate field is |
− | used in conjunction with all subsequent X-Sender-ID and X-RecipientID | + | used in conjunction with all subsequent X-Sender-ID and X-RecipientID |
− | fields until another X-Certificate field occurs; the ordinary case | + | fields until another X-Certificate field occurs; the ordinary case |
− | will be that only a single X-Certificate field will occur, prior to | + | will be that only a single X-Certificate field will occur, prior to |
− | any X-Sender-ID and X-Recipient-ID fields. | + | any X-Sender-ID and X-Recipient-ID fields. |
− | Due to the length of a certificate, it may need to be folded across | + | Due to the length of a certificate, it may need to be folded across |
− | multiple printed lines. In order to enable such folding to be | + | multiple printed lines. In order to enable such folding to be |
− | performed, the hexadecimal digits representing the contents of a | + | performed, the hexadecimal digits representing the contents of a |
− | certificate are to be divided into an ordered set (with more | + | certificate are to be divided into an ordered set (with more |
− | significant digits first) of zero or more 64-digit groups, followed | + | significant digits first) of zero or more 64-digit groups, followed |
− | by a final digit group which may be any length up to 64-digits. A | + | by a final digit group which may be any length up to 64-digits. A |
− | single whitespace character is interposed between each pair of groups | + | single whitespace character is interposed between each pair of groups |
− | so that folding (per RFC-822, section 3.1.1) may take place; this | + | so that folding (per RFC-822, section 3.1.1) may take place; this |
− | whitespace is ignored in parsing the received digit string. | + | whitespace is ignored in parsing the received digit string. |
4.6.2 X-IV Field | 4.6.2 X-IV Field | ||
− | The X-IV encapsulated header field carries the Initializing Vector | + | The X-IV encapsulated header field carries the Initializing Vector |
− | used for message encryption. Only one X-IV field occurs in a | + | used for message encryption. Only one X-IV field occurs in a |
− | message. It appears in all messages, even if the entirety of message | + | message. It appears in all messages, even if the entirety of message |
− | text is excluded from encryption. Following the field name, and one | + | text is excluded from encryption. Following the field name, and one |
− | or more delimiting whitespace characters, a 64-bit Initializing | + | or more delimiting whitespace characters, a 64-bit Initializing |
− | Vector is represented as a contiguous string of 16 hexadecimal | + | Vector is represented as a contiguous string of 16 hexadecimal |
+ | |||
+ | Linn [Page 17] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | digits. | + | digits. |
4.6.3 X-Key-Info Field | 4.6.3 X-Key-Info Field | ||
− | The X-Key-Info encapsulated header field transfers two items: a DEK | + | The X-Key-Info encapsulated header field transfers two items: a DEK |
− | and a MIC. One X-Key-Info field is included for each of a message's | + | and a MIC. One X-Key-Info field is included for each of a message's |
− | named recipients. The DEK and MIC are encrypted under the IK | + | named recipients. The DEK and MIC are encrypted under the IK |
− | identified by a preceding X-Recipient-ID field and prior X-Sender-ID | + | identified by a preceding X-Recipient-ID field and prior X-Sender-ID |
− | field; they are represented as two strings of contiguous hexadecimal | + | field; they are represented as two strings of contiguous hexadecimal |
− | digits, separated by a comma. For DEA-1, the DEK representation will | + | digits, separated by a comma. For DEA-1, the DEK representation will |
− | be 16 hexadecimal digits (corresponding to a 64-bit key); this | + | be 16 hexadecimal digits (corresponding to a 64-bit key); this |
− | subfield can be extended to 32 hexadecimal digits (corresponding to a | + | subfield can be extended to 32 hexadecimal digits (corresponding to a |
− | 128-bit key), if required to support other algorithms. MICs are also | + | 128-bit key), if required to support other algorithms. MICs are also |
− | represented as contiguous strings of hexadecimal digits. The size of | + | represented as contiguous strings of hexadecimal digits. The size of |
− | a MIC is dependent on the choice of MIC algorithm as specified in the | + | a MIC is dependent on the choice of MIC algorithm as specified in the |
− | X-Recipient-ID field corresponding to a given recipient. | + | X-Recipient-ID field corresponding to a given recipient. |
4.6.4 X-Proc-Type Field | 4.6.4 X-Proc-Type Field | ||
− | The X-Proc-Type encapsulated header field identifies the type of | + | The X-Proc-Type encapsulated header field identifies the type of |
− | processing performed on the transmitted message. Only one X-ProcType | + | processing performed on the transmitted message. Only one X-ProcType |
− | field occurs in a message. It has one subfield, a decimal number | + | field occurs in a message. It has one subfield, a decimal number |
− | which is used to distinguish among incompatible encapsulated header | + | which is used to distinguish among incompatible encapsulated header |
− | field interpretations which may arise as changes are made to this | + | field interpretations which may arise as changes are made to this |
− | standard. Messages processed according to this RFC will carry the | + | standard. Messages processed according to this RFC will carry the |
− | subfield value "2". | + | subfield value "2". |
4.6.5 X-Sender-ID Field | 4.6.5 X-Sender-ID Field | ||
− | The X-Sender-ID encapsulated header field provides the sender's | + | The X-Sender-ID encapsulated header field provides the sender's |
− | interchange key identification component. It should be replicated | + | interchange key identification component. It should be replicated |
− | within the encapsulated text. The interchange key identification | + | within the encapsulated text. The interchange key identification |
− | component carried in an X-Sender-ID field is used in conjunction with | + | 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 | + | 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 | + | occurs; the ordinary case will be that only a single X-Sender-ID |
− | field will occur, prior to any X-Recipient-ID fields. | + | field will occur, prior to any X-Recipient-ID fields. |
− | The X-Sender-ID field contains (in order) an Entity Identifier | + | The X-Sender-ID field contains (in order) an Entity Identifier |
− | subfield, an (optional) Issuing Authority subfield, an (optional) | + | subfield, an (optional) Issuing Authority subfield, an (optional) |
− | Version/Expiration subfield, and an (optional) IK Use Indicator | + | Version/Expiration subfield, and an (optional) IK Use Indicator |
− | subfield. The optional subfields are omitted if their use is | + | subfield. The optional subfields are omitted if their use is |
− | rendered redundant by information carried in subsequent X-RecipientID | + | rendered redundant by information carried in subsequent X-RecipientID |
− | fields; this will ordinarily be the case where symmetric cryptography | + | fields; this will ordinarily be the case where symmetric cryptography |
− | is used for key management. The subfields are delimited by the colon | + | is used for key management. The subfields are delimited by the colon |
− | character (":"), optionally followed by whitespace. | + | character (":"), optionally followed by whitespace. |
− | Section 5.2, Interchange Keys, discusses the semantics of these | + | Section 5.2, Interchange Keys, discusses the semantics of these |
− | subfields and specifies the alphabet from which they are chosen. | + | subfields and specifies the alphabet from which they are chosen. |
+ | Linn [Page 18] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | Note that multiple X-Sender-ID fields may occur within a single | + | |
− | encapsulated header. All X-Recipient-ID fields are interpreted in | + | Note that multiple X-Sender-ID fields may occur within a single |
− | the context of the most recent preceding X-Sender-ID field; it is | + | encapsulated header. All X-Recipient-ID fields are interpreted in |
− | illegal for an X-Recipient-ID field to occur in a header before an | + | the context of the most recent preceding X-Sender-ID field; it is |
− | X-Sender-ID has been provided. | + | illegal for an X-Recipient-ID field to occur in a header before an |
+ | X-Sender-ID has been provided. | ||
4.6.6 X-Recipient-ID Field | 4.6.6 X-Recipient-ID Field | ||
− | The X-Recipient-ID encapsulated header field provides the recipient's | + | The X-Recipient-ID encapsulated header field provides the recipient's |
− | interchange key identification component. One X-Recipient-ID field | + | interchange key identification component. One X-Recipient-ID field |
− | is included for each of a message's named recipients. It should be | + | is included for each of a message's named recipients. It should be |
− | replicated within the encapsulated text. The field contains (in | + | replicated within the encapsulated text. The field contains (in |
− | order) an Entity Identifier subfield, an Issuing Authority subfield, | + | order) an Entity Identifier subfield, an Issuing Authority subfield, |
− | a Version/Expiration subfield, a MIC algorithm indicator subfield, | + | a Version/Expiration subfield, a MIC algorithm indicator subfield, |
− | and an IK Use Indicator subfield. The subfields are delimited by the | + | and an IK Use Indicator subfield. The subfields are delimited by the |
− | colon character (":"), optionally followed by whitespace. | + | colon character (":"), optionally followed by whitespace. |
− | The MIC algorithm indicator is an ASCII string, selected from the | + | The MIC algorithm indicator is an ASCII string, selected from the |
− | values defined in Appendix A of this RFC. Section 5.2, Interchange | + | values defined in Appendix A of this RFC. Section 5.2, Interchange |
− | Keys, discusses the semantics of the other subfields and specifies | + | Keys, discusses the semantics of the other subfields and specifies |
− | the alphabet from which they are chosen. All X-Recipient-ID | + | the alphabet from which they are chosen. All X-Recipient-ID |
− | fields are interpreted in the context of the most recent preceding | + | fields are interpreted in the context of the most recent preceding |
− | XSender-ID field; it is illegal for an X-Recipient-ID field to | + | XSender-ID field; it is illegal for an X-Recipient-ID field to |
− | occur in a header before an X-Sender-ID has been provided. | + | occur in a header before an X-Sender-ID has been provided. |
− | + | 5. Key Management | |
− | Several cryptographic constructs are involved in supporting the | + | Several cryptographic constructs are involved in supporting the |
− | privacy-enhanced message processing procedure. While (as noted in | + | privacy-enhanced message processing procedure. While (as noted in |
− | the Executive Summary section of this RFC), key management mechanisms | + | the Executive Summary section of this RFC), key management mechanisms |
− | have not yet been fully defined, a set of fundamental elements are | + | have not yet been fully defined, a set of fundamental elements are |
− | assumed. Data Encrypting Keys (DEKs) are used to encrypt message | + | assumed. Data Encrypting Keys (DEKs) are used to encrypt message |
− | text and in the message integrity check (MIC) computation process. | + | text and in the message integrity check (MIC) computation process. |
− | Interchange Keys (IKs) are used to encrypt DEKs for transmission with | + | Interchange Keys (IKs) are used to encrypt DEKs for transmission with |
− | messages. In an asymmetric key management architecture, certificates | + | messages. In an asymmetric key management architecture, certificates |
− | are used as a means to provide entities' public key components and | + | are used as a means to provide entities' public key components and |
− | other information in a fashion which is securely bound by a central | + | other information in a fashion which is securely bound by a central |
− | authority. The remainder of this section provides more information | + | authority. The remainder of this section provides more information |
− | about these constructs. | + | about these constructs. |
5.1 Data Encrypting Keys (DEKs) | 5.1 Data Encrypting Keys (DEKs) | ||
− | Data Encrypting Keys (DEKs) are used for encryption of message text | + | Data Encrypting Keys (DEKs) are used for encryption of message text |
− | and for computation of message integrity check quantities (MICs). It | + | and for computation of message integrity check quantities (MICs). It |
− | is strongly recommended that DEKs be generated and used on a one-time | + | is strongly recommended that DEKs be generated and used on a one-time |
− | basis. A transmitted message will incorporate a representation of | + | basis. A transmitted message will incorporate a representation of |
− | the DEK encrypted under an appropriate interchange key (IK) for each | + | the DEK encrypted under an appropriate interchange key (IK) for each |
− | the authorized recipient. | + | the authorized recipient. |
+ | Linn [Page 19] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | When symmetric cryptography is used, one advantage of centralized | + | DEK generation can be performed either centrally by key distribution |
− | KDC-based generation is that DEKs can be returned to endpoints | + | centers (KDCs) or by endpoint systems. Dedicated KDC systems may be |
− | already encrypted under the IKs of message recipients rather than | + | able to implement better algorithms for random DEK generation than |
− | providing the IKs to the senders. This reduces IK exposure and | + | can be supported in endpoint systems. On the other hand, |
− | simplifies endpoint key management requirements. This approach has | + | decentralization allows endpoints to be relatively self-sufficient, |
− | less value if asymmetric cryptography is used for key management, | + | reducing the level of trust which must be placed in components other |
− | since per-recipient public IK components are assumed to be generally | + | than a message's originator and recipient. Moreover, decentralized |
− | available and per-sender secret IK components need not necessarily be | + | DEK generation at endpoints reduces the frequency with which senders |
− | shared with a KDC. | + | 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 secret IK components need not necessarily be | ||
+ | shared with a KDC. | ||
5.2 Interchange Keys (IKs) | 5.2 Interchange Keys (IKs) | ||
− | Interchange Keys (IKs) are used to encrypt Data Encrypting Keys. In | + | Interchange Keys (IKs) are used to encrypt Data Encrypting Keys. In |
− | general, IK granularity is at the pairwise per-user level except for | + | general, IK granularity is at the pairwise per-user level except for |
− | mail sent to address lists comprising multiple users. In order for | + | mail sent to address lists comprising multiple users. In order for |
− | two principals to engage in a useful exchange of privacy-enhanced | + | two principals to engage in a useful exchange of privacy-enhanced |
− | electronic mail using conventional cryptography, they must first | + | electronic mail using conventional cryptography, they must first |
− | share a common interchange key. When symmetric cryptography is used, | + | share a common interchange key. When symmetric cryptography is used, |
− | the interchange key consists of a single component. When asymmetric | + | the interchange key consists of a single component. When asymmetric |
− | cryptography is used, an originator and recipient must possess an | + | cryptography is used, an originator and recipient must possess an |
− | asymmetric key's public and secret components, as appropriate. This | + | asymmetric key's public and secret components, as appropriate. This |
− | pair of components, when composed, constitute an interchange key. | + | pair of components, when composed, constitute an interchange key. |
− | While this RFC does not prescribe the means by which interchange keys | + | While this RFC does not prescribe the means by which interchange keys |
− | are provided to appropriate parties, it is useful to note that such | + | are provided to appropriate parties, it is useful to note that such |
− | means may be centralized (e.g., via key management servers) or | + | means may be centralized (e.g., via key management servers) or |
− | decentralized (e.g., via pairwise agreement and direct distribution | + | decentralized (e.g., via pairwise agreement and direct distribution |
− | among users). In any case, any given IK component is associated with | + | among users). In any case, any given IK component is associated with |
− | a responsible Issuing Authority (IA). When an IA generates and | + | a responsible Issuing Authority (IA). When an IA generates and |
− | distributes an IK, associated control information is provided to | + | distributes an IK, associated control information is provided to |
− | direct how that IK is to be used. In order to select the appropriate | + | direct how that IK is to be used. In order to select the appropriate |
− | IK to use in message encryption, a sender must retain a | + | IK to use in message encryption, a sender must retain a |
− | correspondence between IK components and the recipients with which | + | correspondence between IK components and the recipients with which |
− | they are associated. Expiration date information must also be | + | they are associated. Expiration date information must also be |
− | retained, in order that cached entries may be invalidated and | + | retained, in order that cached entries may be invalidated and |
− | replaced as appropriate. | + | replaced as appropriate. |
+ | Linn [Page 20] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Since a message may be sent with multiple IK component | |
− | IK | + | representations, corresponding to multiple intended recipients, each |
− | the | + | recipient must be able to determine which IK component is intended |
− | + | for it. Moreover, if no corresponding IK component is available in | |
+ | the recipient's database when a message arrives, the recipient must | ||
+ | be able to determine which IK component to request and to 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 | |
− | + | IK components used for DEK 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. Indicator of IK usage mode (IK use indicator subfield). | |
− | + | 4. 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: [email protected]:ptf-kmc:2:BMAC:ECB | |
− | |||
+ | This example field indicates that IA "ptf-kmc" has issued an IK | ||
+ | component for use on messages sent to "[email protected]", that the IA | ||
+ | Linn [Page 21] | ||
− | has provided the number 2 as a version indicator for that IK | + | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 |
− | component, that the BMAC MIC computation algorithm is to be used for | + | |
− | the recipient, and that the IK component is to be used in ECB mode. | + | |
+ | has provided the number 2 as a version indicator for that IK | ||
+ | component, that the BMAC MIC computation algorithm is to be used for | ||
+ | the recipient, and that the IK component is to be used in ECB mode. | ||
5.2.1 Subfield Definitions | 5.2.1 Subfield Definitions | ||
− | The following subsections define the subfields of "X-Sender-ID:" and | + | The following subsections define the subfields of "X-Sender-ID:" and |
− | "X-Recipient-ID:" fields. | + | "X-Recipient-ID:" fields. |
5.2.1.1 Entity Identifier Subfield | 5.2.1.1 Entity Identifier Subfield | ||
− | An entity identifier is constructed as an IKsubfld. More | + | An entity identifier is constructed as an IKsubfld. More |
− | restrictively, an entity identifier subfield assumes the following | + | restrictively, an entity identifier subfield assumes the following |
− | form: | + | form: |
− | + | <user>@<domain-qualified-host> | |
− | In order to support universal interoperability, it is necessary to | + | In order to support universal interoperability, it is necessary to |
− | assume a universal form for the naming information. For the case of | + | assume a universal form for the naming information. For the case of |
− | installations which transform local host names before transmission | + | installations which transform local host names before transmission |
− | into the broader Internet, it is strongly recommended that the host | + | into the broader Internet, it is strongly recommended that the host |
− | name as presented to the Internet be employed. | + | name as presented to the Internet be employed. |
5.2.1.2 Issuing Authority Subfield | 5.2.1.2 Issuing Authority Subfield | ||
− | An IA identifier subfield is constructed as an IKsubfld. IA | + | An IA identifier subfield is constructed as an IKsubfld. IA |
− | identifiers must be assigned in a manner which assures uniqueness. | + | identifiers must be assigned in a manner which assures uniqueness. |
− | This can be done on a centralized or hierarchic basis. | + | This can be done on a centralized or hierarchic basis. |
5.2.1.3 Version/Expiration Subfield | 5.2.1.3 Version/Expiration Subfield | ||
− | A version/expiration subfield is constructed as an IKsubfld. The | + | A version/expiration subfield is constructed as an IKsubfld. The |
− | version/expiration subfield format may vary among different IAs, but | + | version/expiration subfield format may vary among different IAs, but |
− | must satisfy certain functional constraints. An IA's | + | must satisfy certain functional constraints. An IA's |
− | version/expiration subfields must be sufficient to distinguish among | + | version/expiration subfields must be sufficient to distinguish among |
− | the set of IK components issued by that IA for a given identified | + | the set of IK components issued by that IA for a given identified |
− | entity. Use of a monotonically increasing number is sufficient to | + | entity. Use of a monotonically increasing number is sufficient to |
− | distinguish among the IK components provided for an entity by an IA; | + | distinguish among the IK components provided for an entity by an IA; |
− | use of a timestamp additionally allows an expiration time or date to | + | use of a timestamp additionally allows an expiration time or date to |
− | be prescribed for an IK component. | + | be prescribed for an IK component. |
5.2.1.4 MIC Algorithm Identifier Subfield | 5.2.1.4 MIC Algorithm Identifier Subfield | ||
− | The MIC algorithm identifier, which occurs only within X-Recipient-ID | + | The MIC algorithm identifier, which occurs only within X-Recipient-ID |
− | fields, is used to identify the choice of message integrity check | + | fields, is used to identify the choice of message integrity check |
− | algorithm for a given recipient. Appendix A of this RFC specifies | + | algorithm for a given recipient. Appendix A of this RFC specifies |
− | the defined values for this subfield. | + | the defined values for this subfield. |
+ | Linn [Page 22] | ||
+ | |||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
5.2.1.5 IK Use Indicator Subfield | 5.2.1.5 IK Use Indicator Subfield | ||
− | The IK use indicator subfield is an optional facility, provided to | + | The IK use indicator subfield is an optional facility, provided to |
− | identify the encryption mode in which an IK component is to be used. | + | identify the encryption mode in which an IK component is to be used. |
− | Currently, this subfield may assume the following reserved string | + | Currently, this subfield may assume the following reserved string |
− | values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the default | + | values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the default |
− | value is "ECB". | + | value is "ECB". |
5.2.2 IK Cryptoperiod Issues | 5.2.2 IK Cryptoperiod Issues | ||
− | An IK component's cryptoperiod is dictated in part by a tradeoff | + | An IK component's cryptoperiod is dictated in part by a tradeoff |
− | between key management overhead and revocation responsiveness. It | + | between key management overhead and revocation responsiveness. It |
− | would be undesirable to delete an IK component permanently before | + | would be undesirable to delete an IK component permanently before |
− | receipt of a message encrypted using that IK component, as this would | + | receipt of a message encrypted using that IK component, as this would |
− | render the message permanently undecipherable. Access to an expired | + | render the message permanently undecipherable. Access to an expired |
− | IK component would be needed, for example, to process mail received | + | IK component would be needed, for example, to process mail received |
− | by a user (or system) which had been inactive for an extended period | + | 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 | + | of time. In order to enable very old IK components to be deleted, a |
− | message's recipient desiring encrypted local long term storage should | + | message's recipient desiring encrypted local long term storage should |
− | transform the DEK used for message text encryption via re-encryption | + | transform the DEK used for message text encryption via re-encryption |
− | under a locally maintained IK, rather than relying on IA maintenance | + | under a locally maintained IK, rather than relying on IA maintenance |
− | of old IK components for indefinite periods. | + | of old IK components for indefinite periods. |
5.3 Certificates | 5.3 Certificates | ||
− | In an asymmetric key management architecture, a certificate binds an | + | In an asymmetric key management architecture, a certificate binds an |
− | entity's public key component to a representation of the entity's | + | entity's public key component to a representation of the entity's |
− | identity and other attributes of the entity. A certificate's issuing | + | identity and other attributes of the entity. A certificate's issuing |
− | authority signs the certificate, vouching for the correspondence | + | authority signs the certificate, vouching for the correspondence |
− | between the entity's identity, attributes, and associated public key | + | between the entity's identity, attributes, and associated public key |
− | component. Once signed, certificate copies may be posted on multiple | + | component. Once signed, certificate copies may be posted on multiple |
− | servers in order to make recipients' certificates directly accessible | + | servers in order to make recipients' certificates directly accessible |
− | to originators at dispersed locations. This allows privacy-enhanced | + | to originators at dispersed locations. This allows privacy-enhanced |
− | mail to be sent between an originator and a recipient without prior | + | mail to be sent between an originator and a recipient without prior |
− | placement of a pairwise key at the originator and recipient, greatly | + | placement of a pairwise key at the originator and recipient, greatly |
− | enhancing mail system flexibility. The properties of a certificate's | + | enhancing mail system flexibility. The properties of a certificate's |
− | authority-applied signature make it unnecessary to be concerned about | + | authority-applied signature make it unnecessary to be concerned about |
− | the prospect that servers, or other entities, could undetectably | + | the prospect that servers, or other entities, could undetectably |
− | modify certificate contents so as to associate a public key with an | + | modify certificate contents so as to associate a public key with an |
− | inappropriate entity. | + | inappropriate entity. |
− | Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a | + | Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a |
− | subject's certificate is defined to contain the following parameters: | + | subject's certificate is defined to contain the following parameters: |
− | + | 1. A signature algorithm identifier, identifying the | |
− | + | algorithm used by the certificate's issuer to compute the | |
− | + | signature applied to the certificate. | |
+ | Linn [Page 23] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | + | 2. Issuer identification, identifying the certificate's | |
− | + | issuer with an O/R name. | |
− | |||
− | + | 3. Validity information, providing date and time limits | |
− | + | before and after which the certificate should not be | |
+ | used. | ||
− | + | 4. Subject identification, identifying the certificate's | |
+ | subject with an O/R name. | ||
− | + | 5. Subject's public key. | |
− | |||
− | + | 6. Algorithm identifier, identifying the algorithm with | |
− | + | which the subject's public key is to be used. | |
− | |||
− | + | 7. Signature, an asymmetrically encrypted, hashed version of | |
− | + | the above parameters, computed by the certificate's | |
− | + | issuer. | |
− | |||
− | |||
− | |||
− | |||
− | + | The Recommendations specify an ASN.1 encoding to define a | |
+ | certificate. Pending further study, it is recommended that | ||
+ | electronic mail privacy enhancement implementations using asymmetric | ||
+ | cryptography for key management employ this encoding for | ||
+ | certificates. Section 4.2.3 of RFC-987 [14] specifies a procedure | ||
+ | for mapping RFC-822 addresses into the O/R names used in X.411/X.509 | ||
+ | certificates. | ||
+ | |||
+ | 6. User Naming | ||
6.1 Current Approach | 6.1 Current Approach | ||
− | Unique naming of electronic mail users, as is needed in order to | + | Unique naming of electronic mail users, as is needed in order to |
− | select corresponding keys correctly, is an important topic and one | + | select corresponding keys correctly, is an important topic and one |
− | requiring significant study. A logical association exists between | + | requiring significant study. A logical association exists between |
− | key distribution and name/directory server functions; their | + | key distribution and name/directory server functions; their |
− | relationship is a topic deserving further consideration. These | + | relationship is a topic deserving further consideration. These |
− | issues have not been fully resolved at this writing. The current | + | issues have not been fully resolved at this writing. The current |
− | architecture relies on association of IK components with user names | + | architecture relies on association of IK components with user names |
− | represented in a universal form ("user@host"), relying on the | + | represented in a universal form ("user@host"), relying on the |
− | following properties: | + | 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 | |
− | + | 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. | |
+ | Linn [Page 24] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | It is difficult to ensure these properties throughout the Internet. | + | 2. The universal form, when processed by a sender UA, must have |
− | For example, an MTS which transforms address representations between | + | a recognizable correspondence with the form of a recipient |
− | the local form used within an organization and the universal form as | + | address as specified by a user (perhaps following local |
− | used for Internet mail transmission may cause property 2 to be | + | transformation from an alias into a universal form). |
− | violated. | + | |
+ | 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 | 6.2 Issues for Consideration | ||
− | The use of flat (non-hierarchic) electronic mail user identifiers, | + | The use of flat (non-hierarchic) electronic mail user identifiers, |
− | which are unrelated to the hosts on which the users reside, may offer | + | which are unrelated to the hosts on which the users reside, may offer |
− | value. Personal characteristics, like social security numbers, might | + | value. Personal characteristics, like social security numbers, might |
− | be considered. Individually-selected identifiers could be registered | + | be considered. Individually-selected identifiers could be registered |
− | with a central authority, but a means to resolve name conflicts would | + | with a central authority, but a means to resolve name conflicts would |
− | be necessary. | + | be necessary. |
− | A point of particular note is the desire to accommodate multiple | + | A point of particular note is the desire to accommodate multiple |
− | names for a single individual, in order to represent and allow | + | names for a single individual, in order to represent and allow |
− | delegation of various roles in which that individual may act. A | + | delegation of various roles in which that individual may act. A |
− | naming mechanism that binds user roles to keys is needed. Bindings | + | naming mechanism that binds user roles to keys is needed. Bindings |
− | cannot be immutable since roles sometimes change (e.g., the | + | cannot be immutable since roles sometimes change (e.g., the |
− | comptroller of a corporation is fired). | + | comptroller of a corporation is fired). |
− | It may be appropriate to examine the prospect of extending the | + | It may be appropriate to examine the prospect of extending the |
− | DARPA/DoD domain system and its associated name servers to resolve | + | DARPA/DoD domain system and its associated name servers to resolve |
− | user names to unique user IDs. An additional issue arises with | + | user names to unique user IDs. An additional issue arises with |
− | regard to mailing list support: name servers do not currently perform | + | regard to mailing list support: name servers do not currently perform |
− | (potentially recursive) expansion of lists into users. ISO and CSNet | + | (potentially recursive) expansion of lists into users. ISO and CSNet |
− | are working on user-level directory service mechanisms, which may | + | are working on user-level directory service mechanisms, which may |
− | also bear consideration. | + | also bear consideration. |
− | + | 7. Example User Interface and Implementation | |
− | In order to place the mechanisms and approaches discussed in this RFC | + | In order to place the mechanisms and approaches discussed in this RFC |
− | into context, this section presents an overview of a prototype | + | into context, this section presents an overview of a prototype |
− | implementation. This implementation is a standalone program which is | + | implementation. This implementation is a standalone program which is |
− | invoked by a user, and lies above the existing UA sublayer. In the | + | invoked by a user, and lies above the existing UA sublayer. In the |
− | UNIX(tm) system, and possibly in other environments as well, such a | + | UNIX(tm) system, and possibly in other environments as well, such a |
− | program can be invoked as a "filter" within an electronic mail UA or | + | program can be invoked as a "filter" within an electronic mail UA or |
− | a text editor, simplifying the sequence of operations which must be | + | a text editor, simplifying the sequence of operations which must be |
− | performed by the user. This form of integration offers the advantage | + | performed by the user. This form of integration offers the advantage |
− | that the program can be used in conjunction with a range of UA | + | that the program can be used in conjunction with a range of UA |
− | programs, rather than being compatible only with a particular UA. | + | programs, rather than being compatible only with a particular UA. |
− | When a user wishes to apply privacy enhancements to an outgoing | + | When a user wishes to apply privacy enhancements to an outgoing |
+ | Linn [Page 25] | ||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | message, the user prepares the message's text and invokes the | |
− | + | standalone program (interacting with the program in order to provide | |
− | information | + | 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, 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 | |
− | and "X-Recipient-ID:" fields. | + | 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 pilot | |
− | + | 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 | |
− | + | functions. | |
− | + | 2. Standardization of Issuing Authority functions, including | |
− | + | protocols for communications among IAs and between User | |
+ | Agents and IAs. | ||
− | + | 3. Specification of public key encryption algorithms to encrypt | |
+ | data encrypting keys. | ||
+ | 4. Interoperability with X.400 mail. | ||
+ | Linn [Page 26] | ||
− | + | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | |
− | |||
− | |||
− | This section identifies background references which may be useful | + | 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. | ||
+ | |||
A. Message Integrity Check Algorithms | A. Message Integrity Check Algorithms | ||
− | This appendix identifies the alternative algorithms which may be | + | |
− | MIC algorithms which utilize DEA-1 cryptography are computed using | + | This appendix identifies the alternative algorithms which may be used |
+ | to compute Message Integrity Check (MIC) values, and assigns them | ||
+ | character string identifiers to be incorporated in "X-Recipient-ID:" | ||
+ | fields to indicate the choice of algorithm employed for individual | ||
+ | message recipients. | ||
+ | |||
+ | MIC algorithms which utilize DEA-1 cryptography are computed using a | ||
+ | key which is a variant of the DEK used for message text encryption. | ||
+ | The variant is formed by modulo-2 addition of the hexadecimal | ||
+ | quantity F0F0F0F0F0F0F0F0 to the encryption DEK. | ||
+ | |||
A.1 Conventional MAC (MAC) | A.1 Conventional MAC (MAC) | ||
− | |||
+ | A conventional MAC, denoted by the string "MAC", is computed using | ||
+ | the DEA-1 algorithm in the fashion defined in FIPS PUB 113 [15]. Use | ||
+ | of the conventional MAC is not recommended for multicast messages. | ||
+ | The message's encapsulated text is padded at the end, per FIPS PUB | ||
+ | 113, with zero-valued octets as needed in order to form an integral | ||
+ | number of 8-octet encryption quanta. These padding octets are | ||
− | inserted implicitly and are not transmitted with a message. | + | Linn [Page 27] |
+ | |||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
+ | |||
+ | |||
+ | inserted implicitly and are not transmitted with a message. The | ||
+ | result of a conventional MAC computation is a single 64-bit value. | ||
+ | |||
A.2 Bidirectional MAC (BMAC) | A.2 Bidirectional MAC (BMAC) | ||
− | A bidirectional MAC, denoted by the string "BMAC", yields a | + | |
− | The low-order 64-bits of the BMAC result are also formed by | + | A bidirectional MAC, denoted by the string "BMAC", yields a result |
+ | which is transferred as a single 128-bit value. The BMAC is computed | ||
+ | in the following manner: First, the encapsulated text is padded at | ||
+ | the end with zero-valued octets as needed in order to form an | ||
+ | integral number of 8-octet encryption quanta. These padding octets | ||
+ | are inserted implicitly and are not transmitted with a message. A | ||
+ | conventional MAC is computed on the padded form, and the resulting | ||
+ | 64-bits form the high-order 64-bits of the BMAC result. | ||
+ | |||
+ | The low-order 64-bits of the BMAC result are also formed by computing | ||
+ | a conventional MAC, but the order of the 8-octet encryption quanta is | ||
+ | reversed for purposes of computation. In other words, the first | ||
+ | quantum entered into this computation is the last quantum in the | ||
+ | encapsulated text, and includes any added padding. The first quantum | ||
+ | in the text is the last quantum processed as input to this | ||
+ | computation. The octets within each 8-octet quantum are not | ||
+ | reordered. | ||
+ | |||
NOTES: | 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. | |
+ | |||
+ | [2] Information Processing Systems: Data Encipherment: Block | ||
+ | Cipher Algorithm DEA 1. | ||
+ | |||
+ | [3] Federal Information Processing Standards Publication 46, | ||
+ | Data Encryption Standard, 15 January 1977. | ||
+ | |||
+ | [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] Addendum to the Transport Layer Protocol Definition for | ||
+ | Providing Connection Oriented End to End Cryptographic Data | ||
+ | Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft | ||
+ | of 19 December 1985, Gaithersburg, MD, p. 15. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Linn [Page 28] | ||
+ | |||
+ | RFC 1040 Privacy Enhancement for Electronic Mail January 1988 | ||
+ | |||
+ | |||
+ | [7] Postel, J., Simple Mail Transfer Protocol (RFC-821), 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. T. and Stefferud, E. A., 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. E., Mapping between X.400 and RFC-822 (RFC-987), | ||
+ | June 1986. | ||
+ | |||
+ | [15] Federal Information Processing Standards Publication 113, | ||
+ | Computer Data Authentication, May 1985. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
Line 1,393: | Line 1,618: | ||
− | + | Linn [Page 29] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 22:45, 22 September 2020
Network Working Group J. Linn (BBNCC) Request for Comments: 1040 IAB Privacy Task Force Obsoletes RFCs: 989 January 1988
Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures
STATUS OF THIS MEMO
This RFC suggests a proposed 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, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and Steve Wilbur.
1. Executive Summary
This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.
Privacy enhancement services (confidentiality, authentication, and 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
Linn [Page 1]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 User Agent. A User Agent (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.
Authentication and integrity facilities are always applied to the entirety of a message's text. No facility for confidentiality service 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
Linn [Page 2]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 offer compatibility with a broad range of electronic mail user agents (UAs). A large variety of electronic mail user agent programs, with a corresponding broad range of user interface paradigms, is used in the Internet. In order that an electronic mail privacy enhancement be available to the broadest possible user community, the selected mechanism should be usable with the widest possible variety of existing UA programs. For
Linn [Page 3]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 enhanced privacy 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.
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).
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.
Linn [Page 4]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
As a result of these restrictions, the following facilities can be provided:
1. disclosure protection,
2. sender authenticity, and
3. message integrity measures,
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 serial reuse of PCs by multiple users,
6. assurance of message receipt and non-deniability of receipt,
7. automatic association of acknowledgments with the messages to which they refer, and
8. message duplicate detection, replay prevention, or other stream-oriented services.
An important goal is that privacy enhancement mechanisms impose a minimum of burden on the users they serve. In particular, this goal suggests eventual automation of the key management mechanisms supporting message encryption and authentication. In order to facilitate deployment and testing of pilot privacy enhancement implementations in the near term, however, compatibility with out-of-band (e.g., manual) key distribution must also be supported.
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.
Linn [Page 5]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.
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 quantities (MICs). 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. An IK may be a single symmetric cryptographic key or, where asymmetric (public-key) cryptography is used to encrypt DEKs, the composition of a public component used by an originator and a secret component used by a recipient. Ordinarily, the same IK will be used for all messages sent between a given originator-recipient pair over a period of time. Each transmitted message includes a representation of the DEK(s) used for message encryption and/or authentication, encrypted under an individual IK per named recipient. This representation is associated with sender and recipient identification header fields, which enable recipients to identify the IKs used. With this information, the recipient can decrypt the transmitted DEK representation, yielding the DEK required for message text decryption and/or MIC verification.
When privacy enhancement processing is to be performed on an outgoing message, a DEK is generated [1] for use in message encryption and a variant of the DEK is formed (if the chosen MIC algorithm requires a key) for use in MIC computation. An "X-Sender-ID:" field is included in the header to provide one identification component for the IK(s) used for message processing. An IK is selected for each individually identified 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 the DEK and computed MIC. The DEK and MIC are encrypted for transmission under the appropriate IK.
Linn [Page 6]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 system to be decrypted on a different type. A plaintext message is accepted in local form, using the host's native character set and 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 encryption and MIC computation 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 explicitly excluded from encryption). The canonically encoded representation is encoded, after encryption, 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. The MIC is verified. Encrypted portions of the transmitted message are decrypted, and 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 ISO draft international standard DIS 8227 [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 DIS 8372 [4]. The CBC mode definition in DIS 8372 is equivalent to that provided in FIPS PUB 81 [5]. A unique initializing vector (IV) will be generated for and transmitted with each privacy-enhanced electronic mail message.
Linn [Page 7]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
An algorithm other than DEA-1 may be employed, provided that it satisfies the following requirements:
1. It must be a 64-bit block cipher, enciphering and deciphering in 8-octet blocks.
2. It is usable in the ECB and CBC modes defined in DIS 8372.
3. It is able to be keyed using the procedures and parameters defined in this RFC.
4. It is appropriate for MIC computation, if the selected MIC computation algorithm is eCcryption-based.
5. Cryptographic key field lengths are limited to 16 octets in length.
Certain operations require that one key be encrypted under another key (interchange key) for purposes of transmission. This encryption may be performed using symmetric cryptography by using DEA-1 in Electronic Codebook (ECB) mode. A header facility is available to indicate that an associated key is to be used for encryption in another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used for key encryption and decryption with pairs of 64-bit keys, as described by ASC X3T1 [6], or public-key algorithms).
Support of public key algorithms for key encryption is under active consideration, and it is intended that the procedures defined in this RFC be appropriate to allow such usage. Support of key encryption modes other than ECB is optional for implementations, however. Therefore, in support of universal interoperability, interchange key providers should not specify other modes in the absence of a priori information indicating that recipients are equipped to perform key encryption in other modes.
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 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
Linn [Page 8]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 encode 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.
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(tm) 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.
Linn [Page 9]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.
A sender may exclude one or more portions of a message from encryption processing. 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 the universal canonical form, equivalent 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. 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 destination system before any conversion necessary to transform the message into a destination-specific local form is performed.
Linn [Page 10]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 excluded from encryption from the total length of the encapsulated 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
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.
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
Linn [Page 11]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
from encipherment processing. The encoding function's output is delimited into text lines (using local conventions), with each line containing 64 printable characters.
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 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 1, 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. In other words, 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.
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)))
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.
Linn [Page 12]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 delimit portions of an encoded message to which encryption processing has not been applied.
Printable Encoding Characters Table 1
4.4 Encapsulation Mechanism
Encapsulation of privacy-enhanced messages within an enclosing layer 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.
Linn [Page 13]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.
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-IV:", "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 "Subject:", etc.)
Post-Encapsulation Boundary (Post-EB) -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Message Encapsulation 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
Linn [Page 14]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the encapsulated text and include those replicated fields in encryption and MIC computations.
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 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.
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- perrecipient method. The choice depends on the information available to 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- perlist), 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 public-key cryptography, the secret component of the composite IK 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 or component, 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.
Linn [Page 15]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 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- perrecipient 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 Added Header and Control Fields
This section summarizes the syntax and semantics of the new encapsulated header fields to be added to messages in the course of privacy enhancement processing. In certain indicated cases, it is recommended that the fields be replicated within the encapsulated text portion as well. Figure 2 shows the appearance of a small example encapsulated message using these fields. The example assumes the use of symmetric cryptography; no "X-Certificate:" field is carried. In all cases, hexadecimal quantities are represented as contiguous strings of digits, where each digit is represented by a character from the ranges "0"-"9" or upper case "A"-"F". Unless otherwise specified, all arguments are to be processed in a casesensitive fashion.
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 between the subfields of these fields to fold them 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.
Linn [Page 16]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
-----PRIVACY-ENHANCED MESSAGE BOUNDARY----- X-Proc-Type: 2 X-IV: F8143EDE5960C597 X-Sender-ID: [email protected]::: X-Recipient-ID: [email protected]:ptf-kmc:3:BMAC:ECB X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD X-Recipient-ID: [email protected]:ptf-kmc:4:BMAC:ECB X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message Figure 2
4.6.1 X-Certificate Field
The X-Certificate encapsulated header field is used only when public-key certificate key management is employed. It transfers a sender's certificate as a string of hexadecimal digits. The semantics of a certificate are discussed in Section 5.3, Certificates. The certificate carried in an X-Certificate field is used in conjunction with all subsequent X-Sender-ID and X-RecipientID fields until another X-Certificate field occurs; the ordinary case will be that only a single X-Certificate field will occur, prior to any X-Sender-ID and X-Recipient-ID fields.
Due to the length of a certificate, it may need to be folded across multiple printed lines. In order to enable such folding to be performed, the hexadecimal digits representing the contents of a certificate are to be divided into an ordered set (with more significant digits first) of zero or more 64-digit groups, followed by a final digit group which may be any length up to 64-digits. A single whitespace character is interposed between each pair of groups so that folding (per RFC-822, section 3.1.1) may take place; this whitespace is ignored in parsing the received digit string.
4.6.2 X-IV Field
The X-IV encapsulated header field carries the Initializing Vector used for message encryption. Only one X-IV field occurs in a message. It appears in all messages, even if the entirety of message text is excluded from encryption. Following the field name, and one or more delimiting whitespace characters, a 64-bit Initializing Vector is represented as a contiguous string of 16 hexadecimal
Linn [Page 17]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
digits.
4.6.3 X-Key-Info Field
The X-Key-Info encapsulated header field transfers two items: a DEK and a MIC. One X-Key-Info field is included for each of a message's named recipients. 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. For DEA-1, 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. MICs are also represented as contiguous strings of hexadecimal digits. The size of a MIC is dependent on the choice of MIC algorithm as specified in the X-Recipient-ID field corresponding to a given recipient.
4.6.4 X-Proc-Type Field
The X-Proc-Type encapsulated header field identifies the type of processing performed on the transmitted message. Only one X-ProcType field occurs in a message. It has one subfield, 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 "2".
4.6.5 X-Sender-ID Field
The X-Sender-ID encapsulated header field provides the sender's interchange key identification component. It should be replicated within the encapsulated text. The interchange key 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, an (optional) Version/Expiration subfield, and an (optional) IK Use Indicator subfield. The optional subfields are omitted if their use is rendered redundant by information carried in subsequent X-RecipientID 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.
Linn [Page 18]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.6 X-Recipient-ID Field
The X-Recipient-ID encapsulated header field provides the recipient's interchange key 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, a Version/Expiration subfield, a MIC algorithm indicator subfield, and an IK Use Indicator subfield. The subfields are delimited by the colon character (":"), optionally followed by whitespace.
The MIC algorithm indicator is an ASCII string, selected from the values defined in Appendix A of this RFC. Section 5.2, Interchange Keys, discusses the semantics of the other 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 XSender-ID field; it is illegal for an X-Recipient-ID field to occur in a header before an X-Sender-ID has been provided.
5. Key Management
Several cryptographic constructs are involved in supporting the privacy-enhanced message processing procedure. While (as noted in the Executive Summary section of this RFC), key management mechanisms have not yet been fully defined, a set of fundamental elements are assumed. Data Encrypting Keys (DEKs) are used to encrypt message text and in the message integrity check (MIC) computation process. Interchange Keys (IKs) are used to encrypt DEKs for transmission with messages. In an asymmetric key management architecture, certificates are used as a means to provide entities' public key 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 for computation of message integrity check quantities (MICs). It is strongly recommended that DEKs be generated and used on a one-time basis. A transmitted message will incorporate a representation of the DEK encrypted under an appropriate interchange key (IK) for each the authorized recipient.
Linn [Page 19]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
DEK generation can be performed either centrally by key distribution centers (KDCs) or by endpoint systems. Dedicated KDC systems may be able to implement better 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 secret IK components need not necessarily be shared with a KDC.
5.2 Interchange Keys (IKs)
Interchange Keys (IKs) are used to encrypt Data Encrypting Keys. 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 share a common interchange key. When symmetric cryptography is used, the interchange key consists of a single component. When asymmetric cryptography is used, an originator and recipient must possess an asymmetric key's public and secret components, as appropriate. This pair of components, when composed, constitute an interchange key.
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 an IA generates and distributes an IK, associated control information is provided to direct how that IK is to be used. In order to select the appropriate IK 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.
Linn [Page 20]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
Since a message may be sent with multiple IK component representations, corresponding to multiple intended recipients, each recipient must be able to determine which IK component is intended for it. Moreover, if no corresponding IK component is available in the recipient's database when a message arrives, the recipient must be able to determine which IK component to request and to 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 IK components used for DEK 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. Indicator of IK usage mode (IK use indicator subfield).
4. 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: [email protected]:ptf-kmc:2:BMAC:ECB
This example field indicates that IA "ptf-kmc" has issued an IK component for use on messages sent to "[email protected]", that the IA
Linn [Page 21]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
has provided the number 2 as a version indicator for that IK component, that the BMAC MIC computation algorithm is to be used for the recipient, and that the IK component is to be used in ECB mode.
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 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.1.4 MIC Algorithm Identifier Subfield
The MIC algorithm identifier, which occurs only within X-Recipient-ID fields, is used to identify the choice of message integrity check algorithm for a given recipient. Appendix A of this RFC specifies the defined values for this subfield.
Linn [Page 22]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
5.2.1.5 IK Use Indicator Subfield
The IK use indicator subfield is an optional facility, provided to identify the encryption mode in which an IK component is to be used. Currently, this subfield may assume the following reserved string values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the default value is "ECB".
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.
5.3 Certificates
In an asymmetric key management architecture, a certificate binds an entity's public key component to a representation of the entity's identity and other attributes of the entity. A certificate's issuing authority signs the certificate, vouching for the correspondence between the entity's identity, attributes, and associated public key component. Once signed, certificate copies may be posted on multiple servers in order to make recipients' certificates directly accessible to originators at dispersed locations. This allows privacy-enhanced mail to be sent between an originator and a recipient without prior placement of a pairwise key at the originator and recipient, greatly enhancing mail system flexibility. The properties of a certificate's authority-applied signature make it unnecessary to be concerned about the prospect that servers, or other entities, could undetectably modify certificate contents so as to associate a public key with an inappropriate entity.
Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a subject's certificate is defined to contain the following parameters:
1. A signature algorithm identifier, identifying the algorithm used by the certificate's issuer to compute the signature applied to the certificate.
Linn [Page 23]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
2. Issuer identification, identifying the certificate's issuer with an O/R name.
3. Validity information, providing date and time limits before and after which the certificate should not be used.
4. Subject identification, identifying the certificate's subject with an O/R name.
5. Subject's public key.
6. Algorithm identifier, identifying the algorithm with which the subject's public key is to be used.
7. Signature, an asymmetrically encrypted, hashed version of the above parameters, computed by the certificate's issuer.
The Recommendations specify an ASN.1 encoding to define a certificate. Pending further study, it is recommended that electronic mail privacy enhancement implementations using asymmetric cryptography for key management employ this encoding for certificates. Section 4.2.3 of RFC-987 [14] specifies a procedure for mapping RFC-822 addresses into the O/R names used in X.411/X.509 certificates.
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 requiring significant study. A logical association exists between key distribution and name/directory server functions; their relationship is a topic deserving further consideration. These issues have not been fully resolved at this writing. The current architecture relies on association of IK components with user names represented in a universal form ("user@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 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.
Linn [Page 24]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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. 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 invoked by a user, and lies above the existing UA sublayer. In the UNIX(tm) 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
Linn [Page 25]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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, 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 pilot 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 functions.
2. Standardization of Issuing Authority functions, including protocols for communications among IAs and between User Agents and IAs.
3. Specification of public key encryption algorithms to encrypt data encrypting keys.
4. Interoperability with X.400 mail.
Linn [Page 26]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.
A. Message Integrity Check Algorithms
This appendix identifies the alternative algorithms which may be used to compute Message Integrity Check (MIC) values, and assigns them character string identifiers to be incorporated in "X-Recipient-ID:" fields to indicate the choice of algorithm employed for individual message recipients.
MIC algorithms which utilize DEA-1 cryptography are computed using a key which is a variant of the DEK used for message text encryption. The variant is formed by modulo-2 addition of the hexadecimal quantity F0F0F0F0F0F0F0F0 to the encryption DEK.
A.1 Conventional MAC (MAC)
A conventional MAC, denoted by the string "MAC", is computed using the DEA-1 algorithm in the fashion defined in FIPS PUB 113 [15]. Use of the conventional MAC is not recommended for multicast messages. The message's encapsulated text is padded at the end, per FIPS PUB 113, with zero-valued octets as needed in order to form an integral number of 8-octet encryption quanta. These padding octets are
Linn [Page 27]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
inserted implicitly and are not transmitted with a message. The result of a conventional MAC computation is a single 64-bit value.
A.2 Bidirectional MAC (BMAC)
A bidirectional MAC, denoted by the string "BMAC", yields a result which is transferred as a single 128-bit value. The BMAC is computed in the following manner: First, the encapsulated text is padded at the end with zero-valued octets as needed in order to form an integral number of 8-octet encryption quanta. These padding octets are inserted implicitly and are not transmitted with a message. A conventional MAC is computed on the padded form, and the resulting 64-bits form the high-order 64-bits of the BMAC result.
The low-order 64-bits of the BMAC result are also formed by computing a conventional MAC, but the order of the 8-octet encryption quanta is reversed for purposes of computation. In other words, the first quantum entered into this computation is the last quantum in the encapsulated text, and includes any added padding. The first quantum in the text is the last quantum processed as input to this computation. The octets within each 8-octet quantum are not reordered.
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.
[2] Information Processing Systems: Data Encipherment: Block Cipher Algorithm DEA 1.
[3] Federal Information Processing Standards Publication 46, Data Encryption Standard, 15 January 1977.
[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] Addendum to the Transport Layer Protocol Definition for Providing Connection Oriented End to End Cryptographic Data Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft of 19 December 1985, Gaithersburg, MD, p. 15.
Linn [Page 28]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
[7] Postel, J., Simple Mail Transfer Protocol (RFC-821), 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. T. and Stefferud, E. A., 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. E., Mapping between X.400 and RFC-822 (RFC-987), June 1986.
[15] Federal Information Processing Standards Publication 113, Computer Data Authentication, May 1985.
Linn [Page 29]