rfc989.txt

RFC 的详细文档！

   Although the encapsulated header fields resemble RFC-822 header
   fields, they are a disjoint set and will not in general be processed
   by the same parser which operates on enclosing header fields.  The
   complexity of lexical analysis needed and appropriate for



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


   encapsulated header field processing is significantly less than that
   appropriate to RFC-822 header processing.  For example, many
   characters with special significance to RFC-822 at the syntactic
   level have no such significance within encapsulated header fields.

   The "X-IK-ID" and "X-Key-Info" fields are the only encapsulated
   header fields with lengths which can vary beyond a size conveniently
   printable on a line.  Whitespace may be used between the subfields of
   these fields to fold them in the manner of RFC-822; such whitespace
   is not to be interpreted as a part of a subfield.

      -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
      X-Proc-Type: 1,E
      X-Pad-Count: 1
      X-IV: F8143EDE5960C597
      X-IK-ID: JL:3:ECB
      X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
      X-IK-ID: JL:1: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


     X-IK-ID:      This field is placed in the encapsulated header
                   portion of a message to identify the Interchange Key
                   used for encryption of an associated Data Encrypting
                   Key or keys (used for message text encryption and/or
                   MAC computation).  This field is used for messages
                   authenticated without confidentiality service and for
                   messages authenticated with confidentiality service.
                   The field contains (in order) an Issuing Authority
                   subfield and an IK Qualifier subfield, and may also
                   contain an optional IK Use Indicator subfield.  The
                   subfields are delimited by the colon character (":"),
                   optionally followed by whitespace.  Section 5.1.2,
                   Interchange Keys, discusses the semantics of these
                   subfields and specifies the alphabet from which they
                   are chosen.  Note that multiple X-IK-ID fields may
                   occur within a single encapsulated header.  Each X-
                   IK-ID field is associated with an immediately
                   subsequent X-Key-Info field.

     X-IV:         This field is placed in the encapsulated header
                   portion of a message to carry the Initializing Vector



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


                   used for message encryption.  It is used only for
                   messages where confidentiality service is applied.
                   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 digits.

     X-Key-Info:   This field is placed in a message's encapsulated
                   header portion to transfer two items: a DEK and a
                   MAC.  Both items are encrypted under the IK
                   identified by a preceding X-IK-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.
                   The MAC is a 64-bit quantity, represented as 16
                   hexadecimal digits.  The MAC is computed under an
                   unmodified version of the DEK.  Message encryption is
                   performed using a variant of the DEK, formed by
                   modulo-2 addition of the hexadecimal quantity
                   F0F0F0F0F0F0F0F0 to the DEK.

     X-Pad-Count:  This field is placed in the encapsulated header
                   portion of a message to indicate the number of zero-
                   valued octets which were added to pad the input
                   stream to the encryption function to an integral
                   multiple of eight octets, as required by the DEA-1
                   CBC encryption mode.  A decimal number in the range
                   0-7 follows the field name, and one or more
                   delimiting whitespace characters.  Inclusion of this
                   field allows disambiguation between terminal zero-
                   valued octets in message text (admittedly, a
                   relatively unlikely prospect) and zero-valued octets
                   inserted for padding purposes.

     X-Proc-Type:  This field is placed in the encapsulated header
                   portion of a message to identify the type of
                   processing performed on the transmitted message.  The
                   first subfield is a decimal version number, which
                   will be used if future developments make it necessary
                   to redefine the interpretation of encapsulated header
                   fields.  At present, this field may assume only the
                   value "1".  The second subfield, delimited by a
                   comma, assumes one of two single-character alphabetic
                   values: "A" and "E", to signify, respectively, (1)
                   authentication processing only and (2) the
                   combination of authentication and confidentiality
                   service through encryption.




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


5 Key Management

5.1 Types of Keys

5.1.1 Data Encrypting Keys (DEKs)

   Data Encrypting Keys (DEKs) are used for encryption of message text
   and for computation of message authentication codes (MACs).  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 interchange key (IK) known to the
   authorized recipient.

   DEK generation can be performed either centrally by key distribution
   centers (KDCs) or by endpoint systems.  One advantage of centralized
   KDC-based generation is that DEKs can be returned to endpoints
   already encrypted under the IKs of message recipients.  This reduces
   IK exposure and simplifies endpoint key management requirements.
   Further, dedicated KDC systems may be able to implement better
   algorithms for random key 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 by
   endpoints reduces the frequency with which senders must make real-
   time queries of (potentially unique) servers in order to send mail,
   enhancing communications availability.

5.1.2 Interchange Keys (IKs)

   Interchange Keys (IKs) are used to encrypt Data Encrypting Keys.  In
   general, the granularity of IK usage 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 asymmetric
   cryptography is used, an originator and recipient must possess
   appropriate public and secret components which, in composition,
   constitute an interchange key.

   The means by which interchange keys are provided to appropriate
   parties are outside the scope of this RFC, but may be centralized
   (e.g., via key management servers) or decentralized (e.g., via direct
   distribution among users).  In any case, a given IK is associated
   with a responsible Issuing Authority (IA).  When an IA generates and
   distributes an IK, associated control information must be 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 IKs 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



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


   appropriate.

   When a privacy-enhanced message is transmitted, an indication of the
   IK (or IKs, in the case of a message sent to multiple recipients)
   used for DEK encryption must be included.  To this end, the IK ID
   construct is defined to provide the following data:

        1.   Identification of the relevant Issuing Authority (IA
             subfield)

        2.   Qualifier string to distinguish the particular IK within
             the set of IKs distributed by the IA (IK qualifier
             subfield)

        3.   (Optional) Indicator of IK usage mode (IK use indicator
             subfield)


   The subfields of an IK ID are delimited with the colon character
   (":").  The IA and IK qualifier 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):

   IAorIKQual   :=      1*ia-char

   ia-char      :=      DIGIT / ALPHA / "'" / "+" / "(" / ")" /
                        "," / "." / "/" / "=" / "?" / "-" / "@" /
                        "%" / "!" / '"' / "_" / "<" / ">"

   The IK use indicator subfield assumes a value from a small set of
   reserved strings, described later in this section.

   IA identifiers must be assigned in a manner which assures uniqueness.
   This can be done on a centralized or hierarchic basis.

   The IK qualifier string format may vary among different IAs, but must
   satisfy certain functional constraints.  An IA's IK qualifiers must
   be sufficient to distinguish among the set of IKs issued by that IA.
   Since a message may be sent with multiple IK IDs, corresponding to
   multiple intended recipients, each recipient must be able to
   determine which IK is intended for it.  Moreover, if no corresponding
   IK is available in the recipient's database when a message arrives,
   the recipient must be able to determine which IK to request and to
   identify that IK'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 an IK shared
   between A and B, but the second would use an IK shared among list
   members.




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


   While use of a monotonically increasing number as an IK qualifier is
   sufficient to distinguish among the set of IKs distributed by an IA,
   it offers no facility for a recipient lacking a matching IK to
   determine the appropriate IK to request.  This suggests that sender
   and recipient name information should be incorporated into an IK
   qualifier, along with a number to distinguish among multiple IKs used
   between a sender/recipient pair.  In order to support universal
   interoperability, it is necessary to assume a universal form for the
   naming information.  General definition of such a form requires
   further study; issues and possible approaches will be noted in
   Section 6.  As an interim measure, the following IK qualifier format
   is suggested:

              <sender-name>/<recipient-name>/<numid>

   where <sender-name> and <recipient-name> are in the following form:

              <user>@<domain-qualified-host>

   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.  The
   <numid> is a contiguous string of decimal digits.