doc: Add RFC documents

1 files changed, 2355 insertions, 0 deletions

diff --git a/doc/rfc/rfc1421.txt b/doc/rfc/rfc1421.txt
new file mode 100644
index 0000000..373e217
--- /dev/null
+++ b/doc/rfc/rfc1421.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group                                            J. Linn
+Request for Comments: 1421                    IAB IRTF PSRG, IETF PEM WG
+Obsoletes: 1113                                            February 1993
+
+
+           Privacy Enhancement for Internet Electronic Mail:
+        Part I: Message Encryption and Authentication Procedures
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Acknowledgements
+
+   This document is the outgrowth of a series of meetings of the Privacy
+   and Security Research Group (PSRG) of the IRTF and the PEM Working
+   Group of the IETF.  I would like to thank the members of the PSRG and
+   the IETF PEM WG, as well as all participants in discussions on the
+   "pem-dev@tis.com" mailing list, for their contributions to this
+   document.
+
+1.  Executive Summary
+
+   This document defines message encryption and authentication
+   procedures, in order to provide privacy-enhanced mail (PEM) services
+   for electronic mail transfer in the Internet.  It is intended to
+   become one member of a related set of four RFCs.  The procedures
+   defined in the current document are intended to be compatible with a
+   wide range of key management approaches, including both symmetric
+   (secret-key) and asymmetric (public-key) approaches for encryption of
+   data encrypting keys.  Use of symmetric cryptography for message text
+   encryption and/or integrity check computation is anticipated. RFC
+   1422 specifies supporting key management mechanisms based on the use
+   of public-key certificates.  RFC 1423 specifies algorithms, modes,
+   and associated identifiers relevant to the current RFC and to RFC
+   1422.  RFC 1424 provides details of paper and electronic formats and
+   procedures for the key management infrastructure being established in
+   support of these services.
+
+   Privacy enhancement services (confidentiality, authentication,
+   message integrity assurance, and non-repudiation of origin) are
+   offered through the use of end-to-end cryptography between originator
+   and recipient processes at or above the User Agent level.  No special
+   processing requirements are imposed on the Message Transfer System at
+
+
+
+Linn                                                            [Page 1]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   endpoints or at intermediate relay sites.  This approach allows
+   privacy enhancement facilities to be incorporated selectively on a
+   site-by-site or user-by-user basis without impact on other Internet
+   entities.  Interoperability among heterogeneous components and mail
+   transport facilities is supported.
+
+   The current specification's scope is confined to PEM processing
+   procedures for the RFC-822 textual mail environment, and defines the
+   Content-Domain indicator value "RFC822" to signify this usage.
+   Follow-on work in integration of PEM capabilities with other
+   messaging environments (e.g., MIME) is anticipated and will be
+   addressed in separate and/or successor documents, at which point
+   additional Content-Domain indicator values will be defined.
+
+2.  Terminology
+
+   For descriptive purposes, this RFC uses some terms defined in the OSI
+   X.400 Message Handling System Model per the CCITT Recommendations.
+   This section replicates a portion of (1984) X.400's Section 2.2.1,
+   "Description of the MHS Model: Overview" in order to make the
+   terminology clear to readers who may not be familiar with the OSI MHS
+   Model.
+
+   In the [MHS] model, a user is a person or a computer application.  A
+   user is referred to as either an originator (when sending a message)
+   or a recipient (when receiving one).  MH Service elements define the
+   set of message types and the capabilities that enable an originator
+   to transfer messages of those types to one or more recipients.
+
+   An originator prepares messages with the assistance of his or her
+   User Agent (UA).  A UA is an application process that interacts with
+   the Message Transfer System (MTS) to submit messages.  The MTS
+   delivers to one or more recipient UAs the messages submitted to it.
+   Functions performed solely by the UA and not standardized as part of
+   the MH Service elements are called local UA functions.
+
+   The MTS is composed of a number of Message Transfer Agents (MTAs).
+   Operating together, the MTAs relay messages and deliver them to the
+   intended recipient UAs, which then make the messages available to the
+   intended recipients.
+
+   The collection of UAs and MTAs is called the Message Handling System
+   (MHS).  The MHS and all of its users are collectively referred to as
+   the Message Handling Environment.
+
+
+
+
+
+
+
+Linn                                                            [Page 2]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+3.  Services, Constraints, and Implications
+
+   This RFC defines mechanisms to enhance privacy for electronic mail
+   transferred in the Internet. The facilities discussed in this RFC
+   provide privacy enhancement services on an end-to-end basis between
+   originator and recipient processes residing at the UA level or above.
+   No privacy enhancements are offered for message fields which are
+   added or transformed by intermediate relay points between PEM
+   processing components.
+
+   If an originator elects to perform PEM processing on an outbound
+   message, all PEM-provided security services are applied to the PEM
+   message's body in its entirety; selective application to portions of
+   a PEM message is not supported. Authentication, integrity, and (when
+   asymmetric key management is employed) non-repudiation of origin
+   services are applied to all PEM messages; confidentiality services
+   are optionally selectable.
+
+   In keeping with the Internet's heterogeneous constituencies and usage
+   modes, the measures defined here are applicable to a broad range of
+   Internet hosts and usage paradigms.  In particular, it is worth
+   noting the following attributes:
+
+        1.  The mechanisms defined in this RFC are not restricted to a
+            particular host or operating system, but rather allow
+            interoperability among a broad range of systems.  All
+            privacy enhancements are implemented at the application
+            layer, and are not dependent on any privacy features at
+            lower protocol layers.
+
+        2.  The defined mechanisms are compatible with non-enhanced
+            Internet components.  Privacy enhancements are implemented
+            in an end-to-end fashion which does not impact mail
+            processing by intermediate relay hosts which do not
+            incorporate privacy enhancement facilities.  It is
+            necessary, however, for a message's originator to be
+            cognizant of whether a message's intended recipient
+            implements privacy enhancements, in order that encoding and
+            possible encryption will not be performed on a message whose
+            destination is not equipped to perform corresponding inverse
+            transformations.  (Section 4.6.1.1.3 of this RFC describes a
+            PEM message type ("MIC-CLEAR") which represents a signed,
+            unencrypted PEM message in a form readable without PEM
+            processing capabilities yet validatable by PEM-equipped
+            recipients.)
+
+        3.  The defined mechanisms are compatible with a range of mail
+            transport facilities (MTAs).  Within the Internet,
+
+
+
+Linn                                                            [Page 3]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+            electronic mail transport is effected by a variety of SMTP
+            [2] implementations.  Certain sites, accessible via SMTP,
+            forward mail into other mail processing environments (e.g.,
+            USENET, CSNET, BITNET).  The privacy enhancements must be
+            able to operate across the SMTP realm; it is desirable that
+            they also be compatible with protection of electronic mail
+            sent between the SMTP environment and other connected
+            environments.
+
+        4.  The defined mechanisms are compatible with a broad range of
+            electronic mail user agents (UAs).  A large variety of
+            electronic mail user agent programs, with a corresponding
+            broad range of user interface paradigms, is used in the
+            Internet.  In order that electronic mail privacy
+            enhancements be available to the broadest possible user
+            community, selected mechanisms should be usable with the
+            widest possible variety of existing UA programs.  For
+            purposes of pilot implementation, it is desirable that
+            privacy enhancement processing be incorporable into a
+            separate program, applicable to a range of UAs, rather than
+            requiring internal modifications to each UA with which PEM
+            services are to be provided.
+
+        5.  The defined mechanisms allow electronic mail privacy
+            enhancement processing to be performed on personal computers
+            (PCs) separate from the systems on which UA functions are
+            implemented.  Given the expanding use of PCs and the limited
+            degree of trust which can be placed in UA implementations on
+            many multi-user systems, this attribute can allow many users
+            to process PEM with a higher assurance level than a strictly
+            UA-integrated approach would allow.
+
+        6.  The defined mechanisms support privacy protection of
+            electronic mail addressed to mailing lists (distribution
+            lists, in ISO parlance).
+
+        7.  The mechanisms defined within this RFC are compatible with a
+            variety of supporting key management approaches, including
+            (but not limited to) manual pre-distribution, centralized
+            key distribution based on symmetric cryptography, and the
+            use of public-key certificates per RFC 1422.  Different
+            key management mechanisms may be used for different
+            recipients of a multicast message.  For two PEM
+            implementations to interoperate, they must share a common
+            key management mechanism; support for the mechanism defined
+            in RFC 1422 is strongly encouraged.
+
+
+
+
+
+Linn                                                            [Page 4]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   In order to achieve applicability to the broadest possible range of
+   Internet hosts and mail systems, and to facilitate pilot
+   implementation and testing without the need for prior and pervasive
+   modifications throughout the Internet, the following design
+   principles were applied in selecting the set of features specified in
+   this RFC:
+
+        1.  This RFC's measures are restricted to implementation at
+            endpoints and are amenable to integration with existing
+            Internet mail protocols at the user agent (UA) level or
+            above, rather than necessitating modifications to existing
+            mail protocols or integration into the message transport
+            system (e.g., SMTP servers).
+
+        2.  The set of supported measures enhances rather than restricts
+            user capabilities.  Trusted implementations, incorporating
+            integrity features protecting software from subversion by
+            local users, cannot be assumed in general.  No mechanisms
+            are assumed to prevent users from sending, at their
+            discretion, messages to which no PEM processing has been
+            applied. In the absence of such features, it appears more
+            feasible to provide facilities which enhance user services
+            (e.g., by protecting and authenticating inter-user traffic)
+            than to enforce restrictions (e.g., inter-user access
+            control) on user actions.
+
+        3.  The set of supported measures focuses on a set of functional
+            capabilities selected to provide significant and tangible
+            benefits to a broad user community.  By concentrating on the
+            most critical set of services, we aim to maximize the added
+            privacy value that can be provided with a modest level of
+            implementation effort.
+
+   Based on these principles, the following facilities are provided:
+
+        1.  disclosure protection,
+
+        2.  originator authenticity,
+
+        3.  message integrity measures, and
+
+        4.  (if asymmetric key management is used) non-repudiation of
+            origin,
+
+   but the following privacy-relevant concerns are not addressed:
+
+        1.  access control,
+
+
+
+
+Linn                                                            [Page 5]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+        2.  traffic flow confidentiality,
+
+        3.  address list accuracy,
+
+        4.  routing control,
+
+        5.  issues relating to the casual serial reuse of PCs by
+            multiple users,
+
+        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
+   files.  Lines in mail incoming to record-oriented systems (such as
+   VAX VMS) may be converted to appropriate records by the destination
+   SMTP server [3].  As a result, if the encryption process generated
+   <CR>s or <LF>s, those characters might not be accessible to a
+   recipient UA program at a destination which uses different line
+   delimiting conventions.  It is also possible that conversion between
+   tabs and spaces may be performed in the course of mapping between
+   inter-SMTP and local format; this is a matter of local option.  If
+   such transformations changed the form of transmitted ciphertext,
+   decryption would fail to regenerate the transmitted plaintext, and a
+   transmitted MIC would fail to compare with that computed at the
+   destination.
+
+   The conversion performed by an SMTP server at a system with EBCDIC as
+   a native character set has even more severe impact, since the
+   conversion from EBCDIC into ASCII is an information-losing
+   transformation.  In principle, the transformation function mapping
+   between inter-SMTP canonical ASCII message representation and local
+   format could be moved from the SMTP server up to the UA, given a
+   means to direct that the SMTP server should no longer perform that
+   transformation.  This approach has a major disadvantage: internal
+   file (e.g., mailbox) formats would be incompatible with the native
+   forms used on the systems where they reside.  Further, it would
+   require modification to SMTP servers, as mail would be passed to SMTP
+   in a different representation than it is passed at present.
+
+
+
+
+Linn                                                           [Page 11]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+4.3.2  Approach
+
+   Our approach to supporting PEM across an environment in which
+   intermediate conversions may occur defines an encoding for mail which
+   is uniformly representable across the set of PEM UAs regardless of
+   their systems' native character sets.  This encoded form is used (for
+   specified PEM message types) to represent mail text in transit from
+   originator to recipient, but the encoding is not applied to enclosing
+   MTS headers or to encapsulated headers inserted to carry control
+   information between PEM UAs.  The encoding's characteristics are such
+   that the transformations anticipated between originator and recipient
+   UAs will not prevent an encoded message from being decoded properly
+   at its destination.
+
+   Four transformation steps, described in the following four
+   subsections, apply to outbound PEM message processing:
+
+4.3.2.1  Step 1: Local Form
+
+   This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
+   MIC-CLEAR.  The message text is created in the system's native
+   character set, with lines delimited in accordance with local
+   convention.
+
+4.3.2.2  Step 2: Canonical Form
+
+   This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and
+   MIC-CLEAR.  The message text is converted to a universal canonical
+   form, similar to the inter-SMTP representation [4] as defined in RFC
+   821 [2] and RFC 822 [5]. The procedures performed in order to
+   accomplish this conversion are dependent on the characteristics of
+   the local form and so are not specified in this RFC.
+
+   PEM canonicalization assures that the message text is represented
+   with the ASCII character set and "<CR><LF>" line delimiters, but does
+   not perform the dot-stuffing transformation discussed in RFC 821,
+   Section 4.5.2.  Since a message is converted to a standard character
+   set and representation before encryption, a transferred PEM message
+   can be decrypted and its MIC can be validated at any type of
+   destination host computer.  Decryption and MIC validation is
+   performed before any conversions which may be necessary to transform
+   the message into a destination-specific local form.
+
+4.3.2.3  Step 3: Authentication and Encryption
+
+   Authentication processing is applicable to PEM message types
+   ENCRYPTED, MIC-ONLY, and MIC-CLEAR.  The canonical form is input to
+   the selected MIC computation algorithm in order to compute an
+
+
+
+Linn                                                           [Page 12]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   integrity check quantity for the message.  No padding is added to the
+   canonical form before submission to the MIC computation algorithm,
+   although certain MIC algorithms will apply their own padding in the
+   course of computing a MIC.
+
+   Encryption processing is applicable only to PEM message type
+   ENCRYPTED.  RFC 1423 defines the padding technique used to support
+   encryption of the canonically-encoded message text.
+
+4.3.2.4  Step 4: Printable Encoding
+
+   This printable encoding step is applicable to PEM message types
+   ENCRYPTED and MIC-ONLY.  The same processing is also employed in
+   representation of certain specifically identified PEM encapsulated
+   header field quantities as cited in Section 4.6.  Proceeding from
+   left to right, the bit string resulting from step 3 is encoded into
+   characters which are universally representable at all sites, though
+   not necessarily with the same bit patterns (e.g., although the
+   character "E" is represented in an ASCII-based system as hexadecimal
+   45 and as hexadecimal C5 in an EBCDIC-based system, the local
+   significance of the two representations is equivalent).
+
+   A 64-character subset of International Alphabet IA5 is used, enabling
+   6 bits to be represented per printable character.  (The proposed
+   subset of characters is represented identically in IA5 and ASCII.)
+   The character "=" signifies a special processing function used for
+   padding within the printable encoding procedure.
+
+   To represent the encapsulated text of a PEM message, the encoding
+   function's output is delimited into text lines (using local
+   conventions), with each line except the last containing exactly 64
+   printable characters and the final line containing 64 or fewer
+   printable characters.  (This line length is easily printable and is
+   guaranteed to satisfy SMTP's 1000-character transmitted line length
+   limit.) This folding requirement does not apply when the encoding
+   procedure is used to represent PEM header field quantities; Section
+   4.6 discusses folding of PEM encapsulated header fields.
+
+   The encoding process represents 24-bit groups of input bits as output
+   strings of 4 encoded characters. Proceeding from left to right across
+   a 24-bit input group extracted from the output of step 3, each 6-bit
+   group is used as an index into an array of 64 printable characters.
+   The character referenced by the index is placed in the output string.
+   These characters, identified in Table 1, are selected so as to be
+   universally representable, and the set excludes characters with
+   particular significance to SMTP (e.g., ".", "<CR>", "<LF>").
+
+
+
+
+
+Linn                                                           [Page 13]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   Special processing is performed if fewer than 24 bits are available
+   in an input group at the end of a message.  A full encoding quantum
+   is always completed at the end of a message.  When fewer than 24
+   input bits are available in an input group, zero bits are added (on
+   the right) to form an integral number of 6-bit groups.  Output
+   character positions which are not required to represent actual input
+   data are set to the character "=".  Since all canonically encoded
+   output is an integral number of octets, only the following cases can
+   arise: (1) the final quantum of encoding input is an integral
+   multiple of 24 bits; here, the final unit of encoded output will be
+   an integral multiple of 4 characters with no "=" padding, (2) the
+   final quantum of encoding input is exactly 8 bits; here, the final
+   unit of encoded output will be two characters followed by two "="
+   padding characters, or (3) the final quantum of encoding input is
+   exactly 16 bits; here, the final unit of encoded output will be three
+   characters followed by one "=" padding character.
+
+
+   Value Encoding  Value Encoding  Value Encoding  Value Encoding
+       0 A            17 R            34 i            51 z
+       1 B            18 S            35 j            52 0
+       2 C            19 T            36 k            53 1
+       3 D            20 U            37 l            54 2
+       4 E            21 V            38 m            55 3
+       5 F            22 W            39 n            56 4
+       6 G            23 X            40 o            57 5
+       7 H            24 Y            41 p            58 6
+       8 I            25 Z            42 q            59 7
+       9 J            26 a            43 r            60 8
+      10 K            27 b            44 s            61 9
+      11 L            28 c            45 t            62 +
+      12 M            29 d            46 u            63 /
+      13 N            30 e            47 v
+      14 O            31 f            48 w         (pad) =
+      15 P            32 g            49 x
+      16 Q            33 h            50 y
+
+                  Printable Encoding Characters
+                             Table 1
+
+
+4.3.2.5  Summary of Transformations
+
+   In summary, the outbound message is subjected to the following
+   composition of transformations (or, for some PEM message types, a
+   subset thereof):
+
+         Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))
+
+
+
+Linn                                                           [Page 14]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   The inverse transformations are performed, in reverse order, to
+   process inbound PEM messages:
+
+       Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
+
+   Note that the local form and the functions to transform messages to
+   and from canonical form may vary between the originator and recipient
+   systems without loss of information.
+
+4.4  Encapsulation Mechanism
+
+   The encapsulation techniques defined in RFC-934 [6] are adopted for
+   encapsulation of PEM messages within separate enclosing MTS messages
+   carrying associated MTS headers. This approach offers a number of
+   advantages relative to a flat approach in which certain fields within
+   a single header are encrypted and/or carry cryptographic control
+   information.  As far as the MTS is concerned, the entirety of a PEM
+   message will reside in an MTS message's text portion, not the MTS
+   message's header portion. Encapsulation provides generality and
+   segregates fields with user-to-user significance from those
+   transformed in transit.  All fields inserted in the course of
+   encryption/authentication processing are placed in the encapsulated
+   header.  This facilitates compatibility with mail handling programs
+   which accept only text, not header fields, from input files or from
+   other programs.
+
+   The encapsulation techniques defined in RFC-934 are consistent with
+   existing Internet mail forwarding and bursting mechanisms.  These
+   techniques are designed so that they may be used in a nested manner.
+   The encapsulation techniques may be used to encapsulate one or more
+   PEM messages for forwarding to a third party, possibly in conjunction
+   with interspersed (non-PEM) text which serves to annotate the PEM
+   messages.
+
+   Two encapsulation boundaries (EB's) are defined for delimiting
+   encapsulated PEM messages and for distinguishing encapsulated PEM
+   messages from interspersed (non-PEM) text.  The pre-EB is the string
+   "-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an
+   encapsulated PEM message follows.  The post-EB is either (1) another
+   pre-EB indicating that another encapsulated PEM message follows, or
+   (2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating
+   that any text that immediately follows is non-PEM text.  A special
+   point must be noted for the case of MIC-CLEAR messages, the text
+   portions of which may contain lines which begin with the "-"
+   character and which are therefore subject to special processing per
+   RFC-934 forwarding procedures.  When the string "- " must be
+   prepended to such a line in the course of a forwarding operation in
+   order to distinguish that line from an encapsulation boundary, MIC
+
+
+
+Linn                                                           [Page 15]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   computation is to be performed prior to prepending the "- " string.
+   Figure 1 depicts the encapsulation of a single PEM message.
+
+   This RFC places no a priori limits on the depth to which such
+   encapsulation may be nested nor on the number of PEM messages which
+   may be grouped in this fashion at a single nesting level for
+   forwarding.  A implementation compliant with this RFC must not
+   preclude a user from submitting or receiving PEM messages which
+   exploit this encapsulation capability.  However, no specific
+   requirements are levied upon implementations with regard to how this
+   capability is made available to the user.  Thus, for example, a
+   compliant PEM implementation is not required to automatically detect
+   and process encapsulated PEM messages.
+
+   In using this encapsulation facility, it is important to note that it
+   is inappropriate to forward directly to a third party a message that
+   is ENCRYPTED because recipients of such a message would not have
+   access to the DEK required to decrypt the message.  Instead, the user
+   forwarding the message must transform the ENCRYPTED message into a
+   MIC-ONLY or MIC-CLEAR form prior to forwarding.  Thus, in order to
+   comply with this RFC, a PEM implementation must provide a facility to
+   enable a user to perform this transformation, while preserving the
+   MIC associated with the original message.
+
+   If a user wishes PEM-provided confidentiality protection for
+   transmitted information, such information must occur in the
+   encapsulated text of an ENCRYPTED PEM message, not in the enclosing
+   MTS header or PEM encapsulated header. If a user wishes to avoid
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 16]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   Encapsulated Message
+
+       Pre-Encapsulation Boundary (Pre-EB)
+           -----BEGIN PRIVACY-ENHANCED MESSAGE-----
+
+       Encapsulated Header Portion
+           (Contains encryption control fields inserted in plaintext.
+           Examples include "DEK-Info:" and "Key-Info:".
+           Note that, although these control fields have line-oriented
+           representations similar to RFC 822 header fields, the set
+           of fields valid in this context is disjoint from those used
+           in RFC 822 processing.)
+
+       Blank Line
+           (Separates Encapsulated Header from subsequent
+           Encapsulated Text Portion)
+
+       Encapsulated Text Portion
+           (Contains message data encoded as specified in Section 4.3.)
+
+       Post-Encapsulation Boundary (Post-EB)
+           -----END PRIVACY-ENHANCED MESSAGE-----
+
+
+                   Encapsulated Message Format
+                            Figure 1
+
+
+   disclosing the actual subject of a message to unintended parties, it
+   is suggested that the enclosing MTS header contain a "Subject:" field
+   indicating that "Encrypted Mail Follows".
+
+   If an integrity-protected representation of information which occurs
+   within an enclosing header (not necessarily in the same format as
+   that in which it occurs within that header) is desired, that data can
+   be included within the encapsulated text portion in addition to its
+   inclusion in the enclosing MTS header.  For example, an originator
+   wishing to provide recipients with a protected indication of a
+   message's position in a series of messages could include within the
+   encapsulated text a copy of a timestamp or message counter value
+   possessing end-to-end significance and extracted from an enclosing
+   MTS header field.  (Note: mailbox specifiers as entered by end users
+   incorporate local conventions and are subject to modification at
+   intermediaries, so inclusion of such specifiers within encapsulated
+   text should not be regarded as a suitable alternative to the
+   authentication semantics defined in RFC 1422 and based on X.500
+   Distinguished Names.) The set of header information (if any) included
+   within the encapsulated text of messages is a local matter, and this
+
+
+
+Linn                                                           [Page 17]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   RFC does not specify formatting conventions to distinguish replicated
+   header fields from other encapsulated text.
+
+4.5  Mail for Mailing Lists
+
+   When mail is addressed to mailing lists, two different methods of
+   processing can be applicable: the IK-per-list method and the IK-per-
+   recipient method.  Hybrid approaches are also possible, as in the
+   case of IK-per-list protection of a message on its path from an
+   originator to a PEM-equipped mailing list exploder, followed by IK-
+   per-recipient protection from the exploder to individual list
+   recipients.
+
+   If a message's originator is equipped to expand a destination mailing
+   list into its individual constituents and elects to do so (IK-per-
+   recipient), the message's DEK (and, in the symmetric key management
+   case, 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 "Key-Info:"
+   field, not for the message text which is, in general, much larger.
+   Although more IKs are involved in processing under the IK-per-
+   recipient 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.
+
+   If a message's originator addresses a message to a list name or
+   alias, use of an IK associated with that name or alias as a entity
+   (IK-per-list), rather than resolution of the name or alias to its
+   constituent destinations, is implied. Such an IK must, therefore, be
+   available to all list members. Unfortunately, it implies an
+   undesirable level of exposure for the shared IK, and makes its
+   revocation difficult.  Moreover, use of the IK-per-list method allows
+   any holder of the list's IK to masquerade as another originator to
+   the list for authentication purposes.
+
+   Pure IK-per-list key management in the asymmetric case (with a common
+   private key shared among multiple list members) is particularly
+   disadvantageous in the asymmetric environment, as it fails to
+   preserve the forwardable authentication and non-repudiation
+   characteristics which are provided for other messages in this
+   environment.  Use of a hybrid approach with a PEM-capable exploder is
+   therefore particularly recommended for protection of mailing list
+   traffic when asymmetric key management is used; such an exploder
+   would reduce (per discussion in Section 4.4 of this RFC) incoming
+   ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding
+   them (perhaps re-encrypted under individual, per-recipient keys) to
+   list members.
+
+
+
+Linn                                                           [Page 18]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+4.6  Summary of Encapsulated Header Fields
+
+   This section defines the syntax and semantics of the encapsulated
+   header fields to be added to messages in the course of privacy
+   enhancement processing.
+
+   The fields are presented in three groups.  Normally, the groups will
+   appear in encapsulated headers in the order in which they are shown,
+   though not all fields in each group will appear in all messages.  The
+   following figures show the appearance of small example encapsulated
+   messages.  Figure 2 assumes the use of symmetric cryptography for key
+   management.  Figure 3 illustrates an example encapsulated ENCRYPTED
+   message in which asymmetric key management is used.
+
+
+   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
+   Proc-Type: 4,ENCRYPTED
+   Content-Domain: RFC822
+   DEK-Info: DES-CBC,F8143EDE5960C597
+   Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
+   Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
+   Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
+             B70665BB9BF7CBCDA60195DB94F727D3
+   Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
+   Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
+             E2EF532C65CBCFF79F83A2658132DB47
+
+   LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
+   8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
+   J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
+   dXd/H5LMDWnonNvPCwQUHt==
+   -----END PRIVACY-ENHANCED MESSAGE-----
+
+          Example Encapsulated Message (Symmetric Case)
+                            Figure 2
+
+
+   Figure 4 illustrates an example encapsulated MIC-ONLY message in
+   which asymmetric key management is used; since no per-recipient keys
+   are involved in preparation of asymmetric-case MIC-ONLY messages,
+   this example should be processable for test purposes by arbitrary PEM
+   implementations.
+
+   Fully-qualified domain names (FQDNs) for hosts, appearing in the
+   mailbox names found in entity identifier subfields of "Originator-
+   ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in
+   a case-insensitive fashion.  Unless specified to the contrary, other
+   field arguments (including the user name components of mailbox names)
+
+
+
+Linn                                                           [Page 19]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   are to be processed in a case-sensitive fashion.
+
+   In most cases, numeric quantities are represented in header fields as
+   contiguous strings of hexadecimal digits, where each digit is
+   represented by a character from the ranges "0"-"9" or upper case
+   "A"-"F".  Since public-key certificates and quantities encrypted
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 20]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
+   Proc-Type: 4,ENCRYPTED
+   Content-Domain: RFC822
+   DEK-Info: DES-CBC,BFF968AA74691AC1
+   Originator-Certificate:
+    MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
+    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
+    BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
+    CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
+    MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
+    yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
+    LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
+    iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
+    5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
+   Key-Info: RSA,
+    I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
+    wGrtiUm/ovtKdinz6ZQ/aQ==
+   Issuer-Certificate:
+    MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
+    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
+    BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
+    CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
+    BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
+    XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
+    cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
+    MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
+    dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
+    EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
+   MIC-Info: RSA-MD5,RSA,
+    UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
+    AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG
+   Recipient-ID-Asymmetric:
+    MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
+    LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,
+    66
+   Key-Info: RSA,
+    O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv
+    7x0Z3Jx2vTAhOYHMcqqCjA==
+
+   qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d
+   jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
+   -----END PRIVACY-ENHANCED MESSAGE-----
+
+    Example Encapsulated ENCRYPTED Message (Asymmetric Case)
+                            Figure 3
+
+
+
+
+
+
+Linn                                                           [Page 21]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   using asymmetric algorithms are large in size, use of a more space-
+   efficient encoding technique is appropriate for such quantities, and
+   the encoding mechanism defined in Section 4.3.2.4 of this RFC,
+   representing 6 bits per printed character, is adopted for this
+   purpose.
+
+   Encapsulated headers of PEM messages are folded using whitespace per
+   RFC 822 header folding conventions; no PEM-specific conventions are
+   defined for encapsulated header folding.  The example shown in Figure
+   4 shows (in its "MIC-Info:" field) an asymmetrically encrypted
+   quantity in its printably encoded representation, illustrating the
+   use of RFC 822 folding.
+
+   In contrast to the encapsulated header representations defined in RFC
+   1113 and its precursors, the field identifiers adopted in this RFC do
+   not begin with the prefix "X-" (for example, the field previously
+   denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes
+   are not to be emitted by implementations conformant to this RFC.  To
+   simplify transition and interoperability with earlier
+   implementations, it is suggested that implementations based on this
+   RFC accept incoming encapsulated header fields carrying the "X-"
+   prefix and act on such fields as if the "X-" were not present.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 22]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   -----BEGIN PRIVACY-ENHANCED MESSAGE-----
+   Proc-Type: 4,MIC-ONLY
+   Content-Domain: RFC822
+   Originator-Certificate:
+    MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
+    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
+    BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
+    CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
+    MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
+    yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
+    LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
+    iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
+    5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
+   Issuer-Certificate:
+    MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
+    BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
+    BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
+    CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
+    BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
+    XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
+    cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
+    MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
+    dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
+    EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
+   MIC-Info: RSA-MD5,RSA,
+    jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
+    EtE7K2QDeVMCyXsdJlA8fA==
+
+   LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg
+   YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=
+   -----END PRIVACY-ENHANCED MESSAGE-----
+
+     Example Encapsulated MIC-ONLY Message (Asymmetric Case)
+                            Figure 4
+
+
+4.6.1  Per-Message Encapsulated Header Fields
+
+   This group of encapsulated header fields contains fields which occur
+   no more than once in a PEM message, generally preceding all other
+   encapsulated header fields.
+
+4.6.1.1  Proc-Type Field
+
+   The "Proc-Type:" encapsulated header field, required for all PEM
+   messages, identifies the type of processing performed on the
+   transmitted message.  Only one "Proc-Type:" field occurs in a
+   message; the "Proc-Type:" field must be the first encapsulated header
+
+
+
+Linn                                                           [Page 23]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   field in the message.
+
+   The "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 "4" to
+   distinguish them from messages processed in accordance with prior PEM
+   RFCs.  The second subfield assumes one of a set of string values,
+   defined in the following subsections.
+
+4.6.1.1.1  ENCRYPTED
+
+   The "ENCRYPTED" specifier signifies that confidentiality,
+   authentication, integrity, and (given use of asymmetric key
+   management) non-repudiation of origin security services have been
+   applied to a PEM message's encapsulated text.  ENCRYPTED messages
+   require a "DEK-Info:" field and individual Recipient-ID and "Key-
+   Info:" fields for all message recipients.
+
+4.6.1.1.2  MIC-ONLY
+
+   The "MIC-ONLY" specifier signifies that all of the security services
+   specified for ENCRYPTED messages, with the exception of
+   confidentiality, have been applied to a PEM message's encapsulated
+   text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this RFC)
+   to protect their encapsulated text against modifications at message
+   transfer or relay points.
+
+   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, when a
+   keyless MIC computation is employed for recipients for whom
+   asymmetric cryptography is used, "Recipient-ID-Asymmetric:" and
+   "Key-Info:" fields can be omitted.  The "DEK-Info:" field can be
+   omitted for all "MIC-ONLY" messages.
+
+4.6.1.1.3  MIC-CLEAR
+
+   The "MIC-CLEAR" specifier represents a PEM message with the same
+   security service selection as for a MIC-ONLY message.  The set of
+   encapsulated header fields required in a MIC-CLEAR message is the
+   same as that required for a MIC-ONLY message.
+
+   MIC-CLEAR message processing omits the encoding step defined in
+   Section 4.3.2.4 of this RFC to protect a message's encapsulated text
+   against modifications within the MTS.  As a result, a MIC-CLEAR
+
+
+
+Linn                                                           [Page 24]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   message's text can be read by recipients lacking access to PEM
+   software, even though such recipients cannot validate the message's
+   signature. The canonical encoding discussed in Section 4.3.2.2 is
+   performed, so interoperation among sites with different native
+   character sets and line representations is not precluded so long as
+   those native formats are unambiguously translatable to and from the
+   canonical form.  (Such interoperability is feasible only for those
+   characters which are included in the canonical representation set.)
+
+   Omission of the printable encoding step implies that MIC-CLEAR
+   message MICs will be validatable only in environments where the MTS
+   does not modify messages in transit, or where the modifications
+   performed can be determined and inverted before MIC validation
+   processing.  Failed MIC validation on a MIC-CLEAR message does not,
+   therefore, necessarily signify a security-relevant event; as a
+   result, it is recommended that PEM implementations reflect to their
+   users (in a suitable local fashion) the type of PEM message being
+   processed when reporting a MIC validation failure.
+
+   A case of particular relevance arises for inbound SMTP processing on
+   systems which delimit text lines with local native representations
+   other than the SMTP-conventional <CR><LF>.  When mail is delivered to
+   a UA on such a system and presented for PEM processing, the <CR><LF>
+   has already been translated to local form.  In order to validate a
+   MIC-CLEAR message's MIC in this situation, the PEM module must
+   recanonicalize the incoming message in order to determine the inter-
+   SMTP representation of the canonically encoded message (as defined in
+   Section 4.3.2.2 of this RFC), and must compute the reference MIC
+   based on that representation.
+
+4.6.1.1.4  CRL
+
+   The "CRL" specifier indicates a special PEM message type, used to
+   transfer one or more Certificate Revocation Lists.  The format of PEM
+   CRLs is defined in RFC 1422.  No user data or encapsulated text
+   accompanies an encapsulated header specifying the CRL message type; a
+   correctly-formed CRL message's PEM header is immediately followed by
+   its terminating message boundary line, with no blank line
+   intervening.
+
+   Only three types of fields are valid in the encapsulated header
+   comprising a CRL message.  The "CRL:" field carries a printable
+   representation of a CRL, encoded using the procedures defined in
+   Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be
+   followed by no more than one "Originator-Certificate:" field and any
+   number of "Issuer-Certificate:" fields. The "Originator-Certificate:"
+   and "Issuer-Certificate:" fields refer to the most recently previous
+   "CRL:" field, and provide certificates useful in validating the
+
+
+
+Linn                                                           [Page 25]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   signature included in the CRL.  "Originator-Certificate:" and
+   "Issuer-Certificate:" fields' contents are the same for CRL messages
+   as they are for other PEM message types.
+
+4.6.1.2  Content-Domain Field
+
+   The "Content-Domain:" encapsulated header field describes the type of
+   content which is represented within a PEM message's encapsulated
+   text.  It carries one string argument, whose value is defined as
+   "RFC822" to indicate processing of RFC-822 mail as defined in this
+   specification.  It is anticipated that additional "Content-Domain:"
+   values will be defined subsequently, in additional or successor
+   documents to this specification. Only one "Content-Domain:" field
+   occurs in a PEM message; this field is the PEM message's second
+   encapsulated header field, immediately following the "Proc-Type:"
+   field.
+
+4.6.1.3  DEK-Info Field
+
+   The "DEK-Info:" encapsulated header field identifies the message text
+   encryption algorithm and mode, and also carries any cryptographic
+   parameters (e.g., IVs) used for message encryption.  No more than one
+   "DEK-Info:" field occurs in a message; the field is required for all
+   messages specified as "ENCRYPTED" in the "Proc-Type:" field.
+
+   The "DEK-Info:" field carries either one argument or two arguments
+   separated by a comma.  The first argument identifies the algorithm
+   and mode used for message text encryption.  The second argument, if
+   present, carries any cryptographic parameters required by the
+   algorithm and mode identified in the first argument.  Appropriate
+   message encryption algorithms, modes and identifiers and
+   corresponding cryptographic parameters and formats are defined in RFC
+   1423.
+
+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.
+
+4.6.2.1  Originator-ID Fields
+
+   Originator-ID encapsulated header fields identify a message's
+   originator and provide the originator's IK identification component.
+   Two varieties of Originator-ID fields are defined, the "Originator-
+   ID-Asymmetric:" and "Originator-ID-Symmetric:" field.  An
+   "Originator-ID-Symmetric:" header field is required for all PEM
+
+
+
+Linn                                                           [Page 26]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   messages employing symmetric key management.  The analogous
+   "Originator-ID-Asymmetric:" field, for the asymmetric key management
+   case, is used only when no corresponding "Originator-Certificate:"
+   field is included.
+
+   Most commonly, only one Originator-ID or "Originator-Certificate:"
+   field will occur within a message. For the symmetric case, the IK
+   identification component carried in an "Originator-ID-Symmetric:"
+   field applies to processing of all subsequent "Recipient-ID-
+   Symmetric:" fields until another "Originator-ID-Symmetric:" field
+   occurs.  It is illegal for a "Recipient-ID-Symmetric:" field to occur
+   before a corresponding "Originator-ID-Symmetric:" field has been
+   provided.  For the asymmetric case, processing of "Recipient-ID-
+   Asymmetric:" fields is logically independent of preceding
+   "Originator-ID-Asymmetric:" and "Originator-Certificate:" fields.
+
+   Multiple Originator-ID and/or "Originator-Certificate:" fields may
+   occur in a message when different originator-oriented IK components
+   must be used by a message's originator in order to prepare a message
+   so as to be suitable for processing by different recipients. In
+   particular, multiple such fields will occur when both symmetric and
+   asymmetric cryptography are applied to a single message in order to
+   process the message for different recipients.
+
+   Originator-ID subfields are delimited by the comma 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.
+
+4.6.2.1.1  Originator-ID-Asymmetric Field
+
+   The "Originator-ID-Asymmetric:" field contains an Issuing Authority
+   subfield, and then a Version/Expiration subfield.  This field is used
+   only when the information it carries is not available from an
+   included "Originator-Certificate:" field.
+
+4.6.2.1.2  Originator-ID-Symmetric Field
+
+   The "Originator-ID-Symmetric:" field contains an Entity Identifier
+   subfield, followed by an (optional) Issuing Authority subfield, and
+   then an (optional) Version/Expiration subfield.  Optional
+   "Originator-ID-Symmetric:" subfields may be omitted only if rendered
+   redundant by information carried in subsequent "Recipient-ID-
+   Symmetric:" fields, and will normally be omitted in such cases.
+
+
+
+
+
+
+
+Linn                                                           [Page 27]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+4.6.2.2  Originator-Certificate Field
+
+   The "Originator-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 an originator's certificate as a numeric quantity,
+   comprised of the certificate's DER encoding, represented in the
+   header field with the encoding mechanism defined in Section 4.3.2.4
+   of this RFC.  The semantics of a certificate are discussed in RFC
+   1422.
+
+4.6.2.3  MIC-Info Field
+
+   The "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.  The second argument identifies the algorithm under which
+   the accompanying MIC is signed.  The third argument represents a MIC
+   signed with an originator's private key.
+
+   For the case of ENCRYPTED PEM messages, the signed MIC is, in turn,
+   symmetrically encrypted using the same DEK, algorithm, mode and
+   cryptographic parameters as are used to encrypt the message's
+   encapsulated text.  This measure prevents unauthorized recipients
+   from determining whether an intercepted message corresponds to a
+   predetermined plaintext value.
+
+   Appropriate MIC algorithms and identifiers, signature algorithms and
+   identifiers, and signed MIC formats are defined in RFC 1423.
+
+   A "MIC-Info:" field will occur after a sequence of fields beginning
+   with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field
+   and followed by any associated "Issuer-Certificate:" fields.  A
+   "MIC-Info:" field applies to all subsequent recipients for whom
+   asymmetric key management is used, until and unless overridden by a
+   subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:"
+   and corresponding "MIC-Info:".
+
+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.
+
+
+
+
+Linn                                                           [Page 28]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+4.6.3.1  Issuer-Certificate Field
+
+   The "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 "Issuer-Certificate:" field would
+   contain the certificate containing the public component used to sign
+   the certificate carried in the message's "Originator-Certificate:"
+   field, for recipients' use in chaining through that certificate's
+   certification path.  Other "Issuer-Certificate:" fields, typically
+   representing higher points in a certification path, also may be
+   included by an originator.  It is recommended that the "Issuer-
+   Certificate:" fields be included in an order corresponding to
+   successive points in a certification path leading from the originator
+   to a common point shared with the message's recipients (i.e., the
+   Internet Certification Authority (ICA), unless a lower Policy
+   Certification Authority (PCA) or CA is common to all recipients.)
+   More information on certification paths can be found in RFC 1422.
+
+   The certificate is represented in the same manner as defined for the
+   "Originator-Certificate:" field (transporting an encoded
+   representation of the certificate in X.509 [7] DER form), and any
+   "Issuer-Certificate:" fields will ordinarily follow the "Originator-
+   Certificate:" field directly.  Use of the "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
+
+   The encapsulated header fields in this group appear for each of an
+   "ENCRYPTED" message's named recipients.  For "MIC-ONLY" and "MIC-
+   CLEAR" messages, these fields are omitted for recipients for whom
+   asymmetric key management is employed in conjunction with a keyless
+   MIC algorithm but the fields appear for recipients for whom symmetric
+   key management or a keyed MIC algorithm is employed.
+
+4.6.4.1  Recipient-ID Fields
+
+   A Recipient-ID encapsulated header field identifies a recipient and
+   provides the recipient's IK identification component.  One
+   Recipient-ID field is included for each of a message's named
+   recipients. Section 5.2, Interchange Keys, discusses the semantics of
+   the subfields and specifies the alphabet from which they are chosen.
+   Recipient-ID subfields are delimited by the comma character (","),
+   optionally followed by whitespace.
+
+
+
+
+
+Linn                                                           [Page 29]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   For the symmetric case, all "Recipient-ID-Symmetric:" fields are
+   interpreted in the context of the most recent preceding "Originator-
+   ID-Symmetric:" field.  It is illegal for a "Recipient-ID-Symmetric:"
+   field to occur in a header before the occurrence of a corresponding
+   "Originator-ID-Symmetric:" field.  For the asymmetric case,
+   "Recipient-ID-Asymmetric:" fields are logically independent of a
+   message's "Originator-ID-Asymmetric:" and "Originator-Certificate:"
+   fields.  "Recipient-ID-Asymmetric:" fields, and their associated
+   "Key-Info:" fields, are included following a header's originator-
+   oriented fields.
+
+4.6.4.1.1  Recipient-ID-Asymmetric Field
+
+   The "Recipient-ID-Asymmetric:" field contains, in order, an Issuing
+   Authority subfield and a Version/Expiration subfield.
+
+4.6.4.1.2  Recipient-ID-Symmetric Field
+
+   The "Recipient-ID-Symmetric:" field contains, in order, an Entity
+   Identifier subfield, an (optional) Issuing Authority subfield, and an
+   (optional) Version/Expiration subfield.
+
+4.6.4.2  Key-Info Field
+
+   One "Key-Info:" field is included for each of a message's named
+   recipients.  In addition, it is recommended that PEM implementations
+   support (as a locally-selectable option) the ability to include a
+   "Key-Info:" field corresponding to a PEM message's originator,
+   following an Originator-ID or "Originator-Certificate:" field and
+   before any associated Recipient-ID fields, but inclusion of such a
+   field is not a requirement for conformance with this RFC.
+
+   Each "Key-Info:" field is interpreted in the context of the most
+   recent preceding Originator-ID, "Originator-Certificate:", or
+   Recipient-ID field; normally, a "Key-Info:" field will immediately
+   follow its associated predecessor field. The "Key-Info:" 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
+   "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 and MIC encryption for a
+   particular recipient.  The MIC Algorithm Indicator identifies the MIC
+   computation algorithm used for a particular recipient.  The DEK and
+
+
+
+Linn                                                           [Page 30]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   MIC are symmetrically encrypted under the IK identified by a
+   preceding "Recipient-ID-Symmetric:" field and/or prior "Originator-
+   ID-Symmetric:" field.
+
+   Appropriate symmetric encryption algorithms, modes and identifiers,
+   MIC computation algorithms and identifiers, and encrypted DEK and MIC
+   formats are defined in RFC 1423.
+
+4.6.4.2.2  Asymmetric Key Management
+
+   When asymmetric key management is employed for a given recipient, the
+   "Key-Info:" field transfers two quantities, separated by a comma.
+   The first argument is an IK Use Indicator identifying the algorithm
+   and mode in which the DEK is asymmetrically encrypted.  The second
+   argument is a DEK, asymmetrically encrypted under the recipient's
+   public component.
+
+   Appropriate asymmetric encryption algorithms and identifiers, and
+   encrypted DEK formats are defined in RFC 1423.
+
+5.  Key Management
+
+   Several cryptographic constructs are involved in supporting the PEM
+   message processing procedure.  A set of fundamental elements is
+   assumed.  Data Encrypting Keys (DEKs) are used to encrypt message
+   text and (for some MIC computation algorithms) in the message
+   integrity check (MIC) computation process.  Interchange Keys (IKs)
+   are used to encrypt DEKs and MICs for transmission with messages.  In
+   a certificate-based asymmetric key management architecture,
+   certificates are used as a means to provide entities' public
+   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 (with some MIC computation algorithms) for computation of message
+   integrity check quantities (MICs).  In the asymmetric key management
+   case, they are also used for encrypting signed MICs in ENCRYPTED PEM
+   messages.  It is strongly recommended that DEKs be generated and used
+   on a one-time, per-message, basis.  A transmitted message will
+   incorporate a representation of the DEK encrypted under an
+   appropriate interchange key (IK) for each of the named recipients.
+
+   DEK generation can be performed either centrally by key distribution
+   centers (KDCs) or  by endpoint systems.  Dedicated KDC systems may be
+   able to  implement stronger algorithms for random DEK generation than
+
+
+
+Linn                                                           [Page 31]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   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 those of a message's originator and recipient.  Moreover,
+   decentralized DEK generation at endpoints reduces the frequency with
+   which originators must make real-time queries of (potentially unique)
+   servers in order to send mail, enhancing communications availability.
+
+   When symmetric key management 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 originators.  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-originator private IK components need not
+   necessarily be shared with a KDC.
+
+5.2  Interchange Keys (IKs)
+
+   Interchange Key (IK) components are used to encrypt DEKs and MICs.
+   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 PEM using
+   conventional cryptography, they must first possess common IK
+   components (when symmetric key management is used) or complementary
+   IK components (when asymmetric key management is used).  When
+   symmetric cryptography is used, the IK consists of a single
+   component, used to encrypt both DEKs and MICs.  When asymmetric
+   cryptography is used, a recipient's public component is used as an IK
+   to encrypt DEKs (a transformation invertible only by a recipient
+   possessing the corresponding private component), and the originator's
+   private component is used to encrypt MICs (a transformation
+   invertible by all recipients, since the originator's certificate
+   provides all recipients with the public component required to perform
+   MIC validation.
+
+   This RFC does not prescribe the means by which interchange keys are
+   made available to appropriate parties; 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 certificate-based asymmetric key management, as
+   discussed in RFC [1422, is employed, the IA function is performed by
+   a Certification Authority (CA).
+
+   When an IA generates and distributes an IK component, associated
+   control information is provided to direct how it is to be used.  In
+
+
+
+Linn                                                           [Page 32]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   order to select the appropriate IK(s) to use in message encryption,
+   an originator 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.
+
+   Since a message may be sent with multiple IK components identified,
+   corresponding to multiple intended recipients, each recipient's UA
+   must be able to determine that recipient's intended IK component.
+   Moreover, if no corresponding IK component is available in the
+   recipient's database when a message arrives, the recipient must be
+   able to identify the required IK component and 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 PEM message is transmitted, an indication of the IK components
+   used for DEK and MIC encryption must be included.  To this end,
+   Originator-ID and Recipient-ID encapsulated header fields provide
+   (some or all of) 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.  Version/Expiration subfield
+
+   In the asymmetric case, all necessary information associated with an
+   originator can be acquired by processing the certificate carried in
+   an "Originator-Certificate:" field; to avoid redundancy in this case,
+   no "Originator-ID-Asymmetric:" field is included if a corresponding
+   "Originator-Certificate:" appears.
+
+   The comma character (",") is used to delimit the subfields within an
+   Originator-ID or 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):
+
+
+
+
+
+
+
+Linn                                                           [Page 33]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   IKsubfld       :=       1*ia-char
+
+   ia-char        :=       DIGIT / ALPHA / "'" / "+" / "(" / ")" /
+                           "." / "/" / "=" / "?" / "-" / "@" /
+                           "%" / "!" / '"' / "_" / "<" / ">"
+
+
+
+   An example Recipient-ID field for the symmetric case is as follows:
+
+   Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,2
+
+   This example field indicates that IA "ptf-kmc" has issued an IK
+   component for use on messages sent  to "linn@zendia.enet.dec.com",
+   and that the IA has provided the number 2 as a version indicator for
+   that IK component.
+
+   An example Recipient-ID field for the asymmetric case is as follows:
+
+   Recipient-ID-Asymmetric:
+    MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
+    LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66
+
+   This example field includes the printably encoded BER representation
+   of a certificate's issuer distinguished name, along with the
+   certificate serial number 66 as assigned by that issuer.
+
+5.2.1  Subfield Definitions
+
+   The following subsections define the subfields of Originator-ID and
+   Recipient-ID fields.
+
+5.2.1.1  Entity Identifier Subfield
+
+   An entity identifier (used only for "Originator-ID-Symmetric:" and
+   "Recipient-ID-Symmetric:" fields) 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.
+
+
+
+
+
+Linn                                                           [Page 34]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+5.2.1.2  Issuing Authority Subfield
+
+   An IA identifier subfield is constructed as an IKsubfld.  This RFC
+   does not define this subfield's contents for the symmetric key
+   management case. Any prospective IAs which are to issue symmetric
+   keys for use in conjunction with this RFC must coordinate assignment
+   of IA identifiers in a manner (centralized or hierarchic) which
+   assures uniqueness.
+
+   For the asymmetric key management case, the IA identifier subfield
+   will be formed from the ASN.1 BER representation of the distinguished
+   name of the issuing organization or organizational unit.  The
+   distinguished encoding rules specified in Clause 8.7 of
+   Recommendation X.509 ("X.509 DER") are to be employed in generating
+   this representation.  The encoded binary result will be represented
+   for inclusion in a transmitted header using the procedure defined in
+   Section 4.3.2.4 of this RFC.
+
+5.2.1.3  Version/Expiration Subfield
+
+   A version/expiration subfield is constructed as an IKsubfld.  For the
+   symmetric key management case, the version/expiration subfield format
+   is permitted to 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.
+
+   For the asymmetric key management case, the version/expiration
+   subfield's value is the hexadecimal serial number of the certificate
+   being used in conjunction with the originator or recipient specified
+   in the "Originator-ID-Asymmetric:" or "Recipient-ID-Asymmetric:"
+   field in which the subfield occurs.
+
+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
+
+
+
+Linn                                                           [Page 35]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   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.
+
+6.  User Naming
+
+   Unique naming of electronic mail users, as is needed in order to
+   select corresponding keys correctly, is an important topic and one
+   which has received (and continues to receive) significant study.  For
+   the symmetric case, IK components are identified in PEM headers
+   through use of mailbox specifiers in traditional Internet-wide form
+   ("user@domain-qualified-host"). Successful operation in this mode
+   relies on users (or their PEM implementations) being able to
+   determine the universal-form names corresponding to PEM originators
+   and recipients.  If a PEM implementation operates in an environment
+   where addresses in a local form differing from the universal form are
+   used, translations must be performed in order to map between the
+   universal form and that local representation.
+
+   The use of user identifiers unrelated to the hosts on which the
+   users' mailboxes reside offers generality and value.  X.500
+   distinguished names, as employed in the certificates of the
+   recommended key management infrastructure defined in RFC 1422,
+   provide a basis for such user identification. As directory services
+   become more pervasive, they will offer originators a means to search
+   for desired recipients which is based on a broader set of attributes
+   than mailbox specifiers alone. Future work is anticipated in
+   integration with directory services, particularly the mechanisms and
+   naming schema of the Internet OSI directory pilot activity.
+
+7.  Example User Interface and Implementation
+
+   In order to place the mechanisms and approaches discussed in this RFC
+   into context, this section presents an overview of a hypothetical
+   prototype implementation.   This implementation is a standalone
+   program   which is invoked by a user, and   lies above the existing
+   UA sublayer.  In the UNIX system, and possibly in other environments
+   as well,  such a program can be invoked as a "filter" within an
+   electronic mail UA or a  text editor, simplifying the sequence of
+   operations which must be performed by  the user. This form of
+   integration offers the  advantage that the program can be used in
+   conjunction with a range of UA  programs, rather than being
+   compatible only with a particular UA.
+
+   When a user wishes to apply privacy enhancements to an outgoing
+   message, the user prepares the message's text and invokes the
+   standalone program, which in turn generates output suitable for
+   transmission via the UA.  When a user receives a PEM message, the UA
+
+
+
+Linn                                                           [Page 36]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   delivers the message in encrypted form, suitable for decryption and
+   associated processing by the standalone program.
+
+   In this prototype implementation, a cache of IK components is
+   maintained in a local file, with entries managed manually based on
+   information provided by originators and recipients.  For the
+   asymmetric key management case, certificates are acquired for a
+   user's PEM correspondents; in advance and/or in addition to retrieval
+   of certificates from directories, they can be extracted from the
+   "Originator-Certificate:" fields of received PEM messages.
+
+   The IK/certificate cache is, effectively, a simple database indexed
+   by mailbox names.  IK components are selected for transmitted
+   messages based on the originator's identity and on recipient names,
+   and corresponding Originator-ID, "Originator-Certificate:", and
+   Recipient-ID fields are placed into the message's encapsulated
+   header.  When a message is received, these fields are used as a basis
+   for a lookup in the database, yielding the appropriate IK component
+   entries.  DEKs and cryptographic parameters (e.g., IVs) are generated
+   dynamically within the program.
+
+   Options and destination addresses are selected by command line
+   arguments to the standalone program.  The function of specifying
+   destination addresses to the privacy enhancement program is logically
+   distinct from the function of specifying the corresponding addresses
+   to the UA for use by the MTS.  This separation results from the fact
+   that, in many cases, the local form of an address as specified to a
+   UA differs from the Internet global form as used in "Originator-ID-
+   Symmetric:" and "Recipient-ID-Symmetric:" fields.
+
+8.  Minimum Essential Requirements
+
+   This section summarizes particular capabilities which an
+   implementation must provide for full conformance with this RFC.
+
+   RFC 1422 specifies asymmetric, certificate-based key management
+   procedures to support the message processing procedures defined in
+   this document; PEM implementation support for these key management
+   procedures is strongly encouraged.  Implementations supporting these
+   procedures must also be equipped to display the names of originator
+   and recipient PEM users in the X.500 DN form as authenticated by the
+   procedures of RFC 1422.
+
+   The message processing procedures defined here can also be used with
+   symmetric key management techniques, though no RFCs analogous to RFC
+   1422 are currently available to provide correspondingly detailed
+   description of suitable symmetric key management procedures.   A
+   complete PEM implementation must support at least one of these
+
+
+
+Linn                                                           [Page 37]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   asymmetric and/or symmetric key management modes.
+
+   A full implementation of PEM is expected to be able to send and
+   receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive
+   CRL messages.  Some level of support for generating and processing
+   nested and annotated PEM messages (for forwarding purposes) is to be
+   provided, and an implementation should be able to reduce ENCRYPTED
+   messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant
+   implementations must be able to emit Certificate and Issuer-
+   Certificate fields, and to include a Key-Info field corresponding to
+   the originator, but users or configurers of PEM implementations may
+   be allowed the option of deactivating those features.
+
+9.  Descriptive Grammar
+
+   This section provides a grammar describing the construction of a PEM
+   message.
+
+   ; PEM BNF representation, using RFC 822 notation.
+
+   ; imports field meta-syntax (field, field-name, field-body,
+   ; field-body-contents) from RFC-822, sec. 3.2
+   ; imports DIGIT, ALPHA, CRLF, text from RFC-822
+   ; Note: algorithm and mode specifiers are officially defined
+   ; in RFC 1423
+
+   <pemmsg> ::= <preeb>
+                <pemhdr>
+                [CRLF <pemtext>]   ; absent for CRL message
+                <posteb>
+
+   <preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF
+   <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>
+
+   <pemtext> ::= <encbinbody>      ; for ENCRYPTED or MIC-ONLY messages
+               / *(<text> CRLF)    ; for MIC-CLEAR
+
+   <pemhdr> ::= <normalhdr> / <crlhdr>
+
+   <normalhdr> ::=  <proctype>
+
+               <contentdomain>
+               [<dekinfo>]         ; needed if ENCRYPTED
+               (1*(<origflds> *<recipflds>)) ; symmetric case --
+                            ; recipflds included for all proc types
+               / ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
+                            ; recipflds included for ENCRYPTED proc type
+
+
+
+
+Linn                                                           [Page 38]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   <crlhdr> ::= <proctype>
+               1*(<crl> [<cert>] *(<issuercert>))
+
+   <asymmorig> ::= <origid-asymm> / <cert>
+
+   <origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
+                  <micinfo>                        ; asymmetric
+                  / <origid-symm> [<keyinfo>]      ; symmetric
+
+   <recipflds> ::= <recipid> <keyinfo>
+
+   ; definitions for PEM header fields
+
+   <proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF
+   <contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
+   <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
+   <symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
+   <asymmid> ::= <IKsubfld> "," <IKsubfld>
+   <origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
+   <origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
+   <recipid> ::= <recipid-asymm> / <recipid-symm>
+   <recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
+   <recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
+   <cert> ::= "Originator-Certificate" ":" <encbin> CRLF
+   <issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
+   <micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
+                  <asymsignmic> CRLF
+   <keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
+                 <symencdek> "," <symencmic> CRLF     ; symmetric case
+                 / "Key-Info" ":" <ikalgid> "," <asymencdek>
+                 CRLF                                ; asymmetric case
+   <crl> ::= "CRL" ":" <encbin> CRLF
+
+   <pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL"
+
+   <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
+   <encbingrp> ::= 4*4<encbinchar>
+   <encbin> ::= 1*<encbingrp>
+   <encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
+   <IKsubfld> ::= 1*<ia-char>
+   ; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
+   ; fields can be delimited with commas (not colons) like all other
+   ; fields
+   <ia-char> ::=  DIGIT / ALPHA / "'" / "+" / "(" / ")" /
+                  "." / "/" / "=" / "?" / "-" / "@" /
+                  "%" / "!" / '"' / "_" / "<" / ">"
+   <hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+                                                      ; no lower case
+
+
+
+Linn                                                           [Page 39]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   ; This specification defines one value ("RFC822") for
+   ; <contentdescrip>: other values may be defined in future in
+   ; separate or successor documents
+   ;
+   <contentdescrip> ::= "RFC822"
+
+   ; The following items are defined in RFC 1423
+   ;  <dekalgid>
+   ;  <dekparameters>
+   ;  <micalgid>
+   ;  <ikalgid>
+   ;  <asymsignmic>
+   ;  <symencdek>
+   ;  <symencmic>
+   ;  <asymencdek>
+
+
+NOTES:
+
+     [1]  Key generation for MIC computation and message text encryption
+          may either be performed by the sending host or by a
+          centralized server.  This RFC does not constrain this design
+          alternative.  Section 5.1 identifies possible advantages of a
+          centralized server approach if symmetric key management is
+          employed.
+
+     [2]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
+          RFC 821, August 1982.
+
+     [3]  This transformation should occur only at an SMTP endpoint, not
+          at an intervening relay, but may take place at a gateway
+          system linking the SMTP realm with other environments.
+
+     [4]  Use of a canonicalization procedure similar to that of SMTP
+          was selected because its functions are widely used and
+          implemented within the Internet mail community, not for
+          purposes of SMTP interoperability with this intermediate
+          result.
+
+     [5]  Crocker, D., "Standard for the Format of ARPA Internet Text
+          Messages", STD 11, RFC 822, August 1982.
+
+     [6]  Rose, M. T. and Stefferud, E. A., "Proposed Standard for
+          Message Encapsulation", RFC 934, January 1985.
+
+     [7]  CCITT Recommendation X.509 (1988), "The Directory -
+          Authentication Framework".
+
+
+
+
+Linn                                                           [Page 40]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+     [8]  Throughout this RFC we have adopted the terms "private
+          component" and "public component" to refer to the quantities
+          which are, respectively, kept secret and made publicly
+          available in asymmetric cryptosystems.  This convention is
+          adopted to avoid possible confusion arising from use of the
+          term "secret key" to refer to either the former quantity or to
+          a key in a symmetric cryptosystem.
+
+Patent Statement
+
+   This version of Privacy Enhanced Mail (PEM) relies on the use of
+   patented public key encryption technology for authentication and
+   encryption.  The Internet Standards Process as defined in RFC 1310
+   requires a written statement from the Patent holder that a license
+   will be made available to applicants under reasonable terms and
+   conditions prior to approving a specification as a Proposed, Draft or
+   Internet Standard.
+
+   The Massachusetts Institute of Technology and the Board of Trustees
+   of the Leland Stanford Junior University have granted Public Key
+   Partners (PKP) exclusive sub-licensing rights to the following
+   patents issued in the United States, and all of their corresponding
+   foreign patents:
+
+      Cryptographic Apparatus and Method
+      ("Diffie-Hellman")............................... No. 4,200,770
+
+      Public Key Cryptographic Apparatus
+      and Method ("Hellman-Merkle").................... No. 4,218,582
+
+      Cryptographic Communications System and
+      Method ("RSA")................................... No. 4,405,829
+
+      Exponential Cryptographic Apparatus
+      and Method ("Hellman-Pohlig").................... No. 4,424,414
+
+   These patents are stated by PKP to cover all known methods of
+   practicing the art of Public Key encryption, including the variations
+   collectively known as El Gamal.
+
+   Public Key Partners has provided written assurance to the Internet
+   Society that parties will be able to obtain, under reasonable,
+   nondiscriminatory terms, the right to use the technology covered by
+   these patents.  This assurance is documented in RFC 1170 titled
+   "Public Key Standards and Licenses".  A copy of the written assurance
+   dated April 20, 1990, may be obtained from the Internet Assigned
+   Number Authority (IANA).
+
+
+
+
+Linn                                                           [Page 41]
+
+RFC 1421        Privacy Enhancement for Electronic Mail    February 1993
+
+
+   The Internet Society, Internet Architecture Board, Internet
+   Engineering Steering Group and the Corporation for National Research
+   Initiatives take no position on the validity or scope of the patents
+   and patent applications, nor on the appropriateness of the terms of
+   the assurance.  The Internet Society and other groups mentioned above
+   have not made any determination as to any other intellectual property
+   rights which may apply to the practice of this standard. Any further
+   consideration of these matters is the user's own responsibility.
+
+Security Considerations
+
+   This entire document is about security.
+
+Author's Address
+
+   John Linn
+
+   EMail: 104-8456@mcimail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linn                                                           [Page 42]
+
\ No newline at end of file