When a privacy-enhanced message is transmitted, an indication of the
IK components used for DEK 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. Indicator of IK usage mode (IK use indicator subfield).
4. 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:BMAC:ECB
This example field indicates that IA "ptf-kmc" has issued an IK
component for use on messages sent to "linn@ccy.bbn.com", that the IA
has provided the number 2 as a version indicator for that IK
component, that the BMAC MIC computation algorithm is to be used for
the recipient, and that the IK component is to be used in ECB mode.
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.1.4 MIC Algorithm Identifier Subfield
The MIC algorithm identifier, which occurs only within X-Recipient-ID
fields, is used to identify the choice of message integrity check
algorithm for a given recipient. Appendix A of this RFCspecifies
the defined values for this subfield.
5.2.1.5 IK Use Indicator Subfield
The IK use indicator subfield is an optional facility, provided to
identify the encryption mode in which an IK component is to be used.
Currently, this subfield may assume the following reserved string
values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the default
value is "ECB".
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.
5.3 Certificates
In an asymmetric key management architecture, a certificate binds an
entity's public key component to a representation of the entity's
identity and other attributes of the entity. A certificate's issuing
authority signs the certificate, vouching for the correspondence
between the entity's identity, attributes, and associated public key
component. Once signed, certificate copies may be posted on multiple
servers in order to make recipients' certificates directly accessible
to originators at dispersed locations. This allows privacy-enhanced
mail to be sent between an originator and a recipient without prior
placement of a pairwise key at the originator and recipient, greatly
enhancing mail system flexibility. The properties of a certificate's
authority-applied signature make it unnecessary to be concerned about
the prospect that servers, or other entities, could undetectably
modify certificate contents so as to associate a public key with an
inappropriate entity.
Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a
subject's certificate is defined to contain the following parameters:
1. A signature algorithm identifier, identifying the
algorithm used by the certificate's issuer to compute the
signature applied to the certificate.
2. Issuer identification, identifying the certificate's
issuer with an O/R name.
3. Validity information, providing date and time limits
before and after which the certificate should not be
used.
4. Subject identification, identifying the certificate's
subject with an O/R name.
5. Subject's public key.
6. Algorithm identifier, identifying the algorithm with
which the subject's public key is to be used.
7. Signature, an asymmetrically encrypted, hashed version of
the above parameters, computed by the certificate's
issuer.
The Recommendations specify an ASN.1 encoding to define a
certificate. Pending further study, it is recommended that
electronic mail privacy enhancement implementations using asymmetric
cryptography for key management employ this encoding for
certificates. Section 4.2.3 of RFC-987 [14] specifies a procedure
for mapping RFC-822 addresses into the O/R names used in X.411/X.509
certificates.
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
requiring significant study. A logical association exists between
key distribution and name/directory server functions; their
relationship is a topic deserving further consideration. These
issues have not been fully resolved at this writing. The current
architecture relies on association of IK components with user names
represented in a universal form ("user@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. 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(tm) 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, 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 pilot
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. Standardization of Issuing Authority functions, including
protocols for communications among IAs and between User
Agents and IAs.
3. Specification of public key encryption algorithms to encrypt
data encrypting keys.
4. 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.
A. Message Integrity Check Algorithms
This appendix identifies the alternative algorithms which may be used
to compute Message Integrity Check (MIC) values, and assigns them
character string identifiers to be incorporated in "X-Recipient-ID:"
fields to indicate the choice of algorithm employed for individual
message recipients.
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.
A.1 Conventional MAC (MAC)
A conventional MAC, denoted by the string "MAC", is computed using
the DEA-1 algorithm in the fashion defined in FIPS PUB 113 [15]. Use
of the conventional MAC is not recommended for multicast messages.
The message's encapsulated 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 conventional MAC computation is a single 64-bit value.
A.2 Bidirectional MAC (BMAC)
A bidirectional MAC, denoted by the string "BMAC", yields a result
which is transferred as a single 128-bit value. The BMAC is computed
in the following manner: First, the encapsulated text is padded at
the end 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. A
conventional MAC is computed on the padded form, and the resulting
64-bits form the high-order 64-bits of the BMAC result.
The low-order 64-bits of the BMAC result are also formed by computing
a conventional MAC, but the order of the 8-octet encryption quanta is
reversed for purposes of computation. In other words, the first
quantum entered into this computation is the last quantum in the
encapsulated text, and includes any added padding. The first quantum
in the text is the last quantum processed as input to this
computation. The octets within each 8-octet quantum are not
reordered.
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.
[2] Information Processing Systems: Data Encipherment: Block
Cipher Algorithm DEA 1.
[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] Addendum to the Transport Layer Protocol Definition for
Providing Connection Oriented End to End Cryptographic Data
Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft
of 19 December 1985, Gaithersburg, MD, p. 15.
[7] Postel, J., Simple Mail Transfer Protocol (RFC-821), 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. T. and Stefferud, E. A., 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. E., Mapping between X.400 and RFC-822 (RFC-987),
June 1986.
[15] Federal Information Processing Standards Publication 113,
Computer Data Authentication, May 1985.