rfc989.txt

RFC 的详细文档！

   The IK use indicator subfield is an optional facility, provided to
   identify the encryption mode in which the IK is to be used.
   Currently, this subfield may assume the following reserved string
   values: "ECB" and "EDE"; the default value is ECB.

   An example IK ID adhering to this recommendation is as follows:

          ptf-kmc:[e-mail]/[e-mail]/2:ECB

   This IK ID would indicate that IA "ptf-kmc" has issued an IK for use
   on messages sent from "[e-mail]" to "[e-mail]",
   that the IA has associated number 2 with that IK, and that the IK is
   to be used in ECB mode.

   IKs will remain valid for a period which will be longer than a single
   message and will be identified by an expiration time distributed
   along with the IK; IK cryptoperiod is dictated in part by a tradeoff
   between key management overhead and revocation responsiveness.  It
   would be undesirable to delete an IK permanently before receipt of a
   message encrypted using that IK, as this would render the message
   permanently undecipherable.  Access to an expired IK 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 IKs 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 IKs for indefinite



Linn, Privacy Task Force                                       [Page 19]

RFC 989                                                    February 1987


   periods.

6 User Naming

   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 interim
   architecture relies on association of IKs with user names represented
   in a universal form, which has the following properties:

          1.   The universal form must be specifiable by an IA as it
               distributes IKs and known to a UA as it processes
               received IKs and IK IDs.  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 global form used
   for Internet mail transmission may cause property 2 to be violated.

   The use of flat (non-hierarchic) electronic mail user identifiers,
   which are unrelated to the hosts on which the users reside, appears
   useful.  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 Domain
   Name 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



Linn, Privacy Task Force                                       [Page 20]

RFC 989                                                    February 1987


   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 [10]
   which is invoked by a user, and lies above the existing UA sublayer.
   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 IKs is maintained in a
   local file, with entries managed manually based on pairwise
   agreements between originators and recipients.  This cache is,
   effectively, a simple database.  IKs are selected for transmitted
   messages based on recipient names, and corresponding IK IDs are
   placed into the message's encapsulated header.  When a message is
   received, the IK ID is used as a basis for a lookup in the database,
   yielding the appropriate IK entry.  DEKs and IVs are generated
   dynamically within the program.

   Options (e.g., authentication only vs. authentication with
   confidentiality service) are selected by command line arguments to
   the standalone program.  Destination addresses are specified in the
   same fashion.  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 for IK 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



Linn, Privacy Task Force                                       [Page 21]

RFC 989                                                    February 1987


          functions

     2.   Standardization of Issuing Authority functions, including
          protocols for communications among IAs and between User Agents
          and IAs

     3.   Use 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
          MAC computation.

     FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
          specific modes in which the Data Encryption Standard algorithm
          is to be used to perform encryption and MAC computation.

NOTES:


     [1]  Information Processing Systems: Data Encipherment: Block
          Cipher Algorithm DEA 1.

     [2]  Federal Information Processing Standards Publication 46, Data
          Encryption Standard, 15 January 1977.

     [3]  Information Processing Systems: Data Encipherment: Modes of
          Operation of a 64-bit Block Cipher

     [4]  Federal Information Processing Standards Publication 81, DES
          Modes of Operation, 2 December 1980.




Linn, Privacy Task Force                                       [Page 22]

RFC 989                                                    February 1987


     [5]  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.

     [6]  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.

     [7]  Crocker, D. Standard for the Format of ARPA Internet Text
          Messages (RFC822), August 1982.

     [8]  Rose, M. T., and Stefferud, E. A., Proposed Standard for
          Message Encapsulation, January 1985.

     [9]  Key generation for authentication 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.1 identifies possible advantages of
          a centralized server approach.

     [10] Note that 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.




























Linn, Privacy Task Force                                       [Page 23]