Path: utzoo!attcan!uunet!ginosko!usc!ucsd!brian
From: br...@ucsd.EDU (Brian Kantor)
Newsgroups: comp.doc
Subject: RFC1113 - Privacy Enhancement for Internet Electronic Mail:
Part I -- Message Encipherment and Authentication Procedures
Message-ID: <1918@ucsd.EDU>
Date: 25 Aug 89 05:43:09 GMT
Distribution: na
Organization: The Avant-Garde of the Now, Ltd.
Lines: 1907
Approved: br...@cyberpunk.ucsd.edu
Network Working Group J. Linn
Request for Comments: 1113 DEC
Obsoletes RFCs: 989, 1040 IAB Privacy Task Force
August 1989
Privacy Enhancement for Internet Electronic Mail:
Part I -- Message Encipherment and Authentication Procedures
STATUS OF THIS MEMO
This RFC suggests a draft standard elective protocol for the Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of IAB Privacy Task Force
meetings and of internal working papers distributed for those
meetings. I would like to thank the following Privacy Task Force
members and meeting guests for their comments and contributions at
the meetings which led to the preparation of this RFC: David
Balenson, Curt Barker, Jim Bidzos, Matt Bishop, Danny Cohen, Tom
Daniel, Charles Fox, Morrie Gasser, Russ Housley, Steve Kent
(chairman), John Laws, Steve Lipner, Dan Nessett, Mike Padlipsky, Rob
Shirey, Miles Smid, Steve Walker, and Steve Wilbur.
Table of Contents
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 Summary
This RFC defines message encipherment and authentication procedures,
in order to provide privacy enhancement services for electronic mail
transfer in the Internet. It is one member of a related set of four
RFCs. The procedures defined in the current RFC 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-1114 specifies supporting key
management mechanisms based on the use of public-key certificates.
RFC-1115 specifies algorithm and related information relevant to the
current RFC and to RFC-1114. A subsequent RFC will provide 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, and
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 Agent
processes, with no special processing requirements imposed on the
Message Transfer System at endpoints or at intermediate relay sites.
This approach allows privacy enhancement facilities to be
incorporated on a site-by-site or user-by-user basis without impact
on other Internet entities. Interoperability among heterogeneous
components and mail transport facilities is supported.
2. Terminology
For descriptive purposes, this RFC uses some terms defined in the OSI
X.400 Message Handling System Model per the 1984 CCITT
Recommendations. This section replicates a portion of 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.
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
sender and recipient UAs. No privacy enhancements are offered for
message fields which are added or transformed by intermediate relay
points.
Linn [Page 3]
RFC 1113 Mail Privacy: Procedures August 1989
Authentication and integrity facilities are always applied to the
entirety of a message's text. No facility for confidentiality
without authentication is provided. Encryption facilities may be
applied selectively to portions of a message's contents; this allows
less sensitive portions of messages (e.g., descriptive fields) to be
processed by a recipient's delegate in the absence of the recipient's
personal cryptographic keys. In the limiting case, where the
entirety of message text is excluded from encryption, this feature
can be used to yield the effective combination of authentication and
integrity services without confidentiality.
In keeping with the Internet's heterogeneous constituencies and usage
modes, the measures defined here are applicable to a broad range of
Internet hosts and usage paradigms. In particular, 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 sender to be cognizant
of whether a message's intended recipient implements privacy
enhancements, in order that encoding and possible
encipherment will not be performed on a message whose
destination is not equipped to perform corresponding inverse
transformations.
3. The defined mechanisms are compatible with a range of mail
transport facilities (MTAs). Within the Internet,
electronic mail transport is effected by a variety of SMTP
implementations. Certain sites, accessible via SMTP,
forward mail into other mail processing environments (e.g.,
USENET, CSNET, BITNET). The privacy enhancements must be
able to operate across the SMTP realm; it is desirable that
they also be compatible with protection of electronic mail
sent between the SMTP environment and other connected
environments.
4. The defined mechanisms are compatible with a broad range of
electronic mail user agents (UAs). A large variety of
Linn [Page 4]
RFC 1113 Mail Privacy: Procedures August 1989
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
privacy-enhanced 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 privacy-enhanced mail with a higher assurance
level than a strictly UA-based approach would allow.
6. The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists (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. Different key management
mechanisms may be used for different recipients of a
multicast message. While support for a particular key
management mechanism is not a minimum essential requirement
for compatibility with this RFC, adoption of the public-key
certificate approach defined in companion RFC-1114 is
strongly recommended.
In order to achieve applicability to the broadest possible range of
Internet hosts and mail systems, and to facilitate pilot
implementation and testing without the need for prior modifications
throughout the Internet, three basic restrictions are imposed on the
set of measures to be considered in this RFC:
1. Measures will be restricted to implementation at endpoints
and will be amenable to integration at the user agent (UA)
level or above, rather than necessitating integration into
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 restricts
user capabilities. Trusted implementations, incorporating
integrity features protecting software from subversion by
local users, cannot be assumed in general. 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.
As a result of these restrictions, the following facilities can be
provided:
1. disclosure protection,
2. sender 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,
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
Linn [Page 6]
RFC 1113 Mail Privacy: Procedures August 1989
stream-oriented services.
A message's sender will determine whether privacy enhancements are to
be performed on a particular message. Therefore, a sender must be
able to determine whether particular recipients are equipped to
process privacy-enhanced mail. In a general architecture, these
mechanisms will be based on server queries; thus, the query function
could be integrated into a UA to avoid imposing burdens or
inconvenience on electronic mail users.
4. Processing of Messages
4.1 Message Processing Overview
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 privacy-enhanced
message 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. DEKs are generated individually for
each transmitted message; no predistribution of DEKs is
needed to support privacy-enhanced message transmission.
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission within messages. 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
associated with "X-Sender-ID:" and "X-Recipient-ID:" fields,
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
verification. The definition of an IK differs depending on
whether symmetric or asymmetric cryptography is used for DEK
encryption:
Linn [Page 7]
RFC 1113 Mail Privacy: Procedures August 1989
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 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 an
"X-Recipient-ID:" or "X-Sender-ID:" field,
respectively.
4.1.2 Processing Procedures
When privacy enhancement 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 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 one
identification component for the IK(s) used for message processing.
IK components are selected for each individually named recipient; a
corresponding "X-Recipient-ID:" field, interpreted in the context of
a prior "X-Sender-ID:" field, serves to identify each IK. Each "X-
Recipient-ID:" field is followed by an "X-Key-Info:" field, which
transfers a DEK encrypted under the IK appropriate for the specified
recipient. When symmetric key management is used for a given
recipient, the "X-Key-Info:" field also transfers the message's
computed MIC, encrypted under the recipient's IK. When asymmetric
key management is used, a prior "X-MIC-Info:" field carries the
message's MIC encrypted under the private component of the sender.
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
Linn [Page 8]
RFC 1113 Mail Privacy: Procedures August 1989
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 and encryption processes.
For encryption purposes, the canonical representation is padded as
required by the encryption algorithm. The padded canonical
representation is encrypted (except for any regions which are
explicitly excluded from encryption). The encrypted text (along with
the canonical representation of regions which were excluded from
encryption) is 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.
The output of the encoding procedure is combined with a set of header
fields carrying cryptographic control information. The result is
passed to the electronic mail system to be encapsulated as the text
portion of a transmitted message.
When a privacy-enhanced message is received, the cryptographic
control fields within its text portion provide the information
required for the authorized recipient to perform MIC verification and
decryption of the received message text. First, the printable
encoding is converted to a bitstring. Encrypted portions of the
transmitted message are decrypted. The MIC is verified. The
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 Modes
For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined
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), as
defined in FIPS PUB 46 [3]. When used for encryption of text, the
DEA-1 shall be used in the Cipher Block Chaining (CBC) mode, as
defined in ISO IS 8372 [4]. The identifier string "DES-CBC", defined
in RFC-1115, signifies this algorithm/mode combination. The CBC mode
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/or
modes for message text processing will require case-by-case study to
determine applicability and constraints. Additional algorithms and
modes approved for use in this context will be specified in
successors to RFC-1115.
It is an originator's responsibility to generate a new pseudorandom
initializing vector (IV) for each privacy-enhanced electronic mail
message unless the entirety of the message is excluded from
Linn [Page 9]
RFC 1113 Mail Privacy: Procedures August 1989
encryption. Section 4.3.1 of [17] provides rationale for this
requirement, even in a context where individual DEKs are generated
for individual messages. The IV will be transmitted with the
message.
Certain operations require that one key be encrypted under an
interchange key (IK) for purposes of transmission. A header facility
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 management
should support DES-ECB IK use, and all implementations using
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 message
processing procedures defined in this document. The message
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 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. In our approach, a canonicalization step is
performed to abstract out local conventions and a subsequent encoding
step is performed to conform to the characteristics of the underlying
mail transport medium (SMTP). The encoding conforms to SMTP
constraints, established to support interpersonal messaging. SMTP's
rules are also used independently in the canonicalization process.
RFC-821's [7] Section 4.5 details SMTP's transparency constraints.
To 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.
Linn [Page 10]
RFC 1113 Mail Privacy: Procedures August 1989
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 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 [8] server.
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.
4.3.2 Approach
Our approach to supporting privacy-enhanced mail across an
environment in which intermediate conversions may occur encodes mail
in a fashion which is uniformly representable across the set of
privacy-enhanced UAs regardless of their systems' native character
sets. This encoded form is used to represent mail text from sender
to recipient, but the encoding is not applied to enclosing mail
transport headers or to encapsulated headers inserted to carry
control information between privacy-enhanced UAs. The encoding's
characteristics are such that the transformations anticipated between
sender and recipient UAs will not prevent an encoded message from
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 from
encryption processing, but authentication processing is always
applied to the entirety of message text. Explicit action is required
to exclude a portion of a message from encryption processing; by
default, encryption is applied to the entirety of message text. The
user-level delimiter which specifies such exclusion is a local
matter, and hence may vary between sender and recipient, but all
systems should provide a means for unambiguous identification of
areas excluded from encryption processing.
An outbound privacy-enhanced message undergoes four transformation
steps, described in the following four subsections.
4.3.2.1 Step 1: Local Form
The message text is created in the system's native character set,
with lines delimited in accordance with local convention.
4.3.2.2 Step 2: Canonical Form
The entire message text, including both those portions subject to
encipherment processing and those portions excluded from such
processing, is converted to a universal canonical form, analogous to
the inter-SMTP representation [9] as defined in RFC-821 and RFC-822
[10] (ASCII character set, <CR><LF> line delimiters). The processing
required to perform this conversion is minimal on systems whose
native character set is ASCII. (Note: Since the output of the
canonical encoding process will never be submitted directly to SMTP,
but only to subsequent steps of the privacy enhancement encoding
process, the dot-stuffing transformation discussed in RFC-821,
section 4.5.2, is not required.) Since a message is converted to a
standard character set and representation before encryption, it can
be decrypted and its MIC can be verified at any type of destination
host computer. The decryption and MIC verification 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 Encipherment
The canonical form is input to the selected MIC computation algorithm
in order to compute an 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.
Padding is applied to the canonical form as needed to perform
encryption in the DEA-1 CBC mode, as follows: The number of octets to
be encrypted is determined by subtracting the number of octets
Linn [Page 12]
RFC 1113 Mail Privacy: Procedures August 1989
excluded from encryption from the total length of the canonically
encoded text. Octets with the hexadecimal value FF (all ones) are
appended to the canonical form as needed so that the text octets to
be encrypted, along with the added padding octets, fill an integral
number of 8-octet encryption quanta. No padding is applied if the
number of octets to be encrypted is already an integral multiple of
8. The use of hexadecimal FF (a value outside the 7-bit ASCII set)
as a padding value allows padding octets to be distinguished from
valid data without inclusion of an explicit padding count indicator.
The regions of the message which have not been excluded from
encryption are encrypted. To support selective encipherment
processing, an implementation must retain internal indications of the
positions of excluded areas excluded from encryption with relation to
non-excluded areas, so that those areas can be properly delimited in
the encoding procedure defined in step 4. If a region excluded from
encryption intervenes between encrypted regions, cryptographic state
(e.g., IVs and accumulation of octets into encryption quanta) is
preserved and continued after the excluded region.
4.3.2.4 Step 4: Printable Encoding
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). This
encoding step is performed for all privacy-enhanced messages, even if
an entire message is excluded from encryption.
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.)
Two additional characters, "=" and "*", are used to signify special
processing functions. The character "=" is used for padding within
the printable encoding procedure. The character "*" is used to
delimit the beginning and end of a region which has been excluded
from encipherment processing. 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.)
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
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 be
universally representable, and the set excludes characters with
particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
Special processing is performed if fewer than 24 bits are available
in an input group, either at the end of a message or (when the
selective encryption facility is invoked) at the end of an encrypted
region or an excluded region. A full encoding quantum is always
completed at the end of a message and before the delimiter "*" is
output to initiate or terminate the representation of a block
excluded from encryption. 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.
Linn [Page 14]
RFC 1113 Mail Privacy: Procedures August 1989
4.3.2.5 Summary of Transformations
In summary, the outbound message is subjected to the following
composition of transformations:
Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
The inverse transformations are performed, in reverse order, to
process inbound privacy-enhanced mail:
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y (1) *
(1) The character "*" is used to enclose portions of an
encoded message to which encryption processing has not
been applied.
Printable Encoding Characters
Table 1
Note that the local form and the functions to transform messages to
and from canonical form may vary between the sender and recipient
systems without loss of information.
4.4 Encapsulation Mechanism
Encapsulation of privacy-enhanced messages within an enclosing layer
Linn [Page 15]
RFC 1113 Mail Privacy: Procedures August 1989
of headers interpreted by the electronic mail transport system offers
a number of advantages in comparison to a flat approach in which
certain fields within a single header are encrypted and/or carry
cryptographic control information. 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. Further, privacy enhancement processing can be
applied recursively. As far as the MTS is concerned, information
incorporated into cryptographic authentication or encryption
processing will reside in a message's text portion, not its header
portion.
The encapsulation mechanism to be used for privacy-enhanced mail is
derived from that described in RFC-934 [11] which is, in turn, based
on precedents in the processing of message digests in the Internet
community. To prepare a user message for encrypted or authenticated
transmission, it will be transformed into the representation shown in
Figure 1.
As a general design principle, sensitive data is protected by
incorporating the data within the encapsulated text rather than by
applying measures selectively to fields in the enclosing header.
Examples of potentially sensitive header information may include
fields such as "Subject:", with contents which are significant on an
end-to-end, inter-user basis. The (possibly empty) set of headers to
which protection is to be applied is a user option. It is strongly
recommended, however, that all implementations should replicate
copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the
encapsulated text.
If a user wishes disclosure protection for header fields, they must
occur only in the encapsulated text and not in the enclosing or
encapsulated header. If disclosure protection is desired for a
message's subject indication, it is recommended that the enclosing
header contain a "Subject:" field indicating that "Encrypted Mail
Follows".
If an authenticated version of header information is desired, that
data can be replicated within the encapsulated text portion in
addition to its inclusion in the enclosing header. For example, a
sender wishing to provide recipients with a protected indication of a
message's position in a series of messages could include a copy of a
timestamp or message counter field within the encapsulated text.
A specific point regarding the integration of privacy-enhanced mail
Linn [Page 16]
RFC 1113 Mail Privacy: Procedures August 1989
facilities with the message encapsulation mechanism is worthy of
note. The subset of IA5 selected for transmission encoding
intentionally excludes the character "-", so encapsulated text can be
distinguished unambiguously from a message's closing encapsulation
boundary (Post-EB) without recourse to character stuffing.
Enclosing Header Portion
(Contains header fields per RFC-822)
Blank Line
(Separates Enclosing Header from Encapsulated Message)
Encapsulated Message
Pre-Encapsulation Boundary (Pre-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Encapsulated Header Portion
(Contains encryption control fields inserted in plaintext.
Examples include "X-DEK-Info:", "X-Sender-ID:", and
"X-Key-Info:".
Note that, although these control fields have line-oriented
representations similar to RFC-822 header fields, the set
of fields valid in this context is disjoint from those used
in RFC-822 processing.)
Blank Line
(Separates Encapsulated Header from subsequent encoded
Encapsulated Text Portion)
Encapsulated Text Portion
(Contains message data encoded as specified in Section 4.3;
may incorporate protected copies of enclosing and
encapsulated header fields such as "Subject:", etc.)
Post-Encapsulation Boundary (Post-EB)
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Message Encapsulation
Figure 1
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. The choice depends on the information available to
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 constituent
destinations, is implied. Such an IK must, therefore, be available
to all list members. For the case of asymmetric key management, the
list's private component must be available to all list members. This
alternative will be the normal case for messages sent via remote
exploder sites, as a sender to such lists may not be cognizant of the
set of individual recipients. 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 sender to the
list for authentication purposes.
If, in contrast, a message's sender is equipped to expand the
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 "X-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.
4.6 Summary of Encapsulated Header Fields
This section summarizes 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. In certain indicated cases, it is recommended
that the fields be replicated within the encapsulated text portion as
well as being included within the encapsulated header. Figures 2 and
3 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 message in which
asymmetric key management is used.
Unless otherwise specified, all field arguments are 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
Linn [Page 18]
RFC 1113 Mail Privacy: Procedures August 1989
ranges "0"-"9" or upper case "A"-"F". Since public-key certificates
and quantities encrypted 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. The example shown in Figure 3 shows asymmetrically
encrypted quantities (e.g., "X-MIC-Info:", "X-Key-Info:") with 64-
character printed representations, corresponding to 384 bits. The
fields carrying asymmetrically encrypted quantities also illustrate
the use of folding as defined in RFC-822, section 3.1.1.
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 3,ENCRYPTED
X-DEK-Info: DES-CBC,F8143EDE5960C597
X-Sender-ID: li...@ccy.bbn.com::
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3
X-Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCD,
A60195DB94F727D3
X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4
X-Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF7,
9F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message (Symmetric Case)
Figure 2
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 3,ENCRYPTED
X-DEK-Info: DES-CBC,F8143EDE5960C597
X-Sender-ID: li...@ccy.bbn.com::
X-Certificate:
jHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIk
YbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUz
agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bATMtPjCUWbz8Lr9wloXIkYbkNpk0
X-Issuer-Certificate:
TMtPjCUWbz8Lr9wloXIkYbkNpk0agV2IzUpk8tEjmFjHUlBLpvXR0UrUz/zxB+bA
IkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloX
vXR0UrUzYbkNpk0agV2IzUpk8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLp
X-MIC-Info: RSA-MD2,RSA,
5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpotJ6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz
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+bATMtPjCUWbz8Lr9wloXIkjHU
X-Recipient-ID: privacy-tf@venera.isi.edu:RSADSI:4
X-Key-Info: RSA,
NcUk2jHEUSoH1nvNSIWL9MLLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72oh
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message (Asymmetric Case)
Figure 3
Although the encapsulated header fields resemble RFC-822 header
fields, they are a disjoint set and will not in general be processed
by the same parser which operates on enclosing header fields. The
complexity of lexical analysis needed and appropriate for
encapsulated header field processing is significantly less than that
appropriate to RFC-822 header processing. For example, many
characters with special significance to RFC-822 at the syntactic
level have no such significance within encapsulated header fields.
When the length of an encapsulated header field is longer than the
size conveniently printable on a line, whitespace may be used to fold
the field in the manner of RFC-822, section 3.1.1. Any such inserted
whitespace is not to be interpreted as a part of a subfield. As a
particular example, due to the length of public-key certificates and
of quantities encrypted using asymmetric algorithms, such quantities
may often need to be folded across multiple printed lines. In order
to facilitate such folding in a uniform manner, the bits representing
such a quantity are to be divided into an ordered set (with leftmost
bits first) of zero or more 384-bit groups (corresponding to 64-
character printed representations), followed by a final group of bits
which may be any length up to 384 bits.
4.6.1 Per-Message Encapsulated Header Fields
This group of encapsulated header fields contains fields which occur
no more than once in a privacy-enhanced message, generally preceding
all other encapsulated header fields.
4.6.1.1 X-Proc-Type Field
The "X-Proc-Type:" encapsulated header field, required for all
privacy-enhanced messages, identifies the type of processing
Linn [Page 20]
RFC 1113 Mail Privacy: Procedures August 1989
performed on the transmitted message. Only one "X-Proc-Type:" field
occurs in a message; the "X-Proc-Type:" field must be the first
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 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 "3" to
distinguish them from messages processed in accordance with prior
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 is
excluded from encryption, the "X-Proc-Type:" field's second subfield
must specify "ENCRYPTED". 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, "X-Recipient-ID:" and "X-Key-Info:" fields can be
omitted for recipients for whom asymmetric cryptography is used,
assuming concurrent use of a keyless MIC computation algorithm. The
"X-DEK-Info:" field can be omitted for all "MIC-ONLY" messages.
4.6.1.2 X-DEK-Info Field
The "X-DEK-Info:" encapsulated header field identifies the message
text encryption algorithm and mode, and also carries the Initializing
Vector used for message encryption. No more than one "X-DEK-Info:"
field occurs in a message; the field is required except for messages
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 string
"DES-CBC", signifying (as defined in RFC-1115) use of the DES
algorithm in the CBC mode. The second argument represents a 64-bit
Initializing Vector (IV) as a contiguous string of 16 hexadecimal
digits. Subsequent revisions of RFC-1115 will specify any additional
values which may appear as the first argument of this field.
4.6.2 Encapsulated Header Fields Normally Per-Message
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. The "X-Sender-ID" field may occur more than once
in a message if different sender-oriented IK components (perhaps
corresponding to different versions) must be used for different
Linn [Page 21]
RFC 1113 Mail Privacy: Procedures August 1989
recipients. In this case later occurrences override prior
occurrences. If a mixture of symmetric and asymmetric key
distribution is used within a single message, the recipients for each
type of key distribution technology should be grouped together to
simplify parsing.
4.6.2.1 X-Sender-ID Field
The "X-Sender-ID:" encapsulated header field, required for all
privacy-enhanced messages, identifies a message's sender and provides
the sender's IK identification component. It should be replicated
within the encapsulated text. The IK identification component
carried in an "X-Sender-ID:" field is used in conjunction with all
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 Identifier
subfield, an (optional) Issuing Authority subfield, and an (optional)
Version/Expiration subfield. The optional subfields are omitted if
their use is rendered redundant by information carried in subsequent
"X-Recipient-ID:" fields; this will ordinarily be the case where
symmetric cryptography is used for key management. The subfields are
delimited by the colon 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.
Note that multiple "X-Sender-ID:" fields may occur within a single
encapsulated header. All "X-Recipient-ID:" fields are interpreted in
the context of the most recent preceding "X-Sender-ID:" field; it is
illegal for an "X-Recipient-ID:" field to occur in a header before an
"X-Sender-ID:" has been provided.
4.6.2.2 X-Certificate Field
The "X-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 a
sender's certificate as a numeric quantity, represented with the
encoding mechanism defined in Section 4.3.2.4 of this RFC. The
semantics of a certificate are discussed in RFC-1114. The
certificate carried in an "X-Certificate:" field is used in
conjunction with "X-Sender-ID:" and "X-Recipient-ID:" fields for
which asymmetric key management is employed.
Linn [Page 22]
RFC 1113 Mail Privacy: Procedures August 1989
4.6.2.3 X-MIC-Info Field
The "X-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; RFC-1115 specifies the acceptable set of MIC algorithm
identifiers. The second argument identifies the algorithm under
which the accompanying MIC is encrypted; for purposes of this RFC,
the string "RSA" as described in RFC-1115 must occur, identifying
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 encrypted
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 the
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 whom
asymmetric key management is used.
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.
4.6.3.1 X-Issuer-Certificate Field
The "X-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 "X-Issuer-Certificate:" field would
contain the certificate containing the public component used to sign
the certificate carried in the message's "X-Certificate:" field, for
recipients' use in chaining through that certificate's certification
path. Other "X-Issuer-Certificate:" fields, typically representing
higher points in a certification path, also may be included by a
sender. The order in which "X-Issuer-Certificate:" fields are
included need not correspond to the order of the certification path;
the order of that path may in general differ from the viewpoint of
different recipients. More information on certification paths can be
found in RFC-1114.
The certificate is represented in the same manner as defined for the
"X-Certificate:" field, and any "X-Issuer-Certificate:" fields will
ordinarily follow the "X-Certificate:" field directly. Use of the
Linn [Page 23]
RFC 1113 Mail Privacy: Procedures August 1989
"X-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
This group of encapsulated header fields normally appears once for
each of a message's named recipients. As a special case, these
fields may be omitted in the case of a "MIC-ONLY" message to
recipients for whom asymmetric key management is employed, given that
the chosen MIC algorithm is keyless.
4.6.4.1 X-Recipient-ID Field
The "X-Recipient-ID:" encapsulated header field identifies a
recipient and provides the recipient's IK identification component.
One "X-Recipient-ID:" field is included for each of a message's named
recipients. It should be replicated within the encapsulated text.
The field contains (in order) an Entity Identifier subfield, an
Issuing Authority subfield, and a Version/Expiration subfield. The
subfields are delimited by the colon character (":"), optionally
followed by whitespace.
Section 5.2, Interchange Keys, discusses the semantics of the
subfields and specifies the alphabet from which they are chosen. All
"X-Recipient-ID:" fields are interpreted in the context of the most
recent preceding "X-Sender-ID:" field; it is illegal for an "X-
Recipient-ID:" field to occur in a header before an "X-Sender-ID:"
has been provided.
4.6.4.2 X-Key-Info Field
One "X-Key-Info:" field is included for each of a message's named
recipients. Each "X-Key-Info:" field is interpreted in the context
of the most recent preceding "X-Recipient-ID:" field; normally, an
"X-Key-Info:" field will immediately follow its associated "X-
Recipient-ID:" field. The field's argument(s) differ depending on
whether symmetric or asymmetric key management is used for a
particular recipient.
4.6.4.2.1 Symmetric Key Management
When symmetric key management is employed for a given recipient, the
"X-Key-Info:" encapsulated header field transfers four items,
separated by commas: an IK Use Indicator, a MIC Algorithm Indicator,
a DEK and a MIC. The IK Use Indicator identifies the algorithm and
mode in which the identified IK was used for DEK encryption for a
Linn [Page 24]
RFC 1113 Mail Privacy: Procedures August 1989
particular recipient. For recipients for whom symmetric key
management is used, it may assume the reserved string values "DES-
ECB" or "DES-EDE", as defined in RFC-1115.
The MIC Algorithm Indicator identifies the MIC computation algorithm
used for a particular recipient; values for this subfield are defined
in RFC-1115. The DEK and MIC are encrypted under the IK identified
by a preceding "X-Recipient-ID:" field and prior "X-Sender-ID:"
field; they are represented as two strings of contiguous hexadecimal
digits, separated by a comma.
When DEA-1 is used for message text encryption, the DEK
representation will be 16 hexadecimal digits (corresponding to a 64-
bit key); this subfield can be extended to 32 hexadecimal digits
(corresponding to a 128-bit key) if required to support other
algorithms.
Symmetric encryption of MICs is always performed in the same
encryption mode used to encrypt the message's DEK. Encrypted MICs,
like encrypted DEKs, are represented as contiguous strings of
hexadecimal digits. The size of a MIC is dependent on the choice of
MIC algorithm as specified in the MIC Algorithm Indicator subfield.
4.6.4.2.2 Asymmetric Key Management
When asymmetric key management is employed for a given recipient, the
"X-Key-Info:" field transfers two quantities, separated by commas.
The first argument is an IK Use Indicator identifying the algorithm
(and mode, if applicable) in which the DEK is encrypted; for purposes
of this RFC, the IK Use Indicator subfield will always assume the
reserved string value "RSA" (as defined in RFC-1115) for recipients
for whom asymmetric key management is employed, signifying use of the
RSA algorithm. The second argument is a DEK, encrypted (using
asymmetric encryption) under the recipient's public component.
Throughout this RFC we have adopted the terms "private component" and
"public component" to refer to the quantities which are,
respectively, kept secret and made publically available in asymmetric
cryptosystems. This convention is adopted to avoid possible
confusion arising from use of the term "secret key" to refer to
either the former quantity or to a key in a symmetric cryptosystem.
As discussed earlier in this section, the asymmetrically encrypted
DEK is represented using the technique described in Section 4.3.2.4
of this RFC.
Linn [Page 25]
RFC 1113 Mail Privacy: Procedures August 1989
5. Key Management
Several cryptographic constructs are involved in supporting the
privacy-enhanced message processing procedure. A set of fundamental
elements is assumed. Data Encrypting Keys (DEKs) are used to encrypt
message text and (for some MIC computation algorithms) in the message
integrity check (MIC) computation process. Interchange Keys (IKs)
are used to encrypt DEKs and MICs for transmission with messages. In
a certificate-based asymmetric key management architecture,
certificates are used as a means to provide entities' public
components and other information in a fashion which is securely bound
by a central authority. The remainder of this section provides more
information about these constructs.
5.1 Data Encrypting Keys (DEKs)
Data Encrypting Keys (DEKs) are used for encryption of message text
and (with some MIC computation algorithms) for computation of message
integrity check quantities (MICs). It is strongly recommended that
DEKs be generated and used on a one-time, per-message, basis. A
transmitted message will incorporate a representation of the DEK
encrypted under an appropriate interchange key (IK) for each of the
named recipients.
DEK generation can be performed either centrally by key distribution
centers (KDCs) or by endpoint systems. Dedicated KDC systems may be
able to implement stronger algorithms for random DEK generation than
can be supported in endpoint systems. On the other hand,
decentralization allows endpoints to be relatively self-sufficient,
reducing the level of trust which must be placed in components other
than a message's originator and recipient. Moreover, decentralized
DEK generation at endpoints reduces the frequency with which senders
must make real-time queries of (potentially unique) servers in order
to send mail, enhancing communications availability.
When symmetric cryptography is used, one advantage of centralized
KDC-based generation is that DEKs can be returned to endpoints
already encrypted under the IKs of message recipients rather than
providing the IKs to the senders. This reduces IK exposure and
simplifies endpoint key management requirements. This approach has
less value if asymmetric cryptography is used for key management,
since per-recipient public IK components are assumed to be generally
available and per-sender private IK components need not necessarily
be shared with a KDC.
5.2 Interchange Keys (IKs)
Interchange Key (IK) components are used to encrypt DEKs and MICs.
Linn [Page 26]
RFC 1113 Mail Privacy: Procedures August 1989
In general, IK granularity is at the pairwise per-user level except
for mail sent to address lists comprising multiple users. In order
for two principals to engage in a useful exchange of privacy-enhanced
electronic mail using conventional cryptography, they must first
possess common IK components (when symmetric key management is used)
or complementary IK components (when asymmetric key management is
used). When symmetric cryptography is used, the IK consists of a
single component, used to encrypt both DEKs and MICs. When
asymmetric cryptography is used, a recipient's public component is
used as an IK to encrypt DEKs (a transformation invertible only by a
recipient possessing the corresponding private component), and the
originator's private component is used to encrypt MICs (a
transformation invertible by all recipients, since the originator's
certificate provides the necessary public component of the
originator).
While this RFC does not prescribe the means by which interchange keys
are provided to appropriate parties, it is useful to note that such
means may be centralized (e.g., via key management servers) or
decentralized (e.g., via pairwise agreement and direct distribution
among users). In any case, any given IK component is associated with
a responsible Issuing Authority (IA). When certificate-based
asymmetric key management, as discussed in RFC-1114, is employed, the
IA function is performed by a Certification Authority (CA).
When an IA generates and distributes an IK component, associated
control information is provided to direct how it is to be used. In
order to select the appropriate IK(s) to use in message encryption, a
sender must retain a correspondence between IK components and the
recipients with which they are associated. Expiration date
information must also be retained, in order that cached entries may
be invalidated and replaced as appropriate.
Since a message may be sent with multiple IK components identified,
corresponding to multiple intended recipients, each recipient's UA
must be able to determine that recipient's intended IK component.
Moreover, if no corresponding IK component is available in the
recipient's database when a message arrives, the recipient must be
able to identify the required IK component and identify that IK
component's associated IA. Note that different IKs may be used for
different messages between a pair of communicants. Consider, for
example, one message sent from A to B and another message sent (using
the IK-per-list method) from A to a mailing list of which B is a
member. The first message would use IK components associated
individually with A and B, but the second would use an IK component
shared among list members.
When a privacy-enhanced message is transmitted, an indication of the
Linn [Page 27]
RFC 1113 Mail Privacy: Procedures August 1989
IK components used for DEK and MIC encryption must be included. To
this end, the "X-Sender-ID:" and "X-Recipient-ID:" encapsulated
header fields provide the following data:
1. Identification of the relevant Issuing Authority (IA subfield)
2. Identification of an entity with which a particular IK
component is associated (Entity Identifier or EI subfield)
3. Version/Expiration subfield
The colon character (":") is used to delimit the subfields within an
"X-Sender-ID:" or "X-Recipient-ID:". The IA, EI, and
version/expiration subfields are generated from a restricted
character set, as prescribed by the following BNF (using notation as
defined in RFC-822, sections 2 and 3.3):
IKsubfld := 1*ia-char
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"," / "." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
An example "X-Recipient-ID:" field is as follows:
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2
This example field indicates that IA "ptf-kmc" has issued an IK
component for use on messages sent to "li...@ccy.bbn.com", and that
the IA has provided the number 2 as a version indicator for that IK
component.
5.2.1 Subfield Definitions
The following subsections define the subfields of "X-Sender-ID:" and
"X-Recipient-ID:" fields.
5.2.1.1 Entity Identifier Subfield
An entity identifier is constructed as an IKsubfld. More
restrictively, an entity identifier subfield assumes the following
form:
<user>@<domain-qualified-host>
In order to support universal interoperability, it is necessary to
assume a universal form for the naming information. For the case of
installations which transform local host names before transmission
into the broader Internet, it is strongly recommended that the host
Linn [Page 28]
RFC 1113 Mail Privacy: Procedures August 1989
name as presented to the Internet be employed.
5.2.1.2 Issuing Authority Subfield
An IA identifier subfield is constructed as an IKsubfld. IA
identifiers must be assigned in a manner which assures uniqueness.
This can be done on a centralized or hierarchic basis.
5.2.1.3 Version/Expiration Subfield
A version/expiration subfield is constructed as an IKsubfld. The
version/expiration subfield format may vary among different IAs, but
must satisfy certain functional constraints. An IA's
version/expiration subfields must be sufficient to distinguish among
the set of IK components issued by that IA for a given identified
entity. Use of a monotonically increasing number is sufficient to
distinguish among the IK components provided for an entity by an IA;
use of a timestamp additionally allows an expiration time or date to
be prescribed for an IK component.
5.2.2 IK Cryptoperiod Issues
An IK component's cryptoperiod is dictated in part by a tradeoff
between key management overhead and revocation responsiveness. It
would be undesirable to delete an IK component permanently before
receipt of a message encrypted using that IK component, as this would
render the message permanently undecipherable. Access to an expired
IK component would be needed, for example, to process mail received
by a user (or system) which had been inactive for an extended period
of time. In order to enable very old IK components to be deleted, a
message's recipient desiring encrypted local long term storage should
transform the DEK used for message text encryption via re-encryption
under a locally maintained IK, rather than relying on IA maintenance
of old IK components for indefinite periods.
6. User Naming
6.1 Current Approach
Unique naming of electronic mail users, as is needed in order to
select corresponding keys correctly, is an important topic and one
which has received significant study. Our current architecture
associates IK components with user names represented in a universal
form ("user@domain-qualified-host"), relying on the following
properties:
1. The universal form must be specifiable by an IA as it
distributes IK components and known to a UA as it processes
Linn [Page 29]
RFC 1113 Mail Privacy: Procedures August 1989
received IK components and IK component identifiers. If a
UA or IA uses addresses in a local form which is different
from the universal form, it must be able to perform an
unambiguous mapping from the universal form into the local
representation.
2. The universal form, when processed by a sender UA, must have
a recognizable correspondence with the form of a recipient
address as specified by a user (perhaps following local
transformation from an alias into a universal form).
It is difficult to ensure these properties throughout the Internet.
For example, an MTS which transforms address representations between
the local form used within an organization and the universal form as
used for Internet mail transmission may cause property 2 to be
violated.
6.2 Issues for Consideration
The use of flat (non-hierarchic) electronic mail user identifiers,
which are unrelated to the hosts on which the users reside, may offer
value. As directory servers become more widespread, it may become
appropriate for would-be senders to search for desired recipients
based on such attributes. Personal characteristics, like social
security numbers, might be considered. Individually-selected
identifiers could be registered with a central authority, but a means
to resolve name conflicts would be necessary.
A point of particular note is the desire to accommodate multiple
names for a single individual, in order to represent and allow
delegation of various roles in which that individual may act. A
naming mechanism that binds user roles to keys is needed. Bindings
cannot be immutable since roles sometimes change (e.g., the
comptroller of a corporation is fired).
It may be appropriate to examine the prospect of extending the
DARPA/DoD domain system and its associated name servers to resolve
user names to unique user IDs. An additional issue arises with
regard to mailing list support: name servers do not currently perform
(potentially recursive) expansion of lists into users. ISO and CSNet
are working on user-level directory service mechanisms, which may
also bear consideration.
7. Example User Interface and Implementation
In order to place the mechanisms and approaches discussed in this RFC
into context, this section presents an overview of a prototype
implementation. This implementation is a standalone program which is
Linn [Page 30]
RFC 1113 Mail Privacy: Procedures August 1989
invoked by a user, and lies above the existing UA sublayer. In the
UNIX system, and possibly in other environments as well, such a
program can be invoked as a "filter" within an electronic mail UA or
a text editor, simplifying the sequence of operations which must be
performed by the user. This form of integration offers the advantage
that the program can be used in conjunction with a range of UA
programs, rather than being compatible only with a particular UA.
When a user wishes to apply privacy enhancements to an outgoing
message, the user prepares the message's text and invokes the
standalone program (interacting with the program in order to provide
address information and other data required to perform privacy
enhancement processing), which in turn generates output suitable for
transmission via the UA. When a user receives a privacy-enhanced
message, the UA delivers the message in encrypted form, suitable for
decryption and associated processing by the standalone program.
In this prototype implementation (based on symmetric key management),
a cache of IK components is maintained in a local file, with entries
managed manually based on information provided by originators and
recipients. This cache is, effectively, a simple database. IK
components are selected for transmitted messages based on the
sender's identity and on recipient names, and corresponding "X-
Sender-ID:" and "X-Recipient-ID:" fields are placed into the
message's encapsulated header. When a message is received, these
fields are used as a basis for a lookup in the database, yielding the
appropriate IK component entries. DEKs and IVs are generated
dynamically within the program.
Options and destination addresses are selected by command line
arguments to the standalone program. The function of specifying
destination addresses to the privacy enhancement program is logically
distinct from the function of specifying the corresponding addresses
to the UA for use by the MTS. This separation results from the fact
that, in many cases, the local form of an address as specified to a
UA differs from the Internet global form as used in "X-Sender-ID:"
and "X-Recipient-ID:" fields.
8. Areas For Further Study
The procedures defined in this RFC are sufficient to support
implementation of privacy-enhanced electronic mail transmission among
cooperating parties in the Internet. Further effort will be needed,
however, to enhance robustness, generality, and interoperability. In
particular, further work is needed in the following areas:
1. User naming techniques, and their relationship to the domain
system, name servers, directory services, and key management
Linn [Page 31]
RFC 1113 Mail Privacy: Procedures August 1989
functions.
2. Detailed standardization of Issuing Authority and directory
service functions and interactions.
3. Privacy-enhanced interoperability with X.400 mail.
We anticipate generation of subsequent RFCs which will address these
topics.
9. References
This section identifies background references which may be useful to
those contemplating use of the mechanisms defined in this RFC.
ISO 7498/Part 2 - Security Architecture, prepared by ISO/TC97/SC
21/WG 1 Ad hoc group on Security, extends the OSI Basic Reference
Model to cover security aspects which are general architectural
elements of communications protocols, and provides an annex with
tutorial and background information.
US Federal Information Processing Standards Publication (FIPS
PUB) 46, Data Encryption Standard, 15 January 1977, defines the
encipherment algorithm used for message text encryption and
Message Authentication Code (MAC) computation.
FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
specific modes in which the Data Encryption Standard algorithm
may to be used to perform encryption.
FIPS PUB 113, Computer Data Authentication, May 1985, defines a
specific procedure for use of the Data Encryption Standard
algorithm to compute a MAC.
NOTES:
[1] Key generation for MIC computation and message text encryption
may either be performed by the sending host or by a centralized
server. This RFC does not constrain this design alternative.
Section 5.1 identifies possible advantages of a centralized
server approach if symmetric key management is employed.
[2] American National Standard Data Encryption Algorithm (ANSI
X3.92-1981), American National Standards Institute, Approved 30
December 1980.
[3] Federal Information Processing Standards Publication 46, Data
Encryption Standard, 15 January 1977.
Linn [Page 32]
RFC 1113 Mail Privacy: Procedures August 1989
[4] Information Processing Systems: Data Encipherment: Modes of
Operation of a 64-bit Block Cipher.
[5] Federal Information Processing Standards Publication 81, DES
Modes of Operation, 2 December 1980.
[6] ANSI X9.17-1985, American National Standard, Financial
Institution Key Management (Wholesale), American Bankers
Association, April 4, 1985, Section 7.2.
[7] Postel, J., "Simple Mail Transfer Protocol" RFC-821,
USC/Information Sciences Institute, August 1982.
[8] This transformation should occur only at an SMTP endpoint, not at
an intervening relay, but may take place at a gateway system
linking the SMTP realm with other environments.
[9] Use of the SMTP canonicalization procedure at this stage was
selected since it is widely used and implemented in the Internet
community, not because SMTP interoperability with this
intermediate result is required; no privacy-enhanced message will
be passed to SMTP for transmission directly from this step in the
four-phase transformation procedure.
[10] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC-822, August 1982.
[11] Rose, M. and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC-934, January 1985.
[12] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and
Procedures".
[13] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[14] Kille, S., "Mapping between X.400 and RFC-822", RFC-987, June
1986.
[15] Federal Information Processing Standards Publication 113,
Computer Data Authentication, May 1985.
[16] American National Standard for Information Systems - Data
Encryption Algorithm - Modes of Operation (ANSI X3.106-1983),
American National Standards Institute - Approved 16 May 1983.
[17] Voydock, V. and S. Kent, "Security Mechanisms in High-Level
Linn [Page 33]
RFC 1113 Mail Privacy: Procedures August 1989
Network Protocols", ACM Computing Surveys, Vol. 15, No. 2, Pages
135-171, June 1983.
Author's Address
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
Phone: 508-264-5491
EMail: Li...@ultra.enet.dec.com
Linn [Page 34]
Path: utzoo!attcan!uunet!ginosko!usc!ucsd!brian
From: br...@ucsd.EDU (Brian Kantor)
Newsgroups: comp.doc
Subject: RFC1114 - Privacy Enhancement for Internet Electronic Mail:
Part II -- Certificate-Based Key Management
Message-ID: <1919@ucsd.EDU>
Date: 25 Aug 89 05:44:27 GMT
Distribution: na
Organization: The Avant-Garde of the Now, Ltd.
Lines: 1403
Approved: br...@cyberpunk.ucsd.edu
Network Working Group S. Kent
Request for Comments: 1114 BBNCC
J. Linn
DEC
IAB Privacy Task Force
August 1989
Privacy Enhancement for Internet Electronic Mail:
Part II -- Certificate-Based Key Management
STATUS OF THIS MEMO
This RFC suggests a draft standard elective protocol for the Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of IAB Privacy Task Force
meetings and of internal working papers distributed for those
meetings. We would like to thank the members of the Privacy Task
Force for their comments and contributions at the meetings which led
to the preparation of this RFC: David Balenson, Curt Barker, Matt
Bishop, Morrie Gasser, Russ Housley, Dan Nessett, Mike Padlipsky, Rob
Shirey, and Steve Wilbur.
Table of Contents
1. Executive Summary 2
2. Overview of Approach 3
3. Architecture 4
3.1 Scope and Restrictions 4
3.2 Relation to X.509 Architecture 7
3.3 Entities' Roles and Responsibilities 7
3.3.1 Users and User Agents 8
3.3.2 Organizational Notaries 9
3.3.3 Certification Authorities 11
3.3.3.1 Interoperation Across Certification Hierarchy Boundaries 14
3.3.3.2 Certificate Revocation 15
3.4 Certificate Definition and Usage 17
3.4.1 Contents and Use 17
3.4.1.1 Version Number 18
3.4.1.2 Serial Number 18
3.4.1.3 Subject Name 18
3.4.1.4 Issuer Name 19
3.4.1.5 Validity Period 19
3.4.1.6 Subject Public Component 20
Kent & Linn [Page 1]
RFC 1114 Mail Privacy: Key Management August 1989
3.4.1.7 Certificate Signature 20
3.4.2 Validation Conventions 20
3.4.3 Relation with X.509 Certificate Specification 22
NOTES 24
1. Executive Summary
This is one of a series of RFCs defining privacy enhancement
mechanisms for electronic mail transferred using Internet mail
protocols. RFC-1113 (the successor to RFC 1040) prescribes protocol
extensions and processing procedures for RFC-822 mail messages, given
that suitable cryptographic keys are held by originators and
recipients as a necessary precondition. RFC-1115 specifies
algorithms for use in processing privacy-enhanced messages, as called
for in RFC-1113. This RFC defines a supporting key management
architecture and infrastructure, based on public-key certificate
techniques, to provide keying information to message originators and
recipients. A subsequent RFC, the fourth in this series, will
provide detailed specifications, paper and electronic application
forms, etc. for the key management infrastructure described herein.
The key management architecture described in this RFC is compatible
with the authentication framework described in X.509. The major
contributions of this RFC lie not in the specification of computer
communication protocols or algorithms but rather in procedures and
conventions for the key management infrastructure. This RFC
incorporates numerous conventions to facilitate near term
implementation. Some of these conventions may be superceded in time
as the motivations for them no longer apply, e.g., when X.500 or
similar directory servers become well established.
The RSA cryptographic algorithm, covered in the U.S. by patents
administered through RSA Data Security, Inc. (hereafter abbreviated
RSADSI) has been selected for use in this key management system.
This algorithm has been selected because it provides all the
necessary algorithmic facilities, is "time tested" and is relatively
efficient to implement in either software or hardware. It is also
the primary algorithm identified (at this time) for use in
international standards where an asymmetric encryption algorithm is
required. Protocol facilities (e.g., algorithm identifiers) exist to
permit use of other asymmetric algorithms if, in the future, it
becomes appropriate to employ a different algorithm for key
management. However, the infrastructure described herein is specific
to use of the RSA algorithm in many respects and thus might be
different if the underlying algorithm were to change.
Current plans call for RSADSI to act in concert with subscriber
organizations as a "certifying authority" in a fashion described
Kent & Linn [Page 2]
RFC 1114 Mail Privacy: Key Management August 1989
later in this RFC. RSADSI will offer a service in which it will sign
a certificate which has been generated by a user and vouched for
either by an organization or by a Notary Public. This service will
carry a $25 biennial fee which includes an associated license to use
the RSA algorithm in conjunction with privacy protection of
electronic mail. Users who do not come under the purview of the RSA
patent, e.g., users affiliated with the U.S. government or users
outside of the U.S., may make use of different certifying authorities
and will not require a license from RSADSI. Procedures for
interacting with these other certification authorities, maintenance
and distribution of revoked certificate lists from such authorities,
etc. are outside the scope of this RFC. However, techniques for
validating certificates issued by other authorities are contained
within the RFC to ensure interoperability across the resulting
jurisdictional boundaries.
2. Overview of Approach
This RFC defines a key management architecture based on the use of
public-key certificates, in support of the message encipherment and
authentication procedures defined in RFC-1113. In the proposed
architecture, a "certification authority" representing an
organization applies a digital signature to a collection of data
consisting of a user's public component, various information that
serves to identify the user, and the identity of the organization
whose signature is affixed. (Throughout this RFC we have adopted the
terms "private component" and "public component" to refer to the
quantities which are, respectively, kept secret and made publically
available in asymmetric cryptosystems. This convention is adopted to
avoid possible confusion arising from use of the term "secret key" to
refer to either the former quantity or to a key in a symmetric
cryptosystem.) This establishes a binding between these user
credentials, the user's public component and the organization which
vouches for this binding. The resulting signed, data item is called
a certificate. The organization identified as the certifying
authority for the certificate is the "issuer" of that certificate.
In signing the certificate, the certification authority vouches for
the user's identification, especially as it relates to the user's
affiliation with the organization. The digital signature is affixed
on behalf of that organization and is in a form which can be
recognized by all members of the privacy-enhanced electronic mail
community. Once generated, certificates can be stored in directory
servers, transmitted via unsecure message exchanges, or distributed
via any other means that make certificates easily accessible to
message originators, without regard for the security of the
transmission medium.
Kent & Linn [Page 3]
RFC 1114 Mail Privacy: Key Management August 1989
Prior to sending an encrypted message, an originator must acquire a
certificate for each recipient and must validate these certificates.
Briefly, validation is performed by checking the digital signature in
the certificate, using the public component of the issuer whose
private component was used to sign the certificate. The issuer's
public component is made available via some out of band means
(described later) or is itself distributed in a certificate to which
this validation procedure is applied recursively.
Once a certificate for a recipient is validated, the public component
contained in the certificate is extracted and used to encrypt the
data encryption key (DEK) that is used to encrypt the message itself.
The resulting encrypted DEK is incorporated into the X-Key-Info field
of the message header. Upon receipt of an encrypted message, a
recipient employs his secret component to decrypt this field,
extracting the DEK, and then uses this DEK to decrypt the message.
In order to provide message integrity and data origin authentication,
the originator generates a message integrity code (MIC), signs
(encrypts) the MIC using the secret component of his public-key pair,
and includes the resulting value in the message header in the X-MIC-
Info field. The certificate of the originator is also included in
the header in the X-Certificate field as described in RFC-1113, in
order to facilitate validation in the absence of ubiquitous directory
services. Upon receipt of a privacy enhanced message, a recipient
validates the originator's certificate, extracts the public component
from the certificate, and uses that value to recover (decrypt) the
MIC. The recovered MIC is compared against the locally calculated
MIC to verify the integrity and data origin authenticity of the
message.
3. Architecture
3.1 Scope and Restrictions
The architecture described below is intended to provide a basis for
managing public-key cryptosystem values in support of privacy
enhanced electronic mail (see RFC-1113) in the Internet environment.
The architecture describes procedures for ordering certificates from
issuers, for generating and distributing certificates, and for "hot
listing" of revoked certificates. Concurrent with the issuance of
this RFC, RFC 1040 has been updated and reissued as RFC-1113 to
describe the syntax and semantics of new or revised header fields
used to transfer certificates, represent the DEK and MIC in this
public-key context, and to segregate algorithm definitions into a
separate RFC to facilitate the addition of other algorithms in the
future. This RFC focuses on the management aspects of certificate-
Kent & Linn [Page 4]
RFC 1114 Mail Privacy: Key Management August 1989
based, public-key cryptography for privacy enhanced mail while RFC-
1113 addresses representation and processing aspects of such mail,
including changes required by this key management technology.
The proposed architecture imposes conventions for certification paths
which are not strictly required by the X.509 recommendation nor by
the technology itself. The decision to impose these conventions is
based in part on constraints imposed by the status of the RSA
cryptosystem within the U.S. as a patented algorithm, and in part on
the need for an organization to assume operational responsibility for
certificate management in the current (minimal) directory system
infrastructure for electronic mail. Over time, we anticipate that
some of these constraints, e.g., directory service availability, will
change and the procedures specified in the RFC will be reviewed and
modified as appropriate.
At this time, we propose a system in which user certificates
represent the leaves in a shallow (usually two tier) certification
hierarchy (tree). Organizations which act as issuers are represented
by certificates higher in the tree. This convention minimizes the
complexity of validating user certificates by limiting the length of
"certification paths" and by making very explicit the relationship
between a certificate issuer and a user. Note that only
organizations may act as issuers in the proposed architecture; a user
certificate may not appear in a certification path, except as the
terminal node in the path. These conventions result in a
certification hierarchy which is a compatible subset of that
permitted under X.509, with respect to both syntax and semantics.
The RFC proposes that RSADSI act as a "co-issuer" of certificates on
behalf of most organizations. This can be effected in a fashion
which is "transparent" so that the organizations appear to be the
issuers with regard to certificate formats and validation procedures.
This is effected by having RSADSI generate and hold the secret
components used to sign certificates on behalf of organizations. The
motivation for RSADSI's role in certificate signing is twofold.
First, it simplifies accounting controls in support of licensing,
ensuring that RSADSI is paid for each certificate. Second, it
contributes to the overall integrity of the system by establishing a
uniform, high level of protection for the private-components used to
sign certificates. If an organization were to sign certificates
directly on behalf of its affiliated users, the organization would
have to establish very stringent security and accounting mechanisms
and enter into (elaborate) legal agreements with RSADSI in order to
provide a comparable level of assurance. Requests by organizations
to perform direct certificate signing will be considered on a case-
by-case basis, but organizations are strongly urged to make use of
the facilities proposed by this RFC.
Kent & Linn [Page 5]
RFC 1114 Mail Privacy: Key Management August 1989
Note that the risks associated with disclosure of an organization's
secret component are different from those associated with disclosure
of a user's secret component. The former component is used only to
sign certificates, never to encrypt message traffic. Thus the
exposure of an organization's secret component could result in the
generation of forged certificates for users affiliated with that
organization, but it would not affect privacy-enhanced messages which
are protected using legitimate certificates. Also note that any
certificates generated as a result of such a disclosure are readily
traceable to the issuing authority which holds this component, e.g.,
RSADSI, due to the non-repudiation feature of the digital signature.
The certificate registration and signing procedures established in
this RFC would provide non-repudiable evidence of disclosure of an
organization's secret component by RSADSI. Thus this RFC advocates
use of RSADSI as a co-issuer for certificates until such time as
technical security mechanisms are available to provide a similar,
system-wide level of assurance for (distributed) certificate signing
by organizations.
We identify two classes of exceptions to this certificate signing
paradigm. First, the RSA algorithm is patented only within the U.S.,
and thus it is very likely that certificate signing by issuers will
arise outside of the U.S., independent of RSADSI. Second, the
research that led to the RSA algorithm was sponsored by the National
Science Foundation, and thus the U.S. government retains royalty-free
license rights to the algorithm. Thus the U.S. government may
establish a certificate generation facilities for its affiliated
users. A number of the procedures described in this document apply
only to the use of RSADSI as a certificate co-issuer; all other
certificate generation practices lie outside the scope of this RFC.
This RFC specifies procedures by which users order certificates
either directly from RSADSI or via a representative in an
organization with which the user holds some affiliation (e.g., the
user's employer or educational institution). Syntactic provisions
are made which allow a recipient to determine, to some granularity,
which identifying information contained in the certificate is vouched
for by the certificate issuer. In particular, organizations will
usually be vouching for the affiliation of a user with that
organization and perhaps a user's role within the organization, in
addition to the user's name. In other circumstances, as discussed in
section 3.3.3, a certificate may indicate that an issuer vouches only
for the user's name, implying that any other identifying information
contained in the certificate may not have been validated by the
issuer. These semantics are beyond the scope of X.509, but are not
incompatible with that recommendation.
The key management architecture described in this RFC has been
Kent & Linn [Page 6]
RFC 1114 Mail Privacy: Key Management August 1989
designed to support privacy enhanced mail as defined in this RFC,
RFC-1113, and their successors. Note that this infrastructure also
supports X.400 mail security facilities (as per X.411) and thus paves
the way for transition to the OSI/CCITT Message Handling System
paradigm in the Internet in the future. The certificate issued to a
user for the $25 biennial fee will grant to the user identified by
that certificate a license from RSADSI to employ the RSA algorithm
for certificate validation and for encryption and decryption
operations in this electronic mail context. No use of the algorithm
outside the scope defined in this RFC is authorized by this license
as of this time. Expansion of the license to other Internet security
applications is possible but not yet authorized. The license granted
by this fee does not authorize the sale of software or hardware
incorporating the RSA algorithm; it is an end-user license, not a
developer's license.
3.2 Relation to X.509 Architecture
CCITT 1988 Recommendation X.509, "The Directory - Authentication
Framework", defines a framework for authentication of entities
involved in a distributed directory service. Strong authentication,
as defined in X.509, is accomplished with the use of public-key
cryptosystems. Unforgeable certificates are generated by
certification authorities; these authorities may be organized
hierarchically, though such organization is not required by X.509.
There is no implied mapping between a certification hierarchy and the
naming hierarchy imposed by directory system naming attributes. The
public-key certificate approach defined in X.509 has also been
adopted in CCITT 1988 X.411 in support of the message handling
application.
This RFC interprets the X.509 certificate mechanism to serve the
needs of privacy-enhanced mail in the Internet environment. The
certification hierarchy proposed in this RFC in support of privacy
enhanced mail is intentionally a subset of that allowed under X.509.
In large part constraints have been levied in order to simplify
certificate validation in the absence of a widely available, user-
level directory service. The certification hierarchy proposed here
also embodies semantics which are not explicitly addressed by X.509,
but which are consistent with X.509 precepts. The additional
semantic constraints have been adopted to explicitly address
questions of issuer "authority" which we feel are not well defined in
X.509.
3.3 Entities' Roles and Responsibilities
One way to explain the architecture proposed by this RFC is to
examine the various roles which are defined for various entities in
Kent & Linn [Page 7]
RFC 1114 Mail Privacy: Key Management August 1989
the architecture and to describe what is required of each entity in
order for the proposed system to work properly. The following
sections identify three different types of entities within this
architecture: users and user agents, organizational notaries, and
certification authorities. For each class of entity we describe the
(electronic and paper) procedures which the entity must execute as
part of the architecture and what responsibilities the entity assumes
as a function of its role in the architecture. Note that the
infrastructure described here applies to the situation wherein RSADSI
acts as a co-issuer of certificates, sharing the role of
certification authority as described later. Other certifying
authority arrangements may employ different procedures and are not
addressed by this RFC.
3.3.1 Users and User Agents
The term User Agent (UA) is taken from CCITT X.400 Message Handling
Systems (MHS) Recommendations, which define it as follows: "In the
context of message handling, the functional object, a component of
MHS, by means of which a single direct user engages in message
handling." UAs exchange messages by calling on a supporting Message
Transfer Service (MTS).
A UA process supporting privacy-enhanced mail processing must protect
the private component of its associated entity (ordinarily, a human
user) from disclosure. We anticipate that a user will employ
ancillary software (not otherwise associated with the UA) to generate
his public/private component pair and to compute the (one-way)
message hash required by the registration procedure. The public
component, along with information that identifies the user, will be
transferred to an organizational notary (see below) for inclusion in
an order to an issuer. The process of generating public and private
components is a local matter, but we anticipate Internet-wide
distribution of software suitable for component-pair generation to
facilitate the process. The mechanisms used to transfer the public
component and the user identification information must preserve the
integrity of both quantities and bind the two during this transfer.
This proposal establishes two ways in which a user may order a
certificate, i.e., through the user's affiliation with an
organization or directly through RSADSI. In either case, a user will
be required to send a paper order to RSADSI on a form described in a
subsequent RFC and containing the following information:
1. Distinguished Name elements (e.g., full legal name,
organization name, etc.)
2. Postal address
Kent & Linn [Page 8]
RFC 1114 Mail Privacy: Key Management August 1989
3. Internet electronic mail address
4. A message hash function, binding the above information to the
user's public component
Note that the user's public component is NOT transmitted via this
paper path. In part the rationale here is that the public component
consists of many (>100) digits and thus is prone to error if it is
copied to and from a piece of paper. Instead, a message hash is
computed on the identifying information and the public component and
this (smaller) message hash value is transmitted along with the
identifying information. Thus the public component is transferred
only via an electronic path, as described below.
If the user is not affiliated with an organization which has
established its own "electronic notary" capability (an organization
notary or "ON" as discussed in the next section), then this paper
registration form must be notarized by a Notary Public. If the user
is affiliated with an organization which has established one or more
ONs, the paper registration form need not carry the endorsement of a
Notary Public. Concurrent with the paper registration, the user must
send the information outlined above, plus his public component,
either to his ON, or directly to RSADSI if no appropriate ON is
available to the user. Direct transmission to RSADSI of this
information will be via electronic mail, using a representation
described in a subsequent RFC. The paper registration must be
accompanied by a check or money order for $25 or an organization may
establish some other billing arrangement with RSADSI. The maximum
(and default) lifetime of a certificate ordered through this process
is two years.
The transmission of ID information and public component from a user
to his ON is a local matter, but we expect electronic mail will also
be the preferred approach in many circumstances and we anticipate
general distribution of software to support this process. Note that
it is the responsibility of the user and his organization to ensure
the integrity of this transfer by some means deemed adequately secure
for the local computing and communication environment. There is no
requirement for secrecy in conjunction with this information
transfer, but the integrity of the information must be ensured.
3.3.2 Organizational Notaries
An organizational notary is an individual who acts as a clearinghouse
for certificate orders originating within an administrative domain
such as a corporation or a university. An ON represents an
organization or organizational unit (in X.500 naming terms), and is
assumed to have some independence from the users on whose behalf
Kent & Linn [Page 9]
RFC 1114 Mail Privacy: Key Management August 1989
certificates are ordered. An ON will be restricted through
mechanisms implemented by the issuing authority, e.g., RSADSI, to
ordering certificates properly associated with the domain of that ON.
For example, an ON for BBN should not be able to order certificates
for users affiliated with MIT or MITRE, nor vice versa. Similarly,
if a corporation such as BBN were to establish ONs on a per-
subsidiary basis (corresponding to organization units in X.500 naming
parlance), then an ON for the BBN Communications subsidiary should
not be allowed to order a certificate for a user who claims
affiliation with the BBN Software Products subsidiary.
It can be assumed that the set of ONs changes relatively slowly and
that the number of ONs is relatively small in comparison with the
number of users. Thus a more extensive, higher assurance process may
reasonably be associated with ON accreditation than with per-user
certificate ordering. Restrictions on the range of information which
an ON is authorized to certify are established as part of this more
elaborate registration process. The procedures by which
organizations and organizational units are established in the RSADSI
database, and by which ONs are registered, will be described in a
subsequent RFC.
An ON is responsible for establishing the correctness and integrity
of information incorporated in an order, and will generally vouch for
(certify) the accuracy of identity information at a granularity finer
than that provided by a Notary Public. We do not believe that it is
feasible to enforce uniform standards for the user certification
process across all ONs, but we anticipate that organizations will
endeavor to maintain high standards in this process in recognition of
the "visibility" associated with the identification data contained in
certificates. An ON also may constrain the validity period of an
ordered certificate, restricting it to less than the default two year
interval imposed by the RSADSI license agreement.
An ON participates in the certificate ordering process by accepting
and validating identification information from a user and forwarding
this information to RSADSI. The ON accepts the electronic ordering
information described above (Distinguished Name elements, mailing
address, public component, and message hash computed on all of this
data) from a user. (The representation for user-to-ON transmission
of this data is a local matter, but we anticipate that the encoding
specified for ON-to-RSADSI representation of this data will often be
employed.) The ON sends an integrity-protected (as described in
RFC-1113) electronic message to RSADSI, vouching for the correctness
of the binding between the public component and the identification
data. Thus, to support this function, each ON will hold a
certificate as an individual user within the organization which he
represents. RSADSI will maintain a database which identifies the
Kent & Linn [Page 10]
RFC 1114 Mail Privacy: Key Management August 1989
users who also act as ONs and the database will specify constraints
on credentials which each ON is authorized to certify. The
electronic mail representation for a user's certificate data in an ON
message to RSADSI will be specified in a subsequent RFC.
3.3.3 Certification Authorities
In X.509 the term "certification authority" is defined as "an
authority trusted by one or more users to create and assign
certificates". This alternate expansion for the acronym "CA" is
roughly equivalent to that contemplated as a "central authority" in
RFC-1040 and RFC-1113. The only difference is that in X.509 there is
no requirement that a CA be a distinguished entity or that a CA serve
a large number of users, as envisioned in these RFCs. Rather, any
user who holds a certificate can, in the X.509 context, act as a CA
for any other user. As noted above, we have chosen to restrict the
role of CA in this electronic mail environment to organizational
entities, to simplify the certificate validation process, to impose
semantics which support organizational affiliation as a basis for
certification, and to facilitate license accountability.
In the proposed architecture, individuals who are affiliated with
(registered) organizations will go through the process described
above, in which they forward their certificate information to their
ON for certification. The ON will, based on local procedures, verify
the accuracy of the user's credentials and forward this information
to RSADSI using privacy-enhanced mail to ensure the integrity and
authenticity of the information. RSADSI will carry out the actual
certificate generation process on behalf of the organization
represented by the ON. Recall that it is the identity of the
organization which the ON represents, not the ON's identity, which
appears in the issuer field of the user certificate. Therefore it is
the private component of the organization, not the ON, which is used
to sign the user certificate.
In order to carry out this procedure RSADSI will serve as the
repository for the private components associated with certificates
representing organizations or organizational units (but not
individuals). In effect the role of CA will be shared between the
organizational notaries and RSADSI. This shared role will not be
visible in the syntax of the certificates issued under this
arrangement nor is it apparent from the validation procedure one
applies to these certificates. In this sense, the role of RSADSI as
the actual signer of certificates on behalf of organizations is
transparent to this aspect of system operation.
If an organization were to carry out the certificate signing process
locally, and thus hold the private component associated with its
Kent & Linn [Page 11]
RFC 1114 Mail Privacy: Key Management August 1989
organization certificate, it would need to contact RSADSI to discuss
security safeguards, special legal agreements, etc. A number of
requirements would be imposed on an organization if such an approach
were persued. The organization would be required to execute
additional legal instruments with RSADSI, e.g., to ensure proper
accounting for certificates generated by the organization. Special
software will be required to support the certificate signing process,
distinct from the software required for an ON. Stringent procedural,
physical, personnel and computer security safeguards would be
required to support this process, to maintain a relatively high level
of security for the system as a whole. Thus, at this time, it is not
recommended that organizations pursue this approach although local
certificate generation is not expressly precluded by the proposed
architecture.
RSADSI has offered to operate a service in which it serves as a CA
for users who are not affiliated with any organization or who are
affiliated with an organization which has not opted to establish an
organizational notary. To distinguish certificates issued to such
"non-affiliated" users the distinguished string "Notary" will appear
as the organizational unit name of the issuer of the certificate.
This convention will be employed throughout the system. Thus not
only RSADSI but any other organization which elects to provide this
type of service to non-affiliated users may do so in a standard
fashion. Hence a corporation might issue a certificate with the
"Notary" designation to students hired for the summer, to
differentiate them from full-time employees. At least in the case of
RSADSI, the standards for verifying user credentials that carry this
designation will be well known and widely recognized (e.g., Notary
Public endorsement).
To illustrate this convention, consider the following examples.
Employees of RSADSI will hold certificates which indicate "RSADSI" as
the organization in both the issuer field and the subject field,
perhaps with no organizational unit specified. Certificates obtained
directly from RSADSI, by user's who are not affiliated with any ON,
will also indicate "RSADSI" as the organization and will specify
"Notary" as an organizational unit in the issuer field. However,
these latter certificates will carry some other designation for
organization (and, optionally, organizational unit) in the subject
field. Moreover, an organization designated in the subject field for
such a certificate will not match any for which RSADSI has an ON
registered (to avoid possible confusion).
In all cases described above, when a certificate is generated RSADSI
will send a paper reply to the ordering user, including two message
hash functions:
Kent & Linn [Page 12]
RFC 1114 Mail Privacy: Key Management August 1989
1. a message hash computed on the user's identifying information
and public component (and sent to RSADSI in the registration
process), to guarantee its integrity across the ordering
process, and
2. a message hash computed on the public component of RSADSI, to
provide independent authentication for this public component
which is transmitted to the user via email (see below).
RSADSI will send to the user via electronic mail (not privacy
enhanced) a copy of his certificate, a copy of the organization
certificate identified in the issuer field of the user's certificate,
and the public component used to validate certificates signed by
RSADSI. The "issuer" certificate is included to simplify the
validation process in the absence of a user-level directory system;
its distribution via this procedure will probably be phased out in
the future. Thus, as described in RFC-1113, the originator of a
message is encouraged, though not required, to include his
certificate, and that of its issuer, in the privacy enhanced message
header (X-Issuer-Certificate) to ensure that each recipient can
process the message using only the information contained in this
header. The organization (organizational unit) identified in the
subject field of the issuer certificate should correspond to that
which the user claims affiliation (as declared in the subject field
of his certificate). If there is no appropriate correspondence
between these fields, recipients ought to be suspicious of the
implied certification path. This relationship should hold except in
the case of "non-affiliated" users for whom the "Notary" convention
is employed.
In contrast, the issuer field of the issuer's certificate will
specify "RSADSI" as the organization, i.e., RSADSI will certify all
organizational certificates. This convention allows a recipient to
validate any originator's certificate (within the RSADSI
certification hierarchy) in just two steps. Even if an organization
establishes a certification hierarchy involving organizational units,
certificates corresponding to each unit can be certified both by
RSADSI and by the organizational entity immediately superior to the
unit in the hierarchy, so as to preserve this short certification
path feature. First, the public component of RSADSI is employed to
validate the issuer's certificate. Then the issuer's public
component is extracted from that certificate and is used to validate
the originator's certificate. The recipient then extracts the
originator's public component for use in processing the X-Mic-Info
field of the message (see and RFC-1113).
The electronic representation used for transmission of the data items
described above (between an ON and RSADSI) will be contained in a
Kent & Linn [Page 13]
RFC 1114 Mail Privacy: Key Management August 1989
subsequent RFC. To verify that the registration process has been
successfully completed and to prepare for exchange of privacy-
enhanced electronic mail, the user should perform the following
steps:
1. extract the RSADSI public component, the issuer's certificate
and the user's certificate from the message
2. compute the message hash on the RSADSI public component and
compare the result to the corresponding message hash that was
included in the paper receipt
3. use the RSADSI public component to validate the signature on
the issuer's certificate (RSADSI will be the issuer of this
certificate)
4. extract the organization public component from the validated
issuer's certificate and use this public component to
validate the user certificate
5. extract the identification information and public component
from the user's certificate, compute the message hash on it
and compare the result to the corresponding message hash
value transmitted via the paper receipt
For a user whose order was processed via an ON, successful completion
of these steps demonstrates that the certificate issued to him
matches that which he requested and which was certified by his ON.
It also demonstrates that he possesses the (correct) public component
for RSADSI and for the issuer of his certificate. For a user whose
order was placed directly with RSADSI, this process demonstrates that
his certificate order was properly processed by RSADSI and that he
possesses the valid issuer certificate for the RSADSI Notary. The
user can use the RSADSI public component to validate organizational
certificates for organizations other than his own. He can employ the
public component associated with his own organization to validate
certificates issued to other users in his organization.
3.3.3.1 Interoperation Across Certification Hierarchy Boundaries
In order to accommodate interoperation with other certification
authorities, e.g., foreign or U.S. government CAs, two conventions
will be adopted. First, all certifying authorities must agree to
"cross-certify" one another, i.e., each must be willing to sign a
certificate in which the issuer is that certifying authority and the
subject is another certifying authority. Thus, RSADSI might generate
a certificate in which it is identified as the issuer and a
certifying authority for the U.S. government is indentified as the
Kent & Linn [Page 14]
RFC 1114 Mail Privacy: Key Management August 1989
subject. Conversely, that U.S. government certifying authority would
generate a certificate in which it is the issuer and RSADSI is the
subject. This cross-certification of certificates for "top-level"
CAs establishes a basis for "lower level" (e.g., organization and
user) certificate validation across the hierarchy boundaries. This
avoids the need for users in one certification hierarchy to engage in
some "out-of-band" procedure to acquire a public-key for use in
validating certificates from a different certification hierarchy.
The second convention is that more than one X-Issuer-Certificate
field may appear in a privacy-enhanced mail header. Multiple issuer
certificates can be included so that a recipient can more easily
validate an originator's certificate when originator and recipient
are not part of a common CA hierarchy. Thus, for example, if an
originator served by the RSADSI certification hierarchy sends a
message to a recipient served by a U.S. government hierarchy, the
originator could (optionally) include an X-Issuer-Certificate field
containing a certificate issued by the U.S. government CA for RSADSI.
In this fashion the recipient could employ his public component for
the U.S. government CA to validate this certificate for RSADSI, from
which he would extract the RSADSI public component to validate the
certificate for the originator's organization, from which he would
extract the public component required to validate the originator's
certificate. Thus, more steps can be required to validate
certificates when certification hierarchy boundaries are crossed, but
the same basic procedure is employed. Remember that caching of
certificates by UAs can significantly reduce the effort required to
process messages and so these examples should be viewed as "worse
case" scenarios.
3.3.3.2 Certificate Revocation
X.509 states that it is a CA's responsibility to maintain:
1. a time-stamped list of the certificates it issued which have
been revoked
2. a time-stamped list of revoked certificates representing
other CAs
There are two primary reasons for a CA to revoke a certificate, i.e.,
suspected compromise of a secret component (invalidating the
corresponding public component) or change of user affiliation
(invalidating the Distinguished Name). As described in X.509, "hot
listing" is one means of propagating information relative to
certificate revocation, though it is not a perfect mechanism. In
particular, an X.509 Revoked Certificate List (RCL) indicates only
the age of the information contained in it; it does not provide any
Kent & Linn [Page 15]
RFC 1114 Mail Privacy: Key Management August 1989
basis for determining if the list is the most current RCL available
from a given CA. To help address this concern, the proposed
architecture establishes a format for an RCL in which not only the
date of issue, but also the next scheduled date of issue is
specified. This is a deviation from the format specified in X.509.
Adopting this convention, when the next scheduled issue date arrives
a CA must issue a new RCL, even if there are no changes in the list
of entries. In this fashion each CA can independently establish and
advertise the frequency with which RCLs are issued by that CA. Note
that this does not preclude RCL issuance on a more frequent basis,
e.g., in case of some emergency, but no Internet-wide mechanisms are
architected for alerting users that such an unscheduled issuance has
taken place. This scheduled RCL issuance convention allows users
(UAs) to determine whether a given RCL is "out of date," a facility
not available from the standard RCL format.
A recent (draft) version of the X.509 recommendation calls for each
RCL to contain the serial numbers of certificates which have been
revoked by the CA administering that list, i.e., the CA that is
identified as the issuer for the corresponding revoked certificates.
Upon receipt of a RCL, a UA should compare the entries against any
cached certificate information, deleting cache entries which match
RCL entries. (Recall that the certificate serial numbers are unique
only for each issuer, so care must be exercised in effecting this
cache search.) The UA should also retain the RCL to screen incoming
messages to detect use of revoked certificates carried in these
message headers. More specific details for processing RCL are beyond
the scope of this RFC as they are a function of local certificate
management techniques.
In the architecture defined by this RFC, a RCL will be maintained for
each CA (organization or organizational unit), signed using the
private component of that organization (and thus verifiable using the
public component of that organization as extracted from its
certificate). The RSADSI Notary organizational unit is included in
this collection of RCLs. CAs operated under the auspices of the U.S.
government or foreign CAs are requested to provide RCLs conforming to
these conventions, at least until such time as X.509 RCLs provide
equivalent functionality, in support of interoperability with the
Internet community. An additional, "top level" RCL, will be
maintained by RSAD-SI, and should be maintained by other "top level"
CAs, for revoked organizational certificates.
The hot listing procedure (expect for this top level RCL) will be
effected by having an ON from each organization transmit to RSADSI a
list of the serial numbers of users within his organization, to be
hot listed. This list will be transmitted using privacy-enhanced
Kent & Linn [Page 16]
RFC 1114 Mail Privacy: Key Management August 1989
mail to ensure authenticity and integrity and will employ
representation conventions to be provided in a subsequent RFC.
RSADSI will format the RCL, sign it using the private component of
the organization, and transmit it to the ON for dissemination, using
a representation defined in a subsequent RFC. Means for
dissemination of RCLs, both within the administrative domain of a CA
and across domain boundaries, are not specified by this proposal.
However, it is anticipated that each hot list will also be available
via network information center databases, directory servers, etc.
The following ASN.1 syntax, derived from X.509, defines the format of
RCLs for use in the Internet privacy enhanced email environment. See
the ASN.1 definition of certificates (later in this RFC or in X.509,
Annex G) for comparison.
revokedCertificateList ::= SIGNED SEQUENCE {
signature AlgorithmIdentifier,
issuer Name,
list SEQUENCE RCLEntry,
lastUpdate UTCTime,
nextUpdate UTCTime}
RCLEntry ::= SEQUENCE {
subject CertificateSerialNumber,
revocationDate UTCTime}
3.4 Certificate Definition and Usage
3.4.1 Contents and Use
A certificate contains the following contents:
1. version
2. serial number
3. certificate signature (and associated algorithm identifier)
4. issuer name
5. validity period
6. subject name
7. subject public component (and associated algorithm identifier)
This section discusses the interpretation and use of each of these
certificate elements.
Kent & Linn [Page 17]
RFC 1114 Mail Privacy: Key Management August 1989
3.4.1.1 Version Number
The version number field is intended to facilitate orderly changes in
certificate formats over time. The initial version number for
certificates is zero (0).
3.4.1.2 Serial Number
The serial number field provides a short form, unique identifier for
each certificate generated by an issuer. The serial number is used
in RCLs to identify revoked certificates instead of including entire
certificates. Thus each certificate generated by an issuer must
contain a unique serial number. It is suggested that these numbers
be issued as a compact, monotonic increasing sequence.
3.4.1.3 Subject Name
A certificate provides a representation of its subject's identity and
organizational affiliation in the form of a Distinguished Name. The
fundamental binding ensured by the privacy enhancement mechanisms is
that between public-key and the user identity. CCITT Recommendation
X.500 defines the concept of Distinguished Name.
Version 2 of the U.S. Government Open Systems Interconnection Profile
(GOSIP) specifies maximum sizes for O/R Name attributes. Since most
of these attributes also appear in Distinguished Names, we have
adopted the O/R Name attribute size constraints specified in GOSIP
and noted below. Using these size constraints yields a maximum
Distinguished Name length (exclusive of ASN encoding) of two-hundred
fifty-nine (259) characters, based on the required and optional
attributes described below for subject names. The following
attributes are required in subject Distinguished Names for purposes
of this RFC:
1. Country Name in standard encoding (e.g., the two-character
Printable String "US" assigned by ISO 3166 as the identifier
for the United States of America, the string "GB" assigned as
the identifier for the United Kingdom, or the string "NQ"
assigned as the identifier for Dronning Maud Land). Maximum
ASCII character length of three (3).
2. Organizational Name (e.g., the Printable String "Bolt Beranek
and Newman, Inc."). Maximum ASCII character length of
sixty-four (64).
3. Personal Name (e.g., the X.402/X.411 structured Printable
String encoding for the name John Linn). Maximum ASCII
character length of sixty-four (64).
Kent & Linn [Page 18]
RFC 1114 Mail Privacy: Key Management August 1989
The following attributes are optional in subject Distinguished Names
for purposes of this RFC:
1. Organizational Unit Name(s) (e.g., the Printable String "BBN
Communications Corporation") A hierarchy of up to four
organizational unit names may be provided; the least
significant member of the hierarchy is represented first.
Each of these attributes has a maximum ASCII character length of
thirty-two (32), for a total of one-hundred and twenty-eight
(128) characters if all four are present.
3.4.1.4 Issuer Name
A certificate provides a representation of its issuer's identity, in
the form of a Distinguished Name. The issuer identification is
needed in order to determine the appropriate issuer public component
to use in performing certificate validation. The following
attributes are required in issuer Distinguished Names for purposes of
this RFC:
1. Country Name (e.g., encoding for "US")
2. Organizational Name
The following attributes are optional in issuer Distinguished Names
for purposes of this RFC:
1. Organizational Unit Name(s). (A hierarchy of up to four
organizational unit names may be provided; the least significant
member of the hierarchy is represented first.) If the
issuer is vouching for the user identity in the Notary capacity
described above, then exactly one instance of this field
must be present and it must consist of the string "Notary".
As noted earlier, only organizations are allowed as issuers in the
proposed authentication hierarchy. Hence the Distinguished Name for
an issuer should always be that of an organization, not a user, and
thus no Personal Name field may be included in the Distinguished Name
of an issuer.
3.4.1.5 Validity Period
A certificate carries a pair of time specifiers, indicating the start
and end of the time period over which a certificate is intended to be
used. No message should ever be prepared for transmission with a
non-current certificate, but recipients should be prepared to receive
messages processed using recently-expired certificates. This fact
results from the unpredictable (and sometimes substantial)
Kent & Linn [Page 19]
RFC 1114 Mail Privacy: Key Management August 1989
transmission delay of the staged-delivery electronic mail
environment. The default and maximum validity period for
certificates issued in this system will be two years.
3.4.1.6 Subject Public Component
A certificate carries the public component of its associated entity,
as well as an indication of the algorithm with which the public
component is to be used. For purposes of this RFC, the algorithm
identifier will indicate use of the RSA algorithm, as specified in
RFC-1115. Note that in this context, a user's public component is
actually the modulus employed in RSA algorithm calculations. A
"universal" (public) exponent is employed in conjunction with the
modulus to complete the system. Two choices of exponents are
recommended for use in this context and are described in section
3.4.3. Modulus size will be permitted to vary between 320 and 632
bits.
3.4.1.7 Certificate Signature
A certificate carries a signature algorithm identifier and a
signature, applied to the certificate by its issuer. The signature
is validated by the user of a certificate, in order to determine that
the integrity of its contents have not been compromised subsequent to
generation by a CA. An encrypted, one-way hash will be employed as
the signature algorithm. Hash functions suitable for use in this
context are notoriously difficult to design and tend to be
computationally intensive. Initially we have adopted a hash function
developed by RSADSI and which exhibits performance roughly equivalent
to the DES (in software). This same function has been selected for
use in other contexts in this system where a hash function (message
hash algorithm) is required, e.g., MIC for multicast messages. In
the future we expect other one-way hash functions will be added to
the list of algorithms designated for this purpose.
3.4.2 Validation Conventions
Validating a certificate involves verifying that the signature
affixed to the certificate is valid, i.e., that the hash value
computed on the certificate contents matches the value that results
from decrypting the signature field using the public component of the
issuer. In order to perform this operation the user must possess the
public component of the issuer, either via some integrity-assured
channel, or by extracting it from another (validated) certificate.
In the proposed architecture this recursive operation is terminated
quickly by adopting the convention that RSADSI will certify the
certificates of all organizations or organizational units which act
as issuers for end users. (Additional validation steps may be
Kent & Linn [Page 20]
RFC 1114 Mail Privacy: Key Management August 1989
required for certificates issued by other CAs as described in section
3.3.3.1.)
Certification means that RSADSI will sign certificates in which the
subject is the organization or organizational unit and for which
RSADSI is the issuer, thus implying that RSADSI vouches for the
credentials of the subject. This is an appropriate construct since
each ON representing an organization or organizational unit must have
registered with RSADSI via a procedure more rigorous than individual
user registration. This does not preclude an organizational unit
from also holding a certificate in which the "parent" organization
(or organizational unit) is the issuer. Both certificates are
appropriate and permitted in the X.509 framework. However, in order
to facilitate the validation process in an environment where user-
level directory services are generally not available, we will (at
this time) adopt this certification convention.
The public component needed to validate certificates signed by RSADSI
(in its role as a CA for issuers) is transmitted to each user as part
of the registration process (using electronic mail with independent,
postal confirmation via a message hash). Thus a user will be able to
validate any user certificate (from the RSADSI hierarchy) in at most
two steps. Consider the situation in which a user receives a privacy
enhanced message from an originator with whom the recipient has never
previously corresponded. Based on the certification convention
described above, the recipient can use the RSADSI public component to
validate the issuer's certificate contained in the X-Issuer-
Certificate field. (We recommend that, initially, the originator
include his organization's certificate in this optional field so that
the recipient need not access a server or cache for this public
component.) Using the issuer's public component (extracted from this
certificate), the recipient can validate the originator's certificate
contained in the X-Certificate field of the header.
Having performed this certificate validation process, the recipient
can extract the originator's public component and use it to decrypt
the content of the X-MIC-Info field and thus verify the data origin
authenticity and integrity of the message. Of course,
implementations of privacy enhanced mail should cache validated
public components (acquired from incoming mail or via the message
from a user registration process) to speed up this process. If a
message arrives from an originator whose public component is held in
the recipient's cache, the recipient can immediately employ that
public component without the need for the certificate validation
process described here. Also note that the arithmetic required for
certificate validation is considerably faster than that involved in
digitally signing a certificate, so as to minimize the computational
burden on users.
Kent & Linn [Page 21]
RFC 1114 Mail Privacy: Key Management August 1989
A separate issue associated with validation of certificates is a
semantic one, i.e., is the entity identified in the issuer field
appropriate to vouch for the identifying information in the subject
field. This is a topic outside the scope of X.509, but one which
must be addressed in any viable system. The hierarchy proposed in
this RFC is designed to address this issue. In most cases a user
will claim, as part of his identifying information, affiliation with
some organization and that organization will have the means and
responsibility for verifying this identifying information. In such
circumstances one should expect an obvious relationship between the
Distinguished Name components in the issuer and subject fields.
For example, if the subject field of a certificate identified an
individual as affiliated with the "Widget Systems Division"
(Organizational Unit Name) of "Compudigicorp" (Organizational Name),
one would expect the issuer field to specify "Compudigicorp" as the
Organizational Name and, if an Organizational Unit Name were present,
it should be "Widget Systems Division." If the issuer's certificate
indicated "Compudigicorp" as the subject (with no Organizational Unit
specified), then the issuer should be "RSADSI." If the issuer's
certificate indicated "Widget Systems Division" as Organizational
Unit and "Compudigicorp" as Organization in the subject field, then
the issuer could be either "RSADSI" (due to the direct certification
convention described earlier) or "Compudigicorp" (if the organization
elected to distribute this intermediate level certificate). In the
later case, the certificate path would involve an additional step
using the certificate in which "Compudigicorp" is the subject and
"RSADSI" is the issuer. One should be suspicious if the validation
path does not indicate a subset relationship for the subject and
issuer Distinguished Names in the certification path, expect where
cross-certification is employed to cross CA boundaries.
It is a local matter whether the message system presents a human user
with the certification path used to validate a certificate associated
with incoming, privacy-enhanced mail. We note that a visual display
of the Distinguished Names involved in that path is one means of
providing the user with the necessary information. We recommend,
however, that certificate validation software incorporate checks and
alert the user whenever the expected certification path relationships
are not present. The rationale here is that regular display of
certification path data will likely be ignored by users, whereas
automated checking with a warning provision is a more effective means
of alerting users to possible certification path anomalies. We urge
developers to provide facilities of this sort.
3.4.3 Relation with X.509 Certificate Specification
An X.509 certificate can be viewed as two components: contents and an
Kent & Linn [Page 22]
RFC 1114 Mail Privacy: Key Management August 1989
encrypted hash. The encrypted hash is formed and processed as
follows:
1. X, the hash, is computed as a function of the certificate
contents
2. the hash is signed by raising X to the power e (modulo n)
3. the hash's signature is validated by raising the result of
step 2 to the power d (modulo n), yielding X, which is
compared with the result computed as a function of certificate
contents.
Annex C to X.509 suggests the use of Fermat number F4 (65537 decimal,
1 + 2 **16 ) as a fixed value for e which allows relatively efficient
authentication processing, i.e., at most seventeen (17)
multiplications are required to effect exponentiation). As an
alternative one can employ three (3) as the value for e, yielding
even faster exponentiation, but some precautions must be observed
(see RFC-1115). Users of the algorithm select values for d (a secret
quantity) and n (a non-secret quantity) given this fixed value for e.
As noted earlier, this RFC proposes that either three (3) or F4 be
employed as universal encryption exponents, with the choice specified
in the algorithm identifier. In particular, use of an exponent value
of three (3) for certificate validation is encouraged, to permit
rapid certificate validation. Given these conventions, a user's
public component, and thus the quantity represented in his
certificate, is actually the modulus (n) employed in this computation
(and in the computations used to protect the DEK and MSGHASH, as
described in RFC-1113). A user's private component is the exponent
(d) cited above.
The X.509 certificate format is defined (in X.509, Annex G) by the
following ASN.1 syntax:
Certificate ::= SIGNED SEQUENCE{
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo}
Version ::= INTEGER {v1988(0)}
CertificateSerialNumber ::= INTEGER
Kent & Linn [Page 23]
RFC 1114 Mail Privacy: Key Management August 1989
Validity ::= SEQUENCE{
notBefore UTCTime,
notAfter UTCTime}
SubjectPublicKeyInfo ::= SEQUENCE{
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING}
AlgorithmIdentifier ::= SEQUENCE{
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL}
All components of this structure are well defined by ASN.1 syntax
defined in the 1988 X.400 and X.500 Series Recommendations, except
for the AlgorithmIdentifier. An algorithm identifier for RSA is
contained in Annex H of X.509 but is unofficial. RFC-1115 will
provide detailed syntax and values for this field.
NOTES:
[1] CCITT Recommendation X.411 (1988), "Message Handling Systems:
Message Transfer System: Abstract Service Definition and
Procedures".
[2] CCITT Recommendation X.509 (1988), "The Directory Authentication
Framework".
Kent & Linn [Page 24]
RFC 1114 Mail Privacy: Key Management August 1989
Authors' Addresses
Steve Kent
BBN Communications
50 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3988
EMail: ke...@BBN.COM
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
Phone: 508-264-5491
EMail: Li...@ultra.enet.dec.com
Kent & Linn [Page 25]
Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!
tut.cis.ohio-state.edu!network!ucsd!brian
From: br...@ucsd.EDU (Brian Kantor)
Newsgroups: comp.doc
Subject: RFC1115 - Privacy Enhancement for Internet Electronic Mail:
Part III -- Algorithms, Modes, and Identifiers
Message-ID: <1920@ucsd.EDU>
Date: 25 Aug 89 05:45:46 GMT
Distribution: na
Organization: The Avant-Garde of the Now, Ltd.
Lines: 450
Approved: br...@cyberpunk.ucsd.edu
Network Working Group J. Linn
Request for Comments: 1115 DEC
IAB Privacy Task Force
August 1989
Privacy Enhancement for Internet Electronic Mail:
Part III -- Algorithms, Modes, and Identifiers
STATUS OF THIS MEMO
This RFC suggests a draft standard elective protocol for the Internet
community, and requests discussion and suggestions for improvement.
This RFC provides definitions, references, and citations for
algorithms, usage modes, and associated identifiers used in RFC-1113
and RFC-1114 in support of privacy-enhanced electronic mail.
Distribution of this memo is unlimited.
ACKNOWLEDGMENT
This RFC is the outgrowth of a series of IAB Privacy Task Force
meetings and of internal working papers distributed for those
meetings. I would like to thank the following Privacy Task Force
members and meeting guests for their comments and contributions at
the meetings which led to the preparation of this RFC: David
Balenson, Curt Barker, Jim Bidzos, Matt Bishop, Morrie Gasser, Russ
Housley, Steve Kent (chairman), Dan Nessett, Mike Padlipsky, Rob
Shirey, and Steve Wilbur.
Table of Contents
1. Executive Summary 2
2. Symmetric Encryption Algorithms and Modes 2
2.1. DES Modes 2
2.1.1. DES in ECB mode (DES-ECB) 2
2.1.2. DES in EDE mode (DES-EDE) 2
2.1.3. DES in CBC mode (DES-CBC) 3
3. Asymmetric Encryption Algorithms and Modes 3
3.1. RSA 3
4. Integrity Check Algorithms 3
4.1. Message Authentication Code (MAC) 4
4.2. RSA-MD2 Message Digest Algorithm 4
4.2.1. Discussion 4
4.2.2. Reference Implementation 5
NOTES 7
Linn [Page 1]
RFC 1115 Mail Privacy: Algorithms August 1989
1. Executive Summary
This RFC provides definitions, references, and citations for algorithms,
usage modes, and associated identifiers used in RFC-1113 and RFC-1114
in support of privacy-enhanced electronic mail in the Internet
community. As some parts of this material are cited by both RFC-1113
and RFC-1114, and as it is anticipated that some of the definitions
herein may be changed, added, or replaced without affecting the citing
RFCs, algorithm-specific material has been placed into this separate
RFC. The text is organized into three primary sections; dealing with
symmetric encryption algorithms, asymmetric encryption algorithms, and
integrity check algorithms.
2. Symmetric Encryption Algorithms and Modes
This section identifies alternative symmetric encryption algorithms
and modes which may be used to encrypt DEKs, MICs, and message text,
and assigns them character string identifiers to be incorporated in
encapsulated header fields to indicate the choice of algorithm
employed. (Note: all alternatives presently defined in this category
correspond to different usage modes of the DEA-1 (DES) algorithm,
rather than to other algorithms per se.)
2.1. DES Modes
The Block Cipher Algorithm DEA-1, defined in ANSI X3.92-1981 [3] may
be used for message text, DEKs, and MICs. The DEA-1 is equivalent to
the Data Encryption Standard (DES), as defined in FIPS PUB 46 [4].
The ECB and CBC modes of operation of DEA-1 are defined in ISO IS 8372
[5].
2.1.1. DES in ECB mode (DES-ECB)
The string "DES-ECB" indicates use of the DES algorithm in Electronic
Codebook (ECB) mode. This algorithm/mode combination is used for DEK
and MIC encryption.
2.1.2. DES in EDE mode (DES-EDE)
The string "DES-EDE" indicates use of the DES algorithm in
Encrypt-Decrypt-Encrypt (EDE) mode as defined by ANSI X9.17 [2] for
key encryption and decryption with pairs of 64-bit keys. This
algorithm/mode combination is used for DEK and MIC encryption.
Linn [Page 2]
RFC 1115 Mail Privacy: Algorithms August 1989
2.1.3. DES in CBC mode (DES-CBC)
The string "DES-CBC" indicates use of the DES algorithm in Cipher
Block Chaining (CBC) mode. This algorithm/mode combination is used
for message text encryption only. The CBC mode definition in IS 8372
is equivalent to that provided in FIPS PUB 81 [6] and in ANSI X3.106-
1983 [7].
3. Asymmetric Encryption Algorithms and Modes
This section identifies alternative asymmetric encryption algorithms and
modes which may be used to encrypt DEKs and MICs, and assigns them
character string identifiers to be incorporated in encapsulated
header fields to indicate the choice of algorithm employed. (Note:
only one alternative is presently defined in this category.)
3.1. RSA
The string "RSA" indicates use of the RSA public-key encryption
algorithm, as described in [8]. This algorithm is used for DEK and
MIC encryption, in the following fashion: the product n of a
individual's selected primes p and q is used as the modulus for the
RSA encryption algorithm, comprising, for our purposes, the
individual's public key. A recipient's public key is used in
conjunction with an associated public exponent (either 3 or 1+2**16)
as identified in the recipient's certificate.
When a MIC must be padded for RSA encryption, the MIC will be
right-justified and padded on the left with zeroes. This is also
appropriate for padding of DEKs on singly-addressed messages, and for
padding of DEKs on multi-addressed messages if and only if an exponent
of 3 is used for no more than one recipient. On multi-addressed
messages in which an exponent of 3 is used for more than one recipient,
it is recommended that a separate 64-bit pseudorandom quantity be
generated for each recipient, in the same manner in which IVs are
generated. (Reference [9] discusses the rationale for this
recommendation.) At least one copy of the pseudorandom quantity should
be included in the input to RSA encryption, placed to the left of the
DEK.
4. Integrity Check Algorithms
This section identifies the alternative algorithms which may be used
to compute Message Integrity Check (MIC) and Certificate Integrity
Check (CIC) values, and assigns the algorithms character string
identifiers for use in encapsulated header fields and within
certificates to indicate the choice of algorithm employed.
Linn [Page 3]
RFC 1115 Mail Privacy: Algorithms August 1989
MIC algorithms which utilize DEA-1 cryptography are computed using a key
which is a variant of the DEK used for message text encryption. The
variant is formed by modulo-2 addition of the hexadecimal quantity
F0F0F0F0F0F0F0F0 to the encryption DEK.
For compatibility with this specification, a privacy-enhanced mail
implementation must be able to process both MAC (Section 2.1) and
RSA-MD2 (Section 2.2) MICs on incoming messages. It is a sender option
whether MAC or RSA-MD2 is employed on an outbound message addressed to
only one recipient. However, use of MAC is strongly discouraged for
messages sent to more than a single recipient. The reason for this
recommendation is that the use of MAC on multi-addressed mail fails to
prevent other intended recipients from tampering with a message in a
manner which preserves the message's appearance as an authentic message
from the sender. In other words, use of MAC on multi-addressed mail
provides source authentication at the granularity of membership in the
message's authorized address list (plus the sender) rather than at a
finer (and more desirable) granularity authenticating the individual
sender.
4.1. Message Authentication Code (MAC)
A message authentication code (MAC), denoted by the string "MAC", is
computed using the DEA-1 algorithm in the fashion defined in FIPS PUB
113 [1]. This algorithm is used only as a MIC algorithm, not as a CIC
algorithm.
As noted above, use of the MAC is not recommended for multicast
messages, as it does not preserve authentication and integrity among
individual recipients, i.e., it is not cryptographically strong enough
for this purpose. The message's canonically encoded text is padded at
the end, per FIPS PUB 113, with zero-valued octets as needed in order to
form an integral number of 8-octet encryption quanta. These padding
octets are inserted implicitly and are not transmitted with a message.
The result of a MAC computation is a single 64-bit value.
4.2. RSA-MD2 Message Digest Algorithm
4.2.1. Discussion
The RSA-MD2 Message Digest Algorithm, denoted by the string "RSA-MD2",
is computed using an algorithm defined in this section. It has been
provided by Ron Rivest of RSA Data Security, Incorporated for use in
support of privacy-enhanced electronic mail, free of licensing
restrictions. This algorithm should be used as a MIC algorithm
whenever a message is addressed to multiple recipients. It is also
the only algorithm currently defined for use as CIC. While its
continued use as the standard CIC algorithm is anticipated, RSA-MD2
Linn [Page 4]
RFC 1115 Mail Privacy: Algorithms August 1989
may be supplanted by later recommendations for MIC algorithm
selections.
The RSA-MD2 message digest algorithm accepts as input a message of any
length and produces as output a 16-byte quantity. The attached
reference implementation serves to define the algorithm; implementors
may choose to develop optimizations suited to their operating
environments.
4.2.2. Reference Implementation
/* RSA-MD2 Message Digest algorithm in C */
/* by Ronald L. Rivest 10/1/88 */
#include <stdio.h>
/**********************************************************************/
/* Message digest routines: */
/* To form the message digest for a message M */
/* (1) Initialize a context buffer md using MDINIT */
/* (2) Call MDUPDATE on md and each character of M in turn */
/* (3) Call MDFINAL on md */
/* The message digest is now in md->D[0...15] */
/**********************************************************************/
/* An MDCTX structure is a context buffer for a message digest */
/* computation; it holds the current "state" of a message digest */
/* computation */
struct MDCTX
{
unsigned char D[48]; /* buffer for forming digest in */
/* At the end, D[0...15] form the message */
/* digest */
unsigned char C[16]; /* checksum register */
unsigned char i; /* number of bytes handled, modulo 16 */
unsigned char L; /* last checksum char saved */
};
/* The table S given below is a permutation of 0...255 constructed */
/* from the digits of pi. It is a ``random'' nonlinear byte */
/* substitution operation. */
int S[256] = {
41, 46, 67,201,162,216,124, 1, 61, 54, 84,161,236,240, 6, 19,
98,167, 5,243,192,199,115,140,152,147, 43,217,188, 76,130,202,
30,155, 87, 60,253,212,224, 22,103, 66,111, 24,138, 23,229, 18,
190, 78,196,214,218,158,222, 73,160,251,245,142,187, 47,238,122,
169,104,121,145, 21,178, 7, 63,148,194, 16,137, 11, 34, 95, 33,
128,127, 93,154, 90,144, 50, 39, 53, 62,204,231,191,247,151, 3,
255, 25, 48,179, 72,165,181,209,215, 94,146, 42,172, 86,170,198,
79,184, 56,210,150,164,125,182,118,252,107,226,156,116, 4,241,
Linn [Page 5]
RFC 1115 Mail Privacy: Algorithms August 1989
69,157,112, 89,100,113,135, 32,134, 91,207,101,230, 45,168, 2,
27, 96, 37,173,174,176,185,246, 28, 70, 97,105, 52, 64,126, 15,
85, 71,163, 35,221, 81,175, 58,195, 92,249,206,186,197,234, 38,
44, 83, 13,110,133, 40,132, 9,211,223,205,244, 65,129, 77, 82,
106,220, 55,200,108,193,171,250, 36,225,123, 8, 12,189,177, 74,
120,136,149,139,227, 99,232,109,233,203,213,254, 59, 0, 29, 57,
242,239,183, 14,102, 88,208,228,166,119,114,248,235,117, 75, 10,
49, 68, 80,180,143,237, 31, 26,219,153,141, 51,159, 17,131, 20,
};
/*The routine MDINIT initializes the message digest context buffer md.*/
/* All fields are set to zero. */
void MDINIT(md)
struct MDCTX *md;
{ int i;
for (i=0;i<16;i++) md->D[i] = md->C[i] = 0;
md->i = 0;
md->L = 0;
}
/* The routine MDUPDATE updates the message digest context buffer to */
/* account for the presence of the character c in the message whose */
/* digest is being computed. This routine will be called for each */
/* message byte in turn. */
void MDUPDATE(md,c)
struct MDCTX *md;
unsigned char c;
{ register unsigned char i,j,t,*p;
/**** Put i in a local register for efficiency ****/
i = md->i;
/**** Add new character to buffer ****/
md->D[16+i] = c;
md->D[32+i] = c ^ md->D[i];
/**** Update checksum register C and value L ****/
md->L = (md->C[i] ^= S[0xFF & (c ^ md->L)]);
/**** Increment md->i by one modulo 16 ****/
i = md->i = (i + 1) & 15;
/**** Transform D if i=0 ****/
if (i == 0)
{ t = 0;
for (j=0;j<18;j++)
{/*The following is a more efficient version of the loop:*/
/* for (i=0;i<48;i++) t = md->D[i] = md->D[i] ^ S[t]; */
p = md->D;
for (i=0;i<8;i++)
{ t = (*p++ ^= S[t]);
t = (*p++ ^= S[t]);
t = (*p++ ^= S[t]);
t = (*p++ ^= S[t]);
t = (*p++ ^= S[t]);
Linn [Page 6]
RFC 1115 Mail Privacy: Algorithms August 1989
t = (*p++ ^= S[t]);
}
/* End of more efficient loop implementation */
t = t + j;
}
}
}
/* The routine MDFINAL terminates the message digest computation and */
/* ends with the desired message digest being in md->D[0...15]. */
void MDFINAL(md)
struct MDCTX *md;
{ int i,padlen;
/* pad out to multiple of 16 */
padlen = 16 - (md->i);
for (i=0;i<padlen;i++) MDUPDATE(md,(unsigned char)padlen);
/* extend with checksum */
/* Note that although md->C is modified by MDUPDATE, character */
/* md->C[i] is modified after it has been passed to MDUPDATE, so */
/* the net effect is the same as if md->C were not being modified.*/
for (i=0;i<16;i++) MDUPDATE(md,md->C[i]);
}
/**********************************************************************/
/* End of message digest implementation */
/**********************************************************************/
NOTES:
[1] Federal Information Processing Standards Publication 113,
Computer Data Authentication, May 1985.
[2] ANSI X9.17-1985, American National Standard, Financial
Institution Key Management (Wholesale), American Bankers
Association, April 4, 1985, Section 7.2.
[3] American National Standard Data Encryption Algorithm (ANSI
X3.92-1981), American National Standards Institute, Approved 30
December 1980.
[4] Federal Information Processing Standards Publication 46, Data
Encryption Standard, 15 January 1977.
[5] Information Processing Systems: Data Encipherment: Modes of
Operation of a 64-bit Block Cipher.
[6] Federal Information Processing Standards Publication 81,
DES Modes of Operation, 2 December 1980.
Linn [Page 7]
RFC 1115 Mail Privacy: Algorithms August 1989
[7] American National Standard for Information Systems - Data
Encryption Algorithm - Modes of Operation (ANSI X3.106-1983),
American National Standards Institute - Approved 16 May 1983.
[8] CCITT, Recommendation X.509, "The Directory: Authentication
Framework", Annex C.
[9] Moore, J., "Protocol Failures in Cryptosystems",
Proceedings of the IEEE, Vol. 76, No. 5, Pg. 597, May 1988.
Author's Address
John Linn
Secure Systems
Digital Equipment Corporation
85 Swanson Road, BXB1-2/D04
Boxborough, MA 01719-1326
Phone: 508-264-5491
EMail: Li...@ultra.enet.dec.com
Linn [Page 8]