As per Relevance of the word procedure, we have this rfc below:
Network Working Group J.
Request for Comments: 1113
Obsoletes RFCs: 989, 1040 IAB Privacy Task
August 1989
Privacy Enhancement for Internet Electronic Mail
Part I -- Message Encipherment and Authentication
STATUS OF THIS
This RFC suggests a draft standard elective protocol for the
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
This RFC is the outgrowth of a series of IAB Privacy Task
meetings and of internal working papers distributed for
meetings. I would like to thank the following Privacy Task
members and meeting guests for their comments and contributions
the meetings which led to the preparation of this RFC:
Balenson, Curt Barker, Jim Bidzos, Matt Bishop, Danny Cohen,
Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve
(chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky,
Shirey, Miles Smid, Steve Walker, and Steve Wilbur
Table of
1. Executive Summary 2
2. Terminology 3
3. Services, Constraints, and Implications 3
4. Processing of Messages 7
4.1 Message Processing Overview 7
4.1.1 Types of Keys 7
4.1.2 Processing Procedures 8
4.2 Encryption Algorithms and Modes 9
4.3 Privacy Enhancement Message Transformations 10
4.3.1 Constraints 10
4.3.2 Approach 11
4.3.2.1 Step 1: Local Form 12
4.3.2.2 Step 2: Canonical Form 12
4.3.2.3 Step 3: Authentication and Encipherment 12
4.3.2.4 Step 4: Printable Encoding 13
4.3.2.5 Summary of Transformations 15
4.4 Encapsulation Mechanism 15
4.5 Mail for Mailing Lists 17
4.6 Summary of Encapsulated Header Fields 18
Linn [Page 1]
RFC 1113 Mail Privacy: Procedures August 1989
4.6.1 Per-Message Encapsulated Header Fields 20
4.6.1.1 X-Proc-Type Field 20
4.6.1.2 X-DEK-Info Field 21
4.6.2 Encapsulated Header Fields Normally Per-Message 21
4.6.2.1 X-Sender-ID Field 22
4.6.2.2 X-Certificate Field 22
4.6.2.3 X-MIC-Info Field 23
4.6.3 Encapsulated Header Fields with Variable Occurrences 23
4.6.3.1 X-Issuer-Certificate Field 23
4.6.4 Per-Recipient Encapsulated Header Fields 24
4.6.4.1 X-Recipient-ID Field 24
4.6.4.2 X-Key-Info Field 24
4.6.4.2.1 Symmetric Key Management 24
4.6.4.2.2 Asymmetric Key Management 25
5. Key Management 26
5.1 Data Encrypting Keys (DEKs) 26
5.2 Interchange Keys (IKs) 26
5.2.1 Subfield Definitions 28
5.2.1.1 Entity Identifier Subfield 28
5.2.1.2 Issuing Authority Subfield 29
5.2.1.3 Version/Expiration Subfield 29
5.2.2 IK Cryptoperiod Issues 29
6. User Naming 29
6.1 Current Approach 29
6.2 Issues for Consideration 30
7. Example User Interface and Implementation 30
8. Areas For Further Study 31
9. References 32
NOTES 32
1. Executive
This RFC defines message encipherment and authentication procedures
in order to provide privacy enhancement services for electronic
transfer in the Internet. It is one member of a related set of
RFCs. The procedures defined in the current RFC are intended to
compatible with a wide range of key management approaches,
both symmetric (secret-key) and asymmetric (public-key)
for encryption of data encrypting keys. Use of
cryptography for message text encryption and/or integrity
computation is anticipated. RFC-1114 specifies supporting
management mechanisms based on the use of public-key certificates
RFC-1115 specifies algorithm and related information relevant to
current RFC and to RFC-1114. A subsequent RFC will provide
of paper and electronic formats and procedures for the key
infrastructure being established in support of these services
Privacy enhancement services (confidentiality, authentication,
Linn [Page 2]
RFC 1113 Mail Privacy: Procedures August 1989
message integrity assurance) are offered through the use of end-to
end cryptography between originator and recipient User
processes, with no special processing requirements imposed on
Message Transfer System at endpoints or at intermediate relay sites
This approach allows privacy enhancement facilities to
incorporated on a site-by-site or user-by-user basis without
on other Internet entities. Interoperability among
components and mail transport facilities is supported
2.
For descriptive purposes, this RFC uses some terms defined in the
X.400 Message Handling System Model per the 1984
Recommendations. This section replicates a portion of X.400'
Section 2.2.1, "Description of the MHS Model: Overview" in order
make the terminology clear to readers who may not be familiar
the OSI MHS Model
In the MHS model, a user is a person or a computer application.
user is referred to as either an originator (when sending a message
or a recipient (when receiving one). MH Service elements define
set of message types and the capabilities that enable an
to transfer messages of those types to one or more recipients
An originator prepares messages with the assistance of his or
User Agent (UA). A UA is an application process that interacts
the Message Transfer System (MTS) to submit messages. The
delivers to one or more recipient UAs the messages submitted to it
Functions performed solely by the UA and not standardized as part
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
intended recipient UAs, which then make the messages available to
intended recipients
The collection of UAs and MTAs is called the Message Handling
(MHS). The MHS and all of its users are collectively referred to
the Message Handling Environment
3. Services, Constraints, and
This RFC defines mechanisms to enhance privacy for electronic
transferred in the Internet. The facilities discussed in this
provide privacy enhancement services on an end-to-end basis
sender and recipient UAs. No privacy enhancements are offered
message fields which are added or transformed by intermediate
points
Linn [Page 3]
RFC 1113 Mail Privacy: Procedures August 1989
Authentication and integrity facilities are always applied to
entirety of a message's text. No facility for
without authentication is provided. Encryption facilities may
applied selectively to portions of a message's contents; this
less sensitive portions of messages (e.g., descriptive fields) to
processed by a recipient's delegate in the absence of the recipient'
personal cryptographic keys. In the limiting case, where
entirety of message text is excluded from encryption, this
can be used to yield the effective combination of authentication
integrity services without confidentiality
In keeping with the Internet's heterogeneous constituencies and
modes, the measures defined here are applicable to a broad range
Internet hosts and usage paradigms. In particular, it is
noting the following attributes
1. The mechanisms defined in this RFC are not restricted to
particular host or operating system, but rather
interoperability among a broad range of systems.
privacy enhancements are implemented at the
layer, and are not dependent on any privacy features
lower protocol layers
2. The defined mechanisms are compatible with non-
Internet components. Privacy enhancements are
in an end-to-end fashion which does not impact
processing by intermediate relay hosts which do
incorporate privacy enhancement facilities. It
necessary, however, for a message's sender to be
of whether a message's intended recipient implements
enhancements, in order that encoding and
encipherment will not be performed on a message
destination is not equipped to perform corresponding
transformations
3. The defined mechanisms are compatible with a range of
transport facilities (MTAs). Within the Internet
electronic mail transport is effected by a variety of
implementations. Certain sites, accessible via SMTP
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must
able to operate across the SMTP realm; it is desirable
they also be compatible with protection of electronic
sent between the SMTP environment and other
environments
4. The defined mechanisms are compatible with a broad range
electronic mail user agents (UAs). A large variety
Linn [Page 4]
RFC 1113 Mail Privacy: Procedures August 1989
electronic mail user agent programs, with a
broad range of user interface paradigms, is used in
Internet. In order that electronic mail
enhancements be available to the broadest possible
community, selected mechanisms should be usable with
widest possible variety of existing UA programs.
purposes of pilot implementation, it is desirable
privacy enhancement processing be incorporable into
separate program, applicable to a range of UAs, rather
requiring internal modifications to each UA with
privacy-enhanced services are to be provided
5. The defined mechanisms allow electronic mail
enhancement processing to be performed on personal
(PCs) separate from the systems on which UA functions
implemented. Given the expanding use of PCs and the
degree of trust which can be placed in UA implementations
many multi-user systems, this attribute can allow many
to process privacy-enhanced mail with a higher
level than a strictly UA-based approach would allow
6. The defined mechanisms support privacy protection
electronic mail addressed to mailing lists (
lists, in ISO parlance).
7. The mechanisms defined within this RFC are compatible with
variety of supporting key management approaches,
(but not limited to) manual pre-distribution,
key distribution based on symmetric cryptography, and
use of public-key certificates. Different key
mechanisms may be used for different recipients of
multicast message. While support for a particular
management mechanism is not a minimum essential
for compatibility with this RFC, adoption of the public-
certificate approach defined in companion RFC-1114
strongly recommended
In order to achieve applicability to the broadest possible range
Internet hosts and mail systems, and to facilitate
implementation and testing without the need for prior
throughout the Internet, three basic restrictions are imposed on
set of measures to be considered in this RFC
1. Measures will be restricted to implementation at
and will be amenable to integration at the user agent (UA
level or above, rather than necessitating integration
the message transport system (e.g., SMTP servers).
Linn [Page 5]
RFC 1113 Mail Privacy: Procedures August 1989
2. The set of supported measures enhances rather than
user capabilities. Trusted implementations,
integrity features protecting software from subversion
local users, cannot be assumed in general. In the
of such features, it appears more feasible to
facilities which enhance user services (e.g., by
and authenticating inter-user traffic) than to
restrictions (e.g., inter-user access control) on
actions
3. The set of supported measures focuses on a set of
capabilities selected to provide significant and
benefits to a broad user community. By concentrating on
most critical set of services, we aim to maximize the
privacy value that can be provided with a modest level
implementation effort
As a result of these restrictions, the following facilities can
provided
1. disclosure protection
2. sender authenticity
3. message integrity measures,
4. (if asymmetric key management is used) non-repudiation
origin
but the following privacy-relevant concerns are not addressed
1. access control
2. traffic flow confidentiality
3. address list accuracy
4. routing control
5. issues relating to the casual serial reuse of PCs
multiple users
6. assurance of message receipt and non-deniability of receipt
7. automatic association of acknowledgments with the
to which they refer,
8. message duplicate detection, replay prevention, or
Linn [Page 6]
RFC 1113 Mail Privacy: Procedures August 1989
stream-oriented services
A message's sender will determine whether privacy enhancements are
be performed on a particular message. Therefore, a sender must
able to determine whether particular recipients are equipped
process privacy-enhanced mail. In a general architecture,
mechanisms will be based on server queries; thus, the query
could be integrated into a UA to avoid imposing burdens
inconvenience on electronic mail users
4. Processing of
4.1 Message Processing
This subsection provides a high-level overview of the components
processing steps involved in electronic mail privacy
processing. Subsequent subsections will define the procedures
more detail
4.1.1 Types of
A two-level keying hierarchy is used to support privacy-
message transmission
1. Data Encrypting Keys (DEKs) are used for encryption
message text and (with certain choices among a set
alternative algorithms) for computation of message
check (MIC) quantities. DEKs are generated individually
each transmitted message; no predistribution of DEKs
needed to support privacy-enhanced message transmission
2. Interchange Keys (IKs) are used to encrypt DEKs
transmission within messages. Ordinarily, the same IK
be used for all messages sent from a given originator to
given recipient over a period of time. Each
message includes a representation of the DEK(s) used
message encryption and/or MIC computation, encrypted
an individual IK per named recipient. The representation
associated with "X-Sender-ID:" and "X-Recipient-ID:" fields
which allow each individual recipient to identify the
used to encrypt DEKs and/or MICs for that recipient's use
Given an appropriate IK, a recipient can decrypt
corresponding transmitted DEK representation, yielding
DEK required for message text decryption and/or
verification. The definition of an IK differs depending
whether symmetric or asymmetric cryptography is used for
encryption
Linn [Page 7]
RFC 1113 Mail Privacy: Procedures August 1989
2a. When symmetric cryptography is used for
encryption, an IK is a single symmetric key
between an originator and a recipient. In
case, the same IK is used to encrypt MICs as
as DEKs for transmission. Version/
information and IA identification associated
the originator and with the recipient must
concatenated in order to fully qualify a
IK
2b. When asymmetric cryptography is used, the
component used for DEK encryption is the
component of the recipient. The IK component
for MIC encryption is the private component of
originator, and therefore only one encrypted
representation need be included per message, rather
one per recipient. Each of these
components can be fully qualified in
"X-Recipient-ID:" or "X-Sender-ID:" field
respectively
4.1.2 Processing
When privacy enhancement processing is to be performed on an
message, a DEK is generated [1] for use in message encryption and (
a chosen MIC algorithm requires a key) a variant of the DEK is
for use in MIC computation. DEK generation can be omitted for
case of a message in which all contents are excluded from encryption
unless a chosen MIC computation algorithm requires a DEK
An "X-Sender-ID:" field is included in the header to provide
identification component for the IK(s) used for message processing
IK components are selected for each individually named recipient;
corresponding "X-Recipient-ID:" field, interpreted in the context
a prior "X-Sender-ID:" field, serves to identify each IK. Each "X
Recipient-ID:" field is followed by an "X-Key-Info:" field,
transfers a DEK encrypted under the IK appropriate for the
recipient. When symmetric key management is used for a
recipient, the "X-Key-Info:" field also transfers the message'
computed MIC, encrypted under the recipient's IK. When
key management is used, a prior "X-MIC-Info:" field carries
message's MIC encrypted under the private component of the sender
A four-phase transformation procedure is employed in order
represent encrypted message text in a universally transmissible
and to enable messages encrypted on one type of host computer to
decrypted on a different type of host computer. A plaintext
is accepted in local form, using the host's native character set
Linn [Page 8]
RFC 1113 Mail Privacy: Procedures August 1989
line representation. The local form is converted to a
message text representation, defined as equivalent to the inter-
representation of message text. This canonical representation
the input to the MIC computation and encryption processes
For encryption purposes, the canonical representation is padded
required by the encryption algorithm. The padded
representation is encrypted (except for any regions which
explicitly excluded from encryption). The encrypted text (along
the canonical representation of regions which were excluded
encryption) is encoded into a printable form. The printable form
composed of a restricted character set which is chosen to
universally representable across sites, and which will not
disrupted by processing within and between MTS entities
The output of the encoding procedure is combined with a set of
fields carrying cryptographic control information. The result
passed to the electronic mail system to be encapsulated as the
portion of a transmitted message
When a privacy-enhanced message is received, the
control fields within its text portion provide the
required for the authorized recipient to perform MIC verification
decryption of the received message text. First, the
encoding is converted to a bitstring. Encrypted portions of
transmitted message are decrypted. The MIC is verified.
canonical representation is converted to the recipient's local form
which need not be the same as the sender's local form
4.2 Encryption Algorithms and
For purposes of this RFC, the Block Cipher Algorithm DEA-1,
in ANSI X3.92-1981 [2] shall be used for encryption of message text
The DEA-1 is equivalent to the Data Encryption Standard (DES),
defined in FIPS PUB 46 [3]. When used for encryption of text,
DEA-1 shall be used in the Cipher Block Chaining (CBC) mode,
defined in ISO IS 8372 [4]. The identifier string "DES-CBC",
in RFC-1115, signifies this algorithm/mode combination. The CBC
definition in IS 8372 is equivalent to that provided in FIPS PUB 81
[5] and in ANSI X3.106-1983 [16]. Use of other algorithms and/
modes for message text processing will require case-by-case study
determine applicability and constraints. Additional algorithms
modes approved for use in this context will be specified
successors to RFC-1115.
It is an originator's responsibility to generate a new
initializing vector (IV) for each privacy-enhanced electronic
message unless the entirety of the message is excluded
Linn [Page 9]
RFC 1113 Mail Privacy: Procedures August 1989
encryption. Section 4.3.1 of [17] provides rationale for
requirement, even in a context where individual DEKs are
for individual messages. The IV will be transmitted with
message
Certain operations require that one key be encrypted under
interchange key (IK) for purposes of transmission. A header
indicates the mode in which the IK is used for encryption. RFC-1115
specifies encryption algorithm/mode identifiers, including DES-ECB
DES-EDE, and RSA. All implementations using symmetric key
should support DES-ECB IK use, and all implementations
asymmetric key management should support RSA IK use
RFC-1114, released concurrently with this RFC, specifies asymmetric
certificate-based key management procedures to support the
processing procedures defined in this document. The
processing procedures can also be used with symmetric key management
given prior distribution of suitable symmetric IKs through out-of
band means. Support for the asymmetric approach defined in RFC-1114
is strongly recommended
4.3 Privacy Enhancement Message
4.3.1
An electronic mail encryption mechanism must be compatible with
transparency constraints of its underlying electronic
facilities. These constraints are generally established based
expected user requirements and on the characteristics of
endpoint and transport facilities. An encryption mechanism must
be compatible with the local conventions of the computer
which it interconnects. In our approach, a canonicalization step
performed to abstract out local conventions and a subsequent
step is performed to conform to the characteristics of the
mail transport medium (SMTP). The encoding conforms to
constraints, established to support interpersonal messaging. SMTP'
rules are also used independently in the canonicalization process
RFC-821's [7] Section 4.5 details SMTP's transparency constraints
To prepare a message for SMTP transmission, the
requirements must be met
1. All characters must be members of the 7-bit ASCII
set
2. Text lines, delimited by the character pair ,
be no more than 1000 characters long
Linn [Page 10]
RFC 1113 Mail Privacy: Procedures August 1989
3. Since the string . indicates the end of
message, it must not occur in text prior to the end of
message
Although SMTP specifies a standard representation for line
(ASCII ), numerous systems use a different
representation to delimit lines. For example, the
delimiting lines in mail inbound to UNIX systems are transformed
single s as mail is written into local mailbox files. Lines
mail incoming to record-oriented systems (such as VAX VMS) may
converted to appropriate records by the destination SMTP [8] server
As a result, if the encryption process generated s or s
those characters might not be accessible to a recipient UA program
a destination which uses different line delimiting conventions.
is also possible that conversion between tabs and spaces may
performed in the course of mapping between inter-SMTP and
format; this is a matter of local option. If such
changed the form of transmitted ciphertext, decryption would fail
regenerate the transmitted plaintext, and a transmitted MIC
fail to compare with that computed at the destination
The conversion performed by an SMTP server at a system with EBCDIC
a native character set has even more severe impact, since
conversion from EBCDIC into ASCII is an information-
transformation. In principle, the transformation function
between inter-SMTP canonical ASCII message representation and
format could be moved from the SMTP server up to the UA, given
means to direct that the SMTP server should no longer perform
transformation. This approach has a major disadvantage:
file (e.g., mailbox) formats would be incompatible with the
forms used on the systems where they reside. Further, it
require modification to SMTP servers, as mail would be passed to
in a different representation than it is passed at present
4.3.2
Our approach to supporting privacy-enhanced mail across
environment in which intermediate conversions may occur encodes
in a fashion which is uniformly representable across the set
privacy-enhanced UAs regardless of their systems' native
sets. This encoded form is used to represent mail text from
to recipient, but the encoding is not applied to enclosing
transport headers or to encapsulated headers inserted to
control information between privacy-enhanced UAs. The encoding'
characteristics are such that the transformations anticipated
sender and recipient UAs will not prevent an encoded message
being decoded properly at its destination
Linn [Page 11]
RFC 1113 Mail Privacy: Procedures August 1989
A sender may exclude one or more portions of a message
encryption processing, but authentication processing is
applied to the entirety of message text. Explicit action is
to exclude a portion of a message from encryption processing;
default, encryption is applied to the entirety of message text.
user-level delimiter which specifies such exclusion is a
matter, and hence may vary between sender and recipient, but
systems should provide a means for unambiguous identification
areas excluded from encryption processing
An outbound privacy-enhanced message undergoes four
steps, described in the following four subsections
4.3.2.1 Step 1: Local
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
The entire message text, including both those portions subject
encipherment processing and those portions excluded from
processing, is converted to a universal canonical form, analogous
the inter-SMTP representation [9] as defined in RFC-821 and RFC-822
[10] (ASCII character set, line delimiters). The
required to perform this conversion is minimal on systems
native character set is ASCII. (Note: Since the output of
canonical encoding process will never be submitted directly to SMTP
but only to subsequent steps of the privacy enhancement
process, the dot-stuffing transformation discussed in RFC-821,
section 4.5.2, is not required.) Since a message is converted to
standard character set and representation before encryption, it
be decrypted and its MIC can be verified at any type of
host computer. The decryption and MIC verification is
before any conversions which may be necessary to transform
message into a destination-specific local form
4.3.2.3 Step 3: Authentication and
The canonical form is input to the selected MIC computation
in order to compute an integrity check quantity for the message.
padding is added to the canonical form before submission to the
computation algorithm, although certain MIC algorithms will
their own padding in the course of computing a MIC
Padding is applied to the canonical form as needed to
encryption in the DEA-1 CBC mode, as follows: The number of octets
be encrypted is determined by subtracting the number of
Linn [Page 12]
RFC 1113 Mail Privacy: Procedures August 1989
excluded from encryption from the total length of the
encoded text. Octets with the hexadecimal value FF (all ones)
appended to the canonical form as needed so that the text octets
be encrypted, along with the added padding octets, fill an
number of 8-octet encryption quanta. No padding is applied if
number of octets to be encrypted is already an integral multiple
8. The use of hexadecimal FF (a value outside the 7-bit ASCII set
as a padding value allows padding octets to be distinguished
valid data without inclusion of an explicit padding count indicator
The regions of the message which have not been excluded
encryption are encrypted. To support selective
processing, an implementation must retain internal indications of
positions of excluded areas excluded from encryption with relation
non-excluded areas, so that those areas can be properly delimited
the encoding procedure defined in step 4. If a region excluded
encryption intervenes between encrypted regions, cryptographic
(e.g., IVs and accumulation of octets into encryption quanta)
preserved and continued after the excluded region
4.3.2.4 Step 4: Printable
Proceeding from left to right, the bit string resulting from step 3
is encoded into characters which are universally representable at
sites, though not necessarily with the same bit patterns (e.g.,
although the character "E" is represented in an ASCII-based system
hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system,
local significance of the two representations is equivalent).
encoding step is performed for all privacy-enhanced messages, even
an entire message is excluded from encryption
A 64-character subset of International Alphabet IA5 is used,
6 bits to be represented per printable character. (The
subset of characters is represented identically in IA5 and ASCII.)
Two additional characters, "=" and "*", are used to signify
processing functions. The character "=" is used for padding
the printable encoding procedure. The character "*" is used
delimit the beginning and end of a region which has been
from encipherment processing. The encoding function's output
delimited into text lines (using local conventions), with each
except the last containing exactly 64 printable characters and
final line containing 64 or fewer printable characters. (This
length is easily printable and is guaranteed to satisfy SMTP's 1000-
character transmitted line length limit.)
The encoding process represents 24-bit groups of input bits as
strings of 4 encoded characters. Proceeding from left to right
a 24-bit input group extracted from the output of step 3, each 6-
Linn [Page 13]
RFC 1113 Mail Privacy: Procedures August 1989
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 0, are selected so as to
universally representable, and the set excludes characters
particular significance to SMTP (e.g., ".", "", "").
Special processing is performed if fewer than 24 bits are
in an input group, either at the end of a message or (when
selective encryption facility is invoked) at the end of an
region or an excluded region. A full encoding quantum is
completed at the end of a message and before the delimiter "*"
output to initiate or terminate the representation of a
excluded from encryption. When fewer than 24 input bits
available in an input group, zero bits are added (on the right)
form an integral number of 6-bit groups. Output character
which are not required to represent actual input data are set to
character "=". Since all canonically encoded output is an
number of octets, only the following cases can arise: (1) the
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
input is exactly 8 bits; here, the final unit of encoded output
be two characters followed by two "=" padding characters, or (3)
final quantum of encoding input is exactly 16 bits; here, the
unit of encoded output will be three characters followed by one "="
padding character
Linn [Page 14]
RFC 1113 Mail Privacy: Procedures August 1989
4.3.2.5 Summary of
In summary, the outbound message is subjected to the
composition of transformations
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
The inverse transformations are performed, in reverse order,
process inbound privacy-enhanced mail
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
Value Encoding Value Encoding Value Encoding Value
0 A 17 R 34 i 51
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
14 O 31 f 48 w (pad) =
15 P 32 g 49
16 Q 33 h 50 y (1) *
(1) The character "*" is used to enclose portions of
encoded message to which encryption processing has
been applied
Printable Encoding
Table 1
Note that the local form and the functions to transform messages
and from canonical form may vary between the sender and
systems without loss of information
4.4 Encapsulation
Encapsulation of privacy-enhanced messages within an enclosing
Linn [Page 15]
RFC 1113 Mail Privacy: Procedures August 1989
of headers interpreted by the electronic mail transport system
a number of advantages in comparison to a flat approach in
certain fields within a single header are encrypted and/or
cryptographic control information. Encapsulation provides
and segregates fields with user-to-user significance from
transformed in transit. All fields inserted in the course
encryption/authentication processing are placed in the
header. This facilitates compatibility with mail handling
which accept only text, not header fields, from input files or
other programs. Further, privacy enhancement processing can
applied recursively. As far as the MTS is concerned,
incorporated into cryptographic authentication or
processing will reside in a message's text portion, not its
portion
The encapsulation mechanism to be used for privacy-enhanced mail
derived from that described in RFC-934 [11] which is, in turn,
on precedents in the processing of message digests in the
community. To prepare a user message for encrypted or
transmission, it will be transformed into the representation shown
Figure 1.
As a general design principle, sensitive data is protected
incorporating the data within the encapsulated text rather than
applying measures selectively to fields in the enclosing header
Examples of potentially sensitive header information may
fields such as "Subject:", with contents which are significant on
end-to-end, inter-user basis. The (possibly empty) set of headers
which protection is to be applied is a user option. It is
recommended, however, that all implementations should
copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within
encapsulated text
If a user wishes disclosure protection for header fields, they
occur only in the encapsulated text and not in the enclosing
encapsulated header. If disclosure protection is desired for
message's subject indication, it is recommended that the
header contain a "Subject:" field indicating that "Encrypted
Follows".
If an authenticated version of header information is desired,
data can be replicated within the encapsulated text portion
addition to its inclusion in the enclosing header. For example,
sender wishing to provide recipients with a protected indication of
message's position in a series of messages could include a copy of
timestamp or message counter field within the encapsulated text
A specific point regarding the integration of privacy-enhanced
Linn [Page 16]
RFC 1113 Mail Privacy: Procedures August 1989
facilities with the message encapsulation mechanism is worthy
note. The subset of IA5 selected for transmission
intentionally excludes the character "-", so encapsulated text can
distinguished unambiguously from a message's closing
boundary (Post-EB) without recourse to character stuffing
Enclosing Header
(Contains header fields per RFC-822)
Blank
(Separates Enclosing Header from Encapsulated Message
Encapsulated
Pre-Encapsulation Boundary (Pre-EB
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Encapsulated Header
(Contains encryption control fields inserted in plaintext
Examples include "X-DEK-Info:", "X-Sender-ID:",
"X-Key-Info:".
Note that, although these control fields have line-
representations similar to RFC-822 header fields, the
of fields valid in this context is disjoint from those
in RFC-822 processing.)
Blank
(Separates Encapsulated Header from subsequent
Encapsulated Text Portion
Encapsulated Text
(Contains message data encoded as specified in Section 4.3;
may incorporate protected copies of enclosing
encapsulated header fields such as "Subject:", etc.)
Post-Encapsulation Boundary (Post-EB
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Message
Figure 1
4.5 Mail for Mailing
When mail is addressed to mailing lists, two different methods
processing can be applicable: the IK-per-list method and the IK-per
recipient method. The choice depends on the information available
Linn [Page 17]
RFC 1113 Mail Privacy: Procedures August 1989
the sender and on the sender's preference
If a message's sender 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
destinations, is implied. Such an IK must, therefore, be
to all list members. For the case of asymmetric key management,
list's private component must be available to all list members.
alternative will be the normal case for messages sent via
exploder sites, as a sender to such lists may not be cognizant of
set of individual recipients. Unfortunately, it implies
undesirable level of exposure for the shared IK, and makes
revocation difficult. Moreover, use of the IK-per-list method
any holder of the list's IK to masquerade as another sender to
list for authentication purposes
If, in contrast, a message's sender is equipped to expand
destination mailing list into its individual constituents and
to do so (IK-per-recipient), the message's DEK (and, in the
key management case, MIC) will be encrypted under each per-
IK and all such encrypted representations will be incorporated
the transmitted message. Note that per-recipient encryption
required only for the relatively small DEK and MIC quantities
in the "X-Key-Info:" field, not for the message text which is,
general, much larger. Although more IKs are involved in
under the IK-per-recipient method, the pairwise IKs can
individually revoked and possession of one IK does not enable
successful masquerade of another user on the list
4.6 Summary of Encapsulated Header
This section summarizes the syntax and semantics of the
header fields to be added to messages in the course of
enhancement processing. The fields are presented in three groups
Normally, the groups will appear in encapsulated headers in the
in which they are shown, though not all fields in each group
appear in all messages. In certain indicated cases, it is
that the fields be replicated within the encapsulated text portion
well as being included within the encapsulated header. Figures 2
3 show the appearance of small example encapsulated messages.
2 assumes the use of symmetric cryptography for key management
Figure 3 illustrates an example encapsulated message in
asymmetric key management is used
Unless otherwise specified, all field arguments are processed in
case-sensitive fashion. In most cases, numeric quantities
represented in header fields as contiguous strings of
digits, where each digit is represented by a character from
Linn [Page 18]
RFC 1113 Mail Privacy: Procedures August 1989
ranges "0"-"9" or upper case "A"-"F". Since public-key
and quantities encrypted using asymmetric algorithms are large
size, use of a more space-efficient encoding technique is
for such quantities, and the encoding mechanism defined in
4.3.2.4 of this RFC, representing 6 bits per printed character,
adopted. The example shown in Figure 3 shows
encrypted quantities (e.g., "X-MIC-Info:", "X-Key-Info:") with 64-
character printed representations, corresponding to 384 bits.
fields carrying asymmetrically encrypted quantities also
the use of folding as defined in RFC-822, section 3.1.1.
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 3,
X-DEK-Info: DES-CBC,F8143EDE5960C597
X-Sender-ID: linn@ccy.bbn.com::
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3
X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD
A60195DB94F727D
X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4
X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
9F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message (Symmetric Case
Figure 2
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 3,
X-DEK-Info: DES-CBC,F8143EDE5960C597
X-Sender-ID: linn@ccy.bbn.com::
X-Certificate
jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9
YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0
agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk
X-Issuer-Certificate
TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+
IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9
vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9
X-MIC-Info: RSA-MD2,RSA
5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5
X-Recipient-ID: linn@ccy.bbn.com:RSADSI:3
Linn [Page 19]
RFC 1113 Mail Privacy: Procedures August 1989
X-Key-Info: RSA
lBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9
X-Recipient-ID: privacy-tf@venera.isi.edu:RSADSI:4
X-Key-Info: RSA
NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message (Asymmetric Case
Figure 3
Although the encapsulated header fields resemble RFC-822
fields, they are a disjoint set and will not in general be
by the same parser which operates on enclosing header fields.
complexity of lexical analysis needed and appropriate
encapsulated header field processing is significantly less than
appropriate to RFC-822 header processing. For example,
characters with special significance to RFC-822 at the
level have no such significance within encapsulated header fields
When the length of an encapsulated header field is longer than
size conveniently printable on a line, whitespace may be used to
the field in the manner of RFC-822, section 3.1.1. Any such
whitespace is not to be interpreted as a part of a subfield. As
particular example, due to the length of public-key certificates
of quantities encrypted using asymmetric algorithms, such
may often need to be folded across multiple printed lines. In
to facilitate such folding in a uniform manner, the bits
such a quantity are to be divided into an ordered set (with
bits first) of zero or more 384-bit groups (corresponding to 64-
character printed representations), followed by a final group of
which may be any length up to 384 bits
4.6.1 Per-Message Encapsulated Header
This group of encapsulated header fields contains fields which
no more than once in a privacy-enhanced message, generally
all other encapsulated header fields
4.6.1.1 X-Proc-Type
The "X-Proc-Type:" encapsulated header field, required for
privacy-enhanced messages, identifies the type of
Linn [Page 20]
RFC 1113 Mail Privacy: Procedures August 1989
performed on the transmitted message. Only one "X-Proc-Type:"
occurs in a message; the "X-Proc-Type:" field must be the
encapsulated header field in the message
The "X-Proc-Type:" field has two subfields, separated by a comma
The first subfield is a decimal number which is used to
among incompatible encapsulated header field interpretations
may arise as changes are made to this standard. Messages
according to this RFC will carry the subfield value "3"
distinguish them from messages processed in accordance with
RFCs 989 and 1040.
The second subfield may assume one of two string values: "ENCRYPTED
or "MIC-ONLY". Unless all of a message's encapsulated text
excluded from encryption, the "X-Proc-Type:" field's second
must specify "ENCRYPTED". Specification of "MIC-ONLY", when
in conjunction with certain combinations of key management and
algorithm options, permits certain fields which are superfluous
the absence of encryption to be omitted from the encapsulated header
In particular, "X-Recipient-ID:" and "X-Key-Info:" fields can
omitted for recipients for whom asymmetric cryptography is used
assuming concurrent use of a keyless MIC computation algorithm.
"X-DEK-Info:" field can be omitted for all "MIC-ONLY" messages
4.6.1.2 X-DEK-Info
The "X-DEK-Info:" encapsulated header field identifies the
text encryption algorithm and mode, and also carries the
Vector used for message encryption. No more than one "X-DEK-Info:"
field occurs in a message; the field is required except for
specified as "MIC-ONLY" in the "X-Proc-Type:" field
The "X-DEK-Info:" field carries two arguments, separated by a comma
For purposes of this RFC, the first argument must be the
"DES-CBC", signifying (as defined in RFC-1115) use of the
algorithm in the CBC mode. The second argument represents a 64-
Initializing Vector (IV) as a contiguous string of 16
digits. Subsequent revisions of RFC-1115 will specify any
values which may appear as the first argument of this field
4.6.2 Encapsulated Header Fields Normally Per-
This group of encapsulated header fields contains fields
ordinarily occur no more than once per message. Depending on the
management option(s) employed, some of these fields may be
from some messages. The "X-Sender-ID" field may occur more than
in a message if different sender-oriented IK components (
corresponding to different versions) must be used for
Linn [Page 21]
RFC 1113 Mail Privacy: Procedures August 1989
recipients. In this case later occurrences override
occurrences. If a mixture of symmetric and asymmetric
distribution is used within a single message, the recipients for
type of key distribution technology should be grouped together
simplify parsing
4.6.2.1 X-Sender-ID
The "X-Sender-ID:" encapsulated header field, required for
privacy-enhanced messages, identifies a message's sender and
the sender's IK identification component. It should be
within the encapsulated text. The IK identification
carried in an "X-Sender-ID:" field is used in conjunction with
subsequent "X-Recipient-ID:" fields until another "X-Sender-ID:"
field occurs; the ordinary case will be that only a single "X
Sender-ID:" field will occur, prior to any "X-Recipient-ID:" fields
The "X-Sender-ID:" field contains (in order) an Entity
subfield, an (optional) Issuing Authority subfield, and an (optional
Version/Expiration subfield. The optional subfields are omitted
their use is rendered redundant by information carried in
"X-Recipient-ID:" fields; this will ordinarily be the case
symmetric cryptography is used for key management. The subfields
delimited by the colon character (":"), optionally followed
whitespace
Section 5.2, Interchange Keys, discusses the semantics of
subfields and specifies the alphabet from which they are chosen
Note that multiple "X-Sender-ID:" fields may occur within a
encapsulated header. All "X-Recipient-ID:" fields are interpreted
the context of the most recent preceding "X-Sender-ID:" field; it
illegal for an "X-Recipient-ID:" field to occur in a header before
"X-Sender-ID:" has been provided
4.6.2.2 X-Certificate
The "X-Certificate:" encapsulated header field is used only
asymmetric key management is employed for one or more of a message'
recipients. To facilitate processing by recipients (at least
advance of general directory server availability), inclusion of
field in all messages is strongly recommended. The field transfers
sender's certificate as a numeric quantity, represented with
encoding mechanism defined in Section 4.3.2.4 of this RFC.
semantics of a certificate are discussed in RFC-1114.
certificate carried in an "X-Certificate:" field is used
conjunction with "X-Sender-ID:" and "X-Recipient-ID:" fields
which asymmetric key management is employed
Linn [Page 22]
RFC 1113 Mail Privacy: Procedures August 1989
4.6.2.3 X-MIC-Info
The "X-MIC-Info:" encapsulated header field, used only
asymmetric key management is employed for at least one recipient of
message, carries three arguments, separated by commas. The
argument identifies the algorithm under which the accompanying MIC
computed; RFC-1115 specifies the acceptable set of MIC
identifiers. The second argument identifies the algorithm
which the accompanying MIC is encrypted; for purposes of this RFC
the string "RSA" as described in RFC-1115 must occur,
use of the RSA algorithm. The third argument is a MIC
asymmetrically encrypted using the originator's private component
As discussed earlier in this section, the asymmetrically
MIC is represented using the technique described in Section 4.3.2.4
of this RFC
The "X-MIC-Info:" field will occur immediately following
message's "X-Sender-ID:" field and any "X-Certificate:" or "X
Issuer-Certificate:" fields. Analogous to the "X-Sender-ID:" field
an "X-MIC-Info:" field applies to all subsequent recipients for
asymmetric key management is used
4.6.3 Encapsulated Header Fields with Variable
This group of encapsulated header fields contains fields which
normally occur variable numbers of times within a message,
numbers of occurrences ranging from zero to non-zero values which
independent of the number of recipients
4.6.3.1 X-Issuer-Certificate
The "X-Issuer-Certificate:" encapsulated header field is
only when asymmetric key management is used for at least one of
message's recipients. A typical "X-Issuer-Certificate:" field
contain the certificate containing the public component used to
the certificate carried in the message's "X-Certificate:" field,
recipients' use in chaining through that certificate's
path. Other "X-Issuer-Certificate:" fields, typically
higher points in a certification path, also may be included by
sender. The order in which "X-Issuer-Certificate:" fields
included need not correspond to the order of the certification path
the order of that path may in general differ from the viewpoint
different recipients. More information on certification paths can
found in RFC-1114.
The certificate is represented in the same manner as defined for
"X-Certificate:" field, and any "X-Issuer-Certificate:" fields
ordinarily follow the "X-Certificate:" field directly. Use of
Linn [Page 23]
RFC 1113 Mail Privacy: Procedures August 1989
"X-Issuer-Certificate:" field is optional even when asymmetric
management is employed, although its incorporation is
recommended in the absence of alternate directory server
from which recipients can access issuers' certificates
4.6.4 Per-Recipient Encapsulated Header
This group of encapsulated header fields normally appears once
each of a message's named recipients. As a special case,
fields may be omitted in the case of a "MIC-ONLY" message
recipients for whom asymmetric key management is employed, given
the chosen MIC algorithm is keyless
4.6.4.1 X-Recipient-ID
The "X-Recipient-ID:" encapsulated header field identifies
recipient and provides the recipient's IK identification component
One "X-Recipient-ID:" field is included for each of a message's
recipients. It should be replicated within the encapsulated text
The field contains (in order) an Entity Identifier subfield,
Issuing Authority subfield, and a Version/Expiration subfield.
subfields are delimited by the colon character (":"),
followed by whitespace
Section 5.2, Interchange Keys, discusses the semantics of
subfields and 