RFC 1421
Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures
RFC 1421: Privacy Enhancement for Internet Electronic Mail 🎀
Okay bestie, this is Part 1 of 11 of the RFC 1421 glow-up, so we're just getting started! 💖
- RFC number: 1421 🌸
- Title: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures ✨
- Series: Network Working Group 🧚
- Author: J. Linn 💅
- Affiliation: IAB IRTF PSRG, IETF PEM WG 👑
- Date: February 1993 📅
- Category: IAB standards track protocol 🦋
- Obsoletes: RFC 1113 💀
It doesn't list any RFCs it updates, but it does replace RFC 1113, so it's the newer version of the story. 🫶
Status of this Memo ✨
Okay so this RFC lays out an IAB standards track protocol for the whole Internet community, and it's basically asking everyone to chat about it and suggest improvements. 💬 If you want to know where this protocol stands right now, check the current edition of the "IAB Official Protocol Standards" 📚 (that's the source of truth, no cap). And the good news? Distribution of this memo is unlimited, so share the tea with anyone who wants it! 🌈
Acknowledgements 🫶
This document is the outgrowth of a series of meetings of the Privacy and Security Research Group (PSRG) of the IRTF and the PEM Working Group of the IETF. 🌸 The author would like to thank the members of the PSRG and the IETF PEM WG, plus everyone who joined the discussions on the pem-dev@tis.com mailing list, for helping shape this document. 💖 Literally a whole squad effort! 👯♀️
1. Executive Summary 🔥
Okay, big picture time! This document defines message encryption and authentication procedures so that privacy-enhanced mail (PEM) services can work for electronic mail transfer across the Internet. 💌 It's meant to be one member of a related set of four RFCs. 📦
The procedures in this document are designed to be compatible with a wide range of key management approaches, which is so iconic 👑. That includes both symmetric (secret-key) and asymmetric (public-key) approaches for encrypting data encrypting keys. 🔐 Using symmetric cryptography for message text encryption and/or integrity check computation is anticipated. ✨
Here's how the rest of the family fits together:
- RFC 1422 specifies supporting key management mechanisms based on the use of public-key certificates. 🎀
- RFC 1423 specifies algorithms, modes, and associated identifiers relevant to the current RFC and to RFC 1422. 🦋
- RFC 1424 provides details of paper and electronic formats and procedures for the key management infrastructure being established in support of these services. 🧚
Privacy enhancement services are offered through end-to-end cryptography between the originator and recipient processes at or above the User Agent level. 💅 These services are: confidentiality, authentication, message integrity assurance, and non-repudiation of origin. 🔥 No special processing requirements are imposed on the Message Transfer System at endpoints or at intermediate relay sites, so the mail infrastructure doesn't have to change a thing! 🙌 This approach lets privacy enhancement facilities be incorporated selectively on a site-by-site or user-by-user basis without impact on other Internet entities. 🌈 And interoperability among heterogeneous components and mail transport facilities is supported, which is giving compatibility queen energy 👑✨.
Scope check: the current specification is confined to PEM processing procedures for the RFC-822 textual mail environment, and it defines the Content-Domain indicator value "RFC822" to signify this usage. 💖 Follow-on work integrating PEM capabilities with other messaging environments (e.g., MIME) is anticipated. That work will be addressed in separate and/or successor documents, and additional Content-Domain indicator values will be defined at that point. 🔮
2. Terminology 📚
Terminology time, and I promise it's not as boring as it sounds! 🙈 For descriptive purposes, this RFC uses some terms defined in the OSI X.400 Message Handling System Model, per the CCITT Recommendations. 🧠
To make things clear for readers who might not know the OSI MHS Model, this section copies a portion of (1984) X.400's Section 2.2.1, "Description of the MHS Model: Overview." 💜
In the [MHS] model, a user is a person or a computer application. 🤖 A user is called either an originator (when sending a message) or a recipient (when receiving one). 📨 MH Service elements define the set of message types and the capabilities that let an originator transfer messages of those types to one or more recipients. 🎀
An originator prepares messages with the help of their User Agent (UA). 💅 A 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 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 are collectively referred to as the Message Handling Environment. 🌸
3. Services, Constraints, and Implications ✨
okay so this RFC is all about making email private 🔐💖. The privacy stuff happens end-to-end, meaning between the originator's process and the recipient's process, and both of those live at the UA level or above. 🫶 Nothing gets privacy treatment for message fields that intermediate relay points add or change between the PEM processing parts. 💅
If an originator decides to do PEM processing on an outbound message, all the PEM services get applied to the message body in its entirety. You can't pick and choose parts of a PEM message, because selective application isn't supported 🙅♀️. Authentication, integrity, and (when asymmetric key management is employed) non-repudiation of origin get applied to every PEM message, but confidentiality is optional 🎀.
The Internet is a total mix of different people, machines, and usage styles 🌈, so these measures are meant to work for a broad range of Internet hosts and usage paradigms. A few things to know:
- The mechanisms here aren't locked to one particular host or operating system. They allow interoperability across a broad range of systems 🧚. All the privacy enhancements happen at the application layer, and they don't depend on any privacy features at lower protocol layers.
- These mechanisms are compatible with non-enhanced Internet components. The privacy enhancements are end-to-end, so they don't mess with mail processing by intermediate relay hosts that don't have privacy facilities 🌸. It's still necessary for a message's originator to be cognizant of whether the intended recipient implements privacy enhancements, so that encoding and possible encryption don't happen to a message whose destination can't do the matching inverse transformations 👀. (Section 4.6.1.1.3 of this RFC describes a PEM message type ("
MIC-CLEAR") which represents a signed, unencrypted PEM message in a form readable without PEM processing capabilities yet validatable by PEM-equipped recipients.) - These mechanisms are compatible with a range of mail transport facilities (MTAs). Within the Internet, electronic mail transport is done by a variety of SMTP [2] implementations 🚚. Certain sites reachable 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.
- These mechanisms are compatible with a broad range of electronic mail user agents (UAs) 💌. There are tons of UA programs out there with all kinds of interface vibes, so to reach the broadest possible user community, selected mechanisms should be usable with the widest possible variety of existing UA programs. For pilot implementation, it's desirable that privacy enhancement processing can be incorporated into a separate program that works with a range of UAs, rather than needing internal modifications to each UA that gets PEM services 🛠️.
- These mechanisms allow PEM processing to run on personal computers (PCs) that are separate from the systems where UA functions are implemented 💻. PCs are everywhere now, and there's limited trust you can place in UA implementations on many multi-user systems. So this attribute lets many users process PEM at a higher assurance level than a strictly UA-integrated approach would allow 🔒.
- These mechanisms support privacy protection for electronic mail addressed to mailing lists (distribution lists, in ISO parlance) 📬.
- These mechanisms are compatible with a variety of supporting key management approaches 🔑, including (but not limited to) manual pre-distribution, centralized key distribution based on symmetric cryptography, and the use of public-key certificates per RFC 1422. Different key management mechanisms may be used for different recipients of a multicast message. For two PEM implementations to interoperate, they must share a common key management mechanism. Support for the mechanism defined in RFC 1422 is strongly encouraged 💜.
To reach the broadest possible range of Internet hosts and mail systems, and to make pilot implementation and testing possible without needing prior and pervasive changes across the whole Internet, the following design principles were applied when picking the features in this RFC 🧠✨:
- This RFC's measures are restricted to implementation at endpoints. They're amenable to integration with existing Internet mail protocols at the user agent (UA) level or above, rather than needing modifications to existing mail protocols or integration into the message transport system (e.g., SMTP servers) 🫶.
- The set of supported measures enhances rather than restricts user capabilities 🙌. Trusted implementations, with integrity features that protect software from subversion by local users, can't be assumed in general. No mechanisms are assumed to stop users from sending, at their discretion, messages to which no PEM processing has been applied. Without those features, it seems 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 🦋.
- The set of supported measures focuses on a set of functional capabilities chosen to provide significant and tangible benefits to a broad user community 🍓. By concentrating on the most critical set of services, the goal is to maximize the added privacy value that can be provided with a modest level of implementation effort 🎯.
Based on these principles, the following facilities are provided:
- disclosure protection,
- originator authenticity,
- message integrity measures, and
- (if asymmetric key management is used) non-repudiation of origin,
but the following privacy-relevant concerns are not addressed 🙈:
- access control,
- traffic flow confidentiality,
- address list accuracy,
- routing control,
- issues relating to the casual serial reuse of PCs by multiple users,
- assurance of message receipt and non-deniability of receipt,
- automatic association of acknowledgments with the messages to which they refer, and
- message duplicate detection, replay prevention, or other stream-oriented services
4. Processing of Messages 🌷
4.1 Message Processing Overview
This subsection gives a high-level overview of the components and processing steps involved in electronic mail privacy enhancement processing 🗺️. Later subsections define the procedures in more detail.
4.1.1 Types of Keys
Okay, so a two-level keying hierarchy is used to support PEM transmission 🗝️✨:
- Data Encrypting Keys (DEKs) are used for encryption of message text and (with certain choices among a set of alternative algorithms) for computation of message integrity check (MIC) quantities. In the asymmetric key management environment, DEKs are also used to encrypt the signed representations of MICs in PEM messages to which confidentiality has been applied. DEKs are generated individually for each transmitted message, so no predistribution of DEKs is needed to support PEM transmission 💅.
- Interchange Keys (IKs) are used to encrypt DEKs for transmission within messages. Ordinarily, the same IK will be used for all messages sent from a given originator to a given recipient over a period of time 🫶. Each transmitted message includes a representation of the DEK(s) used for message encryption and/or MIC computation, encrypted under an individual IK per named recipient. That representation is associated with
Originator-IDandRecipient-IDfields (defined in different forms so as to distinguish symmetric from asymmetric cases), which let each individual recipient identify the IK used to encrypt DEKs and/or MICs for that recipient's use 🔍. Given an appropriate IK, a recipient can decrypt the corresponding transmitted DEK representation, yielding the DEK required for message text decryption and/or MIC validation 🔓. The definition of an IK differs depending on whether symmetric or asymmetric cryptography is used for DEK encryption:- 2a. When symmetric cryptography is used for DEK encryption, an IK is a single symmetric key shared between an originator and a recipient. In this case, the same IK is used to encrypt MICs as well as DEKs for transmission. Version/expiration information and IA identification associated with the originator and with the recipient must be concatenated in order to fully qualify a symmetric IK 🎀.
- 2b. When asymmetric cryptography is used, the IK component used for DEK encryption is the public component [8] of the recipient. The IK component used for MIC encryption is the private component of the originator, and therefore only one encrypted MIC representation need be included per message, rather than one per recipient 🧁. Each of these IK components can be fully qualified in a
Recipient-IDorOriginator-IDfield, respectively. Alternatively, an originator's IK component may be determined from a certificate carried in anOriginator-Certificate:field 📜.
4.1.2. Processing Procedures ✨
okay so when PEM processing is happening on an outgoing message 💌, a DEK gets generated [1] for the message encryption. If the MIC algorithm you picked needs a key, you also form a variant of the DEK for the MIC computation 🔐. You can skip DEK generation when the message isn't getting confidentiality, unless the MIC computation algorithm needs a DEK anyway. Other parameters, like Initialization Vectors (IVs), also get generated when the encryption algorithm needs them 🎀
One or more Originator-ID and/or Originator-Certificate: fields go in a PEM message's encapsulated header 🦋 They give recipients an identification component for the IK(s) used for processing the message. All of a message's Originator-ID and/or Originator-Certificate: fields are assumed to belong to the same principal. Having more than one is for the case where different recipients need different keys, algorithms, and/or certification paths. If a message has recipients using asymmetric key management and recipients using symmetric key management, a separate Originator-ID or Originator-Certificate: field goes right before each set of recipients ✨
In the symmetric case, per-recipient IK components get applied for each individually named recipient when preparing ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages. A matching Recipient-ID-Symmetric: field identifies each IK, and it gets read in the context of the most recent preceding Originator-ID-Symmetric: field 🌸 In the asymmetric case, per-recipient IK components only get applied for ENCRYPTED messages. They're independent of the originator-oriented header stuff, and they're identified by Recipient-ID-Asymmetric: fields. Every Recipient-ID field is followed by a Key-Info: field, which carries the message's DEK encrypted under the IK for that specific recipient 💅
When symmetric key management is used for a recipient, the Key-Info: field after the Recipient-ID-Symmetric: field also carries the message's computed MIC, encrypted under that recipient's IK 🔥 When asymmetric key management is used, a MIC-Info: field tied to an Originator-ID-Asymmetric: or Originator-Certificate: field carries the MIC. It's signed with the originator's private component 🫶 If the PEM message is type ENCRYPTED (see Section 4.6.1.1.1 of this RFC), that signed MIC then gets symmetrically encrypted with the same DEK, algorithm, encryption mode, and other cryptographic parameters used for the message text, before it goes into the MIC-Info: field 😭
4.1.2.1. Processing Steps
okay this part is so clever 🧚 There's a four-phase transformation procedure. It exists so encrypted message text can go in a universally transmissible form, and so a message encrypted on one type of host computer can be decrypted on a totally different type of host computer 🌈 A plaintext message gets accepted in local form, using the host's native character set and line representation. That local form then gets converted to a canonical message text representation, which is defined as equivalent to the inter-SMTP representation of message text. This canonical representation is the input to the MIC computation step (for ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages) and to the encryption process (for ENCRYPTED messages only) 💜
For ENCRYPTED PEM messages, the canonical representation gets padded as the encryption algorithm requires, and then that padded canonical representation gets encrypted. The encrypted text (for an ENCRYPTED message) or the unpadded canonical form (for a MIC-ONLY message) is then encoded into a printable form 🍓 That printable form uses a restricted character set, picked so it's universally representable across sites and won't get messed up by processing within and between MTS entities. MIC-CLEAR PEM messages skip the printable encoding step entirely 🙈
The output of those earlier steps gets combined with a set of header fields that carry the cryptographic control information. The resulting PEM message is handed to the electronic mail system to be included within the text portion of a transmitted message ✨ There's no requirement that a PEM message be the entire text portion of an MTS message. That means PEM-protected info can come with unprotected annotations, which is so useful 🦋 It's also fine for multiple PEM messages (plus associated unprotected text outside the PEM message boundaries) to show up inside the encapsulated text of a higher-level PEM message. PEM message signatures are forwardable when asymmetric key management is employed 👑 An authorized recipient of a PEM message with confidentiality applied can either reduce that message to a signed but unencrypted form for forwarding, or re-encrypt it for later transmission.
When a PEM message gets received, the cryptographic control fields in its encapsulated header give each authorized recipient the info needed to do MIC validation and decryption of the message text 🎀 For ENCRYPTED and MIC-ONLY messages, the printable encoding gets converted back to a bitstring. Encrypted portions of the transmitted message get decrypted, and then the MIC gets validated. After that, the recipient PEM process converts the canonical representation into its appropriate local form 💖
4.1.2.2. Error Cases
so a bunch of error cases can pop up while a received PEM message is being processed 🙈 What actually happens in response is a local matter. It depends on user preferences and the type of user interface a particular PEM implementation has. Still, there are some general recommendations that make sense 🌸 Syntactically invalid PEM messages should be flagged as invalid, ideally with diagnostic info collected to help debug incompatibilities or other failures. RFC 1422 defines specific error processing requirements for the certificate-based key management mechanisms it defines 🧚
Syntactically valid PEM messages that yield MIC failures are a special kind of concerning, because they might come from attempted attacks or forged messages 😭 So it's unsuitable to display their contents to recipient users without first saying that the contents' authenticity and integrity can't be guaranteed, and then getting positive user confirmation of that warning.
Please don't skip the warning. Showing the contents of a MIC-failed message without it is a no-go 🚨
MIC-CLEAR messages (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns too, since MIC failures on those can happen for a much broader range of benign causes than with other PEM message types 💀
4.2. Encryption Algorithms, Modes, and Parameters
okay so for using this RFC, RFC 1423 defines the right algorithms, modes, and associated identifiers for encrypting message text with DEKs 🎀
The mechanisms in this RFC have facilities for sending cryptographic parameters (like pseudorandom Initializing Vectors (IVs)) along with PEM messages that get the confidentiality service. This happens when the symmetric message encryption algorithms and modes specified in RFC 1423 require it ✨
Certain operations need DEKs, MICs, and digital signatures to be encrypted under an IK for transmission 🦋 A header facility says which mode the IK is being used in for that encryption. RFC 1423 specifies the encryption algorithm and mode identifiers, plus the minimum essential support requirements for key encryption processing 💅
RFC 1422 specifies asymmetric, certificate-based key management procedures based on CCITT Recommendation X.509, to support the message processing procedures in this document. Support for the key management approach in RFC 1422 is strongly recommended 👑 The message processing procedures can also be used with symmetric key management, given prior distribution of suitable symmetric IKs. But no current RFCs specify key distribution procedures for those IKs 😭
4.3. Privacy Enhancement Message Transformations
4.3.1. Constraints
okay this is the core of the whole thing 🧚 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 on the characteristics of the anticipated endpoint and transport facilities 🌈 An encryption mechanism must also be compatible with the local conventions of the computer systems it interconnects. Our approach uses a canonicalization step to abstract out the local conventions, and then a subsequent encoding step to conform to the characteristics of the underlying mail transport medium (SMTP) 💜 The encoding conforms to SMTP constraints. Section 4.5 of RFC 821 [2] details SMTP's transparency constraints.
To prepare a message for SMTP transmission, the following requirements must be met:
- All characters must be members of the 7-bit ASCII character set.
- Text lines, delimited by the character pair
<CR><LF>, must be no more than 1000 characters long. - 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.
Here's the thing though 🍓 Although SMTP specifies a standard representation for line delimiters (ASCII <CR><LF>), a bunch of systems on the Internet use a different native representation to delimit lines. For example, the <CR><LF> sequences delimiting lines in mail coming into UNIX systems get transformed to single <LF>s as the mail is written into local mailbox files. Lines in mail going to record-oriented systems (like VAX VMS) may be converted into appropriate records by the destination SMTP server [3] 🙈 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 using different line delimiting conventions. Conversion between tabs and spaces may also happen while mapping between inter-SMTP and local format, and that's just a matter of local option. If transformations like these changed the form of the 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 done by an SMTP server at a system with EBCDIC as its native character set has an even more severe impact 💀 That's because converting from EBCDIC into ASCII is an information-losing transformation. In principle, the transformation function mapping between inter-SMTP canonical ASCII message representation and local format could be moved from the SMTP server up to the UA, given a way to tell the SMTP server to stop doing that transformation. But this approach has a major disadvantage 🥺 Internal file formats (like mailbox formats) would be incompatible with the native forms used on the systems where they live. And it would require changes to SMTP servers too, since mail would be passed to SMTP in a different representation than it's passed at present 🌸
4.3.2. Approach ✨
okay bestie, the big idea here is making PEM still work when messages get converted along the way 🦋 different machines have different character sets, so PEM UAs defined an encoding for mail that looks the same across all of them, no matter what their system's native character set is 💅 this encoded form is only used for certain PEM message types, to carry the mail text from originator to recipient in transit 🎀 BUT it's not applied to the enclosing MTS headers, or to the encapsulated headers that carry control info between PEM UAs 🙈 and the encoding is built so that the transformations we expect between originator and recipient UAs won't stop an encoded message from being decoded properly at its destination 🫶 iconic, honestly.
Four transformation steps, each with its own subsection, apply to outbound PEM message processing 🌸
4.3.2.1. Step 1: Local Form 💖
this step applies to PEM message types ENCRYPTED, MIC-ONLY, and MIC-CLEAR 🍓 the message text gets created in the system's native character set, with lines delimited according to local convention ✨
4.3.2.2. Step 2: Canonical Form 🧚
this step applies to PEM message types ENCRYPTED, MIC-ONLY, and MIC-CLEAR 💜 the message text gets converted to a universal canonical form, similar to the inter-SMTP representation [4] as defined in RFC 821 [2] and RFC 822 [5] 📜 the procedures for doing that conversion depend on the characteristics of the local form, so they are not specified in this RFC 🤷♀️
canonicalization makes sure the message text is represented with the ASCII character set and "<CR><LF>" line delimiters 🌈 but it does not do the dot-stuffing transformation from RFC 821, Section 4.5.2 🙅♀️ and since the message gets converted to a standard character set and representation before encryption, a transferred PEM message can be decrypted and its MIC validated at any type of destination host computer 👑 decryption and MIC validation happen before any conversions needed to turn the message into a destination-specific local form 💅
4.3.2.3. Step 3: Authentication and Encryption 🔐
authentication processing applies to PEM message types ENCRYPTED, MIC-ONLY, and MIC-CLEAR 🫧 the canonical form gets fed into the selected MIC computation algorithm to compute an integrity check quantity for the message 🔍 no padding is added to the canonical form before it goes to the MIC computation algorithm, although certain MIC algorithms will apply their own padding while computing a MIC 🙃
encryption processing applies only to PEM message type ENCRYPTED 🔥 RFC 1423 defines the padding technique used to support encryption of the canonically-encoded message text 📦
4.3.2.4. Step 4: Printable Encoding 🎀
this printable encoding step applies to PEM message types ENCRYPTED and MIC-ONLY 🌸 the same processing is also used for representing certain specifically identified PEM encapsulated header field quantities, as cited in Section 4.6 📌 going from left to right, the bit string from step 3 gets encoded into characters that are universally representable at all sites, though not necessarily with the same bit patterns 🌈 (like, "E" is hexadecimal 45 in an ASCII-based system and hexadecimal C5 in an EBCDIC-based system, and both mean the same thing locally 🤓)
a 64-character subset of International Alphabet IA5 is used, which means 6 bits get represented per printable character 🧁 (the proposed subset of characters is represented identically in IA5 and ASCII.) the character "=" signals a special processing function used for padding within the printable encoding procedure 🫶
to represent the encapsulated text of a PEM message, the encoding function's output is delimited into text lines (using local conventions) 📏 each line except the last contains exactly 64 printable characters, and the final line contains 64 or fewer 💅 (this line length is easy to print and is guaranteed to satisfy SMTP's 1000-character transmitted line length limit 😌) this folding requirement does not apply when the encoding procedure is used to represent PEM header field quantities 🙈 Section 4.6 discusses folding of PEM encapsulated header fields 📜
the encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters 🧚 going left to right across a 24-bit input group pulled from the output of step 3, each 6-bit group is used as an index into an array of 64 printable characters 🔢 the character referenced by that index goes into the output string 🍓 these characters, identified in Table 1, were selected so they are universally representable, and the set leaves out characters with particular significance to SMTP (like ".", "<CR>", and "<LF>") 🚫
special processing happens if fewer than 24 bits are available in an input group at the end of a message 🫧 a full encoding quantum is always completed at the end of a message 💯 when fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups 🧮 output character positions that aren't needed to represent actual input data get set to "=" 🌷 since all canonically encoded output is an integral number of octets, only these cases can arise:
- (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding,
- (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or
- (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Printable Encoding Characters
Table 14.3.2.5. Summary of Transformations 🦋
in summary, the outbound message goes through the following composition of transformations (or, for some PEM message types, a subset of them) 💖
Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))the inverse transformations get performed, in reverse order, to process inbound PEM messages 🔄
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 originator and recipient systems without loss of information 💜✨
4.4. Encapsulation Mechanism 🎀
okay so the encapsulation techniques from RFC-934 [6] are what we use to wrap PEM messages up inside separate enclosing MTS messages, each carrying its own MTS headers 🎁. bestie, this is SO much better than a flat approach where you encrypt some fields in one header and cram crypto control info in there too 😭. From the MTS's point of view, the entire PEM message lives in the MTS message's text portion, NOT its header portion. Encapsulation gives us generality and keeps the fields with user-to-user significance separate from the ones that get transformed in transit 💅. Every field added during encryption/authentication processing goes in the encapsulated header. This is lowkey clutch because mail handling programs that only accept text (not header fields) from input files or other programs can still deal with it 🫶.
The RFC-934 techniques fit right in with existing Internet mail forwarding and bursting mechanisms ✨. They're also designed to be nested, which is giving main character energy 👑. You can encapsulate one or more PEM messages to forward to a third party, and you can even mix in interspersed (non-PEM) text to annotate them 🦋.
Two encapsulation boundaries (EB's) do the heavy lifting here 🧚. They mark off encapsulated PEM messages and tell them apart from interspersed (non-PEM) text. The pre-EB is the string -----BEGIN PRIVACY-ENHANCED MESSAGE-----, which basically says "an encapsulated PEM message is coming." The post-EB is either (1) another pre-EB, meaning another encapsulated PEM message follows, or (2) the string -----END PRIVACY-ENHANCED MESSAGE-----, which means whatever comes next is non-PEM text 🌸. Now here's the tea 🍵: MIC-CLEAR messages can have text lines that start with the "-" character, and those lines get special handling under the RFC-934 forwarding procedures. If the string "- " has to be prepended to such a line during forwarding so it doesn't look like an encapsulation boundary, MIC computation is to be performed BEFORE prepending the "- " string 🙈. Figure 1 shows what a single encapsulated PEM message looks like 💖.
Encapsulated Message
Pre-Encapsulation Boundary (Pre-EB)
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Encapsulated Header Portion
(Contains encryption control fields inserted in plaintext.
Examples include "DEK-Info:" and "Key-Info:".
Note that, although these control fields have line-oriented
representations similar to RFC 822 header fields, the set
of fields valid in this context is disjoint from those used
in RFC 822 processing.)
Blank Line
(Separates Encapsulated Header from subsequent
Encapsulated Text Portion)
Encapsulated Text Portion
(Contains message data encoded as specified in Section 4.3.)
Post-Encapsulation Boundary (Post-EB)
-----END PRIVACY-ENHANCED MESSAGE-----
Encapsulated Message Format
Figure 1This RFC doesn't set any a priori limits on how deep you can nest encapsulation, or how many PEM messages you can group at a single nesting level for forwarding 🎀. An implementation that complies with this RFC MUST NOT prevent a user from submitting or receiving PEM messages that use this encapsulation capability. HOWEVER, there are no specific requirements on how the capability gets made available to the user 🤷♀️. So a compliant PEM implementation isn't required to automatically detect and process encapsulated PEM messages, which is a vibe-check worth knowing about 🫠.
Now for a big warning 🚨. It's inappropriate to forward an ENCRYPTED message directly to a third party, because recipients wouldn't have the DEK needed to decrypt it 💀. Instead, the forwarding user has to transform the ENCRYPTED message into MIC-ONLY or MIC-CLEAR form before forwarding. So to comply with this RFC, a PEM implementation must give users a facility to do that transformation while preserving the MIC from the original message 🔥.
If a user wants PEM-provided confidentiality protection for transmitted information, that information MUST occur in the encapsulated text of an ENCRYPTED PEM message. It must NOT end up in the enclosing MTS header or the PEM encapsulated header. Being sneaky about this with headers is not a vibe 😭.
Wait, that last line isn't in the original, so let me scrap it and stick to the facts. The actual text reads: if a user wants PEM-provided confidentiality protection for transmitted information, that information must occur in the encapsulated text of an ENCRYPTED PEM message, not in the enclosing MTS header or PEM encapsulated header. If a user wants to avoid disclosing the actual subject of a message to unintended parties, it is suggested that the enclosing MTS header contain a "Subject:" field indicating that "Encrypted Mail Follows" 🙈✨.
Sometimes you want an integrity-protected version of something that lives in an enclosing header (and it doesn't have to be in the same format as it is in that header) 🎀. In that case, you can put that data into the encapsulated text portion as well as keeping it in the enclosing MTS header. For example, an originator who wants to give recipients a protected indication of where a message sits in a series of messages could copy a timestamp or message counter with end-to-end significance from an enclosing MTS header field into the encapsulated text 🧚. Heads up though: mailbox specifiers entered by end users come with local conventions and can get modified at intermediaries, so putting them in encapsulated text should NOT be treated as a suitable replacement for the authentication semantics defined in RFC 1422 and based on X.500 Distinguished Names 💅. Whatever header info (if any) gets included in the encapsulated text is a local matter, and this RFC doesn't specify formatting conventions for telling replicated header fields apart from other encapsulated text 🌈.
4.5. Mail for Mailing Lists 💌
When mail is addressed to mailing lists, there are two main ways it can get processed: the IK-per-list method and the IK-per-recipient method 🍓. Hybrid approaches are also possible. For example, you could use IK-per-list protection from the originator to a PEM-equipped mailing list exploder, and then IK-per-recipient protection from the exploder out to the individual list recipients ✨.
If the originator can expand a destination mailing list into its individual members and chooses to do so (IK-per-recipient), the message's DEK (and, in the symmetric key management case, MIC) gets encrypted under each per-recipient IK, and all of those encrypted versions go into the transmitted message 🦋. Per-recipient encryption is only needed for the relatively small DEK and MIC quantities carried in the "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 one at a time, and having one IK doesn't let someone successfully masquerade as another user on the list 👑.
If the originator addresses a message to a list name or alias, then the IK associated with that name or alias is implied to be used as an entity (IK-per-list), rather than resolving the name or alias into its constituent destinations 😬. That IK MUST, therefore, be available to all list members. Unfortunately, this exposes the shared IK a lot, and makes revoking it difficult 💀. On top of that, the IK-per-list method lets any holder of the list's IK masquerade as another originator to the list for authentication purposes 🙈.
Pure IK-per-list key management in the asymmetric case (where a common private key is shared among multiple list members) is especially disadvantageous in an asymmetric environment 😭. It fails to preserve the forwardable authentication and non-repudiation characteristics that are provided for other messages in this environment. So a hybrid approach with a PEM-capable exploder is particularly recommended for protecting mailing list traffic when asymmetric key management is used 🌸. That exploder would reduce incoming ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding them (perhaps re-encrypted under individual, per-recipient keys) to list members, per the discussion in Section 4.4 of this RFC 💖.
4.6. Summary of Encapsulated Header Fields ✨
okay so this section is the cheat sheet for every encapsulated header field that gets added while privacy enhancement processing is happening 💅 It defines the syntax and semantics of all of them, so bookmark it bestie 🔖
The fields come in three groups. Normally the groups show up in encapsulated headers in the order I'm about to show you, though not every field in each group will appear in every message 🎀 Figure 2 assumes symmetric cryptography for key management. Figure 3 is an example ENCRYPTED message that uses asymmetric key management. Here's Figure 2 first 👇
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated Message (Symmetric Case)
Figure 2Figure 4 shows an example encapsulated MIC-ONLY message that uses asymmetric key management 🦋 Since no per-recipient keys are involved in preparing asymmetric-case MIC-ONLY messages, this example should be processable for test purposes by arbitrary PEM implementations 🧪
Fully-qualified domain names (FQDNs) for hosts, which show up in the mailbox names inside the entity identifier subfields of Originator-ID-Symmetric: and Recipient-ID-Symmetric: fields, get processed case-insensitively 🌸 Unless specified otherwise, every other field argument (including the user name parts of mailbox names) gets processed case-sensitively. so careful with those capitals, bestie 👀
In most cases, numbers show up in header fields as contiguous strings of hexadecimal digits. Each digit is a character from "0"-"9" or upper case "A"-"F" 🔢 Public-key certificates and quantities encrypted with asymmetric algorithms are huge, so a more space-efficient encoding is the move for those. The encoding mechanism from Section 4.3.2.4 of this RFC, which represents 6 bits per printed character, is adopted for exactly that job 💜 Quick heads up, Figure 3 lands right in the middle of this sentence because of page break drama 🙈 Here it is:
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,BFF968AA74691AC1
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Key-Info: RSA,
I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
wGrtiUm/ovtKdinz6ZQ/aQ==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,
66
Key-Info: RSA,
O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv
7x0Z3Jx2vTAhOYHMcqqCjA==
qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d
jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated ENCRYPTED Message (Asymmetric Case)
Figure 3Okay, back to the sentence 💅 Those asymmetric quantities get the 6-bits-per-character treatment we just talked about 🍓
Encapsulated headers of PEM messages get folded with whitespace using RFC 822 header folding conventions. There are no PEM-specific folding rules for encapsulated headers 🧚 Figure 4 shows this off: the MIC-Info: field holds an asymmetrically encrypted quantity in its printably encoded form, so you can see RFC 822 folding in action ✨
Here's the big glow-up moment. Unlike the encapsulated header representations in RFC 1113 and its predecessors, the field identifiers in this RFC do not start with the "X-" prefix. For example, the field that used to be X-Key-Info: is now just Key-Info: 🎀 Implementations that follow this RFC must not emit those prefixes. To make the transition smoother and keep things interoperable with older implementations, it is suggested that implementations based on this RFC accept incoming encapsulated header fields that carry the "X-" prefix, and treat them as if the "X-" wasn't there 🫶
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-ONLY
Content-Domain: RFC822
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
EtE7K2QDeVMCyXsdJlA8fA==
LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg
YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated MIC-ONLY Message (Asymmetric Case)
Figure 44.6.1. Per-Message Encapsulated Header Fields 🌈
this group is for fields that show up no more than once in a PEM message 💖 They usually come before all the other encapsulated header fields, so they're basically the VIP section 👑
4.6.1.1. Proc-Type Field 🔥
The Proc-Type: encapsulated header field is required for all PEM messages 😭 It tells you what kind of processing happened to the message being sent. Only one Proc-Type: field can appear in a message, and it must be the very first encapsulated header field 🧚
Proc-Type: has two subfields, separated by a comma. The first is a decimal number that tells apart incompatible encapsulated header field interpretations, which can pop up as this standard changes over time 🌸 Messages processed according to this RFC carry the subfield value 4 so they can be told apart from messages processed under earlier PEM RFCs 🎀 The second subfield is one of a set of string values, defined in the subsections right below 💅
4.6.1.1.1. ENCRYPTED
The ENCRYPTED specifier means confidentiality, authentication, integrity, and (when asymmetric key management is used) non-repudiation of origin security services have all been applied to a PEM message's encapsulated text 🔐 ENCRYPTED messages need a DEK-Info: field, plus individual Recipient-ID-* and Key-Info: fields for every single message recipient 🫶
4.6.1.1.2. MIC-ONLY
The MIC-ONLY specifier means every security service listed for ENCRYPTED messages has been applied to a PEM message's encapsulated text, except for confidentiality 🦋 MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC) so their encapsulated text is protected against modifications at message transfer or relay points 🛡️
Specifying MIC-ONLY, when combined with certain mixes of key management and MIC algorithm options, lets you leave out some fields that would be pointless without encryption 🍓 Specifically, when a keyless MIC computation is used for recipients who use asymmetric cryptography, the Recipient-ID-Asymmetric: and Key-Info: fields can be omitted. The DEK-Info: field can be omitted for all MIC-ONLY messages 💜
⚠️ these are the omission rules, so double-check which combo you're using before you start stripping fields, bestie 🙈
4.6.1.1.3 MIC-CLEAR 🦋
okay so MIC-CLEAR is basically a PEM message that gets the same security service selection as a MIC-ONLY message 💅 That means the set of encapsulated header fields required in a MIC-CLEAR message is the same set required for a MIC-ONLY message. no extra homework, bestie 🎀
here's the vibe check: MIC-CLEAR processing skips the encoding step from Section 4.3.2.4 of this RFC. that's the step that protects the encapsulated text against modifications inside the MTS 🙈 so the result is that the text is readable by recipients who don't have PEM software, even though they can't validate the signature. the canonical encoding from Section 4.3.2.2 still happens though ✨ which means sites with different native character sets and line representations can still interoperate, as long as those native formats translate cleanly to and from the canonical form. (and yes, that only works for characters inside the canonical representation set 🧚)
now the tea 🍵 skipping the printable encoding means MIC-CLEAR MICs will only be validatable in environments where the MTS doesn't modify messages in transit, or where any modifications can be figured out and inverted before MIC validation runs. so a failed MIC validation on a MIC-CLEAR message doesn't automatically mean something sketchy happened 😭 that's why it's recommended that PEM implementations show their users (in a suitable local way) what type of PEM message they're processing when they report a MIC validation failure. transparency is iconic 💜
side quest: this matters most for inbound SMTP on systems that use local native line representations other than the SMTP-standard <CR><LF>. when mail gets delivered to a UA on one of those systems and handed off for PEM processing, the <CR><LF> has already been translated to local form. so to validate a MIC-CLEAR message's MIC here, the PEM module has to recanonicalize the incoming message, figure out the inter-SMTP representation of the canonically encoded message (per Section 4.3.2.2 of this RFC), and compute the reference MIC based on that representation 🔥
4.6.1.1.4 CRL 📜
the CRL specifier marks a special PEM message type that's used to transfer one or more Certificate Revocation Lists 🌸 the format of PEM CRLs is defined in RFC 1422. no user data or encapsulated text comes along for the ride with a CRL header. a correctly-formed CRL message's PEM header goes straight into its terminating message boundary line, with no blank line in between 🙌
only three types of fields are valid in the encapsulated header of a CRL message, bestie 👑 the CRL: field carries a printable representation of a CRL, encoded using the procedures in Section 4.3.2.4 of this RFC. CRL: fields may (as an option) be followed by no more than one Originator-Certificate: field and any number of Issuer-Certificate: fields. those two certificate fields refer to the most recent previous CRL: field, and they provide certificates that help validate the signature included in the CRL. their contents are the same for CRL messages as they are for other PEM message types 💖
CRL: <printable representation of a CRL>
Originator-Certificate: <optional, no more than one>
Issuer-Certificate: <any number, optional>4.6.1.2 Content-Domain Field 🧚
the Content-Domain: encapsulated header field describes what kind of content is inside a PEM message's encapsulated text ✨ it carries one string argument, and the value RFC822 means the message is RFC-822 mail processed the way this spec describes. more Content-Domain: values are expected to show up later in additional or successor documents 🦋 only one Content-Domain: field can appear in a PEM message, and it's the PEM message's second encapsulated header field, right after the Proc-Type: field. main character placement, honestly 💅
4.6.1.3 DEK-Info Field 🔐
the DEK-Info: encapsulated header field identifies the message text encryption algorithm and mode, and it also carries any cryptographic parameters (like IVs) used for encrypting the message 💜 no more than one DEK-Info: field can occur in a message, and it's required for every message specified as ENCRYPTED in the Proc-Type: field 😭
the DEK-Info: field carries either one argument or two arguments separated by a comma. the first argument identifies the algorithm and mode used for message text encryption. the second argument, if it's there, carries any cryptographic parameters the algorithm and mode from the first argument need. the appropriate message encryption algorithms, modes, identifiers, and their matching cryptographic parameters and formats are defined in RFC 1423 🎀
4.6.2 Encapsulated Header Fields Normally Per-Message 🌈
this group is for encapsulated header fields that usually show up no more than once per message ✨ depending on the key management option(s) being used, some of these fields might be absent from some messages, so don't panic if you don't see one 🫶
4.6.2.1 Originator-ID Fields 🍓
Originator-ID encapsulated header fields identify a message's originator and provide the originator's IK identification component 👑 there are two varieties: the Originator-ID-Asymmetric: field and the Originator-ID-Symmetric: field. an Originator-ID-Symmetric: header field is required for all PEM messages that use symmetric key management ✨ the analogous Originator-ID-Asymmetric: field, for the asymmetric key management case, is only used when no corresponding Originator-Certificate: field is included.
most of the time, only one Originator-ID or Originator-Certificate: field shows up in a message 🙈 in the symmetric case, the IK identification component carried in an Originator-ID-Symmetric: field applies to processing every later Recipient-ID-Symmetric: field, until another Originator-ID-Symmetric: field appears. it's illegal for a Recipient-ID-Symmetric: field to come before its matching Originator-ID-Symmetric: field, so the order really matters, bestie 😭 in the asymmetric case, processing Recipient-ID-Asymmetric: fields is logically independent of any earlier Originator-ID-Asymmetric: and Originator-Certificate: fields 🦋
you might see multiple Originator-ID and/or Originator-Certificate: fields in one message when different originator-oriented IK components have to be used so the originator can prepare the message for different recipients. the big example is when both symmetric and asymmetric cryptography get applied to one message so it can be processed by different recipients 🔥
Originator-ID subfields are delimited by the comma character (","), and a comma can optionally be followed by whitespace 🧚 Section 5.2, Interchange Keys, goes into the semantics of these subfields and specifies the alphabet they're chosen from 💅
4.6.2.1.1 Originator-ID-Asymmetric Field 🌸
the Originator-ID-Asymmetric: field has an Issuing Authority subfield, and then a Version/Expiration subfield ✨ it's only used when the information it carries isn't already available from an included Originator-Certificate: field 💖
4.6.2.1.2 Originator-ID-Symmetric Field 🎀
the Originator-ID-Symmetric: field has an Entity Identifier subfield, followed by an (optional) Issuing Authority subfield, and then an (optional) Version/Expiration subfield 🌈 the optional subfields can only be left out if the information in later Recipient-ID-Symmetric: fields already makes them redundant, and in those cases they'll normally be omitted 🙌
4.6.2.2 Originator-Certificate Field 📜
the Originator-Certificate: encapsulated header field is only used when asymmetric key management is employed for one or more of a message's recipients 🦋 to make life easier for recipients (at least before general directory server availability), including this field in all messages is strongly recommended 🫶 the field transfers an originator's certificate as a numeric quantity, made of the certificate's DER encoding, represented in the header field with the encoding mechanism from Section 4.3.2.4 of this RFC 🔐 the semantics of a certificate are discussed in RFC 1422.
4.6.2.3 MIC-Info Field 🔐
the MIC-Info: encapsulated header field is only used when asymmetric key management is employed for at least one recipient of a message 💜 it carries three arguments, separated by commas ✨ the first argument identifies the algorithm the accompanying MIC is computed under. the second argument identifies the algorithm the accompanying MIC is signed under. the third argument represents a MIC signed with the originator's private key 👑
for ENCRYPTED PEM messages, the signed MIC is, in turn, symmetrically encrypted using the same DEK, algorithm, mode, and cryptographic parameters used to encrypt the message's encapsulated text 😭 this measure stops unauthorized recipients from figuring out whether an intercepted message matches a predetermined plaintext value. big brain move 🧠💅
the appropriate MIC algorithms and identifiers, signature algorithms and identifiers, and signed MIC formats are defined in RFC 1423 🌸
a MIC-Info: field will occur after a sequence of fields that begins with an Originator-ID-Asymmetric: or Originator-Certificate: field and is followed by any associated Issuer-Certificate: fields 🎀 a MIC-Info: field applies to all subsequent recipients who use asymmetric key management, until and unless it's overridden by a later Originator-ID-Asymmetric: or Originator-Certificate: field and its corresponding MIC-Info: 🦋
4.6.3 Encapsulated Header Fields with Variable Occurrences 🌈
this group contains encapsulated header fields that will normally occur a variable number of times in a message 🧚 the number of occurrences can range from zero up to non-zero values, and it's independent of how many recipients there are ✨
4.6.3.1 Issuer-Certificate Field ✨
okay so the Issuer-Certificate: field only matters when asymmetric key management is used for at least one of a message's recipients 🔑. A typical one holds the certificate with the public component that signed the certificate in the message's Originator-Certificate: field, so recipients can chain through that certificate's certification path 🛤️. An originator can also include other Issuer-Certificate: fields, usually for higher points in a certification path 💅.
It is recommended that these fields go in order, following successive points in the certification path from the originator to a common point shared with the recipients. That common point is the Internet Certification Authority (ICA), unless a lower Policy Certification Authority (PCA) or CA is shared by all the recipients 🌈. More on certification paths is in RFC 1422 📚.
The certificate is represented the same way as in the Originator-Certificate: field, as an encoded X.509 [7] DER form. Any Issuer-Certificate: fields will ordinarily come right after the Originator-Certificate: field 🎀. Using Issuer-Certificate: is optional even when asymmetric key management is employed, but it is strongly recommended when recipients don't have alternate directory server facilities to look up issuers' certificates 🫶.
4.6.4 Per-Recipient Encapsulated Header Fields 🧚
These encapsulated header fields show up once for each of an "ENCRYPTED" message's named recipients 💜. For "MIC-ONLY" and "MIC-CLEAR" messages, they're left out for recipients who use asymmetric key management together with a keyless MIC algorithm. They do appear for recipients who use symmetric key management or a keyed MIC algorithm 🔐.
4.6.4.1 Recipient-ID Fields 🪪
A Recipient-ID encapsulated header field identifies a recipient and gives the recipient's IK identification component. There is one Recipient-ID field for each of a message's named recipients. Section 5.2, Interchange Keys, explains what the subfields mean and lists the alphabet they're picked from 🔤. Recipient-ID subfields are separated by the comma character (","), optionally followed by whitespace ✨.
For the symmetric case, every Recipient-ID-Symmetric: field is read in the context of the most recent preceding Originator-ID-Symmetric: field 💅. It is illegal for a Recipient-ID-Symmetric: field to appear in a header before its corresponding Originator-ID-Symmetric: field. That's a hard no 🚫. For the asymmetric case, Recipient-ID-Asymmetric: fields are logically independent of a message's Originator-ID-Asymmetric: and Originator-Certificate: fields. The Recipient-ID-Asymmetric: fields, and their associated Key-Info: fields, come after the header's originator-oriented fields 🦋.
4.6.4.1.1 Recipient-ID-Asymmetric Field 🦋
The Recipient-ID-Asymmetric: field contains, in order, an Issuing Authority subfield and a Version/Expiration subfield 💖.
4.6.4.1.2 Recipient-ID-Symmetric Field 🌸
The Recipient-ID-Symmetric: field contains, in order, an Entity Identifier subfield, an (optional) Issuing Authority subfield, and an (optional) Version/Expiration subfield 🍓.
4.6.4.2 Key-Info Field 🔑
One Key-Info: field is included for each of a message's named recipients 🫧. On top of that, it is recommended that PEM implementations support, as a locally-selectable option, the ability to include a Key-Info: field for a PEM message's originator. That field goes after an Originator-ID or Originator-Certificate: field and before any associated Recipient-ID fields. Including it is not a requirement for conformance with this RFC 🙏.
Each Key-Info: field is interpreted in the context of the most recent preceding Originator-ID, Originator-Certificate:, or Recipient-ID field. Normally, a Key-Info: field immediately follows its associated predecessor field 👑. The argument(s) of Key-Info: depend on whether symmetric or asymmetric key management is used for a particular recipient.
4.6.4.2.1 Symmetric Key Management 🗝️
When symmetric key management is employed for a given recipient, the Key-Info: encapsulated header field carries four items, separated by commas:
- an IK Use Indicator
- a MIC Algorithm Indicator
- a DEK
- a MIC
The IK Use Indicator names the algorithm and mode in which the identified IK was used for DEK and MIC encryption for that recipient. The MIC Algorithm Indicator names the MIC computation algorithm used for that recipient. The DEK and MIC are symmetrically encrypted under the IK identified by a preceding Recipient-ID-Symmetric: field and/or prior Originator-ID-Symmetric: field 🌈.
Appropriate symmetric encryption algorithms, modes and identifiers, MIC computation algorithms and identifiers, and encrypted DEK and MIC formats are defined in RFC 1423 🎀.
4.6.4.2.2 Asymmetric Key Management 🌙
When asymmetric key management is employed for a given recipient, the Key-Info: field carries two quantities, separated by a comma. The first argument is an IK Use Indicator that names the algorithm and mode in which the DEK is asymmetrically encrypted. The second argument is a DEK, asymmetrically encrypted under the recipient's public component 💅.
Appropriate asymmetric encryption algorithms and identifiers, and encrypted DEK formats, are defined in RFC 1423 📖.
5. Key Management 🔐
Several cryptographic constructs are involved in supporting the PEM message processing procedure, and a set of fundamental elements is assumed 🧩. Data Encrypting Keys (DEKs) are used to encrypt message text and, for some MIC computation algorithms, take part in the message integrity check (MIC) computation process. Interchange Keys (IKs) are used to encrypt DEKs and MICs for transmission with messages 💌. In a certificate-based asymmetric key management architecture, certificates provide entities' public components and other information in a way that is securely bound by a central authority 🏛️. The rest of this section gives more detail on these constructs 🦋.
5.1 Data Encrypting Keys (DEKs) 🗝️
Data Encrypting Keys (DEKs) are used to encrypt message text and, with some MIC computation algorithms, to compute message integrity check quantities (MICs). In the asymmetric key management case, they are also used to encrypt signed MICs in ENCRYPTED PEM messages. It is strongly recommended that DEKs be generated and used on a one-time, per-message basis 🔥. A transmitted message incorporates a representation of the DEK encrypted under an appropriate interchange key (IK) for each of the named recipients ✨.
DEK generation can be performed either centrally by key distribution centers (KDCs) or by endpoint systems. Dedicated KDC systems may be able to implement stronger algorithms for random DEK generation than endpoint systems can support. On the other hand, decentralization lets endpoints be relatively self-sufficient, which reduces the level of trust placed in components other than those of a message's originator and recipient 🫶. Decentralized DEK generation at endpoints also reduces how often originators have to make real-time queries of (potentially unique) servers in order to send mail, which boosts communications availability 🚀.
When symmetric key management is used, one advantage of centralized KDC-based generation is that DEKs can be returned to endpoints already encrypted under the IKs of message recipients, rather than providing the IKs to the originators. This reduces IK exposure and simplifies endpoint key management requirements 🙌. This approach has less value if asymmetric cryptography is used for key management, since per-recipient public IK components are assumed to be generally available and per-originator private IK components need not necessarily be shared with a KDC 💜.
5.2 Interchange Keys (IKs) 🔑
okay so Interchange Key (IK) components are what get used to encrypt DEKs and MICs 💅 IK granularity is usually pairwise per-user, except for mail going to address lists with multiple users 🎀 For two principals to have a useful PEM exchange using conventional cryptography, they must first possess common IK components (if symmetric key management is used) or complementary IK components (if asymmetric key management is used) ✨ With symmetric cryptography, the IK is a single component that encrypts both DEKs and MICs 🦋 With asymmetric cryptography, the recipient's public component is the IK used to encrypt DEKs (a transformation only the recipient with the matching private component can undo 🔒), and the originator's private component encrypts MICs (a transformation every recipient can undo, since the originator's certificate gives them the public component they need for MIC validation 🌸)
This RFC doesn't say how interchange keys get to the right people 🧚 The means could be centralized (like key management servers) or decentralized (like pairwise agreement and direct distribution among users). Either way, every IK component has a responsible Issuing Authority (IA) 👑 When certificate-based asymmetric key management, as discussed in RFC [1422, is used, the IA job is done by a Certification Authority (CA) 💜
When an IA generates and distributes an IK component, control information comes along to say how it should be used ✨ To pick the right IK(s) for message encryption, an originator has to keep track of which IK components go with which recipients. Expiration date info also has to be kept, so cached entries can get invalidated and replaced when needed 🙈
Since one message can carry multiple IK components for multiple recipients, each recipient's UA must be able to figure out which IK component is theirs 💖 And if the recipient's database doesn't have the matching IK when the message shows up, they must be able to identify the IK they need and its IA 🫶 Different messages between the same communicants can use different IKs. Like, A to B uses the IKs tied to A and B individually, but A sending to a mailing list that B is on uses an IK shared by all the list members 💅
When a PEM message is sent, it has to indicate which IK components were used for DEK and MIC encryption 😭 The Originator-ID and Recipient-ID encapsulated header fields provide (some or all of) this data:
- Identification of the relevant Issuing Authority (IA subfield)
- Identification of an entity that a particular IK component is associated with (Entity Identifier or EI subfield)
- Version/Expiration subfield
In the asymmetric case, everything about an originator can be pulled from the certificate in an Originator-Certificate: field 🌈 To avoid redundancy, no Originator-ID-Asymmetric: field gets included when a matching Originator-Certificate: is there.
A comma (,) separates the subfields in an Originator-ID or Recipient-ID 🍓 The IA, EI, and version/expiration subfields come from a restricted character set, defined by this BNF (using the notation from RFC 822, Sections 2 and 3.3):
IKsubfld := 1*ia-char
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"Here's an example Recipient-ID field for the symmetric case 🧁
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,2This means IA "ptf-kmc" issued an IK component for messages sent to "linn@zendia.enet.dec.com", and the IA gave it the number 2 as a version indicator 🦋
And here's one for the asymmetric case 🫧
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66This one has the printably encoded BER representation of a certificate's issuer distinguished name, plus the certificate serial number 66 that the issuer assigned 💜
5.2.1 Subfield Definitions 🧩
These subsections define the subfields of Originator-ID and Recipient-ID fields, so let's go 🏃♀️
5.2.1.1 Entity Identifier Subfield 🪪
An entity identifier (used only in Originator-ID-Symmetric: and Recipient-ID-Symmetric: fields) is built as an IKsubfld 💅 It's more restrictive, though, and takes this form:
<user>@<domain-qualified-host>For universal interoperability, you need a universal form for the naming info ✨ For installations that transform local host names before they go out to the broader Internet, it's strongly recommended to use the host name as the Internet sees it 🌐
5.2.1.2 Issuing Authority Subfield 🏛️
An IA identifier subfield is built as an IKsubfld. This RFC doesn't define what this subfield contains for the symmetric key management case 🙈 Any prospective IAs that will issue symmetric keys for use with this RFC have to coordinate how they assign IA identifiers (centralized or hierarchic), so the identifiers stay unique 🫶
For the asymmetric key management case, the IA identifier subfield is formed from the ASN.1 BER representation of the distinguished name of the issuing organization or organizational unit 💖 The distinguished encoding rules from Clause 8.7 of Recommendation X.509 ("X.509 DER") are to be used to generate this representation. The encoded binary result gets represented for inclusion in a transmitted header using the procedure in Section 4.3.2.4 of this RFC 🎀
5.2.1.3 Version/Expiration Subfield ⏳
A version/expiration subfield is built as an IKsubfld. For the symmetric key management case, the format of this subfield is allowed to vary between IAs, but it has to meet some functional constraints 🧠 An IA's version/expiration subfields must be enough to tell apart the IK components that IA issued for a given identified entity. A monotonically increasing number is enough to do that. A timestamp also lets you set an expiration time or date for an IK component 🕰️
For the asymmetric key management case, the version/expiration subfield's value is the hexadecimal serial number of the certificate being used with the originator or recipient named in the Originator-ID-Asymmetric: or Recipient-ID-Asymmetric: field where the subfield appears 🌸
5.2.2 IK Cryptoperiod Issues 🗓️
An IK component's cryptoperiod is shaped partly by a tradeoff between key management overhead and how fast revocation can happen 🎢 It would be bad to permanently delete an IK component before a message encrypted with it has been received, since the message would then be permanently unreadable 😭 You'd need access to an expired IK component, for example, to process mail received by a user (or system) that's been inactive for a long time 📬 So that very old IK components can be deleted, a recipient who wants encrypted local long-term storage should re-encrypt the DEK used for message text encryption under a locally maintained IK. That's better than relying on IAs to keep old IK components around forever 🔐
6. User Naming 🪪
Unique naming of electronic mail users is a big deal, because you need it to pick the right keys 🔑 It's been studied a lot and people are still studying it 🤓 In the symmetric case, IK components are identified in PEM headers with mailbox specifiers in the traditional Internet-wide form ("user@domain-qualified-host") 💌 This only works if users (or their PEM implementations) can work out the universal-form names for PEM originators and recipients. If a PEM implementation runs somewhere that uses local addresses different from the universal form, translations must be done to map between the universal form and that local form 🔄
Using user identifiers that aren't tied to the hosts where the users' mailboxes live is super general and valuable 🌈 X.500 distinguished names, which show up in the certificates of the recommended key management infrastructure defined in RFC 1422, give a basis for this kind of user identification 💜 As directory services get more common, they'll let originators search for recipients using a wider set of attributes than mailbox specifiers alone 🔍 Future work is expected to integrate with directory services, especially the mechanisms and naming schema of the Internet OSI directory pilot activity ✨
7. Example User Interface and Implementation 🎀
Okay bestie, so to put everything we've talked about into context, this section walks through a hypothetical prototype 💅 It's a standalone program that a user runs by hand, and it sits above the existing UA sublayer 🦋 On UNIX (and maybe other systems too), you can invoke it as a "filter" inside an email UA or a text editor, which makes the whole process way less of a chore ✨ The best part is that it works with a whole range of UA programs instead of being tied to just one. Main character energy 👑
Here's the flow. When you want to add privacy enhancements to an outgoing message, you write the text and run the standalone program, which spits out output that's ready to send through the UA 💌 When you receive a PEM message, the UA hands it over still encrypted, and then the standalone program decrypts it and does the rest of the processing 🔐
In this prototype, a cache of IK components lives in a local file, and entries get managed by hand based on info from originators and recipients 🗂️ For asymmetric key management, you collect certificates for your PEM correspondents. You can get them ahead of time, along with directory retrieval, or pull them straight out of the "Originator-Certificate:" fields of messages you've received 🫶
The IK/certificate cache is basically a simple database indexed by mailbox names 🍓 Transmitted messages pick IK components based on the originator's identity and the recipient names, and the matching Originator-ID, "Originator-Certificate:", and Recipient-ID fields go into the encapsulated header. When a message comes in, those same fields are used to look things up in the database, which gives back the right IK component entries ✨ DEKs and cryptographic parameters (like IVs) are generated on the fly inside the program 🌸
Options and destination addresses come from command line arguments 💻 Specifying destination addresses for the privacy enhancement program is a separate job from specifying those same addresses to the UA for the MTS, and that's on purpose 🙈 Why? Because the local form of an address that you give a UA is often different from the Internet global form used in "Originator-ID-Symmetric:" and "Recipient-ID-Symmetric:" fields. So yeah, two different jobs, no mix-ups 🧚
8. Minimum Essential Requirements 💖
This section is the checklist of capabilities an implementation must provide to be fully conformant with this RFC 📋
RFC 1422 specifies asymmetric, certificate-based key management procedures that support the message processing procedures defined in this document. PEM implementations are strongly encouraged to support these key management procedures 🔑 Implementations that do support them also have to be able to display the names of originator and recipient PEM users in the X.500 DN form, as authenticated by the procedures of RFC 1422 🪪
The message processing procedures defined here can also be used with symmetric key management techniques. The catch? No RFCs analogous to RFC 1422 exist yet to describe suitable symmetric key management procedures in similar detail 🥲 A complete PEM implementation has to support at least one of these asymmetric and/or symmetric key management modes ✅
A full PEM implementation is expected to be able to send and receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive CRL messages 📬 Some level of support for generating and processing nested and annotated PEM messages (for forwarding) is also expected, and an implementation should be able to reduce ENCRYPTED messages to MIC-ONLY or MIC-CLEAR when forwarding them 🔁 Fully-conformant implementations must be able to emit Certificate and Issuer-Certificate fields, and to include a Key-Info field corresponding to the originator. That said, users or configurers of PEM implementations may be allowed to turn those features off 🎚️
9. Descriptive Grammar 🎀
This section gives you the grammar for building a PEM message. Think of it as the blueprint 🧾
; PEM BNF representation, using RFC 822 notation.
; imports field meta-syntax (field, field-name, field-body,
; field-body-contents) from RFC-822, sec. 3.2
; imports DIGIT, ALPHA, CRLF, text from RFC-822
; Note: algorithm and mode specifiers are officially defined
; in RFC 1423
<pemmsg> ::= <preeb>
<pemhdr>
[CRLF <pemtext>] ; absent for CRL message
<posteb>
<preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF
<posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>
<pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages
/ *(<text> CRLF) ; for MIC-CLEAR
<pemhdr> ::= <normalhdr> / <crlhdr>
<normalhdr> ::= <proctype>
<contentdomain>
[<dekinfo>] ; needed if ENCRYPTED
(1*(<origflds> *<recipflds>)) ; symmetric case --
; recipflds included for all proc types
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
; recipflds included for ENCRYPTED proc type
<crlhdr> ::= <proctype>
1*(<crl> [<cert>] *(<issuercert>))
<asymmorig> ::= <origid-asymm> / <cert>
<origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
<micinfo> ; asymmetric
/ <origid-symm> [<keyinfo>] ; symmetric
<recipflds> ::= <recipid> <keyinfo>
; definitions for PEM header fields
<proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF
<contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
<symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
<asymmid> ::= <IKsubfld> "," <IKsubfld>
<origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
<origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
<recipid> ::= <recipid-asymm> / <recipid-symm>
<recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<cert> ::= "Originator-Certificate" ":" <encbin> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
<symencdek> "," <symencmic> CRLF ; symmetric case
/ "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric case
<crl> ::= "CRL" ":" <encbin> CRLF
<pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL"
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
<encbingrp> ::= 4*4<encbinchar>
<encbin> ::= 1*<encbingrp>
<encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
<IKsubfld> ::= 1*<ia-char>
; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
; fields can be delimited with commas (not colons) like all other
; fields
<ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
; This specification defines one value ("RFC822") for
; <contentdescrip>: other values may be defined in future in
; separate or successor documents
;
<contentdescrip> ::= "RFC822"
; The following items are defined in RFC 1423
; <dekalgid>
; <dekparameters>
; <micalgid>
; <ikalgid>
; <asymsignmic>
; <symencdek>
; <symencmic>
; <asymencdek>NOTES 📝
[1] Key generation for MIC computation and message text encryption can be done either by the sending host or by a centralized server 🖥️ This RFC doesn't constrain that choice. Section 5.1 covers the possible advantages of a centralized server approach when symmetric key management is used.
[2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[3] This transformation should only happen at an SMTP endpoint, not at an intervening relay 🚫, but it may take place at a gateway system that links the SMTP realm with other environments 🌉
[4] A canonicalization procedure similar to SMTP's was chosen because its functions are widely used and implemented across the Internet mail community. It was not picked for SMTP interoperability with this intermediate result 💭
[5] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[6] Rose, M. T. and Stefferud, E. A., "Proposed Standard for Message Encapsulation", RFC 934, January 1985.
[7] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework".
[8] Throughout this RFC we've adopted the terms "private component" and "public component" 🔐 They refer to the quantities that are kept secret and made publicly available in asymmetric cryptosystems, respectively. This naming avoids confusion with "secret key," which can mean either of those quantities or a key in a symmetric cryptosystem 🫶
Patent Statement ✨
okay bestie, this one is about the legal stuff 🫶. This version of Privacy Enhanced Mail (PEM) leans on patented public key encryption tech for authentication and encryption 🔐. The Internet Standards Process, as laid out in RFC 1310, says the patent holder has to put a written statement on file promising that a license will be available to applicants on reasonable terms and conditions before a spec gets approved as a Proposed, Draft or Internet Standard. So that's the vibe check 💅.
The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University gave Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, plus all of their matching foreign patents:
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414PKP says these patents cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal 🧠. Wild, right? 😭
Public Key Partners gave the Internet Society written assurance that parties will be able to get the right to use the technology covered by these patents, under reasonable, nondiscriminatory terms 🎀. That assurance is documented in RFC 1170, titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, can be obtained from the Internet Assigned Number Authority (IANA) 📜.
Now the disclaimer era 🙈. The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, and no position on whether the terms of the assurance are appropriate ✨. The Internet Society and the other groups above haven't made any determination about any other intellectual property rights that might apply to practicing this standard 🌸. Any further thinking about these matters is the user's own responsibility, so go do your homework, bestie 📚💜.
Security Considerations 🔐
okay this is the big one and it is literally giving everything. This entire document is about security 😭🔥. Every single part of it, from the message formats to the key management to the user naming, exists to protect the privacy and authenticity of mail. So treat every section as load-bearing and don't skip past any of it 💀.
Author's Address 💌
And finally, the person behind the words ✨:
John Linn
EMail: 104-8456@mcimail.comThat's the whole spec, babe 🦋👑. Slay, and go build something secure 💖🫶.
📦 where this page comes from
- ietf: rfc1421 1993-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms