rfc1113.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
   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 to fold
   the field 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.  As a
   particular example, due to the length of public-key certificates and
   of quantities encrypted using asymmetric algorithms, such quantities
   may often need to be folded across multiple printed lines.  In order
   to facilitate such folding in a uniform manner, the bits representing
   such a quantity are to be divided into an ordered set (with leftmost
   bits first) of zero or more 384-bit groups (corresponding to 64-
   character printed representations), followed by a final group of bits
   which may be any length up to 384 bits.

4.6.1  Per-Message Encapsulated Header Fields

   This group of encapsulated header fields contains fields which occur
   no more than once in a privacy-enhanced message, generally preceding
   all other encapsulated header fields.

4.6.1.1  X-Proc-Type Field

   The "X-Proc-Type:" encapsulated header field, required for all
   privacy-enhanced messages, identifies the type of processing



Linn                                                           [Page 20]

RFC 1113                Mail Privacy: Procedures             August 1989


   performed on the transmitted message.  Only one "X-Proc-Type:" field
   occurs in a message; the "X-Proc-Type:" field must be the first
   encapsulated header field in the message.

   The "X-Proc-Type:" field has two subfields, separated by a comma.
   The first subfield is 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 "3" to
   distinguish them from messages processed in accordance with prior
   RFCs 989 and 1040.

   The second subfield may assume one of two string values: "ENCRYPTED"
   or "MIC-ONLY".  Unless all of a message's encapsulated text is
   excluded from encryption, the "X-Proc-Type:" field's second subfield
   must specify "ENCRYPTED".  Specification of "MIC-ONLY", when applied
   in conjunction with certain combinations of key management and MIC
   algorithm options, permits certain fields which are superfluous in
   the absence of encryption to be omitted from the encapsulated header.
   In particular, "X-Recipient-ID:" and "X-Key-Info:" fields can be
   omitted for recipients for whom asymmetric cryptography is used,
   assuming concurrent use of a keyless MIC computation algorithm.  The
   "X-DEK-Info:" field can be omitted for all "MIC-ONLY" messages.

4.6.1.2  X-DEK-Info Field

   The "X-DEK-Info:" encapsulated header field identifies the message
   text encryption algorithm and mode, and also carries the Initializing
   Vector used for message encryption.  No more than one "X-DEK-Info:"
   field occurs in a message; the field is required except for messages
   specified as "MIC-ONLY" in the "X-Proc-Type:" field.

   The "X-DEK-Info:" field carries two arguments, separated by a comma.
   For purposes of this RFC, the first argument must be the string
   "DES-CBC", signifying (as defined in RFC-1115) use of the DES
   algorithm in the CBC mode.  The second argument represents a 64-bit
   Initializing Vector (IV) as a contiguous string of 16 hexadecimal
   digits.  Subsequent revisions of RFC-1115 will specify any additional
   values which may appear as the first argument of this field.

4.6.2  Encapsulated Header Fields Normally Per-Message

   This group of encapsulated header fields contains fields which
   ordinarily occur no more than once per message.  Depending on the key
   management option(s) employed, some of these fields may be absent
   from some messages.  The "X-Sender-ID" field may occur more than once
   in a message if different sender-oriented IK components (perhaps
   corresponding to different versions) must be used for different



Linn                                                           [Page 21]

RFC 1113                Mail Privacy: Procedures             August 1989


   recipients. In this case later occurrences override prior
   occurrences.  If a mixture of symmetric and asymmetric key
   distribution is used within a single message, the recipients for each
   type of key distribution technology should be grouped together to
   simplify parsing.

4.6.2.1  X-Sender-ID Field

   The "X-Sender-ID:" encapsulated header field, required for all
   privacy-enhanced messages, identifies a message's sender and provides
   the sender's IK identification component.  It should be replicated
   within the encapsulated text.  The IK 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, and an (optional)
   Version/Expiration subfield.  The optional subfields are omitted if
   their use is rendered redundant by information carried in subsequent
   "X-Recipient-ID:" 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.
   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.2.2  X-Certificate Field

   The "X-Certificate:" encapsulated header field is used only when
   asymmetric key management is employed for one or more of a message's
   recipients.  To facilitate processing by recipients (at least in
   advance of general directory server availability), inclusion of this
   field in all messages is strongly recommended.  The field transfers a
   sender's certificate as a numeric quantity, represented with the
   encoding mechanism defined in Section 4.3.2.4 of this RFC.  The
   semantics of a certificate are discussed in RFC-1114.  The
   certificate carried in an "X-Certificate:" field is used in
   conjunction with "X-Sender-ID:" and "X-Recipient-ID:" fields for
   which asymmetric key management is employed.




Linn                                                           [Page 22]

RFC 1113                Mail Privacy: Procedures             August 1989


4.6.2.3  X-MIC-Info Field

   The "X-MIC-Info:" encapsulated header field, used only when
   asymmetric key management is employed for at least one recipient of a
   message, carries three arguments, separated by commas.  The first
   argument identifies the algorithm under which the accompanying MIC is
   computed; RFC-1115 specifies the acceptable set of MIC algorithm
   identifiers.  The second argument identifies the algorithm under
   which the accompanying MIC is encrypted; for purposes of this RFC,
   the string "RSA" as described in RFC-1115  must occur, identifying
   use of the RSA algorithm.  The third argument is a MIC,
   asymmetrically encrypted using the originator's private component.
   As discussed earlier in this section, the asymmetrically encrypted
   MIC is represented using the technique described in Section 4.3.2.4
   of this RFC.

   The "X-MIC-Info:" field will occur immediately following the
   message's "X-Sender-ID:" field and any "X-Certificate:" or "X-
   Issuer-Certificate:" fields.  Analogous to the "X-Sender-ID:" field,
   an "X-MIC-Info:" field applies to all subsequent recipients for whom
   asymmetric key management is used.

4.6.3  Encapsulated Header Fields with Variable Occurrences

   This group of encapsulated header fields contains fields which will
   normally occur variable numbers of times within a message, with
   numbers of occurrences ranging from zero to non-zero values which are
   independent of the number of recipients.

4.6.3.1  X-Issuer-Certificate Field

   The "X-Issuer-Certificate:" encapsulated header field is meaningful
   only when asymmetric key management is used for at least one of a
   message's recipients.  A typical "X-Issuer-Certificate:" field would
   contain the certificate containing the public component used to sign
   the certificate carried in the message's "X-Certificate:" field, for
   recipients' use in chaining through that certificate's certification
   path.  Other "X-Issuer-Certificate:" fields, typically representing
   higher points in a certification path, also may be included by a
   sender.  The order in which "X-Issuer-Certificate:" fields are
   included need not correspond to the order of the certification path;
   the order of that path may in general differ from the viewpoint of
   different recipients.  More information on certification paths can be
   found in RFC-1114.

   The certificate is represented in the same manner as defined for the
   "X-Certificate:" field, and any "X-Issuer-Certificate:" fields will
   ordinarily follow the "X-Certificate:" field directly.  Use of the



Linn                                                           [Page 23]

RFC 1113                Mail Privacy: Procedures             August 1989


   "X-Issuer-Certificate:" field is optional even when asymmetric key
   management is employed, although its incorporation is strongly
   recommended in the absence of alternate directory server facilities
   from which recipients can access issuers' certificates.

4.6.4  Per-Recipient Encapsulated Header Fields

   This group of encapsulated header fields normally appears once for
   each of a message's named recipients.  As a special case, these
   fields may be omitted in the case of a "MIC-ONLY" message to
   recipients for whom asymmetric key management is employed, given that
   the chosen MIC algorithm is keyless.

4.6.4.1  X-Recipient-ID Field

   The "X-Recipient-ID:" encapsulated header field identifies a
   recipient and provides the recipient's IK 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, and a Version/Expiration subfield.  The
   subfields are delimited by the colon character (":"), optionally
   followed by whitespace.

   Section 5.2, Interchange Keys, discusses the semantics of the
   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 "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.4.2  X-Key-Info Field

   One "X-Key-Info:" field is included for each of a message's named
   recipients.  Each "X-Key-Info:" field is interpreted in the context
   of the most recent preceding "X-Recipient-ID:" field; normally, an
   "X-Key-Info:" field will immediately follow its associated "X-
   Recipient-ID:" field.  The field's argument(s) differ depending on
   whether symmetric or asymmetric key management is used for a
   particular recipient.

4.6.4.2.1  Symmetric Key Management

   When symmetric key management is employed for a given recipient, the
   "X-Key-Info:" encapsulated header field transfers four items,
   separated by commas: an IK Use Indicator, a MIC Algorithm Indicator,
   a DEK and a MIC.  The IK Use Indicator identifies the algorithm and
   mode in which the identified IK was used for DEK encryption for a



Linn                                                           [Page 24]

RFC 1113                Mail Privacy: Procedures             August 1989


   particular recipient.  For recipients for whom symmetric key
   management is used, it may assume the reserved string values "DES-
   ECB" or "DES-EDE", as defined in RFC-1115.

   The MIC Algorithm Indicator identifies