rfc1040.txt

RFC 的详细文档！

   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: [e-mail]:ptf-kmc:2:BMAC:ECB

   This example field indicates that IA "ptf-kmc" has issued an IK
   component for use on messages sent to "[e-mail]", 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