RFC 989

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

📅 published February 1987, from ietf

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

RFC 989, from the Network Working Group, written by John Linn (BBNCC) for the IAB Privacy Task Force, dated February 1987. It's a proposed protocol for the Internet community, and it's open for discussion and suggestions for improvements. It doesn't list any RFCs it obsoletes or updates. 💖

Status of This Memo ✨

okay so this RFC is a proposed protocol that the Internet community can look at, and it's basically asking for feedback and ideas to make it better 🫶 distribution of this memo is unlimited, so share it with whoever you want 💅

Acknowledgment 🌸

this RFC came out of a whole series of IAB Privacy Task Force meetings, plus internal working papers that got passed around for those meetings. huge thanks to these Privacy Task Force members and meeting guests for their comments and contributions at the meetings that led to it: David Balenson, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and Steve Wilbur. the squad really showed up 👑

1. Executive Summary 🦋

okay bestie, this RFC defines message encipherment and authentication procedures. think of it as the first phase of a bigger plan to give electronic mail transfer on the Internet some privacy enhancement services 🔐 the detailed key management mechanisms that support all this will get defined in a later RFC, so stay tuned 👀

a big goal of this first phase is that the procedures work with a wide range of key management approaches. that means both conventional (symmetric) and public-key (asymmetric) approaches for encrypting data encrypting keys are welcome, which is so iconic of them 🌈 using conventional cryptography for message text encryption and/or authentication is anticipated too.

so here's the vibe: privacy enhancement services (confidentiality, authentication, and message integrity assurance) are offered through end-to-end cryptography between the originator and recipient User Agent processes ✨ the Message Transfer System doesn't get any special processing requirements, either at the endpoints or at intermediate relay sites. that's the main slay, honestly 💅

this approach lets privacy enhancement facilities get added on a site-by-site or user-by-user basis, without impacting other Internet entities 🧚 and interoperability among heterogeneous components and mail transport facilities is supported. not me being impressed by how well it all fits together 😭

2. Terminology 💜

for descriptive purposes, this RFC uses some terms from the OSI X.400 Message Handling System Model. this section copies over a piece of X.400's Section 2.2.1, "Description of the MHS Model: Overview", so the terminology makes sense even if you've never looked at the OSI MHS Model before 🍓

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 writes messages with help from their User Agent. a User Agent (UA) 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 that a UA performs on its own, and that aren't standardized as part of the MH Service elements, are called local UA functions 🌸

the MTS is made up of a number 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 collection of UAs and MTAs is called the Message Handling System (MHS). the MHS and all of its users together are called the Message Handling Environment. it's giving whole ecosystem 🌍

3. Services, Constraints, and Implications 🎀

the goal of this RFC is to define mechanisms that enhance privacy for electronic mail transferred over the Internet 🔒 the facilities it talks about provide privacy enhancement services end-to-end, between sender and recipient UAs. no privacy enhancements are offered for message fields that get added or transformed by intermediate relay points, so those are on their own, bestie 🙈 there are two distinct privacy enhancement service options:

  1. an option providing sender authentication and integrity verification
  2. an option providing sender authentication and integrity verification in addition to confidentiality service through encryption

there's no facility for confidentiality service without authentication. it's not a thing here 🚫 encryption and authentication facilities may be applied selectively to portions of a message's contents. this means less sensitive parts of a message (like descriptive fields) can be handled by a recipient's delegate without the recipient's personal cryptographic keys. that's such a smart little detail 🧚

the Internet is super diverse in its constituencies and usage modes, so the measures defined here are meant to apply to a broad range of Internet hosts and usage paradigms 🌈 some specific attributes worth noting:

  1. the mechanisms defined in this RFC are not restricted to a particular host or operating system. instead, they allow interoperability among a broad range of systems. all privacy enhancements are implemented at the application layer, and they don't depend on any privacy features at lower protocol layers 💅
  2. the defined mechanisms are compatible with non-enhanced Internet components. privacy enhancements are implemented end-to-end in a way that doesn't affect mail processing by intermediate relay hosts that don't include privacy enhancement facilities. however, a message's sender does need to know whether the intended recipient implements privacy enhancements. that way, encoding and possible encipherment won't get done on a message whose destination can't perform the matching inverse transformations 🫶
  3. the defined mechanisms are compatible with a range of mail transport facilities (MTAs). inside the Internet, mail transport happens through a variety of SMTP implementations. certain sites, reachable via SMTP, forward mail into other mail processing environments (for example, USENET, CSNET, BITNET). the privacy enhancements must be able to operate across the SMTP realm, and it's desirable that they're also compatible with protecting 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). the Internet uses a huge variety of mail user agent programs, each with its own user interface paradigms 🎨 so that privacy enhancement can reach the widest possible user community, it's desirable that the selected mechanism works with as many existing UA programs as possible. for pilot implementation, it's desirable that privacy enhancement processing can be built into a separate program that works with a range of UAs, instead of needing internal modifications to each UA that gets enhanced privacy services 🔧
  5. the defined mechanisms allow electronic mail privacy enhancement processing to run on personal computers (PCs) that are separate from the systems where UA functions are implemented. with PCs being used more and more, and with limited trust that can be placed in UA implementations on many multi-user systems, this attribute lets many users process privacy-enhanced mail at a higher assurance level than a strictly UA-based approach would allow 💪
  6. the defined mechanisms support privacy protection of electronic mail addressed to mailing lists 📣

to make this work across the broadest possible range of Internet hosts and mail systems, and to make pilot implementation and testing easy without needing prior changes throughout the Internet, three basic restrictions are placed on the set of measures considered in this RFC:

  1. measures are restricted to implementation at endpoints, and they're designed to be integrated at the user agent (UA) level or above. they don't require integration into the message transport system (for example, SMTP servers) 🙅
  2. the set of supported measures enhances rather than restricts user capabilities. trusted implementations, which have integrity features that protect software from being subverted by local users, can't be assumed in general. without those features, it seems more feasible to provide facilities that enhance user services (for example, by protecting and authenticating inter-user traffic) than to enforce restrictions (for example, inter-user access control) on user actions 🧁
  3. the set of supported measures focuses on a set of functional capabilities chosen to give significant and tangible benefits to a broad user community. by concentrating on the most critical services, the aim is to maximize the added privacy value that can be provided with a modest level of implementation effort 🏆

because of these restrictions, the following facilities can be provided:

  • disclosure protection,
  • sender authenticity, and
  • message integrity measures,

but the following privacy-relevant concerns are not addressed:

  • access control,
  • traffic flow security,
  • address list accuracy,
  • routing control,
  • issues relating to the serial reuse of PCs by multiple users,
  • assurance of message receipt and non-deniability of receipt, and
  • automatic association of acknowledgments with the messages to which they refer
⚠️ heads up: the stuff in that second list is NOT covered by this RFC, so don't assume it's handled just because the first list sounds great 🙈

an important goal is that privacy enhancement mechanisms impose a minimum of burden on the users they serve. in particular, this goal points toward eventually automating the key management mechanisms behind message encryption and authentication 🤖 but to make deployment and testing of pilot privacy enhancement implementations happen in the near term, compatibility with out-of-band (for example, manual) key distribution must also be supported 🗝️

a message's sender decides whether privacy enhancements get performed on a particular message. that means there need to be mechanisms that let a sender figure out 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, which avoids dumping burdens or inconvenience on electronic mail users 💖

okay that's part 1 of 7 bestie, so more is coming 🫶✨

4. Processing of Messages 🎀

4.1. Message Processing Overview 💌

okay so this subsection is the big-picture tour of how privacy-enhanced email processing works, bestie 🫶 the later subsections get into the nitty gritty, so this is your map ✨

first up, there's a two-level keying hierarchy that makes private message transmission work 🔐

  1. Data Encrypting Keys (DEKs) are used to encrypt the message text and to compute message authentication codes (MACs) 🧁 they get generated fresh for each transmitted message, so no predistribution of DEKs is needed to support privacy-enhanced message transmission. no cap, that's so clean 💅
  2. Interchange Keys (IKs) are used to encrypt DEKs for transmission 🦋 an IK can be either a single symmetric cryptographic key, or, when asymmetric (public-key) cryptography is used for DEK encryption, it's a composition of a public component used by an originator and a secret component used by a recipient 🌸 usually the same IK gets used for all messages between a given originator-recipient pair over a period of time 💖 each transmitted message carries a representation of the DEK(s) used for message encryption and/or authentication, encrypted under an individual IK per named recipient 🧚 that representation comes with an identifier (IK ID) so the recipient can figure out which IK was used, and then decrypt the representation to get the DEK needed for message text decryption and/or MAC verification 😭 it's giving key handoff energy fr fr

now the encoding procedure 🌈 its whole job is to represent encrypted message text in a universally transmissible form, so messages encrypted on one type of system can be decrypted on a totally different type of system 🙈 there are four phases in this process:

  • phase one: a plaintext message is accepted in local form, using the host's native character set and line representation 💜
  • phase two: the local form gets converted to a canonical message text representation, which is defined as equivalent to the inter-SMTP representation of message text ✨
  • phase three: the canonical representation is padded to an integral multiple of eight octets, as required by the encryption algorithm 🍓 then MAC computation is performed, and (if disclosure protection is required) the padded canonical representation is encrypted 🔥
  • phase four: the output of that step is encoded into a printable form 🎀 this printable form is made of a restricted character set chosen to be universally representable across sites, and it won't be disrupted by processing within and between MTS entities 💅

then the encoded output gets combined with a set of header fields (to be defined in Section 4.8) carrying cryptographic control information 🫶 the result gets passed to the electronic mail system to be encapsulated as the text portion of a transmitted message 💌

and on the receiving end 🦋 the cryptographic control fields inside the text portion give the authorized recipient everything they need to do MAC verification and decryption 🔐 the steps go like this: first, the printable encoding gets converted to a bitstring 🌸 if the message was encrypted, it gets decrypted into the canonical representation ✨ if it wasn't encrypted, decoding from the printable form produces the canonical representation directly 🧁 then the MAC is verified, and the canonical representation is converted to the recipient's local form, which doesn't have to match the sender's local form 💖 slay 👑

4.2. Encryption Algorithms and Modes 🔐

okay bestie, this one's about which ciphers are allowed 🎀 for purposes of this RFC, the Block Cipher Algorithm DEA-1, defined in ISO draft international standard DIS 8227 [1] MUST be used for encryption of message text and for computation of authentication codes on messages 💅 wait, let me fix that, it's a SHALL 💜 the original says shall there, so: DEA-1 SHALL be used for encryption of message text and for computing authentication codes on messages 🫶

quick fact check on the family tree 🌳 DEA-1 is equivalent to the Data Encryption Standard (DES), as defined in FIPS PUB 46 [2] 🧚 when it's used for these purposes, DEA-1 SHALL be used in the Cipher Block Chaining (CBC) mode, as defined in ISO DIS 8372 [3] 🍓 the CBC mode definition in DIS 8372 is equivalent to the one in FIPS PUB 81 [4] ✨ and a unique initializing vector (IV) will be generated for and transmitted with each encrypted electronic mail message 🌈

now, other algorithms are allowed too, as long as they meet these requirements 🦋

  1. it MUST be a 64-bit block cipher, enciphering and deciphering in 8 octet blocks 💖
  2. it is usable in the ECB and CBC modes defined in DIS8372 🌸
  3. it is able to be keyed using the procedures and parameters defined in this RFC 🧁
  4. it is appropriate for MAC computation 🔥
  5. cryptographic key field lengths are limited to 16 octets in length 👑

okay now the interchange key stuff 🔑 certain operations need one key encrypted under another key (the interchange key) for transmission 💜 for purposes of this RFC, that encryption SHALL be done with DEA-1 in Electronic Codebook (ECB) mode 🎀 there's an optional facility where an interchange key provider can say that an associated key should be used for encryption in another mode 💅 the example given is the Encrypt-Decrypt-Encrypt (EDE) mode, used for key encryption and decryption with pairs of 64-bit keys, as described [5] by ASC X3T1 🫶

last bit, and it's a lowkey important one 😭 public key algorithms for key encryption are under consideration for the future, and this RFC's procedures are intended to be appropriate to allow that usage 🔮 support of key encryption modes other than ECB is OPTIONAL for implementations, though 🦋 so for universal interoperability, interchange key providers SHOULD NOT specify other modes unless they have a priori information indicating that recipients are equipped to perform key encryption in other modes 🙈 that's the vibe, periodt 💖

4.3. Canonical Encoding 💅

okay so any encryption scheme has to play nice with the transparency constraints of the email facilities it runs on 🎀. Those constraints are usually set based on what users are expected to need and on the kinds of endpoint transport facilities people will actually use. SMTP was built mainly for interpersonal messages, and it expects systems and transport media that might be stuck on a 7-bit character set, so it can carry any 7-bit characters (but not arbitrary 8-bit binary data) in message text 🦋.

SMTP also has its own transparency rules about line lengths and message delimiters 📏. Message text must not contain the string <CR><LF>.<CR><LF> in sequence before the end of a message, and it must contain the string <CR><LF> at least every 1000 characters. There's another big SMTP transparency issue too 😭. SMTP says line delimiters are the ASCII <CR><LF>, but tons of systems use their own native way to mark lines. For example, the <CR><LF> sequences in mail going into UNIX(tm) systems get squished into a single <LF> when the mail is written to local mailbox files. Lines in mail heading to record-oriented systems (like VAX VMS) may get turned into proper records by the destination SMTP [6] server. So if the encryption process made <CR>s or <LF>s, the recipient's UA program at a destination with different line-delimiting conventions might not be able to access them. It's also possible that tabs and spaces get converted while mapping between inter-SMTP and local format, and that's a local option. If transformations like that changed the form of the transmitted ciphertext, decryption would fail to regenerate the transmitted plaintext, and a transmitted MAC would fail to match the one computed at the destination 💀.

EBCDIC systems are even more chaotic 🙈. The conversion an SMTP server does on a system with EBCDIC as its native character set has an even bigger impact, because converting EBCDIC into ASCII is an information-losing transformation. In principle, the function mapping between the inter-SMTP canonical ASCII representation and the local format could move from the SMTP server up to the UA, as long as there's a way to tell the SMTP server to stop doing that transformation. But that's a hard no from us 🙅. It would mean internal file (e.g., mailbox) formats that are incompatible with the systems they live on, which is an untenable prospect. It would also require changes to SMTP servers, since mail would get passed to SMTP in a different representation than it does today.

So our fix is to pick a canonical character set that every privacy-enhanced UA can represent uniformly, no matter what its system's native character set is. That set carries the encrypted mail text (but not electronic mail transport headers!) between endpoints 🫶.

In this approach, an outbound privacy-enhanced message gets transformed between four forms, in sequence:

  1. (Local_Form) The message text is created (e.g., in an editor) in the system's native character set, with lines delimited according to local convention.
  2. (Canonicalize) The message text is converted to the universal canonical form, which is equivalent to the inter-SMTP representation defined in RFC822 [7] (ASCII character set, <CR><LF> line delimiters). (The processing needed for this conversion is relatively small, at least on systems whose native character set is ASCII.)
  3. (Encipher/Authenticate) A padded version of the canonical plaintext representation is created by appending zero-valued octets to the end of the representation until the length is an integral multiple of 8 octets, as is required to perform encryption in the DEA-1 CBC mode. No padding is applied if the canonical plaintext representation's length is already a multiple of 8 octets. This padded representation is used as the input to the encryption function and to the MAC computation function.
  4. (Encode to Printable Form) The bits resulting from the encryption operation are encoded into characters that 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). The proposal is to use a 64-character subset of International Alphabet IA5, which lets 6 bits be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) Two additional characters, "=" and "*", are used to signify special processing functions. The encoding function's output is delimited into text lines (using local conventions), with each line containing 64 printable characters. The encoding process is performed as follows, transforming strings of 3 arbitrary (8-bit) characters into strings of 4 encoded characters:
    • 4a. Proceeding from left to right across the input characters (considered as a contiguous bitstring), each group of 6 bits is used as an index into an array of 64 printable characters, and 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>).
    • 4b. If fewer than 3 input characters are available in a final quantum, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions that are not required to represent actual input data are set to a 65th reserved, universally representable character ("="). Using a reserved character for padding allows compensatory processing to be performed by a recipient, so the decoded message text's length can be precisely the same as the input message's length. A final 3-octet input quantum will be represented as a 4-octet encoding with no terminal "=", a 2-octet input quantum will be represented as 3 octets followed by one terminal "=", and a 1-octet input quantum will be represented as 2 octets followed by two occurrences of "=".

A sender may exclude one or more portions of a message from encryption/authentication processing. Explicit action is required to exclude a portion of a message from such processing; by default, encryption/authentication is applied to the entirety of the 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/authentication processing. An excluded area is represented in the inter-SMTP transmission form (universal across communicating systems) by bracketing it with the reserved delimiter "*". Cryptographic state is preserved transparently across an excluded area and continues after the end of the excluded area. A printable encoding quantum (per step 4b) is completed before the delimiter "*" is output to initiate or terminate the representation of an excluded block. Note that the canonicalizing transformation (step 2 above) and the encoding to printable form (step 4 above) are applied to all portions of the message text, even those excluded from encryption and authentication.

In summary, the outbound message is subjected to the following composition of transformations:

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

The inverse transformations are performed, in reverse order, to process inbound privacy-enhanced mail:

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

Note that the local form, and the functions that transform messages to and from canonical form, may vary between the sender and recipient systems without loss of information. 🌈

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

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

                      Printable Encoding Characters
                                 Table 1

4.4 Encapsulation Mechanism ✨

okay so wrapping your privacy-enhanced message inside an enclosing layer of headers that the mail transport system reads is literally SO clean 💅 compared to the flat approach, where you'd encrypt a few fields in one header and cram the crypto control info in there too. encapsulation is more general, and it keeps the fields with user-to-user meaning separate from the stuff that gets transformed in transit 🎀. from the MTS's point of view, anything going 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 comes from RFC934 [8], which is itself built on earlier message digest processing in the Internet community 🌸 to get a user message ready for encrypted or authenticated transmission, you transform it into the representation shown in Figure 1. the processing might depend on stuff in the enclosing header (like To:), but every field added during encryption/authentication processing goes into the encapsulated header 🧚 this helps with mail handling programs that only accept text, not header fields, from input files or other programs. privacy enhancement processing can also be applied recursively 🔁

sensitive data should be protected by putting it inside the encapsulated text, not by poking at individual fields in the enclosing header 🔒 examples of potentially sensitive header info include stuff like Subject:, whose contents matter end-to-end between users 👀 the set of headers to protect (which can be empty) is a user option. if you want an authenticated version of header info, you can copy that data into the encapsulated text as well as keeping it in the enclosing header. if a user wants disclosure protection for header fields, they must occur only in the encapsulated text, not in the enclosing or encapsulated header ⚠️ and if you want disclosure protection for Subject:, it is recommended that the enclosing header contain a Subject: field saying Encrypted Mail Follows 💜

a specific point about mixing privacy-enhanced mail with the encapsulation mechanism is worth noting 🍓 the IA5 subset picked for transmission encoding intentionally leaves out the character -, so the encapsulated text can be told apart from the closing encapsulation boundary (Post-EB) without needing character stuffing. no cap, that's a clever little trick 🧠✨

4.5 Processing for Authentication Without Confidentiality ✨

so when a message only needs authentication and NOT confidentiality, a DEK gets generated [9] for the MAC computation, and then the MAC is computed with that DEK 🔑 for each individually identified recipient, you pick an IK and label it with an X-IK-ID: field. every X-IK-ID: field is followed by an X-Key-Info: field, which carries the key the MAC was computed under (encrypted under the IK named in the X-IK-ID: field right before it) along with the MAC, also encrypted under that same IK 🫠 the encapsulated text portion after the encapsulated header is canonically encoded and turned into printable characters for transmission, but it is NOT encrypted 👀

here's what the whole thing looks like, bestie 📦

   Enclosing Header Portion

          (Contains header fields per RFC-822)

   Blank Line

          (Separates Enclosing Header from Encapsulated Message)

   Encapsulated Message

       Pre-Encapsulation Boundary (Pre-EB)

           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

       Encapsulated Header Portion

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

       Blank Line

           (Separates Encapsulated Header from subsequent encoded
           Encapsulated Text Portion)

       Encapsulated Text Portion

           (Contains message data encoded as specified in Section 4.3;
           may incorporate protected copies of "Subject:", etc.)

       Post-Encapsulation Boundary (Post-EB)

           -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

                           Message Encapsulation
                                 Figure 1

the vibe check: the control fields look like RFC-822 header fields, but the set of valid fields here is totally separate from the ones used in RFC-822 processing 🙅‍♀️ so don't mix them up!

4.6 Processing for Authentication and Confidentiality ✨

okay this one is the full package 🎁 when a message needs authentication AND confidentiality, a DEK is generated for the MAC computation, and a variant of that DEK is formed for message encryption 🔐 for each individually identified recipient, you select an IK and identify it with an X-IK-ID: field. each X-IK-ID: field is followed by an X-Key-Info: field, which transfers the DEK and the computed MAC, each one encrypted under the IK named in the X-IK-ID: field before it 💖 the encapsulated text portion after the encapsulated header is canonically encoded, encrypted, and then turned into printable characters for transmission. main character energy, honestly 👑

4.7 Mail for Mailing Lists ✨

mailing lists are where things get spicy 🌶️ when mail is addressed to a list, there are two possible methods of processing: the IK-per-list method and the IK-per-recipient method 🦋 which one applies depends on what information the sender has and on the sender's preference.

so if a sender addresses a message to a list name or alias, using an IK tied to that name or alias as an entity (IK-per-list), instead of resolving the name or alias to its individual destinations, is implied. that means such an IK must be available to all list members. this is going to be the normal case for messages sent through remote exploder sites, since the sender may not know who the individual recipients are 🙈 the downside: it means the shared IK is exposed in an undesirable way, and revoking it is hard. also, the IK-per-list method lets any holder of the list's IK pretend to be another sender to the list for authentication purposes 😭

if instead the sender can expand the mailing list into its individual constituents and chooses to (IK-per-recipient), the message's DEK and MAC get encrypted under each per-recipient IK, and all of those encrypted versions go into the transmitted message 🧚‍♀️ (per-recipient encryption is only needed for the relatively small DEK and MAC carried in the X-Key-Info: field, not for the message text, which is usually much bigger ✨). yes, more IKs are involved with IK-per-recipient, but the pairwise IKs can be revoked individually, and having one IK doesn't let someone successfully masquerade as another user on the list 🥰

4.8. Summary of Added Header and Control Fields ✨

Okay bestie, this section is basically the cheat sheet 📋 for every new header and control field that gets added to a message during privacy enhancement processing. It tells you whether each field lives in the encapsulated header portion or the encapsulated text portion. Figure 2 shows a small example encapsulated message using these fields 🦋. Everywhere, hexadecimal quantities are contiguous strings of digits, where each digit is "0"-"9" or upper case "A"-"F" 💜. Unless it says otherwise, all arguments get processed case-sensitively, so don't mix up your casing 🙈.

The encapsulated header fields look a lot like RFC-822 header fields, but they're a totally separate set 🎀. They usually won't be handled by the same parser that handles the enclosing header fields. The lexical analysis you need for encapsulated header processing is way simpler than what RFC-822 header processing needs 💅. For example, lots of characters that are super meaningful to RFC-822 at the syntax level mean absolutely nothing inside encapsulated header fields 🌸.

X-IK-ID and X-Key-Info are the only encapsulated header fields whose lengths can grow past what fits neatly on one printed line 📏. You can use whitespace between their subfields to fold them the RFC-822 way, but that whitespace isn't part of any subfield 🫶.

      -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
      X-Proc-Type: 1,E
      X-Pad-Count: 1
      X-IV: F8143EDE5960C597
      X-IK-ID: JL:3:ECB
      X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
      X-IK-ID: JL:1:ECB
      X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7

      LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
      8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
      J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
      dXd/H5LMDWnonNvPCwQUHt==
      -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
                         Example Encapsulated Message
                                   Figure 2

X-IK-ID: goes in the encapsulated header portion and identifies the Interchange Key used for encrypting the associated Data Encrypting Key or keys (the ones used for message text encryption and/or MAC computation) 🔑. It's used for messages authenticated without confidentiality service and for messages authenticated with confidentiality service. The field contains, in order, an Issuing Authority subfield and an IK Qualifier subfield, and it may also contain an optional IK Use Indicator subfield. The subfields are delimited by the colon character (":"), optionally followed by whitespace. Section 5.1.2, Interchange Keys, discusses what these subfields mean and specifies the alphabet they're chosen from 📚. Heads up: multiple X-IK-ID fields can show up in a single encapsulated header, and each one is associated with the X-Key-Info field right after it 👯.

X-IV: goes in the encapsulated header portion to carry the Initializing Vector used for message encryption 🧊. It's only used for messages where confidentiality service is applied. After the field name and one or more delimiting whitespace characters, a 64-bit Initializing Vector is represented as a contiguous string of 16 hexadecimal digits.

X-Key-Info: goes in the encapsulated header portion and transfers two items: a DEK and a MAC 🗝️. Both items are encrypted under the IK identified by the X-IK-ID field just before it. They're two strings of contiguous hexadecimal digits, separated by a comma. For DEA-1, the DEK representation is 16 hexadecimal digits (a 64-bit key), but this subfield can be extended to 32 hexadecimal digits (a 128-bit key) if it's needed to support other algorithms 💪. The MAC is a 64-bit quantity, represented as 16 hexadecimal digits. The MAC is computed under an unmodified version of the DEK. Message encryption is performed using a variant of the DEK, formed by modulo-2 addition of the hexadecimal quantity F0F0F0F0F0F0F0F0 to the DEK.

X-Pad-Count: goes in the encapsulated header portion to indicate how many zero-valued octets were added to pad the input stream to the encryption function up to an integral multiple of eight octets, as the DEA-1 CBC encryption mode requires 🧸. A decimal number in the range 0-7 follows the field name and one or more delimiting whitespace characters. Including this field lets you tell apart terminal zero-valued octets in the message text (admittedly a relatively unlikely prospect 🙃) from zero-valued octets inserted for padding purposes.

X-Proc-Type: goes in the encapsulated header portion to identify the type of processing performed on the transmitted message 🔍. The first subfield is a decimal version number, which will be used if future developments make it necessary to redefine how encapsulated header fields are interpreted 🔮. Right now, this field may assume only the value "1". The second subfield, delimited by a comma, takes one of two single-character alphabetic values: "A" and "E". These signify, respectively, (1) authentication processing only and (2) the combination of authentication and confidentiality service through encryption 🔐.

5. Key Management 🗝️👑

5.1. Types of Keys 🎀

5.1.1. Data Encrypting Keys (DEKs) 🔑

Data Encrypting Keys (DEKs) are used for encryption of message text and for computation of message authentication codes (MACs) 💜. It is strongly recommended that DEKs be generated and used on a one-time basis 😭. A transmitted message will incorporate a representation of the DEK encrypted under an interchange key (IK) known to the authorized recipient 🫶.

DEK generation can be performed either centrally by key distribution centers (KDCs) or by endpoint systems 🖥️. One advantage of centralized KDC-based generation is that DEKs can be returned to endpoints already encrypted under the IKs of message recipients. That reduces IK exposure and simplifies endpoint key management requirements 💅. Further, dedicated KDC systems may be able to implement better algorithms for random key generation than can be supported in endpoint systems 🎲. On the other hand, decentralization allows endpoints to be relatively self-sufficient, reducing the level of trust which must be placed in components other than a message's originator and recipient 🦋. Moreover, decentralized DEK generation by endpoints reduces the frequency with which senders must make real-time queries of (potentially unique) servers in order to send mail, which enhances communications availability 🚀.

5.1.2 Interchange Keys (IKs) 🔑

okay bestie, Interchange Keys (IKs) are the keys used to encrypt Data Encrypting Keys 🔐. Usually the granularity is pairwise per-user, except when mail goes to an address list with multiple users. For two principals to actually swap privacy-enhanced email using conventional cryptography, they must first share a common interchange key 🫶. With asymmetric cryptography, an originator and recipient must each have the right public and secret components, which together make up an interchange key 💜.

How IKs get handed out is outside the scope of this RFC 🙈. It could be centralized (like key management servers) or decentralized (like direct distribution between users). Either way, every IK is tied to a responsible Issuing Authority (IA) ✨. When an IA generates and distributes an IK, it must also send along control information that says how that IK should be used. To pick the right IK for encryption, a sender must keep a correspondence between IKs and the recipients they're associated with. Expiration date info must be kept too, so cached entries can be invalidated and replaced when needed ⏰.

When a privacy-enhanced message is sent, it must include an indicator of the IK (or IKs, if the message goes to multiple recipients) used for DEK encryption. That's what the IK ID construct is for, and it provides:

  1. The relevant Issuing Authority (the IA subfield)
  2. A qualifier string that tells the particular IK apart from the others the IA distributed (the IK qualifier subfield)
  3. (Optional) An indicator of IK usage mode (the IK use indicator subfield)

The subfields of an IK ID are separated by colons (":") 🌈. The IA and IK qualifier subfields come from a restricted character set, prescribed by this BNF (using the notation from RFC-822, sections 2 and 3.3):

IAorIKQual   :=      1*ia-char

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

The IK use indicator subfield takes one value from a small set of reserved strings, which we'll cover later in this section 💅.

IA identifiers must be assigned in a way that guarantees uniqueness. That can be done on a centralized or hierarchic basis 🧚.

The IK qualifier string format can vary between IAs, but it must meet certain functional constraints. An IA's IK qualifiers must be enough to distinguish the IKs that IA issued. A message can be sent with multiple IK IDs for multiple intended recipients, so each recipient must be able to figure out which IK is meant for it. And if a recipient doesn't have the matching IK in its database when a message arrives, it must be able to work out which IK to request and identify that IK's associated IA 👀. Also, different IKs can be used for different messages between the same pair of communicants. Say one message goes from A to B, and another goes from A to a mailing list that B belongs to (using the IK-per-list method). The first message would use an IK shared between A and B, but the second would use an IK shared among the list members 📬.

A monotonically increasing number as an IK qualifier does distinguish between the IKs an IA distributes, but it gives a recipient with no matching IK no way to figure out which one to request. So the fix is to put sender and recipient name information into the qualifier, along with a number that tells apart multiple IKs used between a sender/recipient pair 💖. For universal interoperability, you need a universal form for the naming info. A general definition of that form still needs further study. Issues and possible approaches will be noted in Section 6. As an interim measure, the following IK qualifier format is suggested:

<sender-name>/<recipient-name>/<numid>

where <sender-name> and <recipient-name> are in this form:

<user>@<domain-qualified-host>

For installations that transform local host names before sending mail out to the broader Internet, it is strongly recommended that the host name as presented to the Internet be used. The <numid> is a contiguous string of decimal digits 🔢.

The IK use indicator subfield is an optional facility, used to identify the encryption mode the IK is meant to be used in. Right now, this subfield may take the reserved string values "ECB" and "EDE", and the default value is ECB 🦋.

Here's an example IK ID that follows this recommendation:

ptf-kmc:linn@CCY.BBN.COM/privacy-tf@C.ISI.EDU/2:ECB

This IK ID says that IA "ptf-kmc" issued an IK for use on messages sent from "linn@CCY.BBN.COM" to "privacy-tf@C.ISI.EDU", the IA gave that IK the number 2, and the IK is to be used in ECB mode 🎀.

IKs stay valid for longer than a single message, and each one comes with an expiration time distributed alongside it. The IK cryptoperiod is set partly by a tradeoff between key management overhead and revocation responsiveness ⚖️. It would be a total disaster to delete an IK permanently before receiving a message encrypted with it, because that message would be permanently undecipherable 💀. Access to an expired IK is needed, for example, to process mail received by a user (or system) that's been inactive for a long stretch. So if you want to let very old IKs get deleted, a recipient who wants encrypted local long-term storage should re-encrypt the DEK used for message text under a locally maintained IK, rather than relying on IA maintenance of old IKs for indefinite periods 🌸.

6 User Naming 👑

Unique naming of electronic mail users is needed to select corresponding keys correctly. It's an important topic that needs a lot of study 🤓. There's a logical association between key distribution and name/directory server functions, and their relationship deserves more consideration. These issues weren't fully resolved at the time of writing. The interim architecture relies on associating IKs with user names represented in a universal form, which has these properties:

  1. The universal form must be specifiable by an IA as it distributes IKs and known to a UA as it processes received IKs and IK IDs. If a UA or IA uses addresses in a local form that differs 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).

Making sure these properties hold across the whole Internet is tough 😭. For example, an MTS that transforms address representations between the local form used inside an organization and the global form used for Internet mail transmission may cause property 2 to be violated.

Flat (non-hierarchic) electronic mail user identifiers, which aren't tied to the hosts users live on, seem useful 🧩. Personal characteristics, like social security numbers, might be considered too. Individually-selected identifiers could be registered with a central authority, but there would need to be a way to resolve name conflicts.

A big point to note is that people want multiple names for one individual, so the various roles they play can be represented and delegated. A naming mechanism that binds user roles to keys is needed. The bindings can't be immutable, since roles sometimes change (e.g., the comptroller of a corporation gets fired) 🙃.

It may be worth looking into extending the Domain Name System and its associated name servers to resolve user names to unique user IDs 🌐. There's an extra wrinkle for mailing list support: name servers don't currently perform (potentially recursive) expansion of lists into users. ISO and CSNet are working on user-level directory service mechanisms, which may also be worth considering 🦋.

7 Example User Interface and Implementation ✨

To put the mechanisms and approaches in this RFC into context, this section gives an overview of a prototype implementation 🧁. It's a standalone program [10] that a user invokes, and it sits above the existing UA sublayer. This form of integration is great because the program can be used with a range of UA programs, rather than being compatible with only one particular UA 💜. When a user wants to apply privacy enhancements to an outgoing message, they prepare the message's text and invoke the standalone program. They interact with it to provide address information and other data needed for privacy enhancement processing, and it generates output suitable for transmission via the UA. When a user receives a privacy-enhanced message, the UA delivers it in encrypted form, suitable for decryption and associated processing by the standalone program 🔓.

In this prototype, a cache of IKs is kept in a local file, with entries managed manually based on pairwise agreements between originators and recipients. This cache is basically a simple database 🗂️. IKs are selected for transmitted messages based on recipient names, and the corresponding IK IDs go into the message's encapsulated header. When a message is received, the IK ID is used as the basis for a lookup in the database, which yields the appropriate IK entry. DEKs and IVs are generated dynamically within the program 🎲.

Options (e.g., authentication only vs. authentication with confidentiality service) are selected with command line arguments to the standalone program. Destination addresses are specified the same way. Specifying destination addresses to the privacy enhancement program is logically distinct from specifying the corresponding addresses to the UA for use by the MTS 🛣️. That separation exists because, in many cases, the local form of an address as specified to a UA differs from the Internet global form used in IK ID fields 🌈.

8. Areas For Further Study ✨

Okay so the procedures in this RFC are enough to support a pilot implementation of privacy-enhanced electronic mail transmission between cooperating parties on the Internet 💌 But bestie, we are NOT done yet! More work is needed to boost robustness, generality, and interoperability 🔥 Specifically, these areas still need love:

  1. User naming techniques, and their relationship to the domain system, name servers, directory services, and key management functions 🏷️
  2. Standardization of Issuing Authority functions, including protocols for communications among IAs and between User Agents and IAs 🏛️
  3. Use of public key encryption algorithms to encrypt data encrypting keys 🔐
  4. Interoperability with X.400 mail 📬

We anticipate generation of subsequent RFCs which will address these topics. Stay tuned, they're coming 🦋

9. References 📚

This section identifies background references that may be useful to anyone contemplating use of the mechanisms defined in this RFC. Bookmark these, they're giving research energy 🧚

  • 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 MAC computation.
  • FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines specific modes in which the Data Encryption Standard algorithm is to be used to perform encryption and MAC computation.

NOTES 🗒️

  • [1] Information Processing Systems: Data Encipherment: Block Cipher Algorithm DEA 1.
  • [2] Federal Information Processing Standards Publication 46, Data Encryption Standard, 15 January 1977.
  • [3] Information Processing Systems: Data Encipherment: Modes of Operation of a 64-bit Block Cipher
  • [4] Federal Information Processing Standards Publication 81, DES Modes of Operation, 2 December 1980.
  • [5] Addendum to the Transport Layer Protocol Definition for Providing Connection Oriented End to End Cryptographic Data Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft of 19 December 1985, Gaithersburg, MD, p. 15.
  • [6] 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.
  • [7] Crocker, D. Standard for the Format of ARPA Internet Text Messages (RFC822), August 1982.
  • [8] Rose, M. T., and Stefferud, E. A., Proposed Standard for Message Encapsulation, January 1985.
  • [9] Key generation for authentication 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.1 identifies possible advantages of a centralized server approach.
  • [10] Note that in the UNIX(tm) system, and possibly in other environments as well, such a program can be invoked as a "filter" within an electronic mail UA or a text editor, simplifying the sequence of operations which must be performed by the user.
📦 where this page comes from