latest news: Sept 20: more domain blacklists have been added
rfc1421 RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures
Network Working Group J. Linn
Request for Comments: 1421 IAB IRTF PSRG, IETF PEM WG
Obsoletes: 1113 February 1993
Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Acknowledgements
This document is the outgrowth of a series of meetings of the Privacy
and Security Research Group (PSRG) of the IRTF and the PEM Working
Group of the IETF. I would like to thank the members of the PSRG and
the IETF PEM WG, as well as all participants in discussions on the
"pem-dev@tis.com" mailing list, for their contributions to this
document.
1. Executive Summary
This document defines message encryption and authentication
procedures, in order to provide privacy-enhanced mail (PEM) services
for electronic mail transfer in the Internet. It is intended to
become one member of a related set of four RFCs. The procedures
defined in the current document are intended to be compatible with a
wide range of key management approaches, including both symmetric
(secret-key) and asymmetric (public-key) approaches for encryption of
data encrypting keys. Use of symmetric cryptography for message text
encryption and/or integrity check computation is anticipated. RFC
1422 specifies supporting key management mechanisms based on the use
of public-key certificates. RFC 1423 specifies algorithms, modes,
and associated identifiers relevant to the current RFC and to RFC
1422. RFC 1424 provides details of paper and electronic formats and
procedures for the key management infrastructure being established in
support of these services.
Privacy enhancement services (confidentiality, authentication,
message integrity assurance, and non-repudiation of origin) are
offered through the use of end-to-end cryptography between originator
and recipient processes at or above the User Agent level. No special
processing requirements are imposed on the Message Transfer System at
Linn [Page 1]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
endpoints or at intermediate relay sites. This approach allows
privacy enhancement facilities to be incorporated selectively on a
site-by-site or user-by-user basis without impact on other Internet
entities. Interoperability among heterogeneous components and mail
transport facilities is supported.
The current specification's scope is confined to PEM processing
procedures for the RFC-822 textual mail environment, and defines the
Content-Domain indicator value "RFC822" to signify this usage.
Follow-on work in integration of PEM capabilities with other
messaging environments (e.g., MIME) is anticipated and will be
addressed in separate and/or successor documents, at which point
additional Content-Domain indicator values will be defined.
2. Terminology
For descriptive purposes, this RFC uses some terms defined in the OSI
X.400 Message Handling System Model per the CCITT Recommendations.
This section replicates a portion of (1984) X.400's Section 2.2.1,
"Description of the MHS Model: Overview" in order to make the
terminology clear to readers who may not be familiar with the OSI MHS
Model.
In the [MHS] model, a user is a person or a computer application. A
user is referred to as either an originator (when sending a message)
or a recipient (when receiving one). MH Service elements define the
set of message types and the capabilities that enable an originator
to transfer messages of those types to one or more recipients.
An originator prepares messages with the assistance of his or her
User Agent (UA). A UA is an application process that interacts with
the Message Transfer System (MTS) to submit messages. The MTS
delivers to one or more recipient UAs the messages submitted to it.
Functions performed solely by the UA and not standardized as part of
the MH Service elements are called local UA functions.
The MTS is composed of a number of Message Transfer Agents (MTAs).
Operating together, the MTAs relay messages and deliver them to the
intended recipient UAs, which then make the messages available to the
intended recipients.
The collection of UAs and MTAs is called the Message Handling System
(MHS). The MHS and all of its users are collectively referred to as
the Message Handling Environment.
Linn [Page 2]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
3. Services, Constraints, and Implications
This RFC defines mechanisms to enhance privacy for electronic mail
transferred in the Internet. The facilities discussed in this RFC
provide privacy enhancement services on an end-to-end basis between
originator and recipient processes residing at the UA level or above.
No privacy enhancements are offered for message fields which are
added or transformed by intermediate relay points between PEM
processing components.
If an originator elects to perform PEM processing on an outbound
message, all PEM-provided security services are applied to the PEM
message's body in its entirety; selective application to portions of
a PEM message is not supported. Authentication, integrity, and (when
asymmetric key management is employed) non-repudiation of origin
services are applied to all PEM messages; confidentiality services
are optionally selectable.
In keeping with the Internet's heterogeneous constituencies and usage
modes, the measures defined here are applicable to a broad range of
Internet hosts and usage paradigms. In particular, it is worth
noting the following attributes:
1. The mechanisms defined in this RFC are not restricted to a
particular host or operating system, but rather allow
interoperability among a broad range of systems. All
privacy enhancements are implemented at the application
layer, and are not dependent on any privacy features at
lower protocol layers.
2. The defined mechanisms are compatible with non-enhanced
Internet components. Privacy enhancements are implemented
in an end-to-end fashion which does not impact mail
processing by intermediate relay hosts which do not
incorporate privacy enhancement facilities. It is
necessary, however, for a message's originator to be
cognizant of whether a message's intended recipient
implements privacy enhancements, in order that encoding and
possible encryption will not be performed on a message whose
destination is not equipped to perform corresponding inverse
transformations. (Section 4.6.1.1.3 of this RFC describes a
PEM message type ("MIC-CLEAR") which represents a signed,
unencrypted PEM message in a form readable without PEM
processing capabilities yet validatable by PEM-equipped
recipients.)
3. The defined mechanisms are compatible with a range of mail
transport facilities (MTAs). Within the Internet,
Linn [Page 3]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
electronic mail transport is effected by a variety of SMTP
[2] implementations. Certain sites, accessible via SMTP,
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must be
able to operate across the SMTP realm; it is desirable that
they also be compatible with protection of electronic mail
sent between the SMTP environment and other connected
environments.
4. The defined mechanisms are compatible with a broad range of
electronic mail user agents (UAs). A large variety of
electronic mail user agent programs, with a corresponding
broad range of user interface paradigms, is used in the
Internet. In order that electronic mail privacy
enhancements be available to the broadest possible user
community, selected mechanisms should be usable with the
widest possible variety of existing UA programs. For
purposes of pilot implementation, it is desirable that
privacy enhancement processing be incorporable into a
separate program, applicable to a range of UAs, rather than
requiring internal modifications to each UA with which PEM
services are to be provided.
5. The defined mechanisms allow electronic mail privacy
enhancement processing to be performed on personal computers
(PCs) separate from the systems on which UA functions are
implemented. Given the expanding use of PCs and the limited
degree of trust which can be placed in UA implementations on
many multi-user systems, this attribute can allow many users
to process PEM with a higher assurance level than a strictly
UA-integrated approach would allow.
6. The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists (distribution
lists, in ISO parlance).
7. The mechanisms defined within this RFC are compatible with a
variety of supporting key management approaches, including
(but not limited to) manual pre-distribution, centralized
key distribution based on symmetric cryptography, and the
use of public-key certificates per RFC 1422. Different
key management mechanisms may be used for different
recipients of a multicast message. For two PEM
implementations to interoperate, they must share a common
key management mechanism; support for the mechanism defined
in RFC 1422 is strongly encouraged.
Linn [Page 4]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
In order to achieve applicability to the broadest possible range of
Internet hosts and mail systems, and to facilitate pilot
implementation and testing without the need for prior and pervasive
modifications throughout the Internet, the following design
principles were applied in selecting the set of features specified in
this RFC:
1. This RFC's measures are restricted to implementation at
endpoints and are amenable to integration with existing
Internet mail protocols at the user agent (UA) level or
above, rather than necessitating modifications to existing
mail protocols or integration into the message transport
system (e.g., SMTP servers).
2. The set of supported measures enhances rather than restricts
user capabilities. Trusted implementations, incorporating
integrity features protecting software from subversion by
local users, cannot be assumed in general. No mechanisms
are assumed to prevent users from sending, at their
discretion, messages to which no PEM processing has been
applied. In the absence of such features, it appears more
feasible to provide facilities which enhance user services
(e.g., by protecting and authenticating inter-user traffic)
than to enforce restrictions (e.g., inter-user access
control) on user actions.
3. The set of supported measures focuses on a set of functional
capabilities selected to provide significant and tangible
benefits to a broad user community. By concentrating on the
most critical set of services, we aim to maximize the added
privacy value that can be provided with a modest level of
implementation effort.
Based on these principles, the following facilities are provided:
1. disclosure protection,
2. originator authenticity,
3. message integrity measures, and
4. (if asymmetric key management is used) non-repudiation of
origin,
but the following privacy-relevant concerns are not addressed:
1. access control,
Linn [Page 5]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
2. traffic flow confidentiality,
3. address list accuracy,
4. routing control,
5. issues relating to the casual serial reuse of PCs by
multiple users,
6. assurance of message receipt and non-deniability of receipt,
7. automatic association of acknowledgments with the messages
to which they refer, and
8. message duplicate detection, replay prevention, or other
stream-oriented services
4. Processing of Messages
4.1 Message Processing Overview
This subsection provides a high-level overview of the components and
processing steps involved in electronic mail privacy enhancement
processing. Subsequent subsections will define the procedures in
more detail.
4.1.1 Types of Keys
A two-level keying hierarchy is used to support PEM transmission:
1. Data Encrypting Keys (DEKs) are used for encryption of
message text and (with certain choices among a set of
alternative algorithms) for computation of message integrity
check (MIC) quantities. In the asymmetric key management
environment, DEKs are also used to encrypt the signed
representations of MICs in PEM messages to which
confidentiality has been applied. DEKs are generated
individually for each transmitted message; no
predistribution of DEKs is needed to support PEM
transmission.
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission within messages. Ordinarily, the same IK will
be used for all messages sent from a given originator to a
given recipient over a period of time. Each transmitted
message includes a representation of the DEK(s) used for
message encryption and/or MIC computation, encrypted under
an individual IK per named recipient. The representation is
Linn [Page 6]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
associated with Originator-ID and Recipient-ID fields
(defined in different forms so as to distinguish symmetric
from asymmetric cases), which allow each individual
recipient to identify the IK used to encrypt DEKs and/or
MICs for that recipient's use. Given an appropriate IK, a
recipient can decrypt the corresponding transmitted DEK
representation, yielding the DEK required for message text
decryption and/or MIC validation. The definition of an IK
differs depending on whether symmetric or asymmetric
cryptography is used for DEK encryption:
2a. When symmetric cryptography is used for DEK
encryption, an IK is a single symmetric key shared
between an originator and a recipient. In this
case, the same IK is used to encrypt MICs as well
as DEKs for transmission. Version/expiration
information and IA identification associated with
the originator and with the recipient must be
concatenated in order to fully qualify a symmetric
IK.
2b. When asymmetric cryptography is used, the IK
component used for DEK encryption is the public
component [8] of the recipient. The IK component
used for MIC encryption is the private component of
the originator, and therefore only one encrypted
MIC representation need be included per message,
rather than one per recipient. Each of these IK
components can be fully qualified in a Recipient-ID
or Originator-ID field, respectively.
Alternatively, an originator's IK component may be
determined from a certificate carried in an
"Originator-Certificate:" field.
4.1.2 Processing Procedures
When PEM processing is to be performed on an outgoing message, a DEK
is generated [1] for use in message encryption and (if a chosen MIC
algorithm requires a key) a variant of the DEK is formed for use in
MIC computation. DEK generation can be omitted for the case of a
message where confidentiality is not to be applied, unless a chosen
MIC computation algorithm requires a DEK. Other parameters (e.g.,
Initialization Vectors (IVs)) as required by selected encryption
algorithms are also generated.
One or more Originator-ID and/or "Originator-Certificate:" fields are
included in a PEM message's encapsulated header to provide recipients
with an identification component for the IK(s) used for message
Linn [Page 7]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
processing. All of a message's Originator-ID and/or "Originator-
Certificate:" fields are assumed to correspond to the same principal;
the facility for inclusion of multiple such fields accomodates the
prospect that different keys, algorithms, and/or certification paths
may be required for processing by different recipients. When a
message includes recipients for which asymmetric key management is
employed as well as recipients for which symmetric key management is
employed, a separate Originator-ID or "Originator-Certificate:" field
precedes each set of recipients.
In the symmetric case, per-recipient IK components are applied for
each individually named recipient in preparation of ENCRYPTED, MIC-
ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID-
Symmetric:" field, interpreted in the context of the most recent
preceding "Originator-ID-Symmetric:" field, serves to identify each
IK. In the asymmetric case, per-recipient IK components are applied
only for ENCRYPTED messages, are independent of originator-oriented
header elements, and are identified by "Recipient-ID-Asymmetric:"
fields. Each Recipient-ID field is followed by a "Key-Info:" field,
which transfers the message's DEK encrypted under the IK appropriate
for the specified recipient.
When symmetric key management is used for a given recipient, the
"Key-Info:" field following the corresponding "Recipient-ID-
Symmetric:" field also transfers the message's computed MIC,
encrypted under the recipient's IK. When asymmetric key management is
used, a "MIC-Info:" field associated with an "Originator-ID-
Asymmetric:" or "Originator-Certificate:" field carries the message's
MIC, asymmetrically signed using the private component of the
originator. If the PEM message is of type ENCRYPTED (as defined in
Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is
symmetrically encrypted using the same DEK, algorithm, encryption
mode and other cryptographic parameters as used to encrypt the
message text, prior to inclusion in the "MIC-Info:" field.
4.1.2.1 Processing Steps
A four-phase transformation procedure is employed in order to
represent encrypted message text in a universally transmissible form
and to enable messages encrypted on one type of host computer to be
decrypted on a different type of host computer. A plaintext message
is accepted in local form, using the host's native character set and
line representation. The local form is converted to a canonical
message text representation, defined as equivalent to the inter-SMTP
representation of message text. This canonical representation forms
the input to the MIC computation step (applicable to ENCRYPTED, MIC-
ONLY, and MIC-CLEAR messages) and the encryption process (applicable
to ENCRYPTED messages only).
Linn [Page 8]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
For ENCRYPTED PEM messages, the canonical representation is padded as
required by the encryption algorithm, and this padded canonical
representation is encrypted. The encrypted text (for an ENCRYPTED
message) or the unpadded canonical form (for a MIC-ONLY message) is
then encoded into a printable form. The printable form is composed
of a restricted character set which is chosen to be universally
representable across sites, and which will not be disrupted by
processing within and between MTS entities. MIC-CLEAR PEM messages
omit the printable encoding step.
The output of the previous processing steps is combined with a set of
header fields carrying cryptographic control information. The
resulting PEM message is passed to the electronic mail system to be
included within the text portion of a transmitted message. There is
no requirement that a PEM message comprise the entirety of an MTS
message's text portion; this allows PEM-protected information to be
accompanied by (unprotected) annotations. It is also permissible for
multiple PEM messages (and associated unprotected text, outside the
PEM message boundaries) to be represented within the encapsulated
text of a higher-level PEM message. PEM message signatures are
forwardable when asymmetric key management is employed; an authorized
recipient of a PEM message with confidentiality applied can reduce
that message to a signed but unencrypted form for forwarding purposes
or can re-encrypt that message for subsequent transmission.
When a PEM message is received, the cryptographic control fields
within its encapsulated header provide the information required for
each authorized recipient to perform MIC validation and decryption of
the received message text. For ENCRYPTED and MIC-ONLY messages, the
printable encoding is converted to a bitstring. Encrypted portions
of the transmitted message are decrypted. The MIC is validated.
Then, the recipient PEM process converts the canonical representation
to its appropriate local form.
4.1.2.2 Error Cases
A variety of error cases may occur and be detected in the course of
processing a received PEM message. The specific actions to be taken
in response to such conditions are local matters, varying as
functions of user preferences and the type of user interface provided
by a particular PEM implementation, but certain general
recommendations are appropriate. Syntactically invalid PEM messages
should be flagged as such, preferably with collection of diagnostic
information to support debugging of incompatibilities or other
failures. RFC 1422 defines specific error processing requirements
relevant to the certificate-based key management mechanisms defined
therein.
Linn [Page 9]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Syntactically valid PEM messages which yield MIC failures raise
special concern, as they may result from attempted attacks or forged
messages. As such, it is unsuitable to display their contents to
recipient users without first indicating the fact that the contents'
authenticity and integrity cannot be guaranteed and then receiving
positive user confirmation of such a warning. MIC-CLEAR messages
(discussed in Section 4.6.1.1.3 of this RFC) raise special concerns,
as MIC failures on such messages may occur for a broader range of
benign causes than are applicable to other PEM message types.
4.2 Encryption Algorithms, Modes, and Parameters
For use in conjunction with this RFC, RFC 1423 defines the
appropriate algorithms, modes, and associated identifiers to be used
for encryption of message text with DEKs.
The mechanisms defined in this RFC incorporate facilities for
transmission of cryptographic parameters (e.g., pseudorandom
Initializing Vectors (IVs)) with PEM messages to which the
confidentiality service is applied, when required by symmetric
message encryption algorithms and modes specified in RFC 1423.
Certain operations require encryption of DEKs, MICs, and digital
signatures under an IK for purposes of transmission. A header
facility indicates the mode in which the IK is used for encryption. RFC 1423 specifies encryption algorithm and mode identifiers and
minimum essential support requirements for key encryption processing.
RFC 1422 specifies asymmetric, certificate-based key management
procedures based on CCITT Recommendation X.509 to support the message
processing procedures defined in this document. Support for the key
management approach defined in RFC 1422 is strongly recommended. The
message processing procedures can also be used with symmetric key
management, given prior distribution of suitable symmetric IKs, but
no current RFCs specify key distribution procedures for such IKs.
4.3 Privacy Enhancement Message Transformations
4.3.1 Constraints
An electronic mail encryption mechanism must be compatible with the
transparency constraints of its underlying electronic mail
facilities. These constraints are generally established based on
expected user requirements and on the characteristics of anticipated
endpoint and transport facilities. An encryption mechanism must also
be compatible with the local conventions of the computer systems
which it interconnects. Our approach uses a canonicalization step to
abstract out local conventions and a subsequent encoding step to
Linn [Page 10]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
conform to the characteristics of the underlying mail transport
medium (SMTP). The encoding conforms to SMTP constraints. Section
4.5 of RFC 821 [2] details SMTP's transparency constraints.
To prepare a message for SMTP transmission, the following
requirements must be met:
1. All characters must be members of the 7-bit ASCII character
set.
2. Text lines, delimited by the character pair <CR><LF>, must
be no more than 1000 characters long.
3. Since the string <CR><LF>.<CR><LF> indicates the end of a
message, it must not occur in text prior to the end of a
message.
Although SMTP specifies a standard representation for line delimiters
(ASCII <CR><LF>), numerous systems in the Internet use a different
native representation to delimit lines. For example, the <CR><LF>
sequences delimiting lines in mail inbound to UNIX systems are
transformed to single <LF>s as mail is written into local mailbox
files. Lines in mail incoming to record-oriented systems (such as
VAX VMS) may be converted to appropriate records by the destination
SMTP server [3]. As a result, if the encryption process generated
<CR>s or <LF>s, those characters might not be accessible to a
recipient UA program at a destination which uses different line
delimiting conventions. It is also possible that conversion between
tabs and spaces may be performed in the course of mapping between
inter-SMTP and local format; this is a matter of local option. If
such transformations changed the form of transmitted ciphertext,
decryption would fail to regenerate the transmitted plaintext, and a
transmitted MIC would fail to compare with that computed at the
destination.
The conversion performed by an SMTP server at a system with EBCDIC as
a native character set has even more severe impact, since the
conversion from EBCDIC into ASCII is an information-losing
transformation. In principle, the transformation function mapping
between inter-SMTP canonical ASCII message representation and local
format could be moved from the SMTP server up to the UA, given a
means to direct that the SMTP server should no longer perform that
transformation. This approach has a major disadvantage: internal
file (e.g., mailbox) formats would be incompatible with the native
forms used on the systems where they reside. Further, it would
require modification to SMTP servers, as mail would be passed to SMTP
in a different representation than it is passed at present.
Linn [Page 11]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.3.2 Approach
Our approach to supporting PEM across an environment in which
intermediate conversions may occur defines an encoding for mail which
is uniformly representable across the set of PEM UAs regardless of
their systems' native character sets. This encoded form is used (for
specified PEM message types) to represent mail text in transit from
originator to recipient, but the encoding is not applied to enclosing
MTS headers or to encapsulated headers inserted to carry control
information between PEM UAs. The encoding's characteristics are such
that the transformations anticipated between originator and recipient
UAs will not prevent an encoded message from being decoded properly
at its destination.
Four transformation steps, described in the following four
subsections, apply to outbound PEM message processing:
4.3.2.1 Step 1: Local Form
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
MIC-CLEAR. The message text is created in the system's native
character set, with lines delimited in accordance with local
convention.
4.3.2.2 Step 2: Canonical Form
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
MIC-CLEAR. The message text is converted to a universal canonical
form, similar to the inter-SMTP representation [4] as defined in RFC
821 [2] and RFC 822 [5]. The procedures performed in order to
accomplish this conversion are dependent on the characteristics of
the local form and so are not specified in this RFC.
PEM canonicalization assures that the message text is represented
with the ASCII character set and "<CR><LF>" line delimiters, but does
not perform the dot-stuffing transformation discussed in RFC 821,
Section 4.5.2. Since a message is converted to a standard character
set and representation before encryption, a transferred PEM message
can be decrypted and its MIC can be validated at any type of
destination host computer. Decryption and MIC validation is
performed before any conversions which may be necessary to transform
the message into a destination-specific local form.
4.3.2.3 Step 3: Authentication and Encryption
Authentication processing is applicable to PEM message types
ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to
the selected MIC computation algorithm in order to compute an
Linn [Page 12]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
integrity check quantity for the message. No padding is added to the
canonical form before submission to the MIC computation algorithm,
although certain MIC algorithms will apply their own padding in the
course of computing a MIC.
Encryption processing is applicable only to PEM message type
ENCRYPTED. RFC 1423 defines the padding technique used to support
encryption of the canonically-encoded message text.
4.3.2.4 Step 4: Printable Encoding
This printable encoding step is applicable to PEM message types
ENCRYPTED and MIC-ONLY. The same processing is also employed in
representation of certain specifically identified PEM encapsulated
header field quantities as cited in Section 4.6. Proceeding from
left to right, the bit string resulting from step 3 is encoded into
characters which are universally representable at all sites, though
not necessarily with the same bit patterns (e.g., although the
character "E" is represented in an ASCII-based system as hexadecimal
45 and as hexadecimal C5 in an EBCDIC-based system, the local
significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used, enabling
6 bits to be represented per printable character. (The proposed
subset of characters is represented identically in IA5 and ASCII.)
The character "=" signifies a special processing function used for
padding within the printable encoding procedure.
To represent the encapsulated text of a PEM message, the encoding
function's output is delimited into text lines (using local
conventions), with each line except the last containing exactly 64
printable characters and the final line containing 64 or fewer
printable characters. (This line length is easily printable and is
guaranteed to satisfy SMTP's 1000-character transmitted line length
limit.) This folding requirement does not apply when the encoding
procedure is used to represent PEM header field quantities; Section
4.6 discusses folding of PEM encapsulated header fields.
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right across
a 24-bit input group extracted from the output of step 3, each 6-bit
group is used as an index into an array of 64 printable characters.
The character referenced by the index is placed in the output string.
These characters, identified in Table 1, are selected so as to be
universally representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
Linn [Page 13]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Special processing is performed if fewer than 24 bits are available
in an input group at the end of a message. A full encoding quantum
is always completed at the end of a message. When fewer than 24
input bits are available in an input group, zero bits are added (on
the right) to form an integral number of 6-bit groups. Output
character positions which are not required to represent actual input
data are set to the character "=". Since all canonically encoded
output is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be three
characters followed by one "=" padding character.
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Printable Encoding Characters
Table 1
4.3.2.5 Summary of Transformations
In summary, the outbound message is subjected to the following
composition of transformations (or, for some PEM message types, a
subset thereof):
Note that the local form and the functions to transform messages to
and from canonical form may vary between the originator and recipient
systems without loss of information.
4.4 Encapsulation Mechanism
The encapsulation techniques defined in RFC-934 [6] are adopted for
encapsulation of PEM messages within separate enclosing MTS messages
carrying associated MTS headers. This approach offers a number of
advantages relative to a flat approach in which certain fields within
a single header are encrypted and/or carry cryptographic control
information. As far as the MTS is concerned, the entirety of a PEM
message will reside in an MTS message's text portion, not the MTS
message's header portion. Encapsulation provides generality and
segregates fields with user-to-user significance from those
transformed in transit. All fields inserted in the course of
encryption/authentication processing are placed in the encapsulated
header. This facilitates compatibility with mail handling programs
which accept only text, not header fields, from input files or from
other programs.
The encapsulation techniques defined in RFC-934 are consistent with
existing Internet mail forwarding and bursting mechanisms. These
techniques are designed so that they may be used in a nested manner.
The encapsulation techniques may be used to encapsulate one or more
PEM messages for forwarding to a third party, possibly in conjunction
with interspersed (non-PEM) text which serves to annotate the PEM
messages.
Two encapsulation boundaries (EB's) are defined for delimiting
encapsulated PEM messages and for distinguishing encapsulated PEM
messages from interspersed (non-PEM) text. The pre-EB is the string
"-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an
encapsulated PEM message follows. The post-EB is either (1) another
pre-EB indicating that another encapsulated PEM message follows, or
(2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating
that any text that immediately follows is non-PEM text. A special
point must be noted for the case of MIC-CLEAR messages, the text
portions of which may contain lines which begin with the "-"
character and which are therefore subject to special processing per RFC-934 forwarding procedures. When the string "- " must be
prepended to such a line in the course of a forwarding operation in
order to distinguish that line from an encapsulation boundary, MIC
Linn [Page 15]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
computation is to be performed prior to prepending the "- " string.
Figure 1 depicts the encapsulation of a single PEM message.
This RFC places no a priori limits on the depth to which such
encapsulation may be nested nor on the number of PEM messages which
may be grouped in this fashion at a single nesting level for
forwarding. A implementation compliant with this RFC must not
preclude a user from submitting or receiving PEM messages which
exploit this encapsulation capability. However, no specific
requirements are levied upon implementations with regard to how this
capability is made available to the user. Thus, for example, a
compliant PEM implementation is not required to automatically detect
and process encapsulated PEM messages.
In using this encapsulation facility, it is important to note that it
is inappropriate to forward directly to a third party a message that
is ENCRYPTED because recipients of such a message would not have
access to the DEK required to decrypt the message. Instead, the user
forwarding the message must transform the ENCRYPTED message into a
MIC-ONLY or MIC-CLEAR form prior to forwarding. Thus, in order to
comply with this RFC, a PEM implementation must provide a facility to
enable a user to perform this transformation, while preserving the
MIC associated with the original message.
If a user wishes PEM-provided confidentiality protection for
transmitted information, such information must occur in the
encapsulated text of an ENCRYPTED PEM message, not in the enclosing
MTS header or PEM encapsulated header. If a user wishes to avoid
Linn [Page 16]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Encapsulated 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.)
disclosing the actual subject of a message to unintended parties, it
is suggested that the enclosing MTS header contain a "Subject:" field
indicating that "Encrypted Mail Follows".
If an integrity-protected representation of information which occurs
within an enclosing header (not necessarily in the same format as
that in which it occurs within that header) is desired, that data can
be included within the encapsulated text portion in addition to its
inclusion in the enclosing MTS header. For example, an originator
wishing to provide recipients with a protected indication of a
message's position in a series of messages could include within the
encapsulated text a copy of a timestamp or message counter value
possessing end-to-end significance and extracted from an enclosing
MTS header field. (Note: mailbox specifiers as entered by end users
incorporate local conventions and are subject to modification at
intermediaries, so inclusion of such specifiers within encapsulated
text should not be regarded as a suitable alternative to the
authentication semantics defined in RFC 1422 and based on X.500
Distinguished Names.) The set of header information (if any) included
within the encapsulated text of messages is a local matter, and this
Linn [Page 17]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
RFC does not specify formatting conventions to distinguish replicated
header fields from other encapsulated text.
4.5 Mail for Mailing Lists
When mail is addressed to mailing lists, two different methods of
processing can be applicable: the IK-per-list method and the IK-per-
recipient method. Hybrid approaches are also possible, as in the
case of IK-per-list protection of a message on its path from an
originator to a PEM-equipped mailing list exploder, followed by IK-
per-recipient protection from the exploder to individual list
recipients.
If a message's originator is equipped to expand a destination mailing
list into its individual constituents and elects to do so (IK-per-
recipient), the message's DEK (and, in the symmetric key management
case, MIC) will be encrypted under each per-recipient IK and all such
encrypted representations will be incorporated into the transmitted
message. Note that per-recipient encryption is required only for the
relatively small DEK and MIC quantities carried in the "Key-Info:"
field, not for the message text which is, in general, much larger.
Although more IKs are involved in processing under the IK-per-
recipient method, the pairwise IKs can be individually revoked and
possession of one IK does not enable a successful masquerade of
another user on the list.
If a message's originator addresses a message to a list name or
alias, use of an IK associated with that name or alias as a entity
(IK-per-list), rather than resolution of the name or alias to its
constituent destinations, is implied. Such an IK must, therefore, be
available to all list members. Unfortunately, it implies an
undesirable level of exposure for the shared IK, and makes its
revocation difficult. Moreover, use of the IK-per-list method allows
any holder of the list's IK to masquerade as another originator to
the list for authentication purposes.
Pure IK-per-list key management in the asymmetric case (with a common
private key shared among multiple list members) is particularly
disadvantageous in the asymmetric environment, as it fails to
preserve the forwardable authentication and non-repudiation
characteristics which are provided for other messages in this
environment. Use of a hybrid approach with a PEM-capable exploder is
therefore particularly recommended for protection of mailing list
traffic when asymmetric key management is used; such an exploder
would reduce (per discussion in Section 4.4 of this RFC) incoming
ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding
them (perhaps re-encrypted under individual, per-recipient keys) to
list members.
Linn [Page 18]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.6 Summary of Encapsulated Header Fields
This section defines the syntax and semantics of the encapsulated
header fields to be added to messages in the course of privacy
enhancement processing.
The fields are presented in three groups. Normally, the groups will
appear in encapsulated headers in the order in which they are shown,
though not all fields in each group will appear in all messages. The
following figures show the appearance of small example encapsulated
messages. Figure 2 assumes the use of symmetric cryptography for key
management. Figure 3 illustrates an example encapsulated ENCRYPTED
message in which asymmetric key management is used.
Example Encapsulated Message (Symmetric Case)
Figure 2
Figure 4 illustrates an example encapsulated MIC-ONLY message in
which asymmetric key management is used; since no per-recipient keys
are involved in preparation of asymmetric-case MIC-ONLY messages,
this example should be processable for test purposes by arbitrary PEM
implementations.
Fully-qualified domain names (FQDNs) for hosts, appearing in the
mailbox names found in entity identifier subfields of "Originator-
ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in
a case-insensitive fashion. Unless specified to the contrary, other
field arguments (including the user name components of mailbox names)
Linn [Page 19]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
are to be processed in a case-sensitive fashion.
In most cases, numeric quantities are represented in header fields as
contiguous strings of hexadecimal digits, where each digit is
represented by a character from the ranges "0"-"9" or upper case
"A"-"F". Since public-key certificates and quantities encrypted
Linn [Page 20]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Example Encapsulated ENCRYPTED Message (Asymmetric Case)
Figure 3
Linn [Page 21]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
using asymmetric algorithms are large in size, use of a more space-
efficient encoding technique is appropriate for such quantities, and
the encoding mechanism defined in Section 4.3.2.4 of this RFC,
representing 6 bits per printed character, is adopted for this
purpose.
Encapsulated headers of PEM messages are folded using whitespace per RFC 822 header folding conventions; no PEM-specific conventions are
defined for encapsulated header folding. The example shown in Figure
4 shows (in its "MIC-Info:" field) an asymmetrically encrypted
quantity in its printably encoded representation, illustrating the
use of RFC 822 folding.
In contrast to the encapsulated header representations defined in RFC
1113 and its precursors, the field identifiers adopted in this RFC do
not begin with the prefix "X-" (for example, the field previously
denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes
are not to be emitted by implementations conformant to this RFC. To
simplify transition and interoperability with earlier
implementations, it is suggested that implementations based on this
RFC accept incoming encapsulated header fields carrying the "X-"
prefix and act on such fields as if the "X-" were not present.
Linn [Page 22]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
Example Encapsulated MIC-ONLY Message (Asymmetric Case)
Figure 4
4.6.1 Per-Message Encapsulated Header Fields
This group of encapsulated header fields contains fields which occur
no more than once in a PEM message, generally preceding all other
encapsulated header fields.
4.6.1.1 Proc-Type Field
The "Proc-Type:" encapsulated header field, required for all PEM
messages, identifies the type of processing performed on the
transmitted message. Only one "Proc-Type:" field occurs in a
message; the "Proc-Type:" field must be the first encapsulated header
Linn [Page 23]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
field in the message.
The "Proc-Type:" field has two subfields, separated by a comma. The
first subfield is a decimal number which is used to distinguish among
incompatible encapsulated header field interpretations which may
arise as changes are made to this standard. Messages processed
according to this RFC will carry the subfield value "4" to
distinguish them from messages processed in accordance with prior PEM
RFCs. The second subfield assumes one of a set of string values,
defined in the following subsections.
4.6.1.1.1 ENCRYPTED
The "ENCRYPTED" specifier signifies that confidentiality,
authentication, integrity, and (given use of asymmetric key
management) non-repudiation of origin security services have been
applied to a PEM message's encapsulated text. ENCRYPTED messages
require a "DEK-Info:" field and individual Recipient-ID and "Key-
Info:" fields for all message recipients.
4.6.1.1.2 MIC-ONLY
The "MIC-ONLY" specifier signifies that all of the security services
specified for ENCRYPTED messages, with the exception of
confidentiality, have been applied to a PEM message's encapsulated
text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC)
to protect their encapsulated text against modifications at message
transfer or relay points.
Specification of MIC-ONLY, when applied in conjunction with certain
combinations of key management and MIC algorithm options, permits
certain fields which are superfluous in the absence of encryption to
be omitted from the encapsulated header. In particular, when a
keyless MIC computation is employed for recipients for whom
asymmetric cryptography is used, "Recipient-ID-Asymmetric:" and
"Key-Info:" fields can be omitted. The "DEK-Info:" field can be
omitted for all "MIC-ONLY" messages.
4.6.1.1.3 MIC-CLEAR
The "MIC-CLEAR" specifier represents a PEM message with the same
security service selection as for a MIC-ONLY message. The set of
encapsulated header fields required in a MIC-CLEAR message is the
same as that required for a MIC-ONLY message.
MIC-CLEAR message processing omits the encoding step defined in
Section 4.3.2.4 of this RFC to protect a message's encapsulated text
against modifications within the MTS. As a result, a MIC-CLEAR
Linn [Page 24]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
message's text can be read by recipients lacking access to PEM
software, even though such recipients cannot validate the message's
signature. The canonical encoding discussed in Section 4.3.2.2 is
performed, so interoperation among sites with different native
character sets and line representations is not precluded so long as
those native formats are unambiguously translatable to and from the
canonical form. (Such interoperability is feasible only for those
characters which are included in the canonical representation set.)
Omission of the printable encoding step implies that MIC-CLEAR
message MICs will be validatable only in environments where the MTS
does not modify messages in transit, or where the modifications
performed can be determined and inverted before MIC validation
processing. Failed MIC validation on a MIC-CLEAR message does not,
therefore, necessarily signify a security-relevant event; as a
result, it is recommended that PEM implementations reflect to their
users (in a suitable local fashion) the type of PEM message being
processed when reporting a MIC validation failure.
A case of particular relevance arises for inbound SMTP processing on
systems which delimit text lines with local native representations
other than the SMTP-conventional <CR><LF>. When mail is delivered to
a UA on such a system and presented for PEM processing, the <CR><LF>
has already been translated to local form. In order to validate a
MIC-CLEAR message's MIC in this situation, the PEM module must
recanonicalize the incoming message in order to determine the inter-
SMTP representation of the canonically encoded message (as defined in
Section 4.3.2.2 of this RFC), and must compute the reference MIC
based on that representation.
4.6.1.1.4 CRL
The "CRL" specifier indicates a special PEM message type, used to
transfer one or more Certificate Revocation Lists. The format of PEM
CRLs is defined in RFC 1422. No user data or encapsulated text
accompanies an encapsulated header specifying the CRL message type; a
correctly-formed CRL message's PEM header is immediately followed by
its terminating message boundary line, with no blank line
intervening.
Only three types of fields are valid in the encapsulated header
comprising a CRL message. The "CRL:" field carries a printable
representation of a CRL, encoded using the procedures defined in
Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be
followed by no more than one "Originator-Certificate:" field and any
number of "Issuer-Certificate:" fields. The "Originator-Certificate:"
and "Issuer-Certificate:" fields refer to the most recently previous
"CRL:" field, and provide certificates useful in validating the
Linn [Page 25]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
signature included in the CRL. "Originator-Certificate:" and
"Issuer-Certificate:" fields' contents are the same for CRL messages
as they are for other PEM message types.
4.6.1.2 Content-Domain Field
The "Content-Domain:" encapsulated header field describes the type of
content which is represented within a PEM message's encapsulated
text. It carries one string argument, whose value is defined as
"RFC822" to indicate processing of RFC-822 mail as defined in this
specification. It is anticipated that additional "Content-Domain:"
values will be defined subsequently, in additional or successor
documents to this specification. Only one "Content-Domain:" field
occurs in a PEM message; this field is the PEM message's second
encapsulated header field, immediately following the "Proc-Type:"
field.
4.6.1.3 DEK-Info Field
The "DEK-Info:" encapsulated header field identifies the message text
encryption algorithm and mode, and also carries any cryptographic
parameters (e.g., IVs) used for message encryption. No more than one
"DEK-Info:" field occurs in a message; the field is required for all
messages specified as "ENCRYPTED" in the "Proc-Type:" field.
The "DEK-Info:" field carries either one argument or two arguments
separated by a comma. The first argument identifies the algorithm
and mode used for message text encryption. The second argument, if
present, carries any cryptographic parameters required by the
algorithm and mode identified in the first argument. Appropriate
message encryption algorithms, modes and identifiers and
corresponding cryptographic parameters and formats are defined in RFC
1423.
This group of encapsulated header fields contains fields which
ordinarily occur no more than once per message. Depending on the key
management option(s) employed, some of these fields may be absent
from some messages.
4.6.2.1 Originator-ID Fields
Originator-ID encapsulated header fields identify a message's
originator and provide the originator's IK identification component.
Two varieties of Originator-ID fields are defined, the "Originator-
ID-Asymmetric:" and "Originator-ID-Symmetric:" field. An
"Originator-ID-Symmetric:" header field is required for all PEM
Linn [Page 26]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
messages employing symmetric key management. The analogous
"Originator-ID-Asymmetric:" field, for the asymmetric key management
case, is used only when no corresponding "Originator-Certificate:"
field is included.
Most commonly, only one Originator-ID or "Originator-Certificate:"
field will occur within a message. For the symmetric case, the IK
identification component carried in an "Originator-ID-Symmetric:"
field applies to processing of all subsequent "Recipient-ID-
Symmetric:" fields until another "Originator-ID-Symmetric:" field
occurs. It is illegal for a "Recipient-ID-Symmetric:" field to occur
before a corresponding "Originator-ID-Symmetric:" field has been
provided. For the asymmetric case, processing of "Recipient-ID-
Asymmetric:" fields is logically independent of preceding
"Originator-ID-Asymmetric:" and "Originator-Certificate:" fields.
Multiple Originator-ID and/or "Originator-Certificate:" fields may
occur in a message when different originator-oriented IK components
must be used by a message's originator in order to prepare a message
so as to be suitable for processing by different recipients. In
particular, multiple such fields will occur when both symmetric and
asymmetric cryptography are applied to a single message in order to
process the message for different recipients.
Originator-ID subfields are delimited by the comma character (","),
optionally followed by whitespace. Section 5.2, Interchange Keys,
discusses the semantics of these subfields and specifies the alphabet
from which they are chosen.
4.6.2.1.1 Originator-ID-Asymmetric Field
The "Originator-ID-Asymmetric:" field contains an Issuing Authority
subfield, and then a Version/Expiration subfield. This field is used
only when the information it carries is not available from an
included "Originator-Certificate:" field.
4.6.2.1.2 Originator-ID-Symmetric Field
The "Originator-ID-Symmetric:" field contains an Entity Identifier
subfield, followed by an (optional) Issuing Authority subfield, and
then an (optional) Version/Expiration subfield. Optional
"Originator-ID-Symmetric:" subfields may be omitted only if rendered
redundant by information carried in subsequent "Recipient-ID-
Symmetric:" fields, and will normally be omitted in such cases.
Linn [Page 27]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.6.2.2 Originator-Certificate Field
The "Originator-Certificate:" encapsulated header field is used only
when asymmetric key management is employed for one or more of a
message's recipients. To facilitate processing by recipients (at
least in advance of general directory server availability), inclusion
of this field in all messages is strongly recommended. The field
transfers an originator's certificate as a numeric quantity,
comprised of the certificate's DER encoding, represented in the
header field with the encoding mechanism defined in Section 4.3.2.4
of this RFC. The semantics of a certificate are discussed in RFC
1422.
4.6.2.3 MIC-Info Field
The "MIC-Info:" encapsulated header field, used only when asymmetric
key management is employed for at least one recipient of a message,
carries three arguments, separated by commas. The first argument
identifies the algorithm under which the accompanying MIC is
computed. The second argument identifies the algorithm under which
the accompanying MIC is signed. The third argument represents a MIC
signed with an originator's private key.
For the case of ENCRYPTED PEM messages, the signed MIC is, in turn,
symmetrically encrypted using the same DEK, algorithm, mode and
cryptographic parameters as are used to encrypt the message's
encapsulated text. This measure prevents unauthorized recipients
from determining whether an intercepted message corresponds to a
predetermined plaintext value.
Appropriate MIC algorithms and identifiers, signature algorithms and
identifiers, and signed MIC formats are defined in RFC 1423.
A "MIC-Info:" field will occur after a sequence of fields beginning
with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field
and followed by any associated "Issuer-Certificate:" fields. A
"MIC-Info:" field applies to all subsequent recipients for whom
asymmetric key management is used, until and unless overridden by a
subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:"
and corresponding "MIC-Info:".
4.6.3 Encapsulated Header Fields with Variable Occurrences
This group of encapsulated header fields contains fields which will
normally occur variable numbers of times within a message, with
numbers of occurrences ranging from zero to non-zero values which are
independent of the number of recipients.
Linn [Page 28]
RFC 1421 Privacy Enhancement for Electronic Mail February 1993
4.6.3.1 Issuer-Certificate Field
The "Issuer-Certificate:" encapsulated header field is meaningful
only when asymmetric key management is used for at least one of a
message's recipients. A typical "Issuer-Certificate:" field would
contain the certificate containing the public component used to sign
the certificate carried in the message's "Originator-Certificate:"
field, for recipients' use in chaining through that certificate's
certification path. Other "Issuer-Certificate:" fields, typically
representing higher points in a certification path, also may be
included by an originator. It is recommended that the "Issuer-
Certificate:" fields be included in an order corresponding to
successive points in a certification path leading from the originator
to a common point shared with the message's recipients (i.e., the
Internet Certification Authority (ICA), unless a lower Policy
Certification Authority (PCA) or CA is common to all recipients.)
More information on certification paths can be found in RFC 1422.
The certificate is represented in the same manner as defined for the
"Originator-Certificate:" field (transporting an encoded
representation of the certificate in X.509 [7] DER form), and any
"Issuer-Certificate:" fields will ordinarily follow the "Originator-
Certificate:" field directly. Use of the "Issuer-Certificate:" field
is optional even when asymmetric key management is employed, although
its incorporation is strongly recommended in the absence of alternate
directory server facilities from which recipients can access issuers'
certificates.
4.6.4 Per-Recipient Encapsulated Header Fields
The encapsulated header fields in this group appear for each of an
"ENCRYPTED" message's named recipients. For "MIC-ONLY" and "MIC-
CLEAR" messages, these fields are omitted for recipients for whom
asymmetric key management is employed in conjunction with a keyless
MIC algorithm but the fields appear for recipients for whom symmetric
key management or a keyed MIC algorithm is employed.
4.6.4.1 Recipient-ID Fields
A Recipient-ID encapsulated header field identifies a recipient and
provides the recipient's IK identification component. One
Recipient-ID field is included for each of a message's named
recipients. Section 5.2, Interchange Keys, discusses the semantics of
the subfields and specifies the alphabet from which they are chosen.
Recipient-ID subfields are delimited by the comma character (","),
optionally followed by whitespace.