RFC 1113

Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures

📅 published August 1989, from ietf

Part 1 of 8 🎀

Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures

Okay bestie, the title block first 💅 This is RFC 1113, filed under the Network Working Group, and it's written by J. Linn from DEC for the IAB Privacy Task Force. It's dated August 1989. It obsoletes RFCs 989 and 1040, so those are officially retired 💀 Its status is a draft standard elective protocol (more on that in a sec 🧚).

STATUS OF THIS MEMO 🦋

So this RFC is suggesting a draft standard elective protocol for the Internet community, and it's literally asking everyone for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited, so share it everywhere ✨

ACKNOWLEDGMENT 💜

This RFC is the outgrowth of a series of IAB Privacy Task Force meetings, plus internal working papers that got passed around for those meetings. The author wants to thank the following Privacy Task Force members and meeting guests for their comments and contributions at the meetings that led to this RFC: David Balenson, Curt Barker, Jim Bidzos, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and Steve Wilbur. Iconic cast 👑

Table of Contents 🌈

   1.  Executive Summary                                               2
   2.  Terminology                                                     3
   3.  Services, Constraints, and Implications                         3
   4.  Processing of Messages                                          7
   4.1  Message Processing Overview                                    7
   4.1.1  Types of Keys                                                7
   4.1.2  Processing Procedures                                        8
   4.2  Encryption Algorithms and Modes                                9
   4.3  Privacy Enhancement Message Transformations                   10
   4.3.1  Constraints                                                 10
   4.3.2  Approach                                                    11
   4.3.2.1  Step 1: Local Form                                        12
   4.3.2.2  Step 2: Canonical Form                                    12
   4.3.2.3  Step 3: Authentication and Encipherment                   12
   4.3.2.4  Step 4: Printable Encoding                                13
   4.3.2.5  Summary of Transformations                                15
   4.4  Encapsulation Mechanism                                       15
   4.5  Mail for Mailing Lists                                        17
   4.6  Summary of Encapsulated Header Fields                         18
   4.6.1  Per-Message Encapsulated Header Fields                      20
   4.6.1.1  X-Proc-Type Field                                         20
   4.6.1.2  X-DEK-Info Field                                          21
   4.6.2  Encapsulated Header Fields Normally Per-Message             21
   4.6.2.1  X-Sender-ID Field                                         22
   4.6.2.2  X-Certificate Field                                       22
   4.6.2.3  X-MIC-Info Field                                          23
   4.6.3  Encapsulated Header Fields with Variable Occurrences        23
   4.6.3.1  X-Issuer-Certificate Field                                23
   4.6.4  Per-Recipient Encapsulated Header Fields                    24
   4.6.4.1  X-Recipient-ID Field                                      24
   4.6.4.2  X-Key-Info Field                                          24
   4.6.4.2.1  Symmetric Key Management                                24
   4.6.4.2.2  Asymmetric Key Management                               25
   5.  Key Management                                                 26
   5.1  Data Encrypting Keys (DEKs)                                   26
   5.2  Interchange Keys (IKs)                                        26
   5.2.1  Subfield Definitions                                        28
   5.2.1.1  Entity Identifier Subfield                                28
   5.2.1.2  Issuing Authority Subfield                                29
   5.2.1.3  Version/Expiration Subfield                               29
   5.2.2  IK Cryptoperiod Issues                                      29
   6.  User Naming                                                    29
   6.1  Current Approach                                              29
   6.2  Issues for Consideration                                      30
   7.  Example User Interface and Implementation                      30
   8.  Areas For Further Study                                        31
   9.  References                                                     32
   NOTES                                                              32

1. Executive Summary ✨

Okay so this RFC defines message encipherment and authentication procedures, which means it's here to give you privacy enhancement services for electronic mail transfer on the Internet 💖 It's one member of a related set of four RFCs. The procedures in this one are meant to play nicely with a wide range of key management approaches, including both symmetric (secret-key) and asymmetric (public-key) approaches for encrypting data encrypting keys 🔑 Using symmetric cryptography for message text encryption and/or integrity check computation is anticipated, so that's the vibe ✨ RFC-1114 is the one that specifies the supporting key management mechanisms based on public-key certificates 🎀 RFC-1115 specifies the algorithm and related information that's relevant to this RFC and to RFC-1114 📚 And a subsequent RFC will cover the details of paper and electronic formats and procedures for the key management infrastructure being set up to support all of this 🌸

Now the main event 🔥 Privacy enhancement services (confidentiality, authentication, and message integrity assurance) are delivered through end-to-end cryptography between the originator and recipient User Agent processes. The Message Transfer System doesn't get any special processing requirements at the endpoints or at intermediate relay sites, which is honestly so iconic 😭 That means privacy enhancement facilities can be added site-by-site or user-by-user without affecting other Internet entities. Interoperability among heterogeneous components and mail transport facilities is supported too 🦋

2. Terminology 🌸

So for descriptive purposes, this RFC borrows some terms from the OSI X.400 Message Handling System Model, as defined in the 1984 CCITT Recommendations 📖 It replicates a portion of X.400's Section 2.2.1, "Description of the MHS Model: Overview", so that readers who aren't familiar with the OSI MHS Model can still follow along 🧚

In the MHS model, a user is a person or a computer application 💅 A user is called 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 let an originator transfer messages of those types to one or more recipients 💜

An originator prepares messages with help from their User Agent (UA), which is an application process that interacts with the Message Transfer System (MTS) to submit messages 🎀 The MTS delivers the messages submitted to it to one or more recipient UAs. Functions performed solely by the UA and not standardized as part of the MH Service elements are called local UA functions 🌈

The MTS is made up of a bunch of Message Transfer Agents (MTAs). Working together, the MTAs relay messages and deliver them to the intended recipient UAs, which then make the messages available to the intended recipients 🫶

The whole collection of UAs and MTAs is called the Message Handling System (MHS). The MHS and all of its users are collectively referred to as the Message Handling Environment 👑

3. Services, Constraints, and Implications ✨

okay bestie, this section is literally the "what can this thing actually do and what can't it do" talk 💅 and the vibe is: privacy stuff happens end-to-end, between the sender's UA and the recipient's UA, and nobody in the middle gets to touch the fields they add or change 🦋

Authentication and integrity are ALWAYS applied to the whole message text 🔒 there is no confidentiality-without-authentication option, no cap. Encryption can be applied to just parts of a message though 🎀 so the less sensitive bits (like descriptive fields) can still be handled by a recipient's delegate without them needing their personal keys. And if you exclude the entire message text from encryption, you still get authentication and integrity without confidentiality, which is a lowkey useful combo 🧚

The measures are meant to work for a huge range of Internet hosts and usage styles 🌈 here are the main attributes, iykyk:

  1. The mechanisms aren't tied to one host or OS 💖 they work across a bunch of systems, and everything happens at the application layer, so nothing depends on privacy features in the lower protocol layers 🫶
  2. They play nicely with non-enhanced Internet components 🌸 the privacy stuff is end-to-end, so it doesn't mess with mail processing at relay hosts that don't have privacy features. BUT the sender has to know whether the recipient supports privacy enhancements, so that encoding and maybe encryption don't get applied to a message the destination can't reverse 😭
  3. They work with a range of mail transports 🚀 email moves over all kinds of SMTP implementations, and some sites forward mail into other environments (USENET, CSNET, BITNET). The privacy enhancements MUST be able to operate across the SMTP realm 💅 and it's desirable that they also be compatible with protection of mail sent between SMTP and those other connected environments ✨
  4. They work with a broad range of mail user agents (UAs) 🎀 there are tons of UA programs with different interfaces, so selected mechanisms SHOULD be usable with as many existing UA programs as possible. For pilot implementations, it's desirable that the privacy processing can be a separate program that works with a range of UAs, instead of needing internal changes to every UA 🧚
  5. They let privacy enhancement processing run on personal computers (PCs) separate from the systems where UA functions live 💻 with PCs everywhere and limited trust in UAs on many multi-user systems, this lets lots of people process privacy-enhanced mail at a higher assurance level than a purely UA-based approach would allow 👑
  6. They support privacy protection for mail addressed to mailing lists (distribution lists, in ISO parlance) 💜
  7. They're compatible with a bunch of key management approaches 🔑 including (but not limited to) manual pre-distribution, centralized key distribution based on symmetric cryptography, and public-key certificates. Different key management mechanisms MAY be used for different recipients of a multicast message 🌈 supporting one particular key management mechanism is NOT a minimum essential requirement for compatibility with this RFC, but adopting the public-key certificate approach from companion RFC-1114 is strongly recommended 🍓

Now the three basic restrictions 🚧 (these are what keep it broadly applicable and make pilots possible without changing the whole Internet first):

  1. Measures are restricted to endpoint implementation and should be easy to integrate at the UA level or above, rather than needing changes to the message transport system (like SMTP servers) 🙈
  2. The supported measures enhance what users can do rather than restricting them 💖 trusted implementations that protect software from subversion by local users can't be assumed in general. Without them, it's more feasible to provide facilities that enhance user services (like protecting and authenticating inter-user traffic) than to enforce restrictions (like inter-user access control) on user actions 🦋
  3. The measures focus on a set of functional capabilities picked to give significant, tangible benefits to a broad user community 🌸 by concentrating on the most critical services, the goal is to maximize added privacy value with a modest implementation effort 🫶

So, because of all that, these facilities CAN be provided 🎉:

  1. disclosure protection,
  2. sender authenticity,
  3. message integrity measures, and
  4. (if asymmetric key management is used) non-repudiation of origin.

BUT these privacy-relevant concerns are NOT addressed 😭:

  1. access control,
  2. traffic flow confidentiality,
  3. address list accuracy,
  4. routing control,
  5. issues relating to the casual serial reuse of PCs by multiple users,
  6. assurance of message receipt and non-deniability of receipt,
  7. automatic association of acknowledgments with the messages to which they refer, and
  8. message duplicate detection, replay prevention, or other stream-oriented services.

Last bit of the section: a message's sender decides whether privacy enhancements get applied to a particular message 💌 so the sender MUST be able to determine whether particular recipients are equipped to process privacy-enhanced mail. In a general architecture, these mechanisms will be based on server queries, so the query function could be built into a UA to avoid burdening or inconveniencing email users ✨

4. Processing of Messages 🎀

4.1. Message Processing Overview 🧚

this subsection is the high-level tour of all the parts and steps involved in privacy enhancement processing 🦋 the later subsections go deeper into the procedures, so this is your cute little map 🗺️

4.1.1. Types of Keys 🔑

okay so there's a two-level keying hierarchy that supports privacy-enhanced message transmission 💅

  1. Data Encrypting Keys (DEKs) 🔐 these encrypt message text and (with certain choices among a set of alternative algorithms) compute message integrity check (MIC) quantities 💖 DEKs are generated individually for each transmitted message, so no predistribution of DEKs is needed to support privacy-enhanced message transmission ✨
  2. Interchange Keys (IKs) 🦋 these encrypt DEKs for transmission within messages 🎀 ordinarily, the same IK is 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 🫶 that representation is associated with X-Sender-ID: and X-Recipient-ID: fields, which let each individual recipient identify the IK used to encrypt DEKs and/or MICs for that recipient's use 💜 given an appropriate IK, a recipient can decrypt the corresponding transmitted DEK representation, yielding the DEK required for message text decryption and/or MIC verification 🌈

The definition of an IK depends 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 of the recipient 💅 the IK component used for MIC encryption is the private component of the originator, and therefore only one encrypted MIC representation needs to be included per message, rather than one per recipient 🦋 each of these IK components can be fully qualified in an X-Recipient-ID: or X-Sender-ID: field, respectively 🫶

4.1.2. Processing Procedures ✨

Okay so when privacy enhancement processing happens on an outgoing message, a DEK gets generated [1] 🔐 for message encryption. If the MIC algorithm you chose needs a key, a variant of the DEK gets formed for MIC computation 🔑. DEK generation can be skipped for a message where all the contents are excluded from encryption, unless the chosen MIC computation algorithm needs a DEK anyway 🙈.

An X-Sender-ID: field goes in the header to give one identification piece for the IK(s) used during message processing 🪪. IK components get picked for each individually named recipient. A matching X-Recipient-ID: field, read in the context of a prior X-Sender-ID: field, is what identifies each IK 🎀. Each X-Recipient-ID: field is followed by an X-Key-Info: field, which carries a DEK encrypted under the IK that fits that specific recipient 💌. When symmetric key management is used for a recipient, the X-Key-Info: field also carries the message's computed MIC, encrypted under that recipient's IK ✨. When asymmetric key management is used, a prior X-MIC-Info: field carries the message's MIC encrypted under the private component of the sender 🦋.

Next up is the four-phase transformation procedure 🧚. It exists so encrypted message text can travel in a universally transmissible form, and so a message encrypted on one type of host computer can be decrypted on a different type 🌈. A plaintext message is accepted in local form, meaning the host's native character set and line representation 💻. That local form gets converted to a canonical message text representation, which is defined as equivalent to the inter-SMTP representation of message text 📬. This canonical representation is the input to the MIC computation and encryption processes 💜.

For encryption, the canonical representation gets padded as the encryption algorithm requires 🧁. The padded canonical representation then gets encrypted, except for any regions that are explicitly excluded from encryption 🔒. The encrypted text, along with the canonical representation of the excluded regions, gets encoded into a printable form 🖨️. That printable form uses a restricted character set, chosen to be universally representable across sites and to not be disrupted by processing within and between MTS entities 🫶.

The output of the encoding procedure gets combined with a set of header fields carrying cryptographic control information 📝. The result gets passed to the electronic mail system to be encapsulated as the text portion of a transmitted message 📨.

When a privacy-enhanced message is received, the cryptographic control fields inside its text portion give the authorized recipient what they need to do MIC verification and decryption 🕵️. First, the printable encoding gets converted to a bitstring. Encrypted portions of the transmitted message get decrypted. The MIC gets verified. Then the canonical representation is converted to the recipient's local form, which doesn't have to be the same as the sender's local form 💖.

4.2. Encryption Algorithms and Modes 🎀

For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined in ANSI X3.92-1981 [2], SHALL be used for encryption of message text. DEA-1 is equivalent to the Data Encryption Standard (DES), as defined in FIPS PUB 46 [3]. When DEA-1 is used to encrypt text, it SHALL be used in the Cipher Block Chaining (CBC) mode, as defined in ISO IS 8372 [4]. The identifier string DES-CBC, defined in RFC-1115, stands for this algorithm/mode combination 🔥. The CBC mode definition in IS 8372 is equivalent to the one provided in FIPS PUB 81 [5] and in ANSI X3.106-1983 [16]. Using other algorithms and/or modes for message text processing will need case-by-case study to figure out applicability and constraints 🧐. Additional algorithms and modes approved for this context will be specified in successors to RFC-1115.

It's an originator's responsibility to generate a new pseudorandom initializing vector (IV) for each privacy-enhanced electronic mail message, unless the entirety of the message is excluded from encryption 🌸. Section 4.3.1 of [17] gives the rationale for this, even in a context where individual DEKs are generated for individual messages. The IV will be transmitted with the message 💜.

Some operations need one key to be encrypted under an interchange key (IK) for transmission. A header facility indicates the mode in which the IK is used for encryption. RFC-1115 specifies encryption algorithm/mode identifiers, including DES-ECB, DES-EDE, and RSA. All implementations using symmetric key management SHOULD support DES-ECB IK use, and all implementations using asymmetric key management SHOULD support RSA IK use 🙌.

RFC-1114, released at the same time as this RFC, specifies asymmetric, certificate-based key management procedures to support the message processing procedures defined in this document 🎁. The message processing procedures can also be used with symmetric key management, as long as suitable symmetric IKs were distributed beforehand through out-of-band means. Support for the asymmetric approach defined in RFC-1114 is strongly RECOMMENDED 👑.

4.3. Privacy Enhancement Message Transformations 🦄

4.3.1. Constraints ⛓️

An electronic mail encryption mechanism MUST be compatible with the transparency constraints of its underlying electronic mail facilities 🙅‍♀️. These constraints are generally established based on expected user requirements and on the characteristics of anticipated endpoint and transport facilities. An encryption mechanism MUST also be compatible with the local conventions of the computer systems it interconnects. In this approach, a canonicalization step abstracts out local conventions, and a later encoding step conforms to the characteristics of the underlying mail transport medium (SMTP). The encoding conforms to SMTP constraints, which were established to support interpersonal messaging. SMTP's rules are also used independently in the canonicalization process. RFC-821's [7] Section 4.5 details SMTP's transparency constraints 📖.

To prepare a message for SMTP transmission, the following requirements MUST be met 📮:

  1. All characters MUST be members of the 7-bit ASCII character set.
  2. Text lines, delimited by the character pair <CR><LF>, MUST be no more than 1000 characters long.
  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>), plenty of systems use a different native representation to delimit lines 🤷‍♀️. For example, the <CR><LF> sequences delimiting lines in mail inbound to UNIX systems are transformed to single <LF>s as mail is written into local mailbox files. Lines in mail incoming to record-oriented systems (such as VAX VMS) may be converted to appropriate records by the destination SMTP [8] server. So if the encryption process generated <CR>s or <LF>s, those characters might not be accessible to a recipient UA program at a destination that uses different line delimiting conventions 😬. It's also possible that conversion between tabs and spaces may be performed while mapping between inter-SMTP and local format, and that's 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 the one computed at the destination 💀.

The conversion an SMTP server performs at a system with EBCDIC as its native character set has an even bigger impact, since the conversion from EBCDIC into ASCII is an information-losing transformation 🙈. In principle, the transformation function mapping between the 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 the SMTP server to stop performing 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, since mail would be passed to SMTP in a different representation than it is passed at present 😤.

4.3.2. Approach 🌷

Our approach to supporting privacy-enhanced mail across an environment where intermediate conversions may occur encodes mail in a form that's uniformly representable across the set of privacy-enhanced UAs, no matter what native character sets their systems use 🫧. This encoded form is used to represent mail text from sender to recipient. The encoding is not applied to enclosing mail transport headers, or to encapsulated headers inserted to carry control information between privacy-enhanced UAs. The encoding's characteristics are such that the transformations anticipated between sender and recipient UAs will not prevent an encoded message from being decoded properly at its destination 💅.

A sender MAY exclude one or more portions of a message from encryption processing, but authentication processing is always applied to the entirety of message text 🔏. Explicit action is required to exclude a portion of a message from encryption processing. By default, encryption is applied to the entirety of message text. The user-level delimiter that specifies such exclusion is a local matter, and hence may vary between sender and recipient, but all systems SHOULD provide a means for unambiguous identification of areas excluded from encryption processing 🪄.

An outbound privacy-enhanced message goes through four transformation steps, described in the following four subsections 🎬.

4.3.2.1. Step 1: Local Form 📍

The message text is created in the system's native character set, with lines delimited in accordance with local convention 🏠.

4.3.2.2. Step 2: Canonical Form 🌈

The entire message text, including both the portions subject to encipherment processing and the portions excluded from such processing, is converted to a universal canonical form, analogous to the inter-SMTP representation [9] as defined in RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line delimiters). The processing required to perform this conversion is minimal on systems whose native character set is ASCII ✨. (Note: Since the output of the canonical encoding process will never be submitted directly to SMTP, but only to subsequent steps of the privacy enhancement encoding process, the dot-stuffing transformation discussed in RFC-821, section 4.5.2, is not required.) Since a message is converted to a standard character set and representation before encryption, it can be decrypted and its MIC can be verified at any type of destination host computer 🥰. The decryption and MIC verification are performed before any conversions which may be necessary to transform the message into a destination-specific local form 🫶.

4.3.2.3. Step 3: Authentication and Encipherment 🔐

Okay so step 3 is where the integrity magic happens 🔥. The canonical form gets fed into whichever MIC computation algorithm was selected, and that gives the message its integrity check quantity. No padding gets added to the canonical form before it goes into the MIC algorithm, though certain MIC algorithms add their own padding while they compute the MIC, so that's on them 💅.

Encryption in the DEA-1 CBC mode needs padding, though, bestie 🎀. First you count the octets to be encrypted by taking the total length of the canonically encoded text and subtracting the octets that are excluded from encryption. Then you append octets with the hexadecimal value FF (all ones) until the text octets being encrypted, plus the padding, fill up an integral number of 8-octet encryption quanta. If the number of octets to be encrypted is already an integral multiple of 8, no padding gets applied at all. The FF value is the best part ✨: it sits outside the 7-bit ASCII set, so padding octets can be told apart from valid data without any explicit padding count indicator. Iconic, honestly 😭.

Next, the regions that weren't excluded from encryption get encrypted. For selective encipherment to work, an implementation must keep internal indications of where the excluded areas sit relative to the non-excluded areas, so those areas can be properly delimited in the encoding procedure from step 4 🧚. If an excluded region shows up between encrypted regions, the cryptographic state (like the IVs and the accumulation of octets into encryption quanta) gets preserved and carried on after the excluded region. No resetting the vibes mid-message 💜.

4.3.2.4. Step 4: Printable Encoding 🍓

Now we go left to right and turn the bit string from step 3 into characters that can be represented universally at all sites. They don't necessarily have the same bit patterns, though. Like, "E" is hexadecimal 45 in an ASCII-based system and hexadecimal C5 in an EBCDIC-based system, but both are equally meaningful locally 🦋. This encoding step runs for every privacy-enhanced message, even if the entire message is excluded from encryption, so no exceptions, babe 💅.

We use a 64-character subset of International Alphabet IA5, which lets us represent 6 bits per printable character. (The proposed subset is represented identically in IA5 and ASCII, so yay for compatibility 🌈.) Two extra characters, = and *, are used for special processing functions. The = is used for padding within the printable encoding procedure. The * marks the beginning and end of a region that's been excluded from encipherment processing. The encoding function's output gets split into text lines (using local conventions). Every line except the last holds exactly 64 printable characters, and the final line holds 64 or fewer. (That line length is easy to print and is guaranteed to fit SMTP's 1000-character transmitted line length limit, which is a whole mood 🙌.)

The encoding process turns 24-bit groups of input bits into output strings of 4 encoded characters. Going left to right across a 24-bit input group pulled from the step 3 output, each 6-bit group becomes an index into an array of 64 printable characters. The character at that index goes into the output string. These characters, listed in Table 0, were picked so they're universally representable, and the set leaves out characters with special meaning to SMTP (like ".", "<CR>", and "<LF>") 🙈.

Special processing happens if fewer than 24 bits are available in an input group. That can occur at the end of a message or, when selective encryption is invoked, at the end of an encrypted region or an excluded region. A full encoding quantum is always completed at the end of a message, and before the delimiter * gets output to start or end the representation of a block excluded from encryption. When fewer than 24 input bits are available, zero bits get added on the right to make an integral number of 6-bit groups. Output character positions that aren't needed to represent actual input data are set to =. Since all canonically encoded output is an integral number of octets, only three cases can happen 🫶:

(1) The final quantum of encoding input is an integral multiple of 24 bits. Then the final unit of encoded output is an integral multiple of 4 characters, with no = padding.

(2) The final quantum of encoding input is exactly 8 bits. Then the final unit of encoded output is two characters followed by two = padding characters.

(3) The final quantum of encoding input is exactly 16 bits. Then the final unit of encoded output is three characters followed by one = padding character.

4.3.2.5. Summary of Transformations 🦋

Here's the whole recap, bestie ✨. The outbound message goes through this composition of transformations:

        Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))

To process inbound privacy-enhanced mail, you do the inverse transformations in reverse order:

       Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))

Here's the encoding table, which is giving alphabet soup energy 🔤:

   Value Encoding  Value Encoding  Value Encoding  Value Encoding
       0 A            17 R            34 i            51 z
       1 B            18 S            35 j            52 0
       2 C            19 T            36 k            53 1
       3 D            20 U            37 l            54 2
       4 E            21 V            38 m            55 3
       5 F            22 W            39 n            56 4
       6 G            23 X            40 o            57 5
       7 H            24 Y            41 p            58 6
       8 I            25 Z            42 q            59 7
       9 J            26 a            43 r            60 8
      10 K            27 b            44 s            61 9
      11 L            28 c            45 t            62 +
      12 M            29 d            46 u            63 /
      13 N            30 e            47 v
      14 O            31 f            48 w         (pad) =
      15 P            32 g            49 x
      16 Q            33 h            50 y           (1) *

   (1) The character "*" is used to enclose portions of an
   encoded message to which encryption processing has not
   been applied.


                       Printable Encoding Characters
                                  Table 1

Also, the local form and the functions that transform messages to and from canonical form can vary between sender and recipient systems without any loss of information 💖.

4.4. Encapsulation Mechanism 🎀

Encapsulating privacy-enhanced messages inside an enclosing layer of headers, the kind the electronic mail transport system interprets, has a bunch of perks compared to a flat approach where certain fields in a single header get encrypted and/or carry cryptographic control info 💅. Encapsulation brings generality and keeps fields with user-to-user significance separate from the ones that get transformed in transit. All fields inserted during encryption/authentication processing go into the encapsulated header. That's great for compatibility with mail handling programs that accept only text, not header fields, from input files or other programs 🧚. Privacy enhancement processing can also be applied recursively, which is so cool 🌀. As far as the MTS is concerned, anything folded into the cryptographic authentication or encryption processing lives in the message's text portion, not its header portion 🫶.

The encapsulation mechanism for privacy-enhanced mail is derived from the one described in RFC-934 [11], which itself builds on precedents in how the Internet community processes message digests 🌸. To get a user message ready for encrypted or authenticated transmission, it gets transformed into the representation shown in Figure 1.

As a general design principle, sensitive data is protected by putting it inside the encapsulated text, rather than applying measures to fields in the enclosing header 🔒. Examples of potentially sensitive header info include fields like Subject:, whose contents matter on an end-to-end, inter-user basis. The set of headers to protect (which might be empty) is a user option. It's strongly recommended, though, that all implementations replicate copies of X-Sender-ID: and X-Recipient-ID: fields within the encapsulated text 👑.

If a user wants disclosure protection for header fields, those fields must occur only in the encapsulated text, and not in the enclosing or encapsulated header 🙈. If you want disclosure protection for a message's subject, it's recommended that the enclosing header contain a Subject: field that says Encrypted Mail Follows ✨.

If you want an authenticated version of header info, that data can be copied into the encapsulated text portion as well as included in the enclosing header. For example, a sender who wants to give recipients a protected indication of a message's position in a series of messages could include a copy of a timestamp or message counter field within the encapsulated text ⭐.

There's one more thing worth noting about how privacy-enhanced mail fits with the encapsulation mechanism 💀. The subset of IA5 chosen for transmission encoding intentionally excludes the character "-". That means encapsulated text can be told apart, without character stuffing, from the message's closing encapsulation boundary (Post-EB) 🦋.

Here's the layout of an encapsulated message:

   Enclosing Header Portion
           (Contains header fields per RFC-822)

   Blank Line
           (Separates Enclosing Header from Encapsulated Message)

   Encapsulated Message

       Pre-Encapsulation Boundary (Pre-EB)
           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

       Encapsulated Header Portion
           (Contains encryption control fields inserted in plaintext.
           Examples include "X-DEK-Info:", "X-Sender-ID:", and
           "X-Key-Info:".
           Note that, although these control fields have line-oriented
           representations similar to RFC-822 header fields, the set
           of fields valid in this context is disjoint from those used
           in RFC-822 processing.)

       Blank Line
           (Separates Encapsulated Header from subsequent encoded
           Encapsulated Text Portion)

       Encapsulated Text Portion
           (Contains message data encoded as specified in Section 4.3;
           may incorporate protected copies of enclosing and
           encapsulated header fields such as "Subject:", etc.)

       Post-Encapsulation Boundary (Post-EB)
           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----


                           Message Encapsulation
                                 Figure 1

4.5. Mail for Mailing Lists 💌

Okay so when mail gets addressed to mailing lists 📬, there are two different ways it can be processed: the IK-per-list method and the IK-per-recipient method. Which one applies depends on what info the sender has, plus the sender's preference 💅.

If a sender addresses a message to a list name or alias, the IK tied to that name or alias as an entity gets used (that's the IK-per-list method), instead of the name or alias being resolved into its constituent destinations 🫶. So that IK MUST be available to all list members. For asymmetric key management, the list's private component MUST be available to all list members too. This is gonna be the normal case for messages sent through remote exploder sites 🌸, since a sender to those lists might not even know who the individual recipients are. Unfortunately 😭, this means the shared IK is way more exposed than it should be, and revoking it is a whole headache. Plus, the IK-per-list method lets any holder of the list's IK masquerade as another sender to the list for authentication purposes. Absolutely not 💀.

If instead the sender can expand the mailing list into its individual constituents and chooses to do that (the IK-per-recipient method) 🎀, then the message's DEK (and, in the symmetric key management case, MIC) gets encrypted under each per-recipient IK, and all of those encrypted versions get packed into the transmitted message. Note that per-recipient encryption is REQUIRED only for the relatively small DEK and MIC quantities carried in the X-Key-Info: field, not for the message text, which is, in general, much larger 📦. Yes, more IKs are involved in processing under this method, but the pairwise IKs can each be revoked individually, and having one IK doesn't let someone successfully masquerade as another user on the list 🔥.

4.6. Summary of Encapsulated Header Fields ✨

This section is basically the recap of the syntax and semantics of the encapsulated header fields that get added to messages during privacy enhancement processing 🧚. The fields are presented in three groups. Normally, the groups show up in encapsulated headers in the order they're listed in, though not every field in each group will appear in every message 💜. In certain indicated cases, it is RECOMMENDED that the fields be replicated within the encapsulated text portion as well as being included within the encapsulated header. Figures 2 and 3 show what small example encapsulated messages look like 👀. Figure 2 assumes symmetric cryptography for key management. Figure 3 illustrates an example encapsulated message where asymmetric key management is used.

   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: linn@ccy.bbn.com::
   X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3
   X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
    A60195DB94F727D3
   X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4
   X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
    9F83A2658132DB47

   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
               Example Encapsulated Message (Symmetric Case)
                                 Figure 2
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 3,ENCRYPTED
   X-DEK-Info: DES-CBC,F8143EDE5960C597
   X-Sender-ID: linn@ccy.bbn.com::
   X-Certificate:
    jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
    YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
    agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
   X-Issuer-Certificate:
    TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
    IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
    vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
   X-MIC-Info: RSA-MD2,RSA,
    5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
   X-Recipient-ID: linn@ccy.bbn.com:RSADSI:3
   X-Key-Info: RSA,
    lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHU
   X-Recipient-ID: privacy-tf@venera.isi.edu:RSADSI:4
   X-Key-Info: RSA,
    NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh

   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
              Example Encapsulated Message (Asymmetric Case)
                                 Figure 3

Unless otherwise specified, all field arguments are processed in a case-sensitive fashion 🔠. In most cases, numeric quantities are represented in header fields as contiguous strings of hexadecimal digits, where each digit is represented by a character from the ranges "0"-"9" or upper case "A"-"F". Since public-key certificates and quantities encrypted using asymmetric algorithms are large in size, a more space-efficient encoding technique is appropriate for those quantities, so the encoding mechanism defined in Section 4.3.2.4 of this RFC, which represents 6 bits per printed character, is adopted 🧮. The example shown in Figure 3 shows asymmetrically encrypted quantities (e.g., X-MIC-Info:, X-Key-Info:) with 64-character printed representations, corresponding to 384 bits. The fields carrying asymmetrically encrypted quantities also illustrate the use of folding as defined in RFC-822, section 3.1.1 🦋.

Although the encapsulated header fields resemble RFC-822 header fields, they're a disjoint set and won't in general be processed by the same parser that handles the enclosing header fields 🙈. The lexical analysis needed for encapsulated header field processing is significantly less complex than what RFC-822 header processing needs. For example, many characters with special significance to RFC-822 at the syntactic level have no such significance within encapsulated header fields ✨.

When an encapsulated header field is longer than what can conveniently be printed on a line, whitespace MAY be used to fold the field in the manner of RFC-822, section 3.1.1 🌈. Any such inserted whitespace is not to be interpreted as a part of a subfield. As a particular example, because public-key certificates and quantities encrypted using asymmetric algorithms are so long, such quantities may often need to be folded across multiple printed lines. To make that folding uniform, the bits representing such a quantity are divided into an ordered set (with leftmost bits first) of zero or more 384-bit groups (corresponding to 64-character printed representations), followed by a final group of bits which may be any length up to 384 bits 🧩.

4.6.1. Per-Message Encapsulated Header Fields 🌟

This group contains fields which occur no more than once in a privacy-enhanced message, and they generally come before all the other encapsulated header fields 👑.

4.6.1.1. X-Proc-Type Field 🔐

The X-Proc-Type: encapsulated header field is REQUIRED for all privacy-enhanced messages. It identifies the type of processing performed on the transmitted message. Only one X-Proc-Type: field occurs in a message, and the X-Proc-Type: field MUST be the first encapsulated header field in the message 🥇.

The X-Proc-Type: field has two subfields, separated by a comma. The first subfield is a decimal number used to tell apart incompatible encapsulated header field interpretations that might pop up as changes get made to this standard 🔢. Messages processed according to this RFC will carry the subfield value 3, which tells them apart from messages processed in accordance with prior RFCs 989 and 1040 🦋.

The second subfield may assume one of two string values: ENCRYPTED or MIC-ONLY 💖. Unless all of a message's encapsulated text is excluded from encryption, the X-Proc-Type: field's second subfield MUST specify ENCRYPTED. Specifying MIC-ONLY, when applied in conjunction with certain combinations of key management and MIC algorithm options, lets certain fields that are superfluous without encryption get left out of the encapsulated header 🧹. In particular, X-Recipient-ID: and X-Key-Info: fields can be omitted for recipients for whom asymmetric cryptography is used, assuming concurrent use of a keyless MIC computation algorithm. The X-DEK-Info: field can be omitted for all MIC-ONLY messages.

4.6.1.2. X-DEK-Info Field 🗝️

The X-DEK-Info: encapsulated header field identifies the message text encryption algorithm and mode, and it also carries the Initializing Vector used for message encryption 🌸. No more than one X-DEK-Info: field occurs in a message. The field is REQUIRED except for messages specified as MIC-ONLY in the X-Proc-Type: field.

The X-DEK-Info: field carries two arguments, separated by a comma. For purposes of this RFC, the first argument MUST be the string DES-CBC, which signifies (as defined in RFC-1115) use of the DES algorithm in the CBC mode 🧁. The second argument represents a 64-bit Initializing Vector (IV) as a contiguous string of 16 hexadecimal digits. Subsequent revisions of RFC-1115 will specify any additional values which may appear as the first argument of this field 🔮.

4.6.2. Encapsulated Header Fields Normally Per-Message 💜

This group contains fields which ordinarily occur no more than once per message. Depending on the key management option(s) employed, some of these fields may be absent from some messages 🌙. The X-Sender-ID field may occur more than once in a message if different sender-oriented IK components (perhaps corresponding to different versions) MUST be used for different recipients. In this case, later occurrences override prior occurrences 🔁. If a mixture of symmetric and asymmetric key distribution is used within a single message, the recipients for each type of key distribution technology SHOULD be grouped together to simplify parsing 🧠.

4.6.2.1 X-Sender-ID Field 💌

okay bestie, the X-Sender-ID: field is required for all privacy-enhanced messages ✨. It identifies the sender and hands over the sender's IK identification component 🪪. It should be replicated within the encapsulated text 🫶.

The IK identification component in an X-Sender-ID: field gets used with every X-Recipient-ID: field after it, until another X-Sender-ID: field shows up 🔄. The usual vibe is one single X-Sender-ID: field, placed before any of the X-Recipient-ID: fields 🧚.

The field holds three things, in this exact order: an Entity Identifier subfield, an (optional) Issuing Authority subfield, and an (optional) Version/Expiration subfield 📋. The optional ones get left out when the info is already redundant thanks to the X-Recipient-ID: fields that come later. That's usually the case when symmetric cryptography is doing the key management 🔐. The subfields are separated by the colon character (:), which can optionally be followed by whitespace 💖.

Section 5.2, Interchange Keys, is where the semantics and the alphabet for these subfields live 📖. Also, multiple X-Sender-ID: fields can show up in one encapsulated header 🌈. Every X-Recipient-ID: field gets read in the context of the most recent X-Sender-ID: field before it.

🚨 Bestie, it is illegal for an X-Recipient-ID: field to show up in a header before an X-Sender-ID: has been provided. Don't do it 💀.

4.6.2.2 X-Certificate Field 🎀

The X-Certificate: field only gets used when asymmetric key management is employed for one or more of a message's recipients 🔑. To make life easier for recipients (especially before directory servers are generally available), putting this field in all messages is strongly recommended 🙏. The field carries a sender's certificate as a numeric quantity, represented with the encoding mechanism from Section 4.3.2.4 of this RFC 🔢. What certificates actually mean is covered in RFC-1114 📚. The certificate in an X-Certificate: field is used together with the X-Sender-ID: and X-Recipient-ID: fields for which asymmetric key management is employed 🦋.

4.6.2.3 X-MIC-Info Field 🔍

The X-MIC-Info: field only appears when asymmetric key management is employed for at least one recipient of a message, and it's giving three arguments, separated by commas 🎀.

  1. First argument: the algorithm under which the accompanying MIC is computed. RFC-1115 specifies the acceptable set of MIC algorithm identifiers 🧮.
  2. Second argument: the algorithm under which the accompanying MIC is encrypted. For purposes of this RFC, the string "RSA", as described in RFC-1115, must occur, identifying use of the RSA algorithm 🔐.
  3. Third argument: a MIC that's been asymmetrically encrypted using the originator's private component 🕵️. As discussed earlier in this section, the asymmetrically encrypted MIC is represented using the technique described in Section 4.3.2.4 of this RFC.

The X-MIC-Info: field will occur immediately following the message's X-Sender-ID: field and any X-Certificate: or X-Issuer-Certificate: fields 📍. Just like X-Sender-ID:, an X-MIC-Info: field applies to all subsequent recipients for whom asymmetric key management is used 🔁.

4.6.3 Encapsulated Header Fields with Variable Occurrences 🎢

This group is the "how many times is this showing up?" crew 🤷. These fields normally occur a variable number of times in a message, anywhere from zero up to some non-zero count. That count is independent of how many recipients there are 💜.

4.6.3.1 X-Issuer-Certificate Field 🏛️

The X-Issuer-Certificate: field only means something when asymmetric key management is used for at least one of a message's recipients 🎯. A typical one holds the certificate with the public component that was used to sign the certificate in the message's X-Certificate: field. That way recipients can chain through that certificate's certification path ⛓️. A sender can also include other ones, typically representing higher points in a certification path 🪜. The order these fields show up in doesn't have to match the order of the certification path. That path can look different depending on which recipient is looking 👀. More info on certification paths is in RFC-1114 📚.

The certificate is represented the same way as in the X-Certificate: field, and any X-Issuer-Certificate: fields will ordinarily follow the X-Certificate: field directly 📬. Using the X-Issuer-Certificate: field is optional even when asymmetric key management is employed. Still, including it is strongly recommended if there aren't alternate directory server facilities for recipients to grab issuers' certificates from 💖.

4.6.4 Per-Recipient Encapsulated Header Fields 👥

This group normally shows up once for each of a message's named recipients 👯. As a special case, these fields may be omitted in a MIC-ONLY message sent to recipients for whom asymmetric key management is employed, given that the chosen MIC algorithm is keyless 🗝️.

4.6.4.1 X-Recipient-ID Field 🪪

The X-Recipient-ID: field identifies a recipient and provides the recipient's IK identification component 🎯. There's one X-Recipient-ID: field for each of a message's named recipients. It should be replicated within the encapsulated text 🫶. The field holds (in order) an Entity Identifier subfield, an Issuing Authority subfield, and a Version/Expiration subfield. The subfields are delimited by the colon character (:), optionally followed by whitespace 💅.

Section 5.2, Interchange Keys, discusses the semantics of the subfields and specifies the alphabet they're chosen from 📖. All X-Recipient-ID: fields get interpreted in the context of the most recent preceding X-Sender-ID: field. It's illegal for an X-Recipient-ID: field to occur in a header before an X-Sender-ID: has been provided 🚫.

4.6.4.2 X-Key-Info Field 🔑

One X-Key-Info: field is included for each of a message's named recipients 🎟️. Each X-Key-Info: field is interpreted in the context of the most recent preceding X-Recipient-ID: field. Normally, an X-Key-Info: field will immediately follow its associated X-Recipient-ID: field 👯‍♀️. Its arguments are different depending on whether symmetric or asymmetric key management is used for a particular recipient 🌗.

4.6.4.2.1 Symmetric Key Management 🧁

When symmetric key management is employed for a given recipient, the X-Key-Info: field transfers four items, separated by commas: an IK Use Indicator, a MIC Algorithm Indicator, a DEK, and a MIC 🍰. The IK Use Indicator identifies the algorithm and mode in which the identified IK was used for DEK encryption for a particular recipient. For recipients under symmetric key management, it may assume the reserved string values "DES-ECB" or "DES-EDE", as defined in RFC-1115 🌸.

The MIC Algorithm Indicator identifies the MIC computation algorithm used for a particular recipient, and its values are defined in RFC-1115 🧮. The DEK and MIC are encrypted under the IK identified by a preceding X-Recipient-ID: field and prior X-Sender-ID: field. They're represented as two strings of contiguous hexadecimal digits, separated by a comma 🔢.

When DEA-1 is used for message text encryption, the DEK representation will be 16 hexadecimal digits (that's a 64-bit key 🔐). This subfield can be extended to 32 hexadecimal digits (a 128-bit key) if it's needed to support other algorithms 🌈.

Symmetric encryption of MICs is always performed in the same encryption mode used to encrypt the message's DEK 🔁. Encrypted MICs, like encrypted DEKs, are represented as contiguous strings of hexadecimal digits. The size of a MIC depends on the choice of MIC algorithm, as specified in the MIC Algorithm Indicator subfield 📏.

4.6.4.2.2 Asymmetric Key Management 🗝️

When asymmetric key management is employed for a given recipient, the X-Key-Info: field transfers two quantities, separated by commas 🧩. The first argument is an IK Use Indicator identifying the algorithm (and mode, if applicable) in which the DEK is encrypted. For purposes of this RFC, the IK Use Indicator subfield will always assume the reserved string value "RSA" (as defined in RFC-1115) for recipients under asymmetric key management, signifying use of the RSA algorithm 🦾. The second argument is a DEK, encrypted (using asymmetric encryption) under the recipient's public component 🎁.

Throughout this RFC, we've adopted the terms "private component" and "public component" to refer to the quantities that are, respectively, kept secret and made publicly available in asymmetric cryptosystems 🤫📢. This convention avoids confusion with the term "secret key", which could mean either of those or a key in a symmetric cryptosystem 🙃.

As discussed earlier in this section, the asymmetrically encrypted DEK is represented using the technique described in Section 4.3.2.4 of this RFC 💯.

5. Key Management 🗝️👑

Several cryptographic constructs are involved in supporting the privacy-enhanced message processing procedure ✨. A set of fundamental elements is assumed. Data Encrypting Keys (DEKs) are used to encrypt message text and, for some MIC computation algorithms, take part 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 way that's securely bound by a central authority 🏛️. The remainder of this section gives more info about these constructs 🧐.

5.1. Data Encrypting Keys (DEKs) ✨

okay bestie, DEKs (Data Encrypting Keys) 🔐 are the keys that encrypt the message text, and (with some MIC computation algorithms) they also help compute the message integrity check quantities (MICs) 💅. It is strongly RECOMMENDED that DEKs be generated and used on a one-time, per-message basis 🦋. A transmitted message will incorporate a representation of the DEK encrypted under an appropriate interchange key (IK) for each of the named recipients 💌.

DEK generation can happen either centrally by key distribution centers (KDCs) or by endpoint systems 🧚. Dedicated KDC systems MAY be able to implement stronger algorithms for random DEK generation than can be supported in endpoint systems 🔥. But decentralization is so iconic because endpoints get to be relatively self-sufficient 🌸, which means less trust has to be placed in components other than a message's originator and recipient 🫶. Plus, decentralized DEK generation at endpoints reduces the frequency with which senders MUST make real-time queries of (potentially unique) servers in order to send mail, which boosts communications availability 📬.

When symmetric cryptography is used, one perk of centralized KDC-based generation is that DEKs can be returned to endpoints already encrypted under the IKs of message recipients, rather than providing the IKs to the senders 🙅‍♀️. This reduces IK exposure and simplifies endpoint key management requirements 💖. This approach has less value if asymmetric cryptography is used for key management 🤔, since per-recipient public IK components are assumed to be generally available and per-sender private IK components need not necessarily be shared with a KDC 🗝️.

5.2. Interchange Keys (IKs)

Interchange Key (IK) components are used to encrypt DEKs and MICs 🎀.

In general, IK granularity is at the pairwise per-user level, except for mail sent to address lists comprising multiple users 👯. In order for two principals to engage in a useful exchange of privacy-enhanced electronic mail using conventional cryptography, they MUST first possess common IK components (when symmetric key management is used) or complementary IK components (when asymmetric key management is used) 🤝. When symmetric cryptography is used, the IK consists of a single component, used to encrypt both DEKs and MICs. When asymmetric cryptography is used, a recipient's public component is used as an IK to encrypt DEKs (a transformation invertible only by a recipient possessing the corresponding private component), and the originator's private component is used to encrypt MICs (a transformation invertible by all recipients, since the originator's certificate provides the necessary public component of the originator) 🔑.

While this RFC does not prescribe the means by which interchange keys are provided to appropriate parties, it is useful to note that such means MAY be centralized (e.g., via key management servers) or decentralized (e.g., via pairwise agreement and direct distribution among users) 🌈. In any case, any given IK component is associated with a responsible Issuing Authority (IA). When certificate-based asymmetric key management, as discussed in RFC-1114, is employed, the IA function is performed by a Certification Authority (CA) 📜.

When an IA generates and distributes an IK component, associated control information is provided to direct how it is to be used. In order to select the appropriate IK(s) to use in message encryption, a sender MUST retain a correspondence between IK components and the recipients with which they are associated. Expiration date information MUST also be retained, in order that cached entries MAY be invalidated and replaced as appropriate ⏰.

Since a message MAY be sent with multiple IK components identified, corresponding to multiple intended recipients, each recipient's UA MUST be able to determine that recipient's intended IK component. Moreover, if no corresponding IK component is available in the recipient's database when a message arrives, the recipient MUST be able to identify the required IK component and identify that IK component's associated IA. Note that different IKs MAY be used for different messages between a pair of communicants. Consider, for example, one message sent from A to B and another message sent (using the IK-per-list method) from A to a mailing list of which B is a member. The first message would use IK components associated individually with A and B, but the second would use an IK component shared among list members 💫.

When a privacy-enhanced message is transmitted, an indication of the IK components used for DEK and MIC encryption MUST be included. To this end, the X-Sender-ID: and X-Recipient-ID: encapsulated header fields provide the following data:

  1. Identification of the relevant Issuing Authority (IA subfield)
  2. Identification of an entity with which a particular IK component is associated (Entity Identifier or EI subfield)
  3. Version/Expiration subfield

The colon character (:) is used to delimit the subfields within an X-Sender-ID: or X-Recipient-ID:. The IA, EI, and version/expiration subfields are generated from a restricted character set, as prescribed by the following BNF (using notation as defined in RFC-822, sections 2 and 3.3) 🧩:

IKsubfld       :=       1*ia-char

ia-char        :=       DIGIT / ALPHA / "'" / "+" / "(" / ")" /
                           "," / "." / "/" / "=" / "?" / "-" / "@" /
                           "%" / "!" / '"' / "_" / "<" / ">"

An example X-Recipient-ID: field is as follows:

X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2

This example field indicates that IA "ptf-kmc" has issued an IK component for use on messages sent to "linn@ccy.bbn.com", and that the IA has provided the number 2 as a version indicator for that IK component 🦋.

5.2.1. Subfield Definitions

The following subsections define the subfields of X-Sender-ID: and X-Recipient-ID: fields 📝.

5.2.1.1. Entity Identifier Subfield

An entity identifier is constructed as an IKsubfld. More restrictively, an entity identifier subfield assumes the following form:

<user>@<domain-qualified-host>

In order to support universal interoperability, it is necessary to assume a universal form for the naming information. For the case of installations which transform local host names before transmission into the broader Internet, it is strongly RECOMMENDED that the host name as presented to the Internet be employed 🌐.

5.2.1.2. Issuing Authority Subfield

An IA identifier subfield is constructed as an IKsubfld. IA identifiers MUST be assigned in a manner which assures uniqueness. This can be done on a centralized or hierarchic basis 🏛️.

5.2.1.3. Version/Expiration Subfield

A version/expiration subfield is constructed as an IKsubfld. The version/expiration subfield format MAY vary among different IAs, but MUST satisfy certain functional constraints. An IA's version/expiration subfields MUST be sufficient to distinguish among the set of IK components issued by that IA for a given identified entity. Use of a monotonically increasing number is sufficient to distinguish among the IK components provided for an entity by an IA; use of a timestamp additionally allows an expiration time or date to be prescribed for an IK component 🔢.

5.2.2. IK Cryptoperiod Issues

An IK component's cryptoperiod is dictated in part by a tradeoff between key management overhead and revocation responsiveness. It would be undesirable to delete an IK component permanently before receipt of a message encrypted using that IK component, as this would render the message permanently undecipherable 😭. Access to an expired IK component would be needed, for example, to process mail received by a user (or system) which had been inactive for an extended period of time. In order to enable very old IK components to be deleted, a message's recipient desiring encrypted local long term storage SHOULD transform the DEK used for message text encryption via re-encryption under a locally maintained IK, rather than relying on IA maintenance of old IK components for indefinite periods 🗄️.

6. User Naming

6.1. Current Approach

Unique naming of electronic mail users, as is needed in order to select corresponding keys correctly, is an important topic and one which has received significant study 🧐. Our current architecture associates IK components with user names represented in a universal form ("user@domain-qualified-host"), relying on the following properties:

  1. The universal form MUST be specifiable by an IA as it distributes IK components and known to a UA as it processes received IK components and IK component identifiers. If a UA or IA uses addresses in a local form which is different from the universal form, it MUST be able to perform an unambiguous mapping from the universal form into the local representation.
  2. The universal form, when processed by a sender UA, MUST have a recognizable correspondence with the form of a recipient address as specified by a user (perhaps following local transformation from an alias into a universal form).

It is difficult to ensure these properties throughout the Internet 🌍. For example, an MTS which transforms address representations between the local form used within an organization and the universal form as used for Internet mail transmission MAY cause property 2 to be violated 🙈.

6.2. Issues for Consideration

The use of flat (non-hierarchic) electronic mail user identifiers, which are unrelated to the hosts on which the users reside, MAY offer value 💜. As directory servers become more widespread, it MAY become appropriate for would-be senders to search for desired recipients based on such attributes. Personal characteristics, like social security numbers, might be considered. Individually-selected identifiers could be registered with a central authority, but a means to resolve name conflicts would be necessary.

A point of particular note is the desire to accommodate multiple names for a single individual, in order to represent and allow delegation of various roles in which that individual MAY act 🎭. A naming mechanism that binds user roles to keys is needed. Bindings cannot be immutable, since roles sometimes change (e.g., the comptroller of a corporation is fired) 💀.

It MAY be appropriate to examine the prospect of extending the DARPA/DoD domain system and its associated name servers to resolve user names to unique user IDs 🔍. An additional issue arises with regard to mailing list support: name servers do not currently perform (potentially recursive) expansion of lists into users. ISO and CSNet are working on user-level directory service mechanisms, which MAY also bear consideration 🌸.

7. Example User Interface and Implementation 🎀

Okay so bestie, to put everything we've been talking about into context, this section gives a sneak peek at a prototype implementation 👀. It's a standalone program that a user invokes, and it lies above the existing UA sublayer. On UNIX, and possibly other environments too, it can be run as a "filter" inside an electronic mail UA or a text editor, which makes the whole sequence of steps way less of a hassle 💅. The slay part is that it can work with a range of UA programs, instead of being compatible with only one particular UA 🦋.

When a user wants to add privacy enhancements to an outgoing message, they write the message text and run the standalone program. They interact with it to give the address info and other stuff needed for privacy enhancement processing, and then it generates output that's ready to go through the UA 📨. When someone gets a privacy-enhanced message, the UA delivers it in encrypted form, and the standalone program takes over for decryption and the rest of the processing 🔐.

In this prototype (based on symmetric key management), a cache of IK components is kept in a local file, and the entries are managed manually using info from originators and recipients 🗂️. It's basically a simple database, no cap 💜. IK components are picked for transmitted messages based on the sender's identity and the recipient names, and the matching "X-Sender-ID:" and "X-Recipient-ID:" fields go into the message's encapsulated header 🎀. When a message comes in, those fields are used to look up the database and grab the right IK component entries ✨. DEKs and IVs are generated dynamically inside the program 🔥.

Options and destination addresses are chosen with command line arguments to the standalone program ⭐. Specifying destination addresses to the privacy enhancement program is logically separate from specifying the corresponding addresses to the UA for use by the MTS 🧚. Why? Because the local form of an address, as given to a UA, is often different from the Internet global form used in the "X-Sender-ID:" and "X-Recipient-ID:" fields 🙈. Iykyk.

8. Areas For Further Study 🔭

The procedures defined in this RFC are enough to support implementing privacy-enhanced electronic mail transmission among cooperating parties on the Internet 💌. But there's more work to do to boost robustness, generality, and interoperability 🛠️. Specifically, further work is needed in these areas:

  1. User naming techniques, and how they relate to the domain system, name servers, directory services, and key management functions.
  2. Detailed standardization of Issuing Authority and directory service functions and interactions.
  3. Privacy-enhanced interoperability with X.400 mail.

We anticipate generating subsequent RFCs that will address these topics 👑. Stay tuned, bestie 🌈.

9. References 📚

This section identifies background references that might be useful to anyone thinking about using the mechanisms defined in this RFC 🧐.

ISO 7498/Part 2 - Security Architecture, prepared by ISO/TC97/SC 21/WG 1 Ad hoc group on Security, extends the OSI Basic Reference Model to cover security aspects which are general architectural elements of communications protocols, and provides an annex with tutorial and background information 🧠.

US Federal Information Processing Standards Publication (FIPS PUB) 46, Data Encryption Standard, 15 January 1977, defines the encipherment algorithm used for message text encryption and Message Authentication Code (MAC) computation 🔑.

FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines specific modes in which the Data Encryption Standard algorithm may to be used to perform encryption 🌸.

FIPS PUB 113, Computer Data Authentication, May 1985, defines a specific procedure for use of the Data Encryption Standard algorithm to compute a MAC 💜.

NOTES ✨

[1] Key generation for MIC computation and message text encryption may either be performed by the sending host or by a centralized server. This RFC does not constrain this design alternative. Section 5.1 identifies possible advantages of a centralized server approach if symmetric key management is employed 🖥️.

[2] American National Standard Data Encryption Algorithm (ANSI X3.92-1981), American National Standards Institute, Approved 30 December 1980.

[3] Federal Information Processing Standards Publication 46, Data Encryption Standard, 15 January 1977.

[4] Information Processing Systems: Data Encipherment: Modes of Operation of a 64-bit Block Cipher.

[5] Federal Information Processing Standards Publication 81, DES Modes of Operation, 2 December 1980.

[6] ANSI X9.17-1985, American National Standard, Financial Institution Key Management (Wholesale), American Bankers Association, April 4, 1985, Section 7.2.

[7] Postel, J., "Simple Mail Transfer Protocol" RFC-821, USC/Information Sciences Institute, August 1982.

[8] This transformation should occur only at an SMTP endpoint, not at an intervening relay, but may take place at a gateway system linking the SMTP realm with other environments 🔁.

[9] Use of the SMTP canonicalization procedure at this stage was selected since it is widely used and implemented in the Internet community, not because SMTP interoperability with this intermediate result is required; no privacy-enhanced message will be passed to SMTP for transmission directly from this step in the four-phase transformation procedure 🧩.

[10] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC-822, August 1982.

[11] Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC-934, January 1985.

[12] CCITT Recommendation X.411 (1988), "Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures".

[13] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework".

[14] Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June 1986.

[15] Federal Information Processing Standards Publication 113, Computer Data Authentication, May 1985.

[16] American National Standard for Information Systems - Data Encryption Algorithm - Modes of Operation (ANSI X3.106-1983), American National Standards Institute - Approved 16 May 1983.

[17] Voydock, V. and S. Kent, "Security Mechanisms in High-Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 2, Pages 135-171, June 1983 📖.

Author's Address 🦋

John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA  01719-1326

Phone: 508-264-5491

EMail: Linn@ultra.enet.dec.com
📦 where this page comes from