brian@ucsd.EDU (Brian Kantor) (05/03/88)
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type: 2
X-IV: F8143EDE5960C597
X-Sender-ID: linn@ccy.bbn.com:::
X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3:BMAC:ECB
X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4:BMAC:ECB
X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message
Figure 2
4.6.1 X-Certificate Field
The X-Certificate encapsulated header field is used only when
public-key certificate key management is employed. It transfers a
sender's certificate as a string of hexadecimal digits. The
semantics of a certificate are discussed in Section 5.3,
Certificates. The certificate carried in an X-Certificate field is
used in conjunction with all subsequent X-Sender-ID and X-RecipientID
fields until another X-Certificate field occurs; the ordinary case
will be that only a single X-Certificate field will occur, prior to
any X-Sender-ID and X-Recipient-ID fields.
Due to the length of a certificate, it may need to be folded across
multiple printed lines. In order to enable such folding to be
performed, the hexadecimal digits representing the contents of a
certificate are to be divided into an ordered set (with more
significant digits first) of zero or more 64-digit groups, followed
by a final digit group which may be any length up to 64-digits. A
single whitespace character is interposed between each pair of groups
so that folding (per RFC-822, section 3.1.1) may take place; this
whitespace is ignored in parsing the received digit string.
4.6.2 X-IV Field
The X-IV encapsulated header field carries the Initializing Vector
used for message encryption. Only one X-IV field occurs in a
message. It appears in all messages, even if the entirety of message
text is excluded from encryption. Following the field name, and one
or more delimiting whitespace characters, a 64-bit Initializing
Vector is represented as a contiguous string of 16 hexadecimal
Linn [Page 17]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
digits.
4.6.3 X-Key-Info Field
The X-Key-Info encapsulated header field transfers two items: a DEK
and a MIC. One X-Key-Info field is included for each of a message's
named recipients. 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. For DEA-1, 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. MICs are also
represented as contiguous strings of hexadecimal digits. The size of
a MIC is dependent on the choice of MIC algorithm as specified in the
X-Recipient-ID field corresponding to a given recipient.
4.6.4 X-Proc-Type Field
The X-Proc-Type encapsulated header field identifies the type of
processing performed on the transmitted message. Only one X-ProcType
field occurs in a message. It has one subfield, 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 "2".
4.6.5 X-Sender-ID Field
The X-Sender-ID encapsulated header field provides the sender's
interchange key identification component. It should be replicated
within the encapsulated text. The interchange key 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, an (optional)
Version/Expiration subfield, and an (optional) IK Use Indicator
subfield. The optional subfields are omitted if their use is
rendered redundant by information carried in subsequent X-RecipientID
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.
Linn [Page 18]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.6 X-Recipient-ID Field
The X-Recipient-ID encapsulated header field provides the recipient's
interchange key 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,
a Version/Expiration subfield, a MIC algorithm indicator subfield,
and an IK Use Indicator subfield. The subfields are delimited by the
colon character (":"), optionally followed by whitespace.
The MIC algorithm indicator is an ASCII string, selected from the
values defined in Appendix A of this RFC. Section 5.2, Interchange
Keys, discusses the semantics of the other 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
XSender-ID field; it is illegal for an X-Recipient-ID field to
occur in a header before an X-Sender-ID has been provided.
5. Key Management
Several cryptographic constructs are involved in supporting the
privacy-enhanced message processing procedure. While (as noted in
the Executive Summary section of this RFC), key management mechanisms
have not yet been fully defined, a set of fundamental elements are
assumed. Data Encrypting Keys (DEKs) are used to encrypt message
text and in the message integrity check (MIC) computation process.
Interchange Keys (IKs) are used to encrypt DEKs for transmission with
messages. In an asymmetric key management architecture, certificates
are used as a means to provide entities' public key 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 for computation of message integrity check quantities (MICs). It
is strongly recommended that DEKs be generated and used on a one-time
basis. A transmitted message will incorporate a representation of
the DEK encrypted under an appropriate interchange key (IK) for each
the authorized recipient.
Linn [Page 19]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
DEK generation can be performed either centrally by key distribution
centers (KDCs) or by endpoint systems. Dedicated KDC systems may be
able to implement better 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 secret IK components need not necessarily be
shared with a KDC.
5.2 Interchange Keys (IKs)
Interchange Keys (IKs) are used to encrypt Data Encrypting Keys. 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
share a common interchange key. When symmetric cryptography is used,
the interchange key consists of a single component. When asymmetric
cryptography is used, an originator and recipient must possess an
asymmetric key's public and secret components, as appropriate. This
pair of components, when composed, constitute an interchange key.
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 an IA generates and
distributes an IK, associated control information is provided to
direct how that IK is to be used. In order to select the appropriate
IK 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.
Linn [Page 20]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
Since a message may be sent with multiple IK component
representations, corresponding to multiple intended recipients, each
recipient must be able to determine which IK component is intended
for it. Moreover, if no corresponding IK component is available in
the recipient's database when a message arrives, the recipient must
be able to determine which IK component to request and to 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 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
Linn [Page 21]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 RFC specifies
the defined values for this subfield.
Linn [Page 22]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.
Linn [Page 23]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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.
Linn [Page 24]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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
Linn [Page 25]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 RFC are 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.
Linn [Page 26]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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
Linn [Page 27]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
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 RFC does 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.
Linn [Page 28]
RFC 1040 Privacy Enhancement for Electronic Mail January 1988
[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.
Linn [Page 29]