rfc1040.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   If, in contrast, a message's sender is equipped to expand the
   destination mailing list into its individual constituents and elects
   to do so (IK-per-recipient), the message's DEK and MIC will be
   encrypted under each per-recipient IK and all such encrypted
   representations will be incorporated into the transmitted message.
   Note that per-recipient encryption is required only for the
   relatively small DEK and MIC quantities carried in the X-Key-Info
   field, not for the message text which is, in general, much larger.
   Although more IKs are involved in processing under the IK-
   perrecipient method, the pairwise IKs can be individually revoked and
   possession of one IK does not enable a successful masquerade of
   another user on the list.

4.6  Summary of Added Header and Control Fields

   This section summarizes the syntax and semantics of the new
   encapsulated header fields to be added to messages in the course of
   privacy enhancement processing.  In certain indicated cases, it is
   recommended that the fields be replicated within the encapsulated
   text portion as well.  Figure 2 shows the appearance of a small
   example encapsulated message using these fields.  The example assumes
   the use of symmetric cryptography; no "X-Certificate:" field is
   carried.  In all cases, hexadecimal quantities are represented as
   contiguous strings of digits, where each digit is represented by a
   character from the ranges "0"-"9" or upper case "A"-"F".  Unless
   otherwise specified, all arguments are to be processed in a
   casesensitive fashion.

   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
   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.

   When the length of an encapsulated header field is longer than the
   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,
   section 3.1.1.  Any such inserted whitespace is not to be interpreted
   as a part of a subfield.









Linn                                                           [Page 16]

RFC 1040        Privacy Enhancement for Electronic Mail     January 1988


   -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
   X-Proc-Type: 2
   X-IV: F8143EDE5960C597
   X-Sender-ID: [e-mail]:::
   X-Recipient-ID: [e-mail]:ptf-kmc:3:BMAC:ECB
   X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
   X-Recipient-ID: [e-mail]: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