RFC 1040

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

📅 published January 1988, from ietf

RFC 1040 🎀

Okay bestie, RFC 1040 is all about privacy for email 💌 It's from the Network Working Group, written by J. Linn (BBNCC) and the IAB Privacy Task Force, and dated January 1988. Its status is a proposed protocol for the Internet community, and it obsoletes RFC 989 💅 The full title is "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures" ✨

Status of This Memo 💖

This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Acknowledgment 🫶

This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. Thank you SO much to the Privacy Task Force members and meeting guests whose comments and contributions at the meetings led to the preparation of this RFC: David Balenson, Curt Barker, Matt Bishop, Danny Cohen, Tom Daniel, Charles Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker, and Steve Wilbur. Iconic cast, honestly 👑

1. Executive Summary ✨

So this RFC defines message encipherment and authentication procedures 🔐 It's the first phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. The detailed key management mechanisms that support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, the procedures defined here are intended to be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.

Privacy enhancement services (confidentiality, authentication, and message integrity assurance) are offered through end-to-end cryptography between originator and recipient User Agent processes 🫧 There are no special processing requirements imposed on the Message Transfer System at endpoints or at intermediate relay sites, which is lowkey the best part. This approach lets privacy enhancement facilities be incorporated on a site-by-site or user-by-user basis without impact on other Internet entities. Interoperability among heterogeneous components and mail transport facilities is supported 🌈

2. Terminology 📚

For descriptive purposes, this RFC uses some terms defined in the OSI X.400 Message Handling System Model per the 1984 CCITT Recommendations. This section repeats a portion of X.400's Section 2.2.1, "Description of the MHS Model: Overview," so that the terminology is clear to readers who may not know the OSI MHS Model yet 🍓

In the [MHS] model, a user is a person or a computer application. A user is referred to as either an originator (when sending a message) or a recipient (when receiving one). MH Service elements define the set of message types and the capabilities that enable an originator to transfer messages of those types to one or more recipients 💜

An originator prepares messages with the assistance of his User Agent. A User Agent (UA) is an application process that interacts with the Message Transfer System (MTS) to submit messages. The MTS delivers 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 composed of a number of Message Transfer Agents (MTAs). Operating together, the MTAs relay messages and deliver them to the intended recipient UAs, which then make the messages available to the intended recipients 📬

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

3. Services, Constraints, and Implications 🦋

This RFC defines mechanisms to enhance privacy for electronic mail transferred in the Internet. The facilities discussed here provide privacy enhancement services on an end-to-end basis between sender and recipient UAs. No privacy enhancements are offered for message fields that are added or transformed by intermediate relay points 🙈

Authentication and integrity facilities are always applied to the entirety of a message's text. No facility for confidentiality service without authentication is provided. Encryption facilities may be applied selectively to portions of a message's contents. This allows less sensitive portions of messages (e.g., descriptive fields) to be processed by a recipient's delegate without the recipient's personal cryptographic keys. In the limiting case, where the entirety of message text is excluded from encryption, this feature can be used to yield the effective combination of authentication and integrity services without confidentiality 🔥

In keeping with the Internet's heterogeneous constituencies and usage modes, the measures defined here are applicable to a broad range of Internet hosts and usage paradigms. In particular, these attributes are 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 do not 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, which does not impact mail processing by intermediate relay hosts that do not incorporate privacy enhancement facilities. It is necessary, however, for a message's sender to be cognizant of whether a message's intended recipient implements privacy enhancements. This way, encoding and possible encipherment will not be performed on a message whose destination is not equipped to perform the corresponding inverse transformations 🫶
  3. The defined mechanisms are compatible with a range of mail transport facilities (MTAs). Within the Internet, electronic mail transport is handled by a variety of SMTP implementations. Certain sites, accessible via SMTP, forward mail into other mail processing environments (e.g., USENET, CSNET, BITNET). The privacy enhancements must be able to operate across the SMTP realm. It is desirable that they also be compatible with protection of electronic mail sent between the SMTP environment and other connected environments 🌸
  4. The defined mechanisms offer compatibility with a broad range of electronic mail user agents (UAs). A large variety of electronic mail user agent programs, with a corresponding broad range of user interface paradigms, is used in the Internet. So that an electronic mail privacy enhancement is available to the broadest possible user community, the selected mechanism should be usable with the widest possible variety of existing UA programs. For pilot implementation purposes, it is desirable that privacy enhancement processing be incorporable into a separate program that applies to a range of UAs, rather than requiring internal modifications to each UA that is to be provided with enhanced privacy services ⭐
  5. The defined mechanisms allow electronic mail privacy enhancement processing to be performed on personal computers (PCs) separate from the systems on which UA functions are implemented. Given the expanding use of PCs and the limited degree of trust that can be placed in UA implementations on many multi-user systems, this attribute can allow many users to process privacy-enhanced mail with a higher assurance level than a strictly UA-based approach would allow 💜
  6. The defined mechanisms support privacy protection of electronic mail addressed to mailing lists 🌈

In order to achieve applicability to the broadest possible range of Internet hosts and mail systems, and to facilitate pilot implementation and testing without the need for prior modifications throughout the Internet, three basic restrictions are imposed on the set of measures to be considered in this RFC:

  1. Measures will be restricted to implementation at endpoints, and they will be amenable to integration at the user agent (UA) level or above. They will not necessitate integration into the message transport system (e.g., SMTP servers) 🔐
  2. The set of supported measures enhances rather than restricts user capabilities. Trusted implementations, incorporating integrity features that protect software from subversion by local users, cannot be assumed in general. In the absence of such features, it appears more feasible to provide facilities that enhance user services (e.g., by protecting and authenticating inter-user traffic) than to enforce restrictions (e.g., inter-user access control) on user actions 🧚
  3. The set of supported measures focuses on a set of functional capabilities selected to provide significant and tangible benefits to a broad user community. By concentrating on the most critical set of services, the aim is to maximize the added privacy value that can be provided with a modest level of implementation effort 🍓

As a result of these restrictions, the following facilities can be provided:

  1. disclosure protection,
  2. sender authenticity, and
  3. message integrity measures,

but the following privacy-relevant concerns are not addressed:

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

An important goal is that privacy enhancement mechanisms impose a minimum of burden on the users they serve. In particular, this goal suggests eventual automation of the key management mechanisms supporting message encryption and authentication. In order to facilitate deployment and testing of pilot privacy enhancement implementations in the near term, however, compatibility with out-of-band (e.g., manual) key distribution must also be supported 🎀

A message's sender will determine whether privacy enhancements are to be performed on a particular message. Therefore, a sender must be able to determine whether particular recipients are equipped to process privacy-enhanced mail. In a general architecture, these mechanisms will be based on server queries. Thus, the query function could be integrated into a UA to avoid imposing burdens or inconvenience on electronic mail users 💖

4. Processing of Messages 🌸

4.1 Message Processing Overview ✨

okay bestie, this is the big-picture tour 🗺️ of how privacy enhancement processing works. the later subsections go deep, so think of this as the trailer before the movie 🎬

the whole thing runs on a two-level keying hierarchy 🔐, which is basically two layers of keys doing different jobs:

  1. Data Encrypting Keys (DEKs) are used for encryption of message text and (with certain choices among a set of alternative algorithms) for computation of message integrity check quantities (MICs). DEKs are generated individually for each transmitted message, so no predistribution of DEKs is needed to support privacy-enhanced message transmission 🙌
  2. Interchange Keys (IKs) are used to encrypt DEKs for transmission within messages. An IK MAY be a single symmetric cryptographic key or, where asymmetric (public-key) cryptography is used to encrypt DEKs, the composition of a public component used by an originator and a secret component used by a recipient. Ordinarily, the same IK will be used for all messages sent between a given originator-recipient pair over a period of time 💌 Each transmitted message includes a representation of the DEK(s) used for message encryption and/or authentication, encrypted under an individual IK per named recipient. This representation is associated with sender and recipient identification header fields, which enable recipients to identify the IKs used. With this information, the recipient can decrypt the transmitted DEK representation, yielding the DEK required for message text decryption and/or MIC verification 🔓

when privacy enhancement processing is going to happen on an outgoing message, a DEK is generated [1] for use in message encryption, and a variant of the DEK is formed (if the chosen MIC algorithm requires a key) for use in MIC computation 🧁 an X-Sender-ID: field is included in the header to give one identification component for the IK(s) used for message processing. an IK is selected for each individually identified recipient, and a matching X-Recipient-ID: field, interpreted in the context of a prior X-Sender-ID: field, serves to identify each IK. each X-Recipient-ID: field is followed by an X-Key-Info: field, which transfers the DEK and computed MIC. the DEK and MIC are encrypted for transmission under the appropriate IK 🎀

next up is a four-phase transformation procedure 💅 which exists so that encrypted message text can be represented in a universally transmissible form, and so messages encrypted on one type of system can be decrypted on a totally different type. a plaintext message is accepted in local form, using 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 what feeds into the encryption and MIC computation processes 🌸

for encryption, the canonical representation is padded as required by the encryption algorithm. the padded canonical representation is then encrypted (except for any regions explicitly excluded from encryption). after encryption, the canonically encoded representation is encoded into a printable form. that printable form uses a restricted character set chosen to be universally representable across sites, and it won't get messed up 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 is passed to the electronic mail system to be encapsulated as the text portion of a transmitted message 📨

when a privacy-enhanced message is received, the cryptographic control fields within its text portion give the authorized recipient what they need to do MIC verification and decryption 🕵️‍♀️ first, the printable encoding is converted to a bitstring. the MIC is verified. encrypted portions of the transmitted message are decrypted, and the canonical representation is converted to the recipient's local form, which doesn't have to match the sender's local form 💖

4.2 Encryption Algorithms and Modes 🔐

for this RFC, the Block Cipher Algorithm DEA-1, defined in ISO draft international standard DIS 8227 [2], SHALL be used for encryption of message text. 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 DIS 8372 [4]. the CBC mode definition in DIS 8372 is equivalent to the one in FIPS PUB 81 [5]. a unique initializing vector (IV) will be generated for, and transmitted with, each privacy-enhanced electronic mail message 🦋

an algorithm other than DEA-1 MAY be employed, as long as it satisfies the following requirements 👑

  1. It MUST be a 64-bit block cipher, enciphering and deciphering in 8-octet blocks.
  2. It is usable in the ECB and CBC modes defined in DIS 8372.
  3. It is able to be keyed using the procedures and parameters defined in this RFC.
  4. It is appropriate for MIC computation, if the selected MIC computation algorithm is eCcryption-based.
  5. Cryptographic key field lengths are limited to 16 octets in length.

certain operations require that one key be encrypted under another key (an interchange key) for purposes of transmission 🍓 this encryption MAY be performed using symmetric cryptography by using DEA-1 in Electronic Codebook (ECB) mode. a header facility is available to indicate that an associated key is to be used for encryption in another mode, like the Encrypt-Decrypt-Encrypt (EDE) mode used for key encryption and decryption with pairs of 64-bit keys (as described by ASC X3T1 [6]), or public-key algorithms 🧚

support of public key algorithms for key encryption is under active consideration, and it's intended that the procedures defined in this RFC stay appropriate to allow that kind of 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 showing that recipients are equipped to perform key encryption in those other modes 🫶

4.3 Privacy Enhancement Message Transformations 🦄

4.3.1 Constraints ⚠️

an electronic mail encryption mechanism MUST be compatible with the transparency constraints of its underlying electronic mail facilities. those constraints are generally set based on expected user requirements and the characteristics of anticipated endpoint transport facilities. an encryption mechanism MUST also be compatible with the local conventions of the computer systems it interconnects. in our 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 encode a message for SMTP transmission, the following requirements MUST be met 🎯

  1. All characters MUST be members of the 7-bit ASCII character set.
  2. Text lines, delimited by the character pair <CR><LF>, MUST be no more than 1000 characters long.
  3. Since the string <CR><LF>.<CR><LF> indicates the end of a message, it MUST NOT occur in text prior to the end of a message.

okay so, SMTP specifies a standard representation for line delimiters (ASCII <CR><LF>), but tons of systems use a different native representation to delimit lines 🙃 for example, the <CR><LF> sequences delimiting lines in mail inbound to UNIX(tm) systems get turned into 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, which is a matter of local option. if transformations like that 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 performed by an SMTP server at a system with EBCDIC as a native character set has even more severe impact, since going from EBCDIC to ASCII is an information-losing transformation 🥀 in principle, the transformation function mapping between inter-SMTP canonical ASCII message representation and local format could be moved from the SMTP server up to the UA, given a means to direct the SMTP server to stop doing that transformation. this approach has a major disadvantage, though: internal file (e.g., mailbox) formats would be incompatible with the native forms used on the systems where they live. it would also require modifying SMTP servers, since mail would be passed to SMTP in a different representation than it is passed today 🙅‍♀️

4.3.2 Approach 🧠

our approach to supporting privacy-enhanced mail across an environment where intermediate conversions may happen encodes mail in a way that's uniformly representable across the set of privacy-enhanced UAs, no matter what their systems' native character sets are 🌍 this encoded form is used to represent mail text from sender to recipient, but the encoding is not applied to enclosing mail transport headers or to encapsulated headers inserted to carry control information between privacy-enhanced UAs. the encoding's characteristics are set up so the transformations expected between sender and recipient UAs won't stop an encoded message from being decoded properly at its destination ✨

a sender MAY exclude one or more portions of a message from encryption processing. authentication processing is always applied to the entirety of message text. explicit action is REQUIRED to exclude a portion of a message from encryption processing, and by default, encryption is applied to the entirety of message text 🔒 the user-level delimiter that specifies such exclusion is a local matter, so it 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 according to local convention 💕

4.3.2.2. Step 2: Canonical Form 🎀

okay bestie, step 2 is all about getting the WHOLE message into one universal shape ✨. The entire message text gets converted to the universal canonical form, no matter whether a part is about to be scrambled or left alone 👀. That shape is the inter-SMTP representation [9] from RFC-821 and RFC-822 [10]: ASCII characters with <CR><LF> line delimiters 💖

ngl this is so smart. If your computer already speaks ASCII, this conversion is basically nothing, like a 2-second glow-up 💅 And since everyone agrees on one standard character set before encryption, any destination can decrypt the message and verify its MIC before it does the local conversion to its own format. The receiver just does the check first, then makes it fit their own vibe 🦋

4.3.2.3. Step 3: Authentication and Encipherment 🔐

Now the canonical form gets fed into the selected MIC computation algorithm, which spits out an integrity check quantity for the message 🧚 No padding gets added before that step, although some MIC algorithms will add their own padding while they're computing the MIC. Each to their own!

Next up is padding for encryption in the DEA-1 CBC mode. Here's the tea ☕ First you work out how many octets are going to be encrypted. You take the total length of the encapsulated text and subtract the octets that are excluded from encryption. Then you append octets with the hexadecimal value FF (all ones) as needed, so that the text octets being encrypted plus the padding octets fill an integral number of 8-octet encryption quanta. If the number of octets to be encrypted is already a multiple of 8, you skip padding entirely 🙌

Why FF? Because it's outside the 7-bit ASCII set, so the padding can be told apart from real data without needing an explicit padding count indicator. Iconic, honestly 👑

Then the regions that weren't excluded get encrypted 🔒 For selective encipherment to work, an implementation must keep internal notes on where the excluded areas sit relative to the non-excluded areas, so those areas can be properly marked off during the encoding in step 4 📍 And if an excluded region sits between two encrypted regions, the cryptographic state (like the IVs and the way octets pile up into encryption quanta) gets saved and picked back up right after the excluded region. No state gets dropped, babe 💜

4.3.2.4. Step 4: Printable Encoding 🍓

Step 4 takes the bit string from step 3 and turns it into characters that every site can represent, even though the actual bit patterns might differ 🌈 For example, the character "E" is hexadecimal 45 in an ASCII-based system but hexadecimal C5 in an EBCDIC-based system. Different bytes, same meaning, equally valid ✨ This encoding happens for all privacy-enhanced messages 💅

The alphabet is a 64-character subset of International Alphabet IA5, which means each printable character carries 6-bits 🦋 (Fun fact: the proposed subset is written the same way in IA5 and ASCII.) On top of those 64 characters, there are two extra ones: "=" and "". The "=" is used for padding inside the printable encoding, and "" marks the beginning and end of a region that was excluded from encipherment 🙈 The output then gets split into text lines using local conventions, and every line holds 64 printable characters 📝

Here's how the actual encoding goes. It works on 24-bit groups, and it grabs 24 bits from the output of step 3, reading left to right. Each 6-bit chunk becomes an index into the array of 64 printable characters, and whichever character that index points to goes into the output string 🎯 The characters are listed in Table 1. They were picked so every site can represent them, and they skip the characters that mean something special to SMTP (like ".", <CR>, and <LF>). Strict, but it keeps things safe 🫶

Sometimes a group has fewer than 24 bits. That happens at the end of a message, and also (when selective encryption is turned on) at the end of an encrypted region or an excluded region. In those cases the group gets zero bits added on the right until it's an integral number of 6-bit groups, and any output positions that don't carry real input data get set to "=". Basically, a full encoding quantum is always finished at the end of a message, and before the "*" delimiter goes out to start or end an excluded block 💀

Because all canonically encoded output comes in whole octets, there are only three cases that can show up:

  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 is two characters followed by two "=" padding characters 🌸
  3. The final quantum of encoding input is exactly 16-bits. Then the final unit is three characters followed by one "=" padding character 🧚

Okay, the big picture 🌈 For an outbound message, the transformations get composed like this:

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

Inbound privacy-enhanced mail goes through the inverse transformations, in reverse order:

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

Here's the best part 👑 The local form, and the functions that move messages to and from canonical form, can be different between sender and recipient systems without losing any information. Everyone keeps their own style and the message still arrives intact 💖

Here's Table 1, the printable encoding characters (copied exactly, no edits 🫶):

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

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

                    Printable Encoding Characters
                               Table 1

4.4. Encapsulation Mechanism 🎀

okay bestie, so wrapping privacy-enhanced messages in an enclosing layer of headers that the electronic mail transport system can read is way more iconic than the flat approach 💅 In the flat approach, certain fields in one single header get encrypted and/or carry crypto control info. Encapsulation is giving generality ✨ and it separates the fields that matter user-to-user from the ones that get transformed in transit 🦋 Every field added during encryption/authentication processing goes in the encapsulated header. This keeps things compatible 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 🌀 And from the MTS's point of view, anything folded into the cryptographic authentication or encryption lives in the message's text portion, not its header portion 💜

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

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

   Blank Line
            (Separates Enclosing Header from Encapsulated Message)

   Encapsulated Message

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

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

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

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

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

                              Message Encapsulation
                                     Figure 1

As a general design principle, sensitive data gets protected by putting it inside the encapsulated text, rather than by applying measures selectively to fields in the enclosing header 🔐 Think of stuff like Subject:, whose contents matter end-to-end between users. The set of headers that get protection (it can even 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 inside the encapsulated text, and include those replicated fields in the encryption and MIC computations. Non-negotiable energy 💅

If a user wants disclosure protection for header fields, they must occur only in the encapsulated text, and not in the enclosing or encapsulated header. 🙈

If disclosure protection is wanted for a message's subject indication, it's recommended that the enclosing header contain a Subject: field saying "Encrypted Mail Follows" 🫶 And if you want an authenticated version of header info, you can replicate that data inside the encapsulated text in addition to including it in the enclosing header ✨ For example, a sender who wants recipients to get a protected indication of where a message sits in a series could include a copy of a timestamp or message counter field in the encapsulated text ⭐

Also, the subset of IA5 picked for transmission encoding intentionally leaves out the character - 🧠 That's the trick: it means the encapsulated text can be told apart from the closing boundary (Post-EB) without needing character stuffing. Genius, honestly 👑

4.5. Mail for Mailing Lists 📬

When mail is addressed to mailing lists, two different processing methods can apply: the IK-per-list method and the IK-per-recipient method 🦋 Which one you use depends on what info the sender has and on the sender's preference.

If a message's sender addresses it to a list name or alias, using an IK tied to that name or alias as an entity (IK-per-list) is implied, rather than resolving the name or alias into its constituent destinations 📮 That IK must, therefore, be available to all list members. For public-key cryptography, the secret component of the composite IK must also be available to all list members. This is the normal case for messages sent through remote exploder sites, since a sender to those lists may not know the individual recipients 🌐 Unfortunately, it means an undesirable level of exposure for the shared IK or component, and it makes revocation difficult 😬 And the IK-per-list method lets any holder of the list's IK masquerade as another sender to the list for authentication purposes 👀

That masquerade thing is a big deal, bestie. Any holder of the list's IK can pretend to be someone else on the list. 💀

If, on the other hand, the sender is equipped to expand the destination mailing list into its individual constituents and chooses to (IK-per-recipient), the message's DEK and MIC get encrypted under each per-recipient IK, and all those encrypted representations are put into the transmitted message 💖 Per-recipient encryption is only required for the relatively small DEK and MIC quantities carried in the X-Key-Info field, not for the message text, which is generally much larger 🍓 Yes, more IKs are involved in this method, 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.6. Summary of Added Header and Control Fields 💅

This section sums up the syntax and semantics of the new encapsulated header fields that get added during privacy enhancement processing 🧁 In certain indicated cases, it's recommended that the fields also be replicated inside the encapsulated text portion. Figure 2 shows what a small example encapsulated message looks like with these fields. The example assumes symmetric cryptography, so there's no X-Certificate: field 🔑 Across the board, hexadecimal quantities are written as contiguous strings of digits, where each digit is a character from "0"-"9" or uppercase "A"-"F". Unless otherwise specified, all arguments are processed case-sensitively 🎀

The encapsulated header fields look like RFC-822 header fields, but they're a disjoint set, and they generally won't be processed by the same parser that handles the enclosing header fields 🧩 The lexical analysis needed (and appropriate) for encapsulated header field processing is significantly simpler than what RFC-822 header processing needs. For example, lots of characters that carry special meaning to RFC-822 at the syntactic level have no such meaning inside encapsulated header fields 🦋

When an encapsulated header field is longer than fits neatly on a printed line, whitespace may be used between its subfields to fold it, the way RFC-822 does in section 3.1.1 📏 Any whitespace inserted like that must not be interpreted as part of a subfield 🙅‍♀️

   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 2
   X-IV: F8143EDE5960C597
   X-Sender-ID: linn@ccy.bbn.com:::
   X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3:BMAC:ECB
   X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
   X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4:BMAC:ECB
   X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7

   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
   dXd/H5LMDWnonNvPCwQUHt==
    -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----

                       Example Encapsulated Message
                                 Figure 2

4.6.1. X-Certificate Field 🪪

The X-Certificate encapsulated header field is only used when public-key certificate key management is in play 🔐 It carries a sender's certificate as a string of hexadecimal digits. The semantics of a certificate are covered in Section 5.3, Certificates. A certificate carried in an X-Certificate field is used together with all the subsequent X-Sender-ID and X-Recipient-ID fields until another X-Certificate field shows up. The usual case is that just one X-Certificate field appears, before any X-Sender-ID and X-Recipient-ID fields ✨

Because certificates are long, they may need to be folded across multiple printed lines 📜 To make that folding possible, the hexadecimal digits for a certificate are split into an ordered set (more significant digits first) of zero or more 64-digit groups, followed by a final digit group that can be any length up to 64 digits. A single whitespace character goes between each pair of groups so folding (per RFC-822, section 3.1.1) can happen, and that whitespace is ignored when the digit string is parsed 🧚

4.6.2. X-IV Field 🌸

The X-IV encapsulated header field carries the Initializing Vector used for message encryption 💜 Only one X-IV field appears in a message. It shows up in all messages, even if the entire message text is excluded from encryption. After the field name and one or more delimiting whitespace characters, a 64-bit Initializing Vector is written as a contiguous string of 16 hexadecimal digits 🔢

4.6.3. X-Key-Info Field 🗝️

The X-Key-Info encapsulated header field transfers two items: a DEK and a MIC 💖 There's one X-Key-Info field for each of a message's named recipients. The DEK and MIC are encrypted under the IK identified by the preceding X-Recipient-ID field and the prior X-Sender-ID field. They're represented as two strings of contiguous hexadecimal digits, separated by a comma 🦋 For DEA-1, the DEK representation is 16 hexadecimal digits (corresponding to a 64-bit key). This subfield can be extended to 32 hexadecimal digits (corresponding to a 128-bit key) if it's needed to support other algorithms 🌈 MICs are also represented as contiguous strings of hexadecimal digits. The size of a MIC depends on the MIC algorithm specified in the X-Recipient-ID field for the corresponding recipient 🍓

4.6.4. X-Proc-Type Field 🎀

The X-Proc-Type encapsulated header field identifies the type of processing performed on the transmitted message 🧁 Only one X-Proc-Type field appears in a message. It has one subfield, a decimal number used to tell apart incompatible encapsulated header field interpretations that might come up as changes are made to this standard. Messages processed according to this RFC carry the subfield value "2" 👑

4.6.5. X-Sender-ID Field ✨

okay bestie, the X-Sender-ID encapsulated header field is where the sender's interchange key identification component lives 🔑💖 It should be replicated within the encapsulated text too 🫶 The interchange key identification component in an X-Sender-ID field gets used together with all the X-Recipient-ID fields after it, until another X-Sender-ID field shows up. ngl the normal situation is one X-Sender-ID field, sitting before any X-Recipient-ID fields 💅

The X-Sender-ID field has (in order) an Entity Identifier subfield, an (optional) Issuing Authority subfield, an (optional) Version/Expiration subfield, and an (optional) IK Use Indicator subfield. The optional ones get left out if later X-Recipient-ID fields already make them redundant, which is usually the case when symmetric cryptography is used for key management 🧚 The subfields are separated by a colon (:), optionally followed by whitespace 🎀

Check out Section 5.2, Interchange Keys, for what these subfields actually mean and the alphabet they're picked from 📚

Note that multiple X-Sender-ID fields may occur within a single encapsulated header 🦋 All X-Recipient-ID fields get interpreted in the context of the most recent X-Sender-ID field before them.

It is illegal for an X-Recipient-ID field to occur in a header before an X-Sender-ID has been provided. No exceptions, bestie 🚫

4.6.6. X-Recipient-ID Field 🌸

The X-Recipient-ID encapsulated header field is the recipient's interchange key 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 contains (in order) an Entity Identifier subfield, an Issuing Authority subfield, a Version/Expiration subfield, a MIC algorithm indicator subfield, and an IK Use Indicator subfield. The subfields are delimited by the colon character (:), optionally followed by whitespace.

The MIC algorithm indicator is an ASCII string, picked from the values defined in Appendix A of this RFC 🍓 Section 5.2, Interchange Keys, covers the semantics of the other subfields and the alphabet they come from. All X-Recipient-ID fields are interpreted in the context of the most recent preceding X-Sender-ID field.

It is illegal for an X-Recipient-ID field to occur in a header before an X-Sender-ID has been provided. Same rule, same energy 😤

5. Key Management 🔐

Several cryptographic constructs are involved in supporting the privacy-enhanced message processing procedure. As noted in the Executive Summary section of this RFC, key management mechanisms have not been fully defined yet, but a set of fundamental elements is assumed 🌈 Data Encrypting Keys (DEKs) are used to encrypt message text and in the message integrity check (MIC) computation process. Interchange Keys (IKs) are used to encrypt DEKs for transmission with messages. In an asymmetric key management architecture, certificates provide entities' public key components and other information, in a fashion that's securely bound by a central authority 👑 The rest of this section gives more detail on these constructs.

5.1. Data Encrypting Keys (DEKs) 🗝️

DEKs are used for encrypting message text and for computing message integrity check quantities (MICs). It is strongly recommended that DEKs be generated and used on a one-time basis. A transmitted message will incorporate a representation of the DEK encrypted under an appropriate interchange key (IK) for each the authorized recipient 💌

DEK generation can happen centrally, by key distribution centers (KDCs), or at endpoint systems. Dedicated KDC systems may be able to implement better algorithms for random DEK generation than endpoint systems can support 🤓 On the flip side, decentralization lets endpoints be relatively self-sufficient, which reduces the level of trust placed in components other than a message's originator and recipient. Decentralized DEK generation at endpoints also cuts down how often senders have to make real-time queries of (potentially unique) servers in order to send mail, which helps 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, instead of giving the IKs to the senders. That reduces IK exposure and simplifies endpoint key management requirements ✨ This approach is less valuable if asymmetric cryptography is used for key management, since per-recipient public IK components are assumed to be generally available, and per-sender secret IK components don't necessarily need to be shared with a KDC 🙈

5.2. Interchange Keys (IKs) 🔑

IKs are used to encrypt Data Encrypting Keys. In general, IK granularity is at the pairwise per-user level, except for mail sent to address lists made up of multiple users 💖 Before two principals can have a useful exchange of privacy-enhanced electronic mail using conventional cryptography, they must first share a common interchange key. When symmetric cryptography is used, the interchange key consists of a single component. When asymmetric cryptography is used, an originator and recipient must possess an asymmetric key's public and secret components, as appropriate. Put that pair together and you've got an interchange key 🧩

This RFC doesn't prescribe how interchange keys get to the right parties 🤷‍♀️ It's useful to know that this can be centralized (for example, via key management servers) or decentralized (for example, via pairwise agreement and direct distribution among users). Either way, any given IK component is tied to a responsible Issuing Authority (IA). When an IA generates and distributes an IK, associated control information comes along to direct how that IK is to be used 📜 To pick the right IK for message encryption, a sender must keep a correspondence between IK components and the recipients they're associated with. Expiration date information must also be kept, so cached entries can be invalidated and replaced as appropriate ⏳

Since a message may be sent with multiple IK component representations, one for each intended recipient, each recipient must be able to figure out which IK component is meant for it 💜 And if there's no matching IK component in the recipient's database when a message arrives, the recipient must be able to work out which IK component to request and identify that IK component's associated IA. Different IKs may be used for different messages between the same pair of communicants 🦋 For example, 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 IK components associated individually with A and B, but the second would use an IK component shared among the list members 📬

When a privacy-enhanced message is transmitted, an indication of the IK components used for DEK encryption must be included. To do this, 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 that a particular IK component is associated with (Entity Identifier or EI subfield).
  3. Indicator of IK usage mode (IK use indicator subfield).
  4. Version/Expiration subfield.

A colon character (:) delimits the subfields within an X-Sender-ID: or X-Recipient-ID: field. 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 / "'" / "+" / "(" / ")" /
                        "," / "." / "/" / "=" / "?" / "-" / "@" /
                        "%" / "!" / '"' / "_" / "<" / ">"

Here's an example X-Recipient-ID: field 🎀

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

This example field says that IA "ptf-kmc" has issued an IK component for use on messages sent to "linn@ccy.bbn.com". The IA has provided the number 2 as a version indicator for that IK component, the BMAC MIC computation algorithm is to be used for the recipient, and the IK component is to be used in ECB mode 🌷

5.2.1. Subfield Definitions 🧁

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

5.2.1.1. Entity Identifier Subfield 🪪

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

<user>@<domain-qualified-host>

To support universal interoperability, we have to assume a universal form for the naming information 🌍 For installations that transform local host names before sending them out into the broader Internet, it is strongly recommended that the host name as presented to the Internet be used 💅

5.2.1.2. Issuing Authority Subfield 🏛️

An IA identifier subfield is constructed as an IKsubfld. IA identifiers must be assigned in a way that 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 it must satisfy certain functional constraints. An IA's version/expiration subfields must be sufficient to distinguish among the set of IK components that IA issued for a given identified entity. Using a monotonically increasing number is enough to tell the IK components provided for an entity by an IA apart. Using a timestamp additionally lets an expiration time or date be prescribed for an IK component ⏰

5.2.1.4. MIC Algorithm Identifier Subfield 🔏

The MIC algorithm identifier only occurs within X-Recipient-ID fields, and it's used to identify the choice of message integrity check algorithm for a given recipient. Appendix A of this RFC specifies the defined values for this subfield 💜

5.2.1.5. IK Use Indicator Subfield 🧚

The IK use indicator subfield is an optional facility, provided to identify the encryption mode in which an IK component is to be used. Right now, this subfield may take the following reserved string values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024". The default value is "ECB" 🎀

5.2.2 IK Cryptoperiod Issues

okay so an IK component's cryptoperiod is a balancing act 💅 between key management overhead and how fast you can revoke things 🔥. Deleting an IK component for good before you've received a message encrypted with it would be a total disaster 💀, because that message would be permanently undecipherable forever. Picture a user (or system) who's been inactive for ages coming back to process their mail 😭. They'd need access to an expired IK component to read it. So if you want very old IK components to be deletable, the move 🎀 is this: a message's recipient who wants encrypted local long-term storage should re-encrypt the DEK used for message text encryption under a locally maintained IK. That way they aren't relying on the IA to keep old IK components around indefinitely 🦋.

5.3 Certificates

in an asymmetric key management setup, a certificate binds an entity's public key component to a representation of their identity and other attributes 🧚. The certificate's issuing authority signs it, basically vouching that the identity, the attributes, and the public key component all actually go together ✨. Once it's signed, copies can be posted on multiple servers so that recipients' certificates are directly accessible to originators at dispersed locations 🌸. This means privacy-enhanced mail can go from an originator to a recipient without a pairwise key being placed at both ends beforehand, which makes mail systems way more flexible 💖. And because of the authority's signature, you don't have to worry that servers or other entities could quietly tweak certificate contents to link a public key to an inappropriate entity 🔒.

Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a subject's certificate is defined to contain the following parameters 📜:

  1. A signature algorithm identifier, which names the algorithm the certificate's issuer used to compute the signature applied to the certificate.
  2. Issuer identification, which identifies the certificate's issuer with an O/R name.
  3. Validity information, which gives the date and time limits before and after which the certificate should not be used.
  4. Subject identification, which identifies the certificate's subject with an O/R name.
  5. Subject's public key.
  6. Algorithm identifier, which names the algorithm the subject's public key is to be used with.
  7. Signature, an asymmetrically encrypted, hashed version of the above parameters, computed by the certificate's issuer.

The Recommendations specify an ASN.1 encoding to define a certificate 🧾. Pending further study, it is recommended that electronic mail privacy enhancement implementations using asymmetric cryptography for key management employ this encoding for certificates 🎀. Section 4.2.3 of RFC-987 [14] specifies a procedure for mapping RFC-822 addresses into the O/R names used in X.411/X.509 certificates 🗺️.

6. User Naming

6.1 Current Approach

Unique naming of electronic mail users is needed so you can select the right keys, and honestly it's a big topic that needs serious study 🧐. There's a logical link between key distribution and name/directory server functions, and how those two relate deserves more thought 💭. These issues haven't been fully resolved at this writing 😬. For now, the architecture hangs IK components off user names written in a universal form ("user@host") 📮, and it relies on these 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 that's 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's hard to make these properties hold across the whole Internet 🌍. For example, an MTS that transforms address representations between the local form used inside an organization and the universal form used for Internet mail transmission may cause property 2 to be violated 🙈.

6.2 Issues for Consideration

Flat (non-hierarchic) electronic mail user identifiers, which are unrelated to the hosts the users live on, may offer real value 🌈. Personal characteristics, like social security numbers, might be considered too. Individually-selected identifiers could be registered with a central authority, but then you'd need a way to resolve name conflicts 🤔.

A point of particular note is the desire to accommodate multiple names for a single individual, so you can represent and delegate the various roles that person might play 👑. A naming mechanism that binds user roles to keys is needed. The bindings can't be immutable, because roles sometimes change (e.g., the comptroller of a corporation is fired) 💀.

It may be appropriate to look at extending the DARPA/DoD domain system and its associated name servers so they resolve user names to unique user IDs 🧚. There's an additional wrinkle with 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 a look 👀.

7. Example User Interface and Implementation

To put the mechanisms and approaches discussed in this RFC into context 🎀, this section gives an overview of a prototype implementation. This implementation is a standalone program that a user invokes, and it sits above the existing UA sublayer ✨. On UNIX(tm) systems, and possibly in other environments too, a program like this can be invoked as a "filter" inside an electronic mail UA or a text editor, which makes the sequence of steps way simpler for the user 💅. The big perk is that the program works with a range of UA programs, instead of being compatible with just one particular UA 🦋.

When a user wants to apply privacy enhancements to an outgoing message, they write 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 spits out output that's suitable for transmission via the UA 📨. When a user receives a privacy-enhanced message, the UA delivers it in encrypted form, ready for decryption and processing by the standalone program 🔐.

In this prototype, a cache of IK components lives in a local file, and entries are managed manually based on information from originators and recipients 🗂️. Honestly, the cache is basically a simple database 💖. IK components get selected for transmitted messages based on the sender's identity and recipient names, and the matching X-Sender-ID: and X-Recipient-ID: fields get placed into the message's encapsulated header 🎀. When a message arrives, those fields are used to look up the database and pull out the right IK component entries 🔍. DEKs and IVs are generated dynamically within 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 🧩. The reason is that, in lots of cases, the local form of an address given to a UA is different from the Internet global form used in X-Sender-ID: and X-Recipient-ID: fields 🌸.

8. Areas For Further Study

The procedures in this RFC are enough to support a pilot implementation of privacy-enhanced electronic mail transmission among cooperating parties on the Internet 🚀. Still, more effort is needed to boost robustness, generality, and interoperability 💪. In particular, more work is needed in these areas:

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

We anticipate generating subsequent RFCs to address these topics 🦋.

9. References

This section lists 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 ✅.

A. Message Integrity Check Algorithms

This appendix identifies the alternative algorithms that can be used to compute Message Integrity Check (MIC) values 🛡️. It also assigns them character string identifiers to be put in X-Recipient-ID: fields, so each recipient's field shows which algorithm was picked for them 🎀.

MIC algorithms that use DEA-1 cryptography are computed with a key that's a variant of the DEK used for message text encryption 🗝️. The variant is made by modulo-2 addition of the hexadecimal quantity F0F0F0F0F0F0F0F0 to the encryption DEK ✨.

A.1 Conventional MAC (MAC)

A conventional MAC, denoted by the string MAC, is computed using the DEA-1 algorithm the way FIPS PUB 113 [15] defines 🧮. Use of the conventional MAC is not recommended for multicast messages 🙅‍♀️. The message's encapsulated text is padded at the end, per FIPS PUB 113, with zero-valued octets as needed to form a whole number of 8-octet encryption quanta 🧩. These padding octets are inserted implicitly and aren't transmitted with the message 🫶. The result of a conventional MAC computation is a single 64-bit value 💜.

A.2. Bidirectional MAC (BMAC) 💖

Okay bestie, the bidirectional MAC (we call it BMAC 🦋) gives you one single 128-bit value as its result. Here's how it's cooked 👩‍🍳

Step one: take the encapsulated text and pad it at the end with zero-valued octets, only as many as you need to make a whole number of 8-octet encryption quanta. These padding octets get inserted implicitly, so they are never actually sent with the message 🫶. Then run a conventional MAC over that padded version, and the resulting 64 bits become the high-order 64 bits of the BMAC result 💅

Step two: the low-order 64 bits are also made with a conventional MAC, but this time the 8-octet quanta go in backwards 🙃 The first quantum fed into the computation is the last quantum in the encapsulated text (padding included!), and the first quantum in the text is the last one processed as input. Plot twist: the octets inside each quantum don't get reordered, only the order of the quanta flips 🌀

NOTES 🎀

[1] Key generation for MIC computation and message text encryption can be done either by the sending host or by a centralized server 🔑 This RFC doesn't put any limits on this design choice. Section 5.1 covers some possible perks of the centralized server approach.

[2] Information Processing Systems: Data Encipherment: Block Cipher Algorithm DEA 1.

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

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

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

[6] Addendum to the Transport Layer Protocol Definition for Providing Connection Oriented End to End Cryptographic Data Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft of 19 December 1985, Gaithersburg, MD, p. 15.

[7] Postel, J., Simple Mail Transfer Protocol (RFC-821), August 1982.

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

[9] The SMTP canonicalization procedure was used at this stage because it's widely used and implemented across the Internet community ✨ It was not because SMTP interoperability with this intermediate result is required. No privacy-enhanced message gets handed to SMTP for transmission directly from this step in the four-phase transformation procedure 🙅‍♀️

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

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

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

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

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

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

📦 where this page comes from