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
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.
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
"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
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 RFCwe 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.
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.
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 RFCdoes 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
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 "linn@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
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
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
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 RFCare 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
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 RFCdoes 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.
[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
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: Linn@ultra.enet.dec.com