diff options
Diffstat (limited to 'doc/rfc/rfc1421.txt')
| -rw-r--r-- | doc/rfc/rfc1421.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc1421.txt b/doc/rfc/rfc1421.txt new file mode 100644 index 0000000..373e217 --- /dev/null +++ b/doc/rfc/rfc1421.txt @@ -0,0 +1,2355 @@ + + + + + + +Network Working Group J. Linn +Request for Comments: 1421 IAB IRTF PSRG, IETF PEM WG +Obsoletes: 1113 February 1993 + + + Privacy Enhancement for Internet Electronic Mail: + Part I: Message Encryption and Authentication Procedures + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Acknowledgements + + This document is the outgrowth of a series of meetings of the Privacy + and Security Research Group (PSRG) of the IRTF and the PEM Working + Group of the IETF. I would like to thank the members of the PSRG and + the IETF PEM WG, as well as all participants in discussions on the + "pem-dev@tis.com" mailing list, for their contributions to this + document. + +1. Executive Summary + + This document defines message encryption and authentication + procedures, in order to provide privacy-enhanced mail (PEM) services + for electronic mail transfer in the Internet. It is intended to + become one member of a related set of four RFCs. The procedures + defined in the current document are intended to be compatible with a + wide range of key management approaches, including both symmetric + (secret-key) and asymmetric (public-key) approaches for encryption of + data encrypting keys. Use of symmetric cryptography for message text + encryption and/or integrity check computation is anticipated. RFC + 1422 specifies supporting key management mechanisms based on the use + of public-key certificates. RFC 1423 specifies algorithms, modes, + and associated identifiers relevant to the current RFC and to RFC + 1422. RFC 1424 provides details of paper and electronic formats and + procedures for the key management infrastructure being established in + support of these services. + + Privacy enhancement services (confidentiality, authentication, + message integrity assurance, and non-repudiation of origin) are + offered through the use of end-to-end cryptography between originator + and recipient processes at or above the User Agent level. No special + processing requirements are imposed on the Message Transfer System at + + + +Linn [Page 1] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + endpoints or at intermediate relay sites. This approach allows + privacy enhancement facilities to be incorporated selectively on a + site-by-site or user-by-user basis without impact on other Internet + entities. Interoperability among heterogeneous components and mail + transport facilities is supported. + + The current specification's scope is confined to PEM processing + procedures for the RFC-822 textual mail environment, and defines the + Content-Domain indicator value "RFC822" to signify this usage. + Follow-on work in integration of PEM capabilities with other + messaging environments (e.g., MIME) is anticipated and will be + addressed in separate and/or successor documents, at which point + additional Content-Domain indicator values will be defined. + +2. Terminology + + For descriptive purposes, this RFC uses some terms defined in the OSI + X.400 Message Handling System Model per the CCITT Recommendations. + This section replicates a portion of (1984) X.400's Section 2.2.1, + "Description of the MHS Model: Overview" in order to make the + terminology clear to readers who may not be familiar with the OSI MHS + Model. + + In the [MHS] model, a user is a person or a computer application. A + user is referred to as either an originator (when sending a message) + or a recipient (when receiving one). MH Service elements define the + set of message types and the capabilities that enable an originator + to transfer messages of those types to one or more recipients. + + An originator prepares messages with the assistance of his or her + User Agent (UA). A UA is an application process that interacts with + the Message Transfer System (MTS) to submit messages. The MTS + delivers to one or more recipient UAs the messages submitted to it. + Functions performed solely by the UA and not standardized as part of + the MH Service elements are called local UA functions. + + The MTS is composed of a number of Message Transfer Agents (MTAs). + Operating together, the MTAs relay messages and deliver them to the + intended recipient UAs, which then make the messages available to the + intended recipients. + + The collection of UAs and MTAs is called the Message Handling System + (MHS). The MHS and all of its users are collectively referred to as + the Message Handling Environment. + + + + + + + +Linn [Page 2] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + +3. Services, Constraints, and Implications + + This RFC defines mechanisms to enhance privacy for electronic mail + transferred in the Internet. The facilities discussed in this RFC + provide privacy enhancement services on an end-to-end basis between + originator and recipient processes residing at the UA level or above. + No privacy enhancements are offered for message fields which are + added or transformed by intermediate relay points between PEM + processing components. + + If an originator elects to perform PEM processing on an outbound + message, all PEM-provided security services are applied to the PEM + message's body in its entirety; selective application to portions of + a PEM message is not supported. Authentication, integrity, and (when + asymmetric key management is employed) non-repudiation of origin + services are applied to all PEM messages; confidentiality services + are optionally selectable. + + In keeping with the Internet's heterogeneous constituencies and usage + modes, the measures defined here are applicable to a broad range of + Internet hosts and usage paradigms. In particular, it is worth + noting the following attributes: + + 1. The mechanisms defined in this RFC are not restricted to a + particular host or operating system, but rather allow + interoperability among a broad range of systems. All + privacy enhancements are implemented at the application + layer, and are not dependent on any privacy features at + lower protocol layers. + + 2. The defined mechanisms are compatible with non-enhanced + Internet components. Privacy enhancements are implemented + in an end-to-end fashion which does not impact mail + processing by intermediate relay hosts which do not + incorporate privacy enhancement facilities. It is + necessary, however, for a message's originator to be + cognizant of whether a message's intended recipient + implements privacy enhancements, in order that encoding and + possible encryption will not be performed on a message whose + destination is not equipped to perform corresponding inverse + transformations. (Section 4.6.1.1.3 of this RFC describes a + PEM message type ("MIC-CLEAR") which represents a signed, + unencrypted PEM message in a form readable without PEM + processing capabilities yet validatable by PEM-equipped + recipients.) + + 3. The defined mechanisms are compatible with a range of mail + transport facilities (MTAs). Within the Internet, + + + +Linn [Page 3] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + electronic mail transport is effected by a variety of SMTP + [2] implementations. Certain sites, accessible via SMTP, + forward mail into other mail processing environments (e.g., + USENET, CSNET, BITNET). The privacy enhancements must be + able to operate across the SMTP realm; it is desirable that + they also be compatible with protection of electronic mail + sent between the SMTP environment and other connected + environments. + + 4. The defined mechanisms are compatible with a broad range of + electronic mail user agents (UAs). A large variety of + electronic mail user agent programs, with a corresponding + broad range of user interface paradigms, is used in the + Internet. In order that electronic mail privacy + enhancements be available to the broadest possible user + community, selected mechanisms should be usable with the + widest possible variety of existing UA programs. For + purposes of pilot implementation, it is desirable that + privacy enhancement processing be incorporable into a + separate program, applicable to a range of UAs, rather than + requiring internal modifications to each UA with which PEM + services are to be provided. + + 5. The defined mechanisms allow electronic mail privacy + enhancement processing to be performed on personal computers + (PCs) separate from the systems on which UA functions are + implemented. Given the expanding use of PCs and the limited + degree of trust which can be placed in UA implementations on + many multi-user systems, this attribute can allow many users + to process PEM with a higher assurance level than a strictly + UA-integrated approach would allow. + + 6. The defined mechanisms support privacy protection of + electronic mail addressed to mailing lists (distribution + lists, in ISO parlance). + + 7. The mechanisms defined within this RFC are compatible with a + variety of supporting key management approaches, including + (but not limited to) manual pre-distribution, centralized + key distribution based on symmetric cryptography, and the + use of public-key certificates per RFC 1422. Different + key management mechanisms may be used for different + recipients of a multicast message. For two PEM + implementations to interoperate, they must share a common + key management mechanism; support for the mechanism defined + in RFC 1422 is strongly encouraged. + + + + + +Linn [Page 4] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + In order to achieve applicability to the broadest possible range of + Internet hosts and mail systems, and to facilitate pilot + implementation and testing without the need for prior and pervasive + modifications throughout the Internet, the following design + principles were applied in selecting the set of features specified in + this RFC: + + 1. This RFC's measures are restricted to implementation at + endpoints and are amenable to integration with existing + Internet mail protocols at the user agent (UA) level or + above, rather than necessitating modifications to existing + mail protocols or integration into the message transport + system (e.g., SMTP servers). + + 2. The set of supported measures enhances rather than restricts + user capabilities. Trusted implementations, incorporating + integrity features protecting software from subversion by + local users, cannot be assumed in general. No mechanisms + are assumed to prevent users from sending, at their + discretion, messages to which no PEM processing has been + applied. In the absence of such features, it appears more + feasible to provide facilities which enhance user services + (e.g., by protecting and authenticating inter-user traffic) + than to enforce restrictions (e.g., inter-user access + control) on user actions. + + 3. The set of supported measures focuses on a set of functional + capabilities selected to provide significant and tangible + benefits to a broad user community. By concentrating on the + most critical set of services, we aim to maximize the added + privacy value that can be provided with a modest level of + implementation effort. + + Based on these principles, the following facilities are provided: + + 1. disclosure protection, + + 2. originator authenticity, + + 3. message integrity measures, and + + 4. (if asymmetric key management is used) non-repudiation of + origin, + + but the following privacy-relevant concerns are not addressed: + + 1. access control, + + + + +Linn [Page 5] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + 2. traffic flow confidentiality, + + 3. address list accuracy, + + 4. routing control, + + 5. issues relating to the casual serial reuse of PCs by + multiple users, + + 6. assurance of message receipt and non-deniability of receipt, + + 7. automatic association of acknowledgments with the messages + to which they refer, and + + 8. message duplicate detection, replay prevention, or other + stream-oriented services + +4. Processing of Messages + +4.1 Message Processing Overview + + This subsection provides a high-level overview of the components and + processing steps involved in electronic mail privacy enhancement + processing. Subsequent subsections will define the procedures in + more detail. + +4.1.1 Types of Keys + + A two-level keying hierarchy is used to support PEM transmission: + + 1. Data Encrypting Keys (DEKs) are used for encryption of + message text and (with certain choices among a set of + alternative algorithms) for computation of message integrity + check (MIC) quantities. In the asymmetric key management + environment, DEKs are also used to encrypt the signed + representations of MICs in PEM messages to which + confidentiality has been applied. DEKs are generated + individually for each transmitted message; no + predistribution of DEKs is needed to support PEM + transmission. + + 2. Interchange Keys (IKs) are used to encrypt DEKs for + transmission within messages. Ordinarily, the same IK will + be used for all messages sent from a given originator to a + given recipient over a period of time. Each transmitted + message includes a representation of the DEK(s) used for + message encryption and/or MIC computation, encrypted under + an individual IK per named recipient. The representation is + + + +Linn [Page 6] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + associated with Originator-ID and Recipient-ID fields + (defined in different forms so as to distinguish symmetric + from asymmetric cases), which allow each individual + recipient to identify the IK used to encrypt DEKs and/or + MICs for that recipient's use. Given an appropriate IK, a + recipient can decrypt the corresponding transmitted DEK + representation, yielding the DEK required for message text + decryption and/or MIC validation. The definition of an IK + differs depending on whether symmetric or asymmetric + cryptography is used for DEK encryption: + + 2a. When symmetric cryptography is used for DEK + encryption, an IK is a single symmetric key shared + between an originator and a recipient. In this + case, the same IK is used to encrypt MICs as well + as DEKs for transmission. Version/expiration + information and IA identification associated with + the originator and with the recipient must be + concatenated in order to fully qualify a symmetric + IK. + + 2b. When asymmetric cryptography is used, the IK + component used for DEK encryption is the public + component [8] of the recipient. The IK component + used for MIC encryption is the private component of + the originator, and therefore only one encrypted + MIC representation need be included per message, + rather than one per recipient. Each of these IK + components can be fully qualified in a Recipient-ID + or Originator-ID field, respectively. + Alternatively, an originator's IK component may be + determined from a certificate carried in an + "Originator-Certificate:" field. + +4.1.2 Processing Procedures + + When PEM processing is to be performed on an outgoing message, a DEK + is generated [1] for use in message encryption and (if a chosen MIC + algorithm requires a key) a variant of the DEK is formed for use in + MIC computation. DEK generation can be omitted for the case of a + message where confidentiality is not to be applied, unless a chosen + MIC computation algorithm requires a DEK. Other parameters (e.g., + Initialization Vectors (IVs)) as required by selected encryption + algorithms are also generated. + + One or more Originator-ID and/or "Originator-Certificate:" fields are + included in a PEM message's encapsulated header to provide recipients + with an identification component for the IK(s) used for message + + + +Linn [Page 7] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + processing. All of a message's Originator-ID and/or "Originator- + Certificate:" fields are assumed to correspond to the same principal; + the facility for inclusion of multiple such fields accomodates the + prospect that different keys, algorithms, and/or certification paths + may be required for processing by different recipients. When a + message includes recipients for which asymmetric key management is + employed as well as recipients for which symmetric key management is + employed, a separate Originator-ID or "Originator-Certificate:" field + precedes each set of recipients. + + In the symmetric case, per-recipient IK components are applied for + each individually named recipient in preparation of ENCRYPTED, MIC- + ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID- + Symmetric:" field, interpreted in the context of the most recent + preceding "Originator-ID-Symmetric:" field, serves to identify each + IK. In the asymmetric case, per-recipient IK components are applied + only for ENCRYPTED messages, are independent of originator-oriented + header elements, and are identified by "Recipient-ID-Asymmetric:" + fields. Each Recipient-ID field is followed by a "Key-Info:" field, + which transfers the message's DEK encrypted under the IK appropriate + for the specified recipient. + + When symmetric key management is used for a given recipient, the + "Key-Info:" field following the corresponding "Recipient-ID- + Symmetric:" field also transfers the message's computed MIC, + encrypted under the recipient's IK. When asymmetric key management is + used, a "MIC-Info:" field associated with an "Originator-ID- + Asymmetric:" or "Originator-Certificate:" field carries the message's + MIC, asymmetrically signed using the private component of the + originator. If the PEM message is of type ENCRYPTED (as defined in + Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is + symmetrically encrypted using the same DEK, algorithm, encryption + mode and other cryptographic parameters as used to encrypt the + message text, prior to inclusion in the "MIC-Info:" field. + +4.1.2.1 Processing Steps + + A four-phase transformation procedure is employed in order to + represent encrypted message text in a universally transmissible form + and to enable messages encrypted on one type of host computer to be + decrypted on a different type of host computer. A plaintext message + is accepted in local form, using the host's native character set and + line representation. The local form is converted to a canonical + message text representation, defined as equivalent to the inter-SMTP + representation of message text. This canonical representation forms + the input to the MIC computation step (applicable to ENCRYPTED, MIC- + ONLY, and MIC-CLEAR messages) and the encryption process (applicable + to ENCRYPTED messages only). + + + +Linn [Page 8] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + For ENCRYPTED PEM messages, the canonical representation is padded as + required by the encryption algorithm, and this padded canonical + representation is encrypted. The encrypted text (for an ENCRYPTED + message) or the unpadded canonical form (for a MIC-ONLY message) is + then encoded into a printable form. The printable form is composed + of a restricted character set which is chosen to be universally + representable across sites, and which will not be disrupted by + processing within and between MTS entities. MIC-CLEAR PEM messages + omit the printable encoding step. + + The output of the previous processing steps is combined with a set of + header fields carrying cryptographic control information. The + resulting PEM message is passed to the electronic mail system to be + included within the text portion of a transmitted message. There is + no requirement that a PEM message comprise the entirety of an MTS + message's text portion; this allows PEM-protected information to be + accompanied by (unprotected) annotations. It is also permissible for + multiple PEM messages (and associated unprotected text, outside the + PEM message boundaries) to be represented within the encapsulated + text of a higher-level PEM message. PEM message signatures are + forwardable when asymmetric key management is employed; an authorized + recipient of a PEM message with confidentiality applied can reduce + that message to a signed but unencrypted form for forwarding purposes + or can re-encrypt that message for subsequent transmission. + + When a PEM message is received, the cryptographic control fields + within its encapsulated header provide the information required for + each authorized recipient to perform MIC validation and decryption of + the received message text. For ENCRYPTED and MIC-ONLY messages, the + printable encoding is converted to a bitstring. Encrypted portions + of the transmitted message are decrypted. The MIC is validated. + Then, the recipient PEM process converts the canonical representation + to its appropriate local form. + +4.1.2.2 Error Cases + + A variety of error cases may occur and be detected in the course of + processing a received PEM message. The specific actions to be taken + in response to such conditions are local matters, varying as + functions of user preferences and the type of user interface provided + by a particular PEM implementation, but certain general + recommendations are appropriate. Syntactically invalid PEM messages + should be flagged as such, preferably with collection of diagnostic + information to support debugging of incompatibilities or other + failures. RFC 1422 defines specific error processing requirements + relevant to the certificate-based key management mechanisms defined + therein. + + + + +Linn [Page 9] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + Syntactically valid PEM messages which yield MIC failures raise + special concern, as they may result from attempted attacks or forged + messages. As such, it is unsuitable to display their contents to + recipient users without first indicating the fact that the contents' + authenticity and integrity cannot be guaranteed and then receiving + positive user confirmation of such a warning. MIC-CLEAR messages + (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns, + as MIC failures on such messages may occur for a broader range of + benign causes than are applicable to other PEM message types. + +4.2 Encryption Algorithms, Modes, and Parameters + + For use in conjunction with this RFC, RFC 1423 defines the + appropriate algorithms, modes, and associated identifiers to be used + for encryption of message text with DEKs. + + The mechanisms defined in this RFC incorporate facilities for + transmission of cryptographic parameters (e.g., pseudorandom + Initializing Vectors (IVs)) with PEM messages to which the + confidentiality service is applied, when required by symmetric + message encryption algorithms and modes specified in RFC 1423. + + Certain operations require encryption of DEKs, MICs, and digital + signatures under an IK for purposes of transmission. A header + facility indicates the mode in which the IK is used for encryption. + RFC 1423 specifies encryption algorithm and mode identifiers and + minimum essential support requirements for key encryption processing. + + RFC 1422 specifies asymmetric, certificate-based key management + procedures based on CCITT Recommendation X.509 to support the message + processing procedures defined in this document. Support for the key + management approach defined in RFC 1422 is strongly recommended. The + message processing procedures can also be used with symmetric key + management, given prior distribution of suitable symmetric IKs, but + no current RFCs specify key distribution procedures for such IKs. + +4.3 Privacy Enhancement Message Transformations + +4.3.1 Constraints + + An electronic mail encryption mechanism must be compatible with the + transparency constraints of its underlying electronic mail + facilities. These constraints are generally established based on + expected user requirements and on the characteristics of anticipated + endpoint and transport facilities. An encryption mechanism must also + be compatible with the local conventions of the computer systems + which it interconnects. Our approach uses a canonicalization step to + abstract out local conventions and a subsequent encoding step to + + + +Linn [Page 10] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + conform to the characteristics of the underlying mail transport + medium (SMTP). The encoding conforms to SMTP constraints. Section + 4.5 of RFC 821 [2] details SMTP's transparency constraints. + + To prepare a message for SMTP transmission, the following + requirements must be met: + + 1. All characters must be members of the 7-bit ASCII character + set. + + 2. Text lines, delimited by the character pair <CR><LF>, must + be no more than 1000 characters long. + + 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 in the Internet use a different + native representation to delimit lines. For example, the <CR><LF> + sequences delimiting lines in mail inbound to UNIX systems are + transformed to single <LF>s as mail is written into local mailbox + files. Lines in mail incoming to record-oriented systems (such as + VAX VMS) may be converted to appropriate records by the destination + SMTP server [3]. 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 11] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + +4.3.2 Approach + + Our approach to supporting PEM across an environment in which + intermediate conversions may occur defines an encoding for mail which + is uniformly representable across the set of PEM UAs regardless of + their systems' native character sets. This encoded form is used (for + specified PEM message types) to represent mail text in transit from + originator to recipient, but the encoding is not applied to enclosing + MTS headers or to encapsulated headers inserted to carry control + information between PEM UAs. The encoding's characteristics are such + that the transformations anticipated between originator and recipient + UAs will not prevent an encoded message from being decoded properly + at its destination. + + Four transformation steps, described in the following four + subsections, apply to outbound PEM message processing: + +4.3.2.1 Step 1: Local Form + + This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and + MIC-CLEAR. 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 + + This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and + MIC-CLEAR. The message text is converted to a universal canonical + form, similar to the inter-SMTP representation [4] as defined in RFC + 821 [2] and RFC 822 [5]. The procedures performed in order to + accomplish this conversion are dependent on the characteristics of + the local form and so are not specified in this RFC. + + PEM canonicalization assures that the message text is represented + with the ASCII character set and "<CR><LF>" line delimiters, but does + not perform the dot-stuffing transformation discussed in RFC 821, + Section 4.5.2. Since a message is converted to a standard character + set and representation before encryption, a transferred PEM message + can be decrypted and its MIC can be validated at any type of + destination host computer. Decryption and MIC validation is + performed before any conversions which may be necessary to transform + the message into a destination-specific local form. + +4.3.2.3 Step 3: Authentication and Encryption + + Authentication processing is applicable to PEM message types + ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to + the selected MIC computation algorithm in order to compute an + + + +Linn [Page 12] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + 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. + + Encryption processing is applicable only to PEM message type + ENCRYPTED. RFC 1423 defines the padding technique used to support + encryption of the canonically-encoded message text. + +4.3.2.4 Step 4: Printable Encoding + + This printable encoding step is applicable to PEM message types + ENCRYPTED and MIC-ONLY. The same processing is also employed in + representation of certain specifically identified PEM encapsulated + header field quantities as cited in Section 4.6. Proceeding from + left to right, the bit string resulting from step 3 is encoded into + characters which are universally representable at all sites, though + not necessarily with the same bit patterns (e.g., although the + character "E" is represented in an ASCII-based system as hexadecimal + 45 and as hexadecimal C5 in an EBCDIC-based system, the local + significance of the two representations is equivalent). + + 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.) + The character "=" signifies a special processing function used for + padding within the printable encoding procedure. + + To represent the encapsulated text of a PEM message, the encoding + function's output is delimited into text lines (using local + conventions), with each line except the last containing exactly 64 + printable characters and the final line containing 64 or fewer + printable characters. (This line length is easily printable and is + guaranteed to satisfy SMTP's 1000-character transmitted line length + limit.) This folding requirement does not apply when the encoding + procedure is used to represent PEM header field quantities; Section + 4.6 discusses folding of PEM encapsulated header fields. + + 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>"). + + + + + +Linn [Page 13] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + Special processing is performed if fewer than 24 bits are available + in an input group at the end of a message. A full encoding quantum + is always completed at the end of a message. 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. + + + 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 + + Printable Encoding Characters + Table 1 + + +4.3.2.5 Summary of Transformations + + In summary, the outbound message is subjected to the following + composition of transformations (or, for some PEM message types, a + subset thereof): + + Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form))) + + + +Linn [Page 14] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + The inverse transformations are performed, in reverse order, to + process inbound PEM messages: + + 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 originator and recipient + systems without loss of information. + +4.4 Encapsulation Mechanism + + The encapsulation techniques defined in RFC-934 [6] are adopted for + encapsulation of PEM messages within separate enclosing MTS messages + carrying associated MTS headers. This approach offers a number of + advantages relative to a flat approach in which certain fields within + a single header are encrypted and/or carry cryptographic control + information. As far as the MTS is concerned, the entirety of a PEM + message will reside in an MTS message's text portion, not the MTS + message's header portion. 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. + + The encapsulation techniques defined in RFC-934 are consistent with + existing Internet mail forwarding and bursting mechanisms. These + techniques are designed so that they may be used in a nested manner. + The encapsulation techniques may be used to encapsulate one or more + PEM messages for forwarding to a third party, possibly in conjunction + with interspersed (non-PEM) text which serves to annotate the PEM + messages. + + Two encapsulation boundaries (EB's) are defined for delimiting + encapsulated PEM messages and for distinguishing encapsulated PEM + messages from interspersed (non-PEM) text. The pre-EB is the string + "-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an + encapsulated PEM message follows. The post-EB is either (1) another + pre-EB indicating that another encapsulated PEM message follows, or + (2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating + that any text that immediately follows is non-PEM text. A special + point must be noted for the case of MIC-CLEAR messages, the text + portions of which may contain lines which begin with the "-" + character and which are therefore subject to special processing per + RFC-934 forwarding procedures. When the string "- " must be + prepended to such a line in the course of a forwarding operation in + order to distinguish that line from an encapsulation boundary, MIC + + + +Linn [Page 15] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + computation is to be performed prior to prepending the "- " string. + Figure 1 depicts the encapsulation of a single PEM message. + + This RFC places no a priori limits on the depth to which such + encapsulation may be nested nor on the number of PEM messages which + may be grouped in this fashion at a single nesting level for + forwarding. A implementation compliant with this RFC must not + preclude a user from submitting or receiving PEM messages which + exploit this encapsulation capability. However, no specific + requirements are levied upon implementations with regard to how this + capability is made available to the user. Thus, for example, a + compliant PEM implementation is not required to automatically detect + and process encapsulated PEM messages. + + In using this encapsulation facility, it is important to note that it + is inappropriate to forward directly to a third party a message that + is ENCRYPTED because recipients of such a message would not have + access to the DEK required to decrypt the message. Instead, the user + forwarding the message must transform the ENCRYPTED message into a + MIC-ONLY or MIC-CLEAR form prior to forwarding. Thus, in order to + comply with this RFC, a PEM implementation must provide a facility to + enable a user to perform this transformation, while preserving the + MIC associated with the original message. + + If a user wishes PEM-provided confidentiality protection for + transmitted information, such information must occur in the + encapsulated text of an ENCRYPTED PEM message, not in the enclosing + MTS header or PEM encapsulated header. If a user wishes to avoid + + + + + + + + + + + + + + + + + + + + + + + +Linn [Page 16] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + Encapsulated Message + + Pre-Encapsulation Boundary (Pre-EB) + -----BEGIN PRIVACY-ENHANCED MESSAGE----- + + Encapsulated Header Portion + (Contains encryption control fields inserted in plaintext. + Examples include "DEK-Info:" and "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 + Encapsulated Text Portion) + + Encapsulated Text Portion + (Contains message data encoded as specified in Section 4.3.) + + Post-Encapsulation Boundary (Post-EB) + -----END PRIVACY-ENHANCED MESSAGE----- + + + Encapsulated Message Format + Figure 1 + + + disclosing the actual subject of a message to unintended parties, it + is suggested that the enclosing MTS header contain a "Subject:" field + indicating that "Encrypted Mail Follows". + + If an integrity-protected representation of information which occurs + within an enclosing header (not necessarily in the same format as + that in which it occurs within that header) is desired, that data can + be included within the encapsulated text portion in addition to its + inclusion in the enclosing MTS header. For example, an originator + wishing to provide recipients with a protected indication of a + message's position in a series of messages could include within the + encapsulated text a copy of a timestamp or message counter value + possessing end-to-end significance and extracted from an enclosing + MTS header field. (Note: mailbox specifiers as entered by end users + incorporate local conventions and are subject to modification at + intermediaries, so inclusion of such specifiers within encapsulated + text should not be regarded as a suitable alternative to the + authentication semantics defined in RFC 1422 and based on X.500 + Distinguished Names.) The set of header information (if any) included + within the encapsulated text of messages is a local matter, and this + + + +Linn [Page 17] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + RFC does not specify formatting conventions to distinguish replicated + header fields from other encapsulated text. + +4.5 Mail for Mailing Lists + + When mail is addressed to mailing lists, two different methods of + processing can be applicable: the IK-per-list method and the IK-per- + recipient method. Hybrid approaches are also possible, as in the + case of IK-per-list protection of a message on its path from an + originator to a PEM-equipped mailing list exploder, followed by IK- + per-recipient protection from the exploder to individual list + recipients. + + If a message's originator is equipped to expand a destination mailing + list into its individual constituents and elects to do so (IK-per- + recipient), the message's DEK (and, in the symmetric key management + case, MIC) will be encrypted under each per-recipient IK and all such + encrypted representations will be incorporated into the transmitted + message. Note that per-recipient encryption is required only for the + relatively small DEK and MIC quantities carried in the "Key-Info:" + field, not for the message text which is, in general, much larger. + Although more IKs are involved in processing under the IK-per- + recipient method, the pairwise IKs can be individually revoked and + possession of one IK does not enable a successful masquerade of + another user on the list. + + If a message's originator addresses a message to a list name or + alias, use of an IK associated with that name or alias as a entity + (IK-per-list), rather than resolution of the name or alias to its + constituent destinations, is implied. Such an IK must, therefore, be + available to all list members. Unfortunately, it implies an + undesirable level of exposure for the shared IK, and makes its + revocation difficult. Moreover, use of the IK-per-list method allows + any holder of the list's IK to masquerade as another originator to + the list for authentication purposes. + + Pure IK-per-list key management in the asymmetric case (with a common + private key shared among multiple list members) is particularly + disadvantageous in the asymmetric environment, as it fails to + preserve the forwardable authentication and non-repudiation + characteristics which are provided for other messages in this + environment. Use of a hybrid approach with a PEM-capable exploder is + therefore particularly recommended for protection of mailing list + traffic when asymmetric key management is used; such an exploder + would reduce (per discussion in Section 4.4 of this RFC) incoming + ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding + them (perhaps re-encrypted under individual, per-recipient keys) to + list members. + + + +Linn [Page 18] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + +4.6 Summary of Encapsulated Header Fields + + This section defines the syntax and semantics of the encapsulated + header fields to be added to messages in the course of privacy + enhancement processing. + + The fields are presented in three groups. Normally, the groups will + appear in encapsulated headers in the order in which they are shown, + though not all fields in each group will appear in all messages. The + following figures show the appearance of small example encapsulated + messages. Figure 2 assumes the use of symmetric cryptography for key + management. Figure 3 illustrates an example encapsulated ENCRYPTED + message in which asymmetric key management is used. + + + -----BEGIN PRIVACY-ENHANCED MESSAGE----- + Proc-Type: 4,ENCRYPTED + Content-Domain: RFC822 + DEK-Info: DES-CBC,F8143EDE5960C597 + Originator-ID-Symmetric: linn@zendia.enet.dec.com,, + Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3 + Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A, + B70665BB9BF7CBCDA60195DB94F727D3 + Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4 + Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26, + E2EF532C65CBCFF79F83A2658132DB47 + + LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M + 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk + J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot + dXd/H5LMDWnonNvPCwQUHt== + -----END PRIVACY-ENHANCED MESSAGE----- + + Example Encapsulated Message (Symmetric Case) + Figure 2 + + + Figure 4 illustrates an example encapsulated MIC-ONLY message in + which asymmetric key management is used; since no per-recipient keys + are involved in preparation of asymmetric-case MIC-ONLY messages, + this example should be processable for test purposes by arbitrary PEM + implementations. + + Fully-qualified domain names (FQDNs) for hosts, appearing in the + mailbox names found in entity identifier subfields of "Originator- + ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in + a case-insensitive fashion. Unless specified to the contrary, other + field arguments (including the user name components of mailbox names) + + + +Linn [Page 19] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + are to be processed in a case-sensitive fashion. + + In most cases, numeric quantities are represented in header fields as + contiguous strings of hexadecimal digits, where each digit is + represented by a character from the ranges "0"-"9" or upper case + "A"-"F". Since public-key certificates and quantities encrypted + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Linn [Page 20] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + -----BEGIN PRIVACY-ENHANCED MESSAGE----- + Proc-Type: 4,ENCRYPTED + Content-Domain: RFC822 + DEK-Info: DES-CBC,BFF968AA74691AC1 + Originator-Certificate: + MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV + BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN + BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx + CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU + MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+ + yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F + LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq + iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/ + 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w== + Key-Info: RSA, + I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+ + wGrtiUm/ovtKdinz6ZQ/aQ== + Issuer-Certificate: + MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV + BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL + BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw + CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN + BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw + XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW + cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB + MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx + dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x + EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h + MIC-Info: RSA-MD5,RSA, + UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv + AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG + Recipient-ID-Asymmetric: + MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j + LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=, + 66 + Key-Info: RSA, + O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv + 7x0Z3Jx2vTAhOYHMcqqCjA== + + qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d + jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA== + -----END PRIVACY-ENHANCED MESSAGE----- + + Example Encapsulated ENCRYPTED Message (Asymmetric Case) + Figure 3 + + + + + + +Linn [Page 21] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + using asymmetric algorithms are large in size, use of a more space- + efficient encoding technique is appropriate for such quantities, and + the encoding mechanism defined in Section 4.3.2.4 of this RFC, + representing 6 bits per printed character, is adopted for this + purpose. + + Encapsulated headers of PEM messages are folded using whitespace per + RFC 822 header folding conventions; no PEM-specific conventions are + defined for encapsulated header folding. The example shown in Figure + 4 shows (in its "MIC-Info:" field) an asymmetrically encrypted + quantity in its printably encoded representation, illustrating the + use of RFC 822 folding. + + In contrast to the encapsulated header representations defined in RFC + 1113 and its precursors, the field identifiers adopted in this RFC do + not begin with the prefix "X-" (for example, the field previously + denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes + are not to be emitted by implementations conformant to this RFC. To + simplify transition and interoperability with earlier + implementations, it is suggested that implementations based on this + RFC accept incoming encapsulated header fields carrying the "X-" + prefix and act on such fields as if the "X-" were not present. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Linn [Page 22] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + -----BEGIN PRIVACY-ENHANCED MESSAGE----- + Proc-Type: 4,MIC-ONLY + Content-Domain: RFC822 + Originator-Certificate: + MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV + BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN + BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx + CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU + MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+ + yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F + LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq + iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/ + 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w== + Issuer-Certificate: + MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV + BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL + BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw + CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN + BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw + XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW + cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB + MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx + dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x + EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h + MIC-Info: RSA-MD5,RSA, + jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6 + EtE7K2QDeVMCyXsdJlA8fA== + + LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg + YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo= + -----END PRIVACY-ENHANCED MESSAGE----- + + Example Encapsulated MIC-ONLY Message (Asymmetric Case) + Figure 4 + + +4.6.1 Per-Message Encapsulated Header Fields + + This group of encapsulated header fields contains fields which occur + no more than once in a PEM message, generally preceding all other + encapsulated header fields. + +4.6.1.1 Proc-Type Field + + The "Proc-Type:" encapsulated header field, required for all PEM + messages, identifies the type of processing performed on the + transmitted message. Only one "Proc-Type:" field occurs in a + message; the "Proc-Type:" field must be the first encapsulated header + + + +Linn [Page 23] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + field in the message. + + The "Proc-Type:" field has two subfields, separated by a comma. The + first subfield is a decimal number which is used to distinguish among + incompatible encapsulated header field interpretations which may + arise as changes are made to this standard. Messages processed + according to this RFC will carry the subfield value "4" to + distinguish them from messages processed in accordance with prior PEM + RFCs. The second subfield assumes one of a set of string values, + defined in the following subsections. + +4.6.1.1.1 ENCRYPTED + + The "ENCRYPTED" specifier signifies that confidentiality, + authentication, integrity, and (given use of asymmetric key + management) non-repudiation of origin security services have been + applied to a PEM message's encapsulated text. ENCRYPTED messages + require a "DEK-Info:" field and individual Recipient-ID and "Key- + Info:" fields for all message recipients. + +4.6.1.1.2 MIC-ONLY + + The "MIC-ONLY" specifier signifies that all of the security services + specified for ENCRYPTED messages, with the exception of + confidentiality, have been applied to a PEM message's encapsulated + text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC) + to protect their encapsulated text against modifications at message + transfer or relay points. + + Specification of MIC-ONLY, when applied in conjunction with certain + combinations of key management and MIC algorithm options, permits + certain fields which are superfluous in the absence of encryption to + be omitted from the encapsulated header. In particular, when a + keyless MIC computation is employed for recipients for whom + asymmetric cryptography is used, "Recipient-ID-Asymmetric:" and + "Key-Info:" fields can be omitted. The "DEK-Info:" field can be + omitted for all "MIC-ONLY" messages. + +4.6.1.1.3 MIC-CLEAR + + The "MIC-CLEAR" specifier represents a PEM message with the same + security service selection as for a MIC-ONLY message. The set of + encapsulated header fields required in a MIC-CLEAR message is the + same as that required for a MIC-ONLY message. + + MIC-CLEAR message processing omits the encoding step defined in + Section 4.3.2.4 of this RFC to protect a message's encapsulated text + against modifications within the MTS. As a result, a MIC-CLEAR + + + +Linn [Page 24] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + message's text can be read by recipients lacking access to PEM + software, even though such recipients cannot validate the message's + signature. The canonical encoding discussed in Section 4.3.2.2 is + performed, so interoperation among sites with different native + character sets and line representations is not precluded so long as + those native formats are unambiguously translatable to and from the + canonical form. (Such interoperability is feasible only for those + characters which are included in the canonical representation set.) + + Omission of the printable encoding step implies that MIC-CLEAR + message MICs will be validatable only in environments where the MTS + does not modify messages in transit, or where the modifications + performed can be determined and inverted before MIC validation + processing. Failed MIC validation on a MIC-CLEAR message does not, + therefore, necessarily signify a security-relevant event; as a + result, it is recommended that PEM implementations reflect to their + users (in a suitable local fashion) the type of PEM message being + processed when reporting a MIC validation failure. + + A case of particular relevance arises for inbound SMTP processing on + systems which delimit text lines with local native representations + other than the SMTP-conventional <CR><LF>. When mail is delivered to + a UA on such a system and presented for PEM processing, the <CR><LF> + has already been translated to local form. In order to validate a + MIC-CLEAR message's MIC in this situation, the PEM module must + recanonicalize the incoming message in order to determine the inter- + SMTP representation of the canonically encoded message (as defined in + Section 4.3.2.2 of this RFC), and must compute the reference MIC + based on that representation. + +4.6.1.1.4 CRL + + The "CRL" specifier indicates a special PEM message type, used to + transfer one or more Certificate Revocation Lists. The format of PEM + CRLs is defined in RFC 1422. No user data or encapsulated text + accompanies an encapsulated header specifying the CRL message type; a + correctly-formed CRL message's PEM header is immediately followed by + its terminating message boundary line, with no blank line + intervening. + + Only three types of fields are valid in the encapsulated header + comprising a CRL message. The "CRL:" field carries a printable + representation of a CRL, encoded using the procedures defined in + Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be + followed by no more than one "Originator-Certificate:" field and any + number of "Issuer-Certificate:" fields. The "Originator-Certificate:" + and "Issuer-Certificate:" fields refer to the most recently previous + "CRL:" field, and provide certificates useful in validating the + + + +Linn [Page 25] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + signature included in the CRL. "Originator-Certificate:" and + "Issuer-Certificate:" fields' contents are the same for CRL messages + as they are for other PEM message types. + +4.6.1.2 Content-Domain Field + + The "Content-Domain:" encapsulated header field describes the type of + content which is represented within a PEM message's encapsulated + text. It carries one string argument, whose value is defined as + "RFC822" to indicate processing of RFC-822 mail as defined in this + specification. It is anticipated that additional "Content-Domain:" + values will be defined subsequently, in additional or successor + documents to this specification. Only one "Content-Domain:" field + occurs in a PEM message; this field is the PEM message's second + encapsulated header field, immediately following the "Proc-Type:" + field. + +4.6.1.3 DEK-Info Field + + The "DEK-Info:" encapsulated header field identifies the message text + encryption algorithm and mode, and also carries any cryptographic + parameters (e.g., IVs) used for message encryption. No more than one + "DEK-Info:" field occurs in a message; the field is required for all + messages specified as "ENCRYPTED" in the "Proc-Type:" field. + + The "DEK-Info:" field carries either one argument or two arguments + separated by a comma. The first argument identifies the algorithm + and mode used for message text encryption. The second argument, if + present, carries any cryptographic parameters required by the + algorithm and mode identified in the first argument. Appropriate + message encryption algorithms, modes and identifiers and + corresponding cryptographic parameters and formats are defined in RFC + 1423. + +4.6.2 Encapsulated Header Fields Normally Per-Message + + This group of encapsulated header fields contains fields which + ordinarily occur no more than once per message. Depending on the key + management option(s) employed, some of these fields may be absent + from some messages. + +4.6.2.1 Originator-ID Fields + + Originator-ID encapsulated header fields identify a message's + originator and provide the originator's IK identification component. + Two varieties of Originator-ID fields are defined, the "Originator- + ID-Asymmetric:" and "Originator-ID-Symmetric:" field. An + "Originator-ID-Symmetric:" header field is required for all PEM + + + +Linn [Page 26] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + messages employing symmetric key management. The analogous + "Originator-ID-Asymmetric:" field, for the asymmetric key management + case, is used only when no corresponding "Originator-Certificate:" + field is included. + + Most commonly, only one Originator-ID or "Originator-Certificate:" + field will occur within a message. For the symmetric case, the IK + identification component carried in an "Originator-ID-Symmetric:" + field applies to processing of all subsequent "Recipient-ID- + Symmetric:" fields until another "Originator-ID-Symmetric:" field + occurs. It is illegal for a "Recipient-ID-Symmetric:" field to occur + before a corresponding "Originator-ID-Symmetric:" field has been + provided. For the asymmetric case, processing of "Recipient-ID- + Asymmetric:" fields is logically independent of preceding + "Originator-ID-Asymmetric:" and "Originator-Certificate:" fields. + + Multiple Originator-ID and/or "Originator-Certificate:" fields may + occur in a message when different originator-oriented IK components + must be used by a message's originator in order to prepare a message + so as to be suitable for processing by different recipients. In + particular, multiple such fields will occur when both symmetric and + asymmetric cryptography are applied to a single message in order to + process the message for different recipients. + + Originator-ID subfields are delimited by the comma 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. + +4.6.2.1.1 Originator-ID-Asymmetric Field + + The "Originator-ID-Asymmetric:" field contains an Issuing Authority + subfield, and then a Version/Expiration subfield. This field is used + only when the information it carries is not available from an + included "Originator-Certificate:" field. + +4.6.2.1.2 Originator-ID-Symmetric Field + + The "Originator-ID-Symmetric:" field contains an Entity Identifier + subfield, followed by an (optional) Issuing Authority subfield, and + then an (optional) Version/Expiration subfield. Optional + "Originator-ID-Symmetric:" subfields may be omitted only if rendered + redundant by information carried in subsequent "Recipient-ID- + Symmetric:" fields, and will normally be omitted in such cases. + + + + + + + +Linn [Page 27] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + +4.6.2.2 Originator-Certificate Field + + The "Originator-Certificate:" encapsulated header field is used only + when asymmetric key management is employed for one or more of a + message's recipients. To facilitate processing by recipients (at + least in advance of general directory server availability), inclusion + of this field in all messages is strongly recommended. The field + transfers an originator's certificate as a numeric quantity, + comprised of the certificate's DER encoding, represented in the + header field with the encoding mechanism defined in Section 4.3.2.4 + of this RFC. The semantics of a certificate are discussed in RFC + 1422. + +4.6.2.3 MIC-Info Field + + The "MIC-Info:" encapsulated header field, used only when asymmetric + key management is employed for at least one recipient of a message, + carries three arguments, separated by commas. The first argument + identifies the algorithm under which the accompanying MIC is + computed. The second argument identifies the algorithm under which + the accompanying MIC is signed. The third argument represents a MIC + signed with an originator's private key. + + For the case of ENCRYPTED PEM messages, the signed MIC is, in turn, + symmetrically encrypted using the same DEK, algorithm, mode and + cryptographic parameters as are used to encrypt the message's + encapsulated text. This measure prevents unauthorized recipients + from determining whether an intercepted message corresponds to a + predetermined plaintext value. + + Appropriate MIC algorithms and identifiers, signature algorithms and + identifiers, and signed MIC formats are defined in RFC 1423. + + A "MIC-Info:" field will occur after a sequence of fields beginning + with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field + and followed by any associated "Issuer-Certificate:" fields. A + "MIC-Info:" field applies to all subsequent recipients for whom + asymmetric key management is used, until and unless overridden by a + subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:" + and corresponding "MIC-Info:". + +4.6.3 Encapsulated Header Fields with Variable Occurrences + + This group of encapsulated header fields contains fields which will + normally occur variable numbers of times within a message, with + numbers of occurrences ranging from zero to non-zero values which are + independent of the number of recipients. + + + + +Linn [Page 28] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + +4.6.3.1 Issuer-Certificate Field + + The "Issuer-Certificate:" encapsulated header field is meaningful + only when asymmetric key management is used for at least one of a + message's recipients. A typical "Issuer-Certificate:" field would + contain the certificate containing the public component used to sign + the certificate carried in the message's "Originator-Certificate:" + field, for recipients' use in chaining through that certificate's + certification path. Other "Issuer-Certificate:" fields, typically + representing higher points in a certification path, also may be + included by an originator. It is recommended that the "Issuer- + Certificate:" fields be included in an order corresponding to + successive points in a certification path leading from the originator + to a common point shared with the message's recipients (i.e., the + Internet Certification Authority (ICA), unless a lower Policy + Certification Authority (PCA) or CA is common to all recipients.) + More information on certification paths can be found in RFC 1422. + + The certificate is represented in the same manner as defined for the + "Originator-Certificate:" field (transporting an encoded + representation of the certificate in X.509 [7] DER form), and any + "Issuer-Certificate:" fields will ordinarily follow the "Originator- + Certificate:" field directly. Use of the "Issuer-Certificate:" field + is optional even when asymmetric key management is employed, although + its incorporation is strongly recommended in the absence of alternate + directory server facilities from which recipients can access issuers' + certificates. + +4.6.4 Per-Recipient Encapsulated Header Fields + + The encapsulated header fields in this group appear for each of an + "ENCRYPTED" message's named recipients. For "MIC-ONLY" and "MIC- + CLEAR" messages, these fields are omitted for recipients for whom + asymmetric key management is employed in conjunction with a keyless + MIC algorithm but the fields appear for recipients for whom symmetric + key management or a keyed MIC algorithm is employed. + +4.6.4.1 Recipient-ID Fields + + A Recipient-ID encapsulated header field identifies a recipient and + provides the recipient's IK identification component. One + Recipient-ID field is included for each of a message's named + recipients. Section 5.2, Interchange Keys, discusses the semantics of + the subfields and specifies the alphabet from which they are chosen. + Recipient-ID subfields are delimited by the comma character (","), + optionally followed by whitespace. + + + + + +Linn [Page 29] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + For the symmetric case, all "Recipient-ID-Symmetric:" fields are + interpreted in the context of the most recent preceding "Originator- + ID-Symmetric:" field. It is illegal for a "Recipient-ID-Symmetric:" + field to occur in a header before the occurrence of a corresponding + "Originator-ID-Symmetric:" field. For the asymmetric case, + "Recipient-ID-Asymmetric:" fields are logically independent of a + message's "Originator-ID-Asymmetric:" and "Originator-Certificate:" + fields. "Recipient-ID-Asymmetric:" fields, and their associated + "Key-Info:" fields, are included following a header's originator- + oriented fields. + +4.6.4.1.1 Recipient-ID-Asymmetric Field + + The "Recipient-ID-Asymmetric:" field contains, in order, an Issuing + Authority subfield and a Version/Expiration subfield. + +4.6.4.1.2 Recipient-ID-Symmetric Field + + The "Recipient-ID-Symmetric:" field contains, in order, an Entity + Identifier subfield, an (optional) Issuing Authority subfield, and an + (optional) Version/Expiration subfield. + +4.6.4.2 Key-Info Field + + One "Key-Info:" field is included for each of a message's named + recipients. In addition, it is recommended that PEM implementations + support (as a locally-selectable option) the ability to include a + "Key-Info:" field corresponding to a PEM message's originator, + following an Originator-ID or "Originator-Certificate:" field and + before any associated Recipient-ID fields, but inclusion of such a + field is not a requirement for conformance with this RFC. + + Each "Key-Info:" field is interpreted in the context of the most + recent preceding Originator-ID, "Originator-Certificate:", or + Recipient-ID field; normally, a "Key-Info:" field will immediately + follow its associated predecessor field. The "Key-Info:" field's + argument(s) differ depending on whether symmetric or asymmetric key + management is used for a particular recipient. + +4.6.4.2.1 Symmetric Key Management + + When symmetric key management is employed for a given recipient, the + "Key-Info:" encapsulated header field transfers four items, separated + by commas: an IK Use Indicator, a MIC Algorithm Indicator, a DEK and + a MIC. The IK Use Indicator identifies the algorithm and mode in + which the identified IK was used for DEK and MIC encryption for a + particular recipient. The MIC Algorithm Indicator identifies the MIC + computation algorithm used for a particular recipient. The DEK and + + + +Linn [Page 30] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + MIC are symmetrically encrypted under the IK identified by a + preceding "Recipient-ID-Symmetric:" field and/or prior "Originator- + ID-Symmetric:" field. + + Appropriate symmetric encryption algorithms, modes and identifiers, + MIC computation algorithms and identifiers, and encrypted DEK and MIC + formats are defined in RFC 1423. + +4.6.4.2.2 Asymmetric Key Management + + When asymmetric key management is employed for a given recipient, the + "Key-Info:" field transfers two quantities, separated by a comma. + The first argument is an IK Use Indicator identifying the algorithm + and mode in which the DEK is asymmetrically encrypted. The second + argument is a DEK, asymmetrically encrypted under the recipient's + public component. + + Appropriate asymmetric encryption algorithms and identifiers, and + encrypted DEK formats are defined in RFC 1423. + +5. Key Management + + Several cryptographic constructs are involved in supporting the PEM + message processing procedure. A set of fundamental elements is + assumed. Data Encrypting Keys (DEKs) are used to encrypt message + text and (for some MIC computation algorithms) in the message + integrity check (MIC) computation process. Interchange Keys (IKs) + are used to encrypt DEKs and MICs for transmission with messages. In + a certificate-based asymmetric key management architecture, + certificates are used as a means to provide entities' public + components and other information in a fashion which is securely bound + by a central authority. The remainder of this section provides more + information about these constructs. + +5.1 Data Encrypting Keys (DEKs) + + Data Encrypting Keys (DEKs) are used for encryption of message text + and (with some MIC computation algorithms) for computation of message + integrity check quantities (MICs). In the asymmetric key management + case, they are also used for encrypting signed MICs in ENCRYPTED PEM + messages. It is strongly recommended that DEKs be generated and used + on a one-time, per-message, basis. A transmitted message will + incorporate a representation of the DEK encrypted under an + appropriate interchange key (IK) for each of the named recipients. + + DEK generation can be performed either centrally by key distribution + centers (KDCs) or by endpoint systems. Dedicated KDC systems may be + able to implement stronger algorithms for random DEK generation than + + + +Linn [Page 31] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + 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 those of a message's originator and recipient. Moreover, + decentralized DEK generation at endpoints reduces the frequency with + which originators must make real-time queries of (potentially unique) + servers in order to send mail, enhancing communications availability. + + When symmetric key management 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 originators. 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-originator private IK components need not + necessarily be shared with a KDC. + +5.2 Interchange Keys (IKs) + + Interchange Key (IK) components are used to encrypt DEKs and MICs. + 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 PEM using + conventional cryptography, they must first possess common IK + components (when symmetric key management is used) or complementary + IK components (when asymmetric key management is used). When + symmetric cryptography is used, the IK consists of a single + component, used to encrypt both DEKs and MICs. When asymmetric + cryptography is used, a recipient's public component is used as an IK + to encrypt DEKs (a transformation invertible only by a recipient + possessing the corresponding private component), and the originator's + private component is used to encrypt MICs (a transformation + invertible by all recipients, since the originator's certificate + provides all recipients with the public component required to perform + MIC validation. + + This RFC does not prescribe the means by which interchange keys are + made available to appropriate parties; such means may be centralized + (e.g., via key management servers) or decentralized (e.g., via + pairwise agreement and direct distribution among users). In any + case, any given IK component is associated with a responsible Issuing + Authority (IA). When certificate-based asymmetric key management, as + discussed in RFC [1422, is employed, the IA function is performed by + a Certification Authority (CA). + + When an IA generates and distributes an IK component, associated + control information is provided to direct how it is to be used. In + + + +Linn [Page 32] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + order to select the appropriate IK(s) to use in message encryption, + an originator must retain a correspondence between IK components and + the recipients with which they are associated. Expiration date + information must also be retained, in order that cached entries may + be invalidated and replaced as appropriate. + + Since a message may be sent with multiple IK components identified, + corresponding to multiple intended recipients, each recipient's UA + must be able to determine that recipient's intended IK component. + Moreover, if no corresponding IK component is available in the + recipient's database when a message arrives, the recipient must be + able to identify the required IK component and identify that IK + component's associated IA. Note that different IKs may be used for + different messages between a pair of communicants. Consider, for + example, one message sent from A to B and another message sent (using + the IK-per-list method) from A to a mailing list of which B is a + member. The first message would use IK components associated + individually with A and B, but the second would use an IK component + shared among list members. + + When a PEM message is transmitted, an indication of the IK components + used for DEK and MIC encryption must be included. To this end, + Originator-ID and Recipient-ID encapsulated header fields provide + (some or all of) the following data: + + 1. Identification of the relevant Issuing Authority (IA + subfield) + + 2. Identification of an entity with which a particular IK + component is associated (Entity Identifier or EI subfield) + + 3. Version/Expiration subfield + + In the asymmetric case, all necessary information associated with an + originator can be acquired by processing the certificate carried in + an "Originator-Certificate:" field; to avoid redundancy in this case, + no "Originator-ID-Asymmetric:" field is included if a corresponding + "Originator-Certificate:" appears. + + The comma character (",") is used to delimit the subfields within an + Originator-ID or 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): + + + + + + + +Linn [Page 33] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + IKsubfld := 1*ia-char + + ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" / + "." / "/" / "=" / "?" / "-" / "@" / + "%" / "!" / '"' / "_" / "<" / ">" + + + + An example Recipient-ID field for the symmetric case is as follows: + + Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,2 + + This example field indicates that IA "ptf-kmc" has issued an IK + component for use on messages sent to "linn@zendia.enet.dec.com", + and that the IA has provided the number 2 as a version indicator for + that IK component. + + An example Recipient-ID field for the asymmetric case is as follows: + + Recipient-ID-Asymmetric: + MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j + LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66 + + This example field includes the printably encoded BER representation + of a certificate's issuer distinguished name, along with the + certificate serial number 66 as assigned by that issuer. + +5.2.1 Subfield Definitions + + The following subsections define the subfields of Originator-ID and + Recipient-ID fields. + +5.2.1.1 Entity Identifier Subfield + + An entity identifier (used only for "Originator-ID-Symmetric:" and + "Recipient-ID-Symmetric:" fields) 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. + + + + + +Linn [Page 34] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + +5.2.1.2 Issuing Authority Subfield + + An IA identifier subfield is constructed as an IKsubfld. This RFC + does not define this subfield's contents for the symmetric key + management case. Any prospective IAs which are to issue symmetric + keys for use in conjunction with this RFC must coordinate assignment + of IA identifiers in a manner (centralized or hierarchic) which + assures uniqueness. + + For the asymmetric key management case, the IA identifier subfield + will be formed from the ASN.1 BER representation of the distinguished + name of the issuing organization or organizational unit. The + distinguished encoding rules specified in Clause 8.7 of + Recommendation X.509 ("X.509 DER") are to be employed in generating + this representation. The encoded binary result will be represented + for inclusion in a transmitted header using the procedure defined in + Section 4.3.2.4 of this RFC. + +5.2.1.3 Version/Expiration Subfield + + A version/expiration subfield is constructed as an IKsubfld. For the + symmetric key management case, the version/expiration subfield format + is permitted to 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. + + For the asymmetric key management case, the version/expiration + subfield's value is the hexadecimal serial number of the certificate + being used in conjunction with the originator or recipient specified + in the "Originator-ID-Asymmetric:" or "Recipient-ID-Asymmetric:" + field in which the subfield occurs. + +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 + + + +Linn [Page 35] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + transform the DEK used for message text encryption via re-encryption + under a locally maintained IK, rather than relying on IA maintenance + of old IK components for indefinite periods. + +6. User Naming + + Unique naming of electronic mail users, as is needed in order to + select corresponding keys correctly, is an important topic and one + which has received (and continues to receive) significant study. For + the symmetric case, IK components are identified in PEM headers + through use of mailbox specifiers in traditional Internet-wide form + ("user@domain-qualified-host"). Successful operation in this mode + relies on users (or their PEM implementations) being able to + determine the universal-form names corresponding to PEM originators + and recipients. If a PEM implementation operates in an environment + where addresses in a local form differing from the universal form are + used, translations must be performed in order to map between the + universal form and that local representation. + + The use of user identifiers unrelated to the hosts on which the + users' mailboxes reside offers generality and value. X.500 + distinguished names, as employed in the certificates of the + recommended key management infrastructure defined in RFC 1422, + provide a basis for such user identification. As directory services + become more pervasive, they will offer originators a means to search + for desired recipients which is based on a broader set of attributes + than mailbox specifiers alone. Future work is anticipated in + integration with directory services, particularly the mechanisms and + naming schema of the Internet OSI directory pilot activity. + +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 hypothetical + prototype implementation. This implementation is a standalone + program which is invoked by a user, and lies above the existing + UA sublayer. In the UNIX system, and possibly in other environments + as well, such a program can be invoked as a "filter" within an + electronic mail UA or a text editor, simplifying the sequence of + operations which must be performed by the user. This form of + integration offers the advantage that the program can be used in + conjunction with a range of UA programs, rather than being + compatible only with a particular UA. + + When a user wishes to apply privacy enhancements to an outgoing + message, the user prepares the message's text and invokes the + standalone program, which in turn generates output suitable for + transmission via the UA. When a user receives a PEM message, the UA + + + +Linn [Page 36] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + 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. For the + asymmetric key management case, certificates are acquired for a + user's PEM correspondents; in advance and/or in addition to retrieval + of certificates from directories, they can be extracted from the + "Originator-Certificate:" fields of received PEM messages. + + The IK/certificate cache is, effectively, a simple database indexed + by mailbox names. IK components are selected for transmitted + messages based on the originator's identity and on recipient names, + and corresponding Originator-ID, "Originator-Certificate:", and + 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 cryptographic parameters (e.g., 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 "Originator-ID- + Symmetric:" and "Recipient-ID-Symmetric:" fields. + +8. Minimum Essential Requirements + + This section summarizes particular capabilities which an + implementation must provide for full conformance with this RFC. + + RFC 1422 specifies asymmetric, certificate-based key management + procedures to support the message processing procedures defined in + this document; PEM implementation support for these key management + procedures is strongly encouraged. Implementations supporting these + procedures must also be equipped to display the names of originator + and recipient PEM users in the X.500 DN form as authenticated by the + procedures of RFC 1422. + + The message processing procedures defined here can also be used with + symmetric key management techniques, though no RFCs analogous to RFC + 1422 are currently available to provide correspondingly detailed + description of suitable symmetric key management procedures. A + complete PEM implementation must support at least one of these + + + +Linn [Page 37] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + asymmetric and/or symmetric key management modes. + + A full implementation of PEM is expected to be able to send and + receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive + CRL messages. Some level of support for generating and processing + nested and annotated PEM messages (for forwarding purposes) is to be + provided, and an implementation should be able to reduce ENCRYPTED + messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant + implementations must be able to emit Certificate and Issuer- + Certificate fields, and to include a Key-Info field corresponding to + the originator, but users or configurers of PEM implementations may + be allowed the option of deactivating those features. + +9. Descriptive Grammar + + This section provides a grammar describing the construction of a PEM + message. + + ; PEM BNF representation, using RFC 822 notation. + + ; imports field meta-syntax (field, field-name, field-body, + ; field-body-contents) from RFC-822, sec. 3.2 + ; imports DIGIT, ALPHA, CRLF, text from RFC-822 + ; Note: algorithm and mode specifiers are officially defined + ; in RFC 1423 + + <pemmsg> ::= <preeb> + <pemhdr> + [CRLF <pemtext>] ; absent for CRL message + <posteb> + + <preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF + <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb> + + <pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages + / *(<text> CRLF) ; for MIC-CLEAR + + <pemhdr> ::= <normalhdr> / <crlhdr> + + <normalhdr> ::= <proctype> + + <contentdomain> + [<dekinfo>] ; needed if ENCRYPTED + (1*(<origflds> *<recipflds>)) ; symmetric case -- + ; recipflds included for all proc types + / ((1*<origflds>) *(<recipflds>)) ; asymmetric case -- + ; recipflds included for ENCRYPTED proc type + + + + +Linn [Page 38] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + <crlhdr> ::= <proctype> + 1*(<crl> [<cert>] *(<issuercert>)) + + <asymmorig> ::= <origid-asymm> / <cert> + + <origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>) + <micinfo> ; asymmetric + / <origid-symm> [<keyinfo>] ; symmetric + + <recipflds> ::= <recipid> <keyinfo> + + ; definitions for PEM header fields + + <proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF + <contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF + <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF + <symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>] + <asymmid> ::= <IKsubfld> "," <IKsubfld> + <origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF + <origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF + <recipid> ::= <recipid-asymm> / <recipid-symm> + <recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF + <recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF + <cert> ::= "Originator-Certificate" ":" <encbin> CRLF + <issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF + <micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> "," + <asymsignmic> CRLF + <keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> "," + <symencdek> "," <symencmic> CRLF ; symmetric case + / "Key-Info" ":" <ikalgid> "," <asymencdek> + CRLF ; asymmetric case + <crl> ::= "CRL" ":" <encbin> CRLF + + <pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL" + + <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "=" + <encbingrp> ::= 4*4<encbinchar> + <encbin> ::= 1*<encbingrp> + <encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF] + <IKsubfld> ::= 1*<ia-char> + ; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID + ; fields can be delimited with commas (not colons) like all other + ; fields + <ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" / + "." / "/" / "=" / "?" / "-" / "@" / + "%" / "!" / '"' / "_" / "<" / ">" + <hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" + ; no lower case + + + +Linn [Page 39] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + ; This specification defines one value ("RFC822") for + ; <contentdescrip>: other values may be defined in future in + ; separate or successor documents + ; + <contentdescrip> ::= "RFC822" + + ; The following items are defined in RFC 1423 + ; <dekalgid> + ; <dekparameters> + ; <micalgid> + ; <ikalgid> + ; <asymsignmic> + ; <symencdek> + ; <symencmic> + ; <asymencdek> + + +NOTES: + + [1] Key generation for MIC computation and message text encryption + may either be performed by the sending host or by a + centralized server. This RFC does not constrain this design + alternative. Section 5.1 identifies possible advantages of a + centralized server approach if symmetric key management is + employed. + + [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, + RFC 821, August 1982. + + [3] 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. + + [4] Use of a canonicalization procedure similar to that of SMTP + was selected because its functions are widely used and + implemented within the Internet mail community, not for + purposes of SMTP interoperability with this intermediate + result. + + [5] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [6] Rose, M. T. and Stefferud, E. A., "Proposed Standard for + Message Encapsulation", RFC 934, January 1985. + + [7] CCITT Recommendation X.509 (1988), "The Directory - + Authentication Framework". + + + + +Linn [Page 40] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + [8] Throughout this RFC we have adopted the terms "private + component" and "public component" to refer to the quantities + which are, respectively, kept secret and made publicly + available in asymmetric cryptosystems. This convention is + adopted to avoid possible confusion arising from use of the + term "secret key" to refer to either the former quantity or to + a key in a symmetric cryptosystem. + +Patent Statement + + This version of Privacy Enhanced Mail (PEM) relies on the use of + patented public key encryption technology for authentication and + encryption. The Internet Standards Process as defined in RFC 1310 + requires a written statement from the Patent holder that a license + will be made available to applicants under reasonable terms and + conditions prior to approving a specification as a Proposed, Draft or + Internet Standard. + + The Massachusetts Institute of Technology and the Board of Trustees + of the Leland Stanford Junior University have granted Public Key + Partners (PKP) exclusive sub-licensing rights to the following + patents issued in the United States, and all of their corresponding + foreign patents: + + Cryptographic Apparatus and Method + ("Diffie-Hellman")............................... No. 4,200,770 + + Public Key Cryptographic Apparatus + and Method ("Hellman-Merkle").................... No. 4,218,582 + + Cryptographic Communications System and + Method ("RSA")................................... No. 4,405,829 + + Exponential Cryptographic Apparatus + and Method ("Hellman-Pohlig").................... No. 4,424,414 + + These patents are stated by PKP to cover all known methods of + practicing the art of Public Key encryption, including the variations + collectively known as El Gamal. + + Public Key Partners has provided written assurance to the Internet + Society that parties will be able to obtain, under reasonable, + nondiscriminatory terms, the right to use the technology covered by + these patents. This assurance is documented in RFC 1170 titled + "Public Key Standards and Licenses". A copy of the written assurance + dated April 20, 1990, may be obtained from the Internet Assigned + Number Authority (IANA). + + + + +Linn [Page 41] + +RFC 1421 Privacy Enhancement for Electronic Mail February 1993 + + + The Internet Society, Internet Architecture Board, Internet + Engineering Steering Group and the Corporation for National Research + Initiatives take no position on the validity or scope of the patents + and patent applications, nor on the appropriateness of the terms of + the assurance. The Internet Society and other groups mentioned above + have not made any determination as to any other intellectual property + rights which may apply to the practice of this standard. Any further + consideration of these matters is the user's own responsibility. + +Security Considerations + + This entire document is about security. + +Author's Address + + John Linn + + EMail: 104-8456@mcimail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Linn [Page 42] +
\ No newline at end of file |