rfc1421.txt

中、英文RFC文档大全打包下载完全版 .

        6.  assurance of message receipt and non-deniability of receipt,

        7.  automatic association of acknowledgments with the messages
            to which they refer, and

        8.  message duplicate detection, replay prevention, or other
            stream-oriented services

4.  Processing of Messages

4.1  Message Processing Overview

   This subsection provides a high-level overview of the components and
   processing steps involved in electronic mail privacy enhancement
   processing.  Subsequent subsections will define the procedures in
   more detail.

4.1.1  Types of Keys

   A two-level keying hierarchy is used to support PEM transmission:

        1.  Data Encrypting Keys (DEKs) are used for encryption of
            message text and (with certain choices among a set of
            alternative algorithms) for computation of message integrity
            check (MIC) quantities.  In the asymmetric key management
            environment, DEKs are also used to encrypt the signed
            representations of MICs in PEM messages to which
            confidentiality has been applied. DEKs are generated
            individually for each transmitted message; no
            predistribution of DEKs is needed to support PEM
            transmission.

        2.  Interchange Keys (IKs) are used to encrypt DEKs for
            transmission within messages.  Ordinarily, the same IK will
            be used for all messages sent from a given originator to a
            given recipient over a period of time.  Each transmitted
            message includes a representation of the DEK(s) used for
            message encryption and/or MIC computation, encrypted under
            an individual IK per named recipient.  The representation is



Linn                                                            [Page 6]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


            associated with Originator-ID and Recipient-ID fields
            (defined in different forms so as to distinguish symmetric
            from asymmetric cases), which allow each individual
            recipient to identify the IK used to encrypt DEKs and/or
            MICs for that recipient's use.  Given an appropriate IK, a
            recipient can decrypt the corresponding transmitted DEK
            representation, yielding the DEK required for message text
            decryption and/or MIC validation.  The definition of an IK
            differs depending on whether symmetric or asymmetric
            cryptography is used for DEK encryption:

                 2a. When symmetric cryptography is used for DEK
                     encryption, an IK is a single symmetric key shared
                     between an originator and a recipient.  In this
                     case, the same IK is used to encrypt MICs as well
                     as DEKs for transmission.  Version/expiration
                     information and IA identification associated with
                     the originator and with the recipient must be
                     concatenated in order to fully qualify a symmetric
                     IK.

                 2b. When asymmetric cryptography is used, the IK
                     component used for DEK encryption is the public
                     component [8] of the recipient.  The IK component
                     used for MIC encryption is the private component of
                     the originator, and therefore only one encrypted
                     MIC representation need be included per message,
                     rather than one per recipient.  Each of these IK
                     components can be fully qualified in a Recipient-ID
                     or Originator-ID field, respectively.
                     Alternatively, an originator's IK component may be
                     determined from a certificate carried in an
                     "Originator-Certificate:" field.

4.1.2  Processing Procedures

   When PEM processing is to be performed on an outgoing message, a DEK
   is generated [1] for use in message encryption and (if a chosen MIC
   algorithm requires a key) a variant of the DEK is formed for use in
   MIC computation.  DEK generation can be omitted for the case of a
   message where confidentiality is not to be applied, unless a chosen
   MIC computation algorithm requires a DEK.  Other parameters (e.g.,
   Initialization Vectors (IVs)) as required by selected encryption
   algorithms are also generated.

   One or more Originator-ID and/or "Originator-Certificate:" fields are
   included in a PEM message's encapsulated header to provide recipients
   with an identification component for the IK(s) used for message



Linn                                                            [Page 7]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   processing.  All of a message's Originator-ID and/or "Originator-
   Certificate:" fields are assumed to correspond to the same principal;
   the facility for inclusion of multiple such fields accomodates the
   prospect that different keys, algorithms, and/or certification paths
   may be required for processing by different recipients.  When a
   message includes recipients for which asymmetric key management is
   employed as well as recipients for which symmetric key management is
   employed, a separate Originator-ID or "Originator-Certificate:" field
   precedes each set of recipients.

   In the symmetric case, per-recipient IK components are applied for
   each individually named recipient in preparation of ENCRYPTED, MIC-
   ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID-
   Symmetric:" field, interpreted in the context of the most recent
   preceding "Originator-ID-Symmetric:" field, serves to identify each
   IK.  In the asymmetric case, per-recipient IK components are applied
   only for ENCRYPTED messages, are independent of originator-oriented
   header elements, and are identified by "Recipient-ID-Asymmetric:"
   fields.  Each Recipient-ID field is followed by a "Key-Info:" field,
   which transfers the message's DEK encrypted under the IK appropriate
   for the specified recipient.

   When symmetric key management is used for a given recipient, the
   "Key-Info:" field following the corresponding "Recipient-ID-
   Symmetric:" field also transfers the message's computed MIC,
   encrypted under the recipient's IK. When asymmetric key management is
   used, a "MIC-Info:" field associated with an "Originator-ID-
   Asymmetric:" or "Originator-Certificate:" field carries the message's
   MIC, asymmetrically signed using the private component of the
   originator.  If the PEM message is of type ENCRYPTED (as defined in
   Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is
   symmetrically encrypted using the same DEK, algorithm, encryption
   mode and other cryptographic parameters as used to encrypt the
   message text, prior to inclusion in the "MIC-Info:" field.

4.1.2.1  Processing Steps

   A four-phase transformation procedure is employed in order to
   represent encrypted message text in a universally transmissible form
   and to enable messages encrypted on one type of host computer to be
   decrypted on a different type of host computer.  A plaintext message
   is accepted in local form, using the host's native character set and
   line representation.  The local form is converted to a canonical
   message text representation, defined as equivalent to the inter-SMTP
   representation of message text.  This canonical representation forms
   the input to the MIC computation step (applicable to ENCRYPTED, MIC-
   ONLY, and MIC-CLEAR messages) and the encryption process (applicable
   to ENCRYPTED messages only).



Linn                                                            [Page 8]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   For ENCRYPTED PEM messages, the canonical representation is padded as
   required by the encryption algorithm, and this padded canonical
   representation is encrypted. The encrypted text (for an ENCRYPTED
   message) or the unpadded canonical form (for a MIC-ONLY message) is
   then encoded into a printable form.  The printable form is composed
   of a restricted character set which is chosen to be universally
   representable across sites, and which will not be disrupted by
   processing within and between MTS entities. MIC-CLEAR PEM messages
   omit the printable encoding step.

   The output of the previous processing steps is combined with a set of
   header fields carrying cryptographic control information.  The
   resulting PEM message is passed to the electronic mail system to be
   included within the text portion of a transmitted message. There is
   no requirement that a PEM message comprise the entirety of an MTS
   message's text portion; this allows PEM-protected information to be
   accompanied by (unprotected) annotations.  It is also permissible for
   multiple PEM messages (and associated unprotected text, outside the
   PEM message boundaries) to be represented within the encapsulated
   text of a higher-level PEM message. PEM message signatures are
   forwardable when asymmetric key management is employed; an authorized
   recipient of a PEM message with confidentiality applied can reduce
   that message to a signed but unencrypted form for forwarding purposes
   or can re-encrypt that message for subsequent transmission.

   When a PEM message is received, the cryptographic control fields
   within its encapsulated header provide the information required for
   each authorized recipient to perform MIC validation and decryption of
   the received message text.  For ENCRYPTED and MIC-ONLY messages, the
   printable encoding is converted to a bitstring.  Encrypted portions
   of the transmitted message are decrypted.  The MIC is validated.
   Then, the recipient PEM process converts the canonical representation
   to its appropriate local form.

4.1.2.2  Error Cases

   A variety of error cases may occur and be detected in the course of
   processing a received PEM message. The specific actions to be taken
   in response to such conditions are local matters, varying as
   functions of user preferences and the type of user interface provided
   by a particular PEM implementation, but certain general
   recommendations are appropriate. Syntactically invalid PEM messages
   should be flagged as such, preferably with collection of diagnostic
   information to support debugging of incompatibilities or other
   failures.  RFC 1422 defines specific error processing requirements
   relevant to the certificate-based key management mechanisms defined
   therein.




Linn                                                            [Page 9]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   Syntactically valid PEM messages which yield MIC failures raise
   special concern, as they may result from attempted attacks or forged
   messages.  As such, it is unsuitable to display their contents to
   recipient users without first indicating the fact that the contents'
   authenticity and integrity cannot be guaranteed and then receiving
   positive user confirmation of such a warning.  MIC-CLEAR messages
   (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns,
   as MIC failures on such messages may occur for a broader range of
   benign causes than are applicable to other PEM message types.

4.2  Encryption Algorithms, Modes, and Parameters

   For use in conjunction with this RFC, RFC 1423 defines the
   appropriate algorithms, modes, and associated identifiers to be used
   for encryption of message text with DEKs.

   The mechanisms defined in this RFC incorporate facilities for
   transmission of cryptographic parameters (e.g., pseudorandom
   Initializing Vectors (IVs)) with PEM messages to which the
   confidentiality service is applied, when required by symmetric
   message encryption algorithms and modes specified in RFC 1423.

   Certain operations require encryption of DEKs, MICs, and digital
   signatures under an IK for purposes of transmission.  A header
   facility indicates the mode in which the IK is used for encryption.
   RFC 1423 specifies encryption algorithm and mode identifiers and
   minimum essential support requirements for key encryption processing.

   RFC 1422 specifies asymmetric, certificate-based key management
   procedures based on CCITT Recommendation X.509 to support the message
   processing procedures defined in this document. Support for the key
   management approach defined in RFC 1422 is strongly recommended.  The
   message processing procedures can also be used with symmetric key
   management, given prior distribution of suitable symmetric IKs, but
   no current RFCs specify key distribution procedures for such IKs.

4.3  Privacy Enhancement Message Transformations

4.3.1  Constraints

   An electronic mail encryption mechanism must be compatible with the
   transparency constraints of its underlying electronic mail
   facilities.  These constraints are generally established based on
   expected user requirements and on the characteristics of anticipated
   endpoint and transport facilities.  An encryption mechanism must also
   be compatible with the local conventions of the computer systems
   which it interconnects.  Our approach uses a canonicalization step to
   abstract out local conventions and a subsequent encoding step to



Linn                                                           [Page 10]

RFC 1421        Privacy Enhancement for Electronic Mail    February 1993


   conform to the characteristics of the underlying mail transport
   medium (SMTP).  The encoding conforms to SMTP constraints.  Section
   4.5 of RFC 821 [2] details SMTP's transparency constraints.

   To prepare a message for SMTP transmission, the following
   requirements must be met:

        1.  All characters must be members of the 7-bit ASCII character
            set.

        2.  Text lines, delimited by the character pair <CR><LF>, must
            be no more than 1000 characters long.

        3.  Since the string <CR><LF>.<CR><LF> indicates the end of a
            message, it must not occur in text prior to the end of a
            message.

   Although SMTP specifies a standard representation for line delimiters
   (ASCII <CR><LF>), numerous systems in the Internet use a different
   native representation to delimit lines.  For example, the <CR><LF>
   sequences delimiting lines in mail inbound to UNIX systems are
   transformed to single <LF>s as mail is written into local mailbox