GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1040

Network Working Group J. Linn (BBNCC) Request for Comments: 1040 IAB Privacy Task Force Obsoletes RFCs: 989 January 1988

         Privacy Enhancement for Internet Electronic Mail:
     Part I: Message Encipherment and Authentication Procedures

STATUS OF THIS MEMO

 This RFC suggests a proposed protocol for the Internet community, and
 requests discussion and suggestions for improvements.  Distribution
 of this memo is unlimited.

ACKNOWLEDGMENT

 This RFC is the outgrowth of a series of IAB Privacy Task Force
 meetings and of internal working papers distributed for those
 meetings.  I would like to thank the following Privacy Task Force
 members and meeting guests for their comments and contributions at
 the meetings which led to the preparation of this RFC:  David
 Balenson, Curt Barker, Matt Bishop, Danny Cohen, Tom Daniel, Charles
 Fox, Morrie Gasser, Steve Kent (chairman), John Laws, Steve Lipner,
 Dan Nessett, Mike Padlipsky, Rob Shirey, Miles Smid, Steve Walker,
 and Steve Wilbur.

1. Executive Summary

 This RFC defines message encipherment and authentication procedures,
 as the initial phase of an effort to provide privacy enhancement
 services for electronic mail transfer in the Internet.  Detailed key
 management mechanisms to support these procedures will be defined in
 a subsequent RFC.  As a goal of this initial phase, it is intended
 that the procedures defined here be compatible with a wide range of
 key management approaches, including both conventional (symmetric)
 and public-key (asymmetric) approaches for encryption of data
 encrypting keys.  Use of conventional cryptography for message text
 encryption and/or integrity check computation is anticipated.
 Privacy enhancement services (confidentiality, authentication, and
 message integrity assurance) are offered through the use of
 end-to-end cryptography between originator and recipient User Agent
 processes, with no special processing requirements imposed on the
 Message Transfer System at endpoints or at intermediate relay
 sites.  This approach allows privacy enhancement facilities to be
 incorporated on a site-by-site or user-by-user basis without impact
 on other Internet entities.  Interoperability among heterogeneous

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

 components and mail transport facilities is supported.

2. Terminology

 For descriptive purposes, this RFC uses some terms defined in the OSI
 X.400 Message Handling System Model per the 1984 CCITT
 Recommendations.  This section replicates a portion of 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 User
 Agent.  A User Agent (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.

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
 sender and recipient UAs.  No privacy enhancements are offered for
 message fields which are added or transformed by intermediate relay
 points.
 Authentication and integrity facilities are always applied to the
 entirety of a message's text.  No facility for confidentiality
 service without authentication is provided.  Encryption facilities
 may be applied selectively to portions of a message's contents; this
 allows less sensitive portions of messages (e.g., descriptive fields)
 to be processed by a recipient's delegate in the absence of the

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

 recipient's personal cryptographic keys.  In the limiting case, where
 the entirety of message text is excluded from encryption, this
 feature can be used to yield the effective combination of
 authentication and integrity services without confidentiality.
 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 sender to be cognizant
         of whether a message's intended recipient implements privacy
         enhancements, in order that encoding and possible
         encipherment will not be performed on a message whose
         destination is not equipped to perform corresponding inverse
         transformations.
     3.  The defined mechanisms are compatible with a range of mail
         transport facilities (MTAs).  Within the Internet,
         electronic mail transport is effected by a variety of SMTP
         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 offer compatibility 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 an electronic mail privacy
         enhancement be available to the broadest possible user
         community, the selected mechanism should be usable with the
         widest possible variety of existing UA programs.  For

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

         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
         enhanced privacy 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 privacy-enhanced mail with a higher assurance
         level than a strictly UA-based approach would allow.
     6.  The defined mechanisms support privacy protection of
         electronic mail addressed to mailing lists.
 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 modifications
 throughout the Internet, three basic restrictions are imposed on the
 set of measures to be considered in this RFC:
     1.  Measures will be restricted to implementation at endpoints
         and will be amenable to integration at the user agent (UA)
         level or above, rather than necessitating 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.  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.

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

 As a result of these restrictions, the following facilities can be
 provided:
         1.  disclosure protection,
         2.  sender authenticity, and
         3.  message integrity measures,
 but the following privacy-relevant concerns are not addressed:
         1.  access control,
         2.  traffic flow confidentiality,
         3.  address list accuracy,
         4.  routing control,
         5.  issues relating to the 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.
 An important goal is that privacy enhancement mechanisms impose a
 minimum of burden on the users they serve.  In particular, this goal
 suggests eventual automation of the key management mechanisms
 supporting message encryption and authentication.  In order to
 facilitate deployment and testing of pilot privacy enhancement
 implementations in the near term, however, compatibility with
 out-of-band (e.g., manual) key distribution must also be supported.
 A message's sender will determine whether privacy enhancements are to
 be performed on a particular message.  Therefore, a sender must be
 able to determine whether particular recipients are equipped to
 process privacy-enhanced mail.  In a general architecture, these
 mechanisms will be based on server queries; thus, the query function
 could be integrated into a UA to avoid imposing burdens or
 inconvenience on electronic mail users.

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

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.
 A two-level keying hierarchy is used to support privacy-enhanced
 message 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 quantities (MICs).  DEKs are generated individually
         for each transmitted message; no predistribution of DEKs is
         needed to support privacy-enhanced message transmission.
     2.  Interchange Keys (IKs) are used to encrypt DEKs for
         transmission within messages.  An IK may be a single
         symmetric cryptographic key or, where asymmetric
         (public-key) cryptography is used to encrypt DEKs, the
         composition of a public component used by an originator and
         a secret component used by a recipient.  Ordinarily, the
         same IK will be used for all messages sent between a given
         originator-recipient pair over a period of time.  Each
         transmitted message includes a representation of the DEK(s)
         used for message encryption and/or authentication,
         encrypted under an individual IK per named recipient.  This
         representation is associated with sender and recipient
         identification header fields, which enable recipients to
         identify the IKs used.  With this information, the recipient
         can decrypt the transmitted DEK representation, yielding
         the DEK required for message text decryption and/or MIC
         verification.
 When privacy enhancement processing is to be performed on an outgoing
 message, a DEK is generated [1] for use in message encryption and a
 variant of the DEK is formed (if the chosen MIC algorithm requires a
 key) for use in MIC computation.  An "X-Sender-ID:" field is included
 in the header to provide one identification component for the IK(s)
 used for message processing.  An IK is selected for each individually
 identified recipient; a corresponding "X-Recipient-ID:" field,
 interpreted in the context of a prior "X-Sender-ID:" field, serves to
 identify each IK.  Each "X-Recipient-ID:" field is followed by an
 "X-Key-Info:" field, which transfers the DEK and computed MIC.  The
 DEK and MIC are encrypted for transmission under the appropriate IK.

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

 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 system to be
 decrypted on a different type.  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 encryption and MIC computation processes.
 For encryption purposes, the canonical representation is padded as
 required by the encryption algorithm.  The padded canonical
 representation is encrypted (except for any regions explicitly
 excluded from encryption).  The canonically encoded representation is
 encoded, after encryption, 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.
 The output of the encoding procedure is combined with a set of header
 fields carrying cryptographic control information.  The result is
 passed to the electronic mail system to be encapsulated as the text
 portion of a transmitted message.
 When a privacy-enhanced message is received, the cryptographic
 control fields within its text portion provide the information
 required for the authorized recipient to perform MIC verification and
 decryption of the received message text.  First, the printable
 encoding is converted to a bitstring.  The MIC is verified.
 Encrypted portions of the transmitted message are decrypted, and the
 canonical representation is converted to the recipient's local form,
 which need not be the same as the sender's local form.

4.2 Encryption Algorithms and Modes

 For purposes of this RFC, the Block Cipher Algorithm DEA-1, defined
 in ISO draft international standard DIS 8227 [2] shall be used for
 encryption of message text.  The DEA-1 is equivalent to the Data
 Encryption Standard (DES), as defined in FIPS PUB 46 [3].  When used
 for encryption of text, the DEA-1 shall be used in the Cipher Block
 Chaining (CBC) mode, as defined in ISO DIS 8372 [4].  The CBC mode
 definition in DIS 8372 is equivalent to that provided in FIPS PUB 81
 [5].  A unique initializing vector (IV) will be generated for and
 transmitted with each privacy-enhanced electronic mail message.

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

 An algorithm other than DEA-1 may be employed, provided that it
 satisfies the following requirements:
         1.  It must be a 64-bit block cipher, enciphering and
             deciphering in 8-octet blocks.
         2.  It is usable in the ECB and CBC modes defined in DIS
             8372.
         3.  It is able to be keyed using the procedures and
             parameters defined in this RFC.
         4.  It is appropriate for MIC computation, if the selected
             MIC computation algorithm is eCcryption-based.
         5.  Cryptographic key field lengths are limited to 16 octets
             in length.
 Certain operations require that one key be encrypted under another
 key (interchange key) for purposes of transmission.  This encryption
 may be performed using symmetric cryptography by using DEA-1 in
 Electronic Codebook (ECB) mode.  A header facility is available to
 indicate that an associated key is to be used for encryption in
 another mode (e.g., the Encrypt-Decrypt-Encrypt (EDE) mode used for
 key encryption and decryption with pairs of 64-bit keys, as described
 by ASC X3T1 [6], or public-key algorithms).
 Support of public key algorithms for key encryption is under active
 consideration, and it is intended that the procedures defined in this
 RFC be appropriate to allow such usage.  Support of key encryption
 modes other than ECB is optional for implementations, however.
 Therefore, in support of universal interoperability, interchange key
 providers should not specify other modes in the absence of a priori
 information indicating that recipients are equipped to perform key
 encryption in other modes.

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 transport facilities.  An encryption mechanism must also be
 compatible with the local conventions of the computer systems which
 it interconnects.  In our approach, a canonicalization step is
 performed to abstract out local conventions and a subsequent encoding

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

 step is performed to conform to the characteristics of the underlying
 mail transport medium (SMTP).  The encoding conforms to SMTP
 constraints, established to support interpersonal messaging.  SMTP's
 rules are also used independently in the canonicalization process.
 RFC-821's [7] Section 4.5 details SMTP's transparency constraints.
 To encode 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 use a different native
 representation to delimit lines.  For example, the <CR><LF> sequences
 delimiting lines in mail inbound to UNIX(tm) 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 [8] server.
 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 9] RFC 1040 Privacy Enhancement for Electronic Mail January 1988

4.3.2 Approach

 Our approach to supporting privacy-enhanced mail across an
 environment in which intermediate conversions may occur encodes mail
 in a fashion which is uniformly representable across the set of
 privacy-enhanced UAs regardless of their systems' native character
 sets.  This encoded form is used to represent mail text from sender
 to recipient, but the encoding is not applied to enclosing mail
 transport headers or to encapsulated headers inserted to carry
 control information between privacy-enhanced UAs.  The encoding's
 characteristics are such that the transformations anticipated between
 sender and recipient UAs will not prevent an encoded message from
 being decoded properly at its destination.
 A sender may exclude one or more portions of a message from
 encryption processing.  Authentication processing is always applied
 to the entirety of message text.  Explicit action is required to
 exclude a portion of a message from encryption processing; by
 default, encryption is applied to the entirety of message text.  The
 user-level delimiter which specifies such exclusion is a local
 matter, and hence may vary between sender and recipient, but all
 systems should provide a means for unambiguous identification of
 areas excluded from encryption processing.
 An outbound privacy-enhanced message undergoes four transformation
 steps, described in the following four subsections.

4.3.2.1 Step 1: Local Form

 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

 The entire message text, including both those portions subject to
 encipherment processing and those portions excluded from such
 processing, is converted to the universal canonical form,
 equivalent to the inter-SMTP representation [9] as defined in
 RFC-821 and RFC-822 [10] (ASCII character set, <CR><LF> line
 delimiters).  The processing required to perform this conversion is
 minimal on systems whose native character set is ASCII.  Since a
 message is converted to a standard character set and representation
 before encryption, it can be decrypted and its MIC can be verified
 at any destination system before any conversion necessary to
 transform the message into a destination-specific local form is
 performed.

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

4.3.2.3 Step 3: Authentication and Encipherment

 The canonical form is input to the selected MIC computation algorithm
 in order to compute an 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.
 Padding is applied to the canonical form as needed to perform
 encryption in the DEA-1 CBC mode, as follows:  The number of octets
 to be encrypted is determined by subtracting the number of octets
 excluded from encryption from the total length of the encapsulated
 text.  Octets with the hexadecimal value FF (all ones) are appended
 to the canonical form as needed so that the text octets to be
 encrypted, along with the added padding octets, fill an integral
 number of 8-octet encryption quanta.  No padding is applied if the
 number of octets to be encrypted is already an integral multiple of
 8.  The use of hexadecimal FF (a value outside the 7-bit ASCII set)
 as a padding value allows padding octets to be distinguished from
 valid data without inclusion of an explicit padding count indicator.
 The regions of the message which have not been excluded from
 encryption are encrypted.  To support selective encipherment
 processing, an implementation must retain internal indications of the
 positions of excluded areas excluded from encryption with relation to
 non-excluded areas, so that those areas can be properly delimited in
 the encoding procedure defined in step 4.  If a region excluded from
 encryption intervenes between encrypted regions, cryptographic state
 (e.g., IVs and accumulation of octets into encryption quanta) is
 preserved and continued after the excluded region.

4.3.2.4 Step 4: Printable Encoding

 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).  This encoding step is
 performed for all privacy-enhanced messages.
 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.)
 Two additional characters, "=" and "*", are used to signify special
 processing functions.  The character "=" is used for padding within
 the printable encoding procedure.  The character "*" is used to
 delimit the beginning and end of a region which has been excluded

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

 from encipherment processing.  The encoding function's output is
 delimited into text lines (using local conventions), with each line
 containing 64 printable characters.
 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>").
 Special processing is performed if fewer than 24-bits are available
 in an input group, either at the end of a message or (when the
 selective encryption facility is invoked) at the end of an encrypted
 region or an excluded region.  In other words, a full encoding
 quantum is always completed at the end of a message and before the
 delimiter "*" is output to initiate or terminate the representation
 of a block excluded from encryption.  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.
 In summary, the outbound message is subjected to the following
 composition of transformations:
       Transmit_Form = Encode(Encipher(Canonicalize(Local_Form)))
 The inverse transformations are performed, in reverse order, to
 process inbound privacy-enhanced mail:
       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 sender and recipient
 systems without loss of information.

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

      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        (1)   *
 (1) The character "*" is used to delimit portions of an encoded
 message to which encryption processing has not been applied.
                     Printable Encoding Characters
                                Table 1

4.4 Encapsulation Mechanism

 Encapsulation of privacy-enhanced messages within an enclosing layer
 of headers interpreted by the electronic mail transport system offers
 a number of advantages in comparison to a flat approach in which
 certain fields within a single header are encrypted and/or carry
 cryptographic control information.  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.  Further, privacy enhancement processing can be
 applied recursively.  As far as the MTS is concerned, information
 incorporated into cryptographic authentication or encryption
 processing will reside in a message's text portion, not its header
 portion.

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

 The encapsulation mechanism to be used for privacy-enhanced mail is
 derived from that described in RFC-934 [11] which is, in turn, based
 on precedents in the processing of message digests in the Internet
 community.  To prepare a user message for encrypted or authenticated
 transmission, it will be transformed into the representation shown in
 Figure 1.
 Enclosing Header Portion
         (Contains header fields per RFC-822)
 Blank Line
          (Separates Enclosing Header from Encapsulated Message)
 Encapsulated Message
    Pre-Encapsulation Boundary (Pre-EB)
        -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
    Encapsulated Header Portion
        (Contains encryption control fields inserted in plaintext.
        Examples include "X-IV:", "X-Sender-ID:", and "X-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 encoded
        Encapsulated Text Portion)
    Encapsulated Text Portion
        (Contains message data encoded as specified in Section 4.3;
        may incorporate protected copies of "Subject:", etc.)
    Post-Encapsulation Boundary (Post-EB)
        -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
                            Message Encapsulation
                                   Figure 1
 As a general design principle, sensitive data is protected by
 incorporating the data within the encapsulated text rather than by
 applying measures selectively to fields in the enclosing header.
 Examples of potentially sensitive header information may include
 fields such as "Subject:", with contents which are significant on an
 end-to-end, inter-user basis.  The (possibly empty) set of headers to
 which protection is to be applied is a user option.  It is strongly
 recommended, however, that all implementations should replicate

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

 copies of "X-Sender-ID:" and "X-Recipient-ID:" fields within the
 encapsulated text and include those replicated fields in encryption
 and MIC computations.
 If a user wishes disclosure protection for header fields, they must
 occur only in the encapsulated text and not in the enclosing or
 encapsulated header.  If disclosure protection is desired for a
 message's subject indication, it is recommended that the enclosing
 header contain a "Subject:" field indicating that "Encrypted Mail
 Follows".
 If an authenticated version of header information is desired, that
 data can be replicated within the encapsulated text portion in
 addition to its inclusion in the enclosing header.  For example, a
 sender wishing to provide recipients with a protected indication of a
 message's position in a series of messages could include a copy of a
 timestamp or message counter field within the encapsulated text.
 A specific point regarding the integration of privacy-enhanced mail
 facilities with the message encapsulation mechanism is worthy of
 note.  The subset of IA5 selected for transmission encoding
 intentionally excludes the character "-", so encapsulated text can be
 distinguished unambiguously from a message's closing encapsulation
 boundary (Post-EB) without recourse to character stuffing.

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-
 perrecipient method.  The choice depends on the information available
 to the sender and on the sender's preference.
 If a message's sender addresses a message to a list name or alias,
 use of an IK associated with that name or alias as a entity (IK-
 perlist), 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.  For the case of public-key
 cryptography, the secret component of the composite IK must be
 available to all list members.  This alternative will be the normal
 case for messages sent via remote exploder sites, as a sender to such
 lists may not be cognizant of the set of individual recipients.
 Unfortunately, it implies an undesirable level of exposure for the
 shared IK or component, 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 sender to the list for
 authentication purposes.

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

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

4.6 Summary of Added Header and Control Fields

 This section summarizes the syntax and semantics of the new
 encapsulated header fields to be added to messages in the course of
 privacy enhancement processing.  In certain indicated cases, it is
 recommended that the fields be replicated within the encapsulated
 text portion as well.  Figure 2 shows the appearance of a small
 example encapsulated message using these fields.  The example assumes
 the use of symmetric cryptography; no "X-Certificate:" field is
 carried.  In all cases, hexadecimal quantities are represented as
 contiguous strings of digits, where each digit is represented by a
 character from the ranges "0"-"9" or upper case "A"-"F".  Unless
 otherwise specified, all arguments are to be processed in a
 casesensitive fashion.
 Although the encapsulated header fields resemble RFC-822 header
 fields, they are a disjoint set and will not in general be processed
 by the same parser which operates on enclosing header fields.  The
 complexity of lexical analysis needed and appropriate for
 encapsulated header field processing is significantly less than that
 appropriate to RFC-822 header processing.  For example, many
 characters with special significance to RFC-822 at the syntactic
 level have no such significance within encapsulated header fields.
 When the length of an encapsulated header field is longer than the
 size conveniently printable on a line, whitespace may be used between
 the subfields of these fields to fold them in the manner of RFC-822,
 section 3.1.1.  Any such inserted whitespace is not to be interpreted
 as a part of a subfield.

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

  1. —-PRIVACY-ENHANCED MESSAGE BOUNDARY—–

X-Proc-Type: 2

 X-IV: F8143EDE5960C597
 X-Sender-ID: linn@ccy.bbn.com:::
 X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:3:BMAC:ECB
 X-Key-Info: 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
 X-Recipient-ID: privacy-tf@venera.isi.edu:ptf-kmc:4:BMAC:ECB
 X-Key-Info: 161A3F75DC82EF26,E2EF532C65CBCFF7
 LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
 J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
 dXd/H5LMDWnonNvPCwQUHt==
  -----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
                     Example Encapsulated Message
                               Figure 2

4.6.1 X-Certificate Field

 The X-Certificate encapsulated header field is used only when
 public-key certificate key management is employed.  It transfers a
 sender's certificate as a string of hexadecimal digits.  The
 semantics of a certificate are discussed in Section 5.3,
 Certificates.  The certificate carried in an X-Certificate field is
 used in conjunction with all subsequent X-Sender-ID and X-RecipientID
 fields until another X-Certificate field occurs; the ordinary case
 will be that only a single X-Certificate field will occur, prior to
 any X-Sender-ID and X-Recipient-ID fields.
 Due to the length of a certificate, it may need to be folded across
 multiple printed lines.  In order to enable such folding to be
 performed, the hexadecimal digits representing the contents of a
 certificate are to be divided into an ordered set (with more
 significant digits first) of zero or more 64-digit groups, followed
 by a final digit group which may be any length up to 64-digits.  A
 single whitespace character is interposed between each pair of groups
 so that folding (per RFC-822, section 3.1.1) may take place; this
 whitespace is ignored in parsing the received digit string.

4.6.2 X-IV Field

 The X-IV encapsulated header field carries the Initializing Vector
 used for message encryption.  Only one X-IV field occurs in a
 message.  It appears in all messages, even if the entirety of message
 text is excluded from encryption.  Following the field name, and one
 or more delimiting whitespace characters, a 64-bit Initializing
 Vector is represented as a contiguous string of 16 hexadecimal

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

 digits.

4.6.3 X-Key-Info Field

 The X-Key-Info encapsulated header field transfers two items: a DEK
 and a MIC.  One X-Key-Info field is included for each of a message's
 named recipients.  The DEK and MIC are encrypted under the IK
 identified by a preceding X-Recipient-ID field and prior X-Sender-ID
 field; they are represented as two strings of contiguous hexadecimal
 digits, separated by a comma.  For DEA-1, the DEK representation will
 be 16 hexadecimal digits (corresponding to a 64-bit key); this
 subfield can be extended to 32 hexadecimal digits (corresponding to a
 128-bit key), if required to support other algorithms.  MICs are also
 represented as contiguous strings of hexadecimal digits.  The size of
 a MIC is dependent on the choice of MIC algorithm as specified in the
 X-Recipient-ID field corresponding to a given recipient.

4.6.4 X-Proc-Type Field

 The X-Proc-Type encapsulated header field identifies the type of
 processing performed on the transmitted message.  Only one X-ProcType
 field occurs in a message.  It has one subfield, a decimal number
 which is used to distinguish among incompatible encapsulated header
 field interpretations which may arise as changes are made to this
 standard.  Messages processed according to this RFC will carry the
 subfield value "2".

4.6.5 X-Sender-ID Field

 The X-Sender-ID encapsulated header field provides the sender's
 interchange key identification component.  It should be replicated
 within the encapsulated text.  The interchange key identification
 component carried in an X-Sender-ID field is used in conjunction with
 all subsequent X-Recipient-ID fields until another X-Sender-ID field
 occurs; the ordinary case will be that only a single X-Sender-ID
 field will occur, prior to any X-Recipient-ID fields.
 The X-Sender-ID field contains (in order) an Entity Identifier
 subfield, an (optional) Issuing Authority subfield, an (optional)
 Version/Expiration subfield, and an (optional) IK Use Indicator
 subfield.  The optional subfields are omitted if their use is
 rendered redundant by information carried in subsequent X-RecipientID
 fields; this will ordinarily be the case where symmetric cryptography
 is used for key management.  The subfields are delimited by the colon
 character (":"), optionally followed by whitespace.
 Section 5.2, Interchange Keys, discusses the semantics of these
 subfields and specifies the alphabet from which they are chosen.

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

 Note that multiple X-Sender-ID fields may occur within a single
 encapsulated header.  All X-Recipient-ID fields are interpreted in
 the context of the most recent preceding X-Sender-ID field; it is
 illegal for an X-Recipient-ID field to occur in a header before an
 X-Sender-ID has been provided.

4.6.6 X-Recipient-ID Field

 The X-Recipient-ID encapsulated header field provides the recipient's
 interchange key identification component.  One X-Recipient-ID field
 is included for each of a message's named recipients.  It should be
 replicated within the encapsulated text.  The field contains (in
 order) an Entity Identifier subfield, an Issuing Authority subfield,
 a Version/Expiration subfield, a MIC algorithm indicator subfield,
 and an IK Use Indicator subfield.  The subfields are delimited by the
 colon character (":"), optionally followed by whitespace.
 The MIC algorithm indicator is an ASCII string, selected from the
 values defined in Appendix A of this RFC.  Section 5.2, Interchange
 Keys, discusses the semantics of the other subfields and specifies
 the alphabet from which they are chosen.  All X-Recipient-ID
 fields are interpreted in the context of the most recent preceding
 XSender-ID field; it is illegal for an X-Recipient-ID field to
 occur in a header before an X-Sender-ID has been provided.

5. Key Management

 Several cryptographic constructs are involved in supporting the
 privacy-enhanced message processing procedure.  While (as noted in
 the Executive Summary section of this RFC), key management mechanisms
 have not yet been fully defined, a set of fundamental elements are
 assumed.  Data Encrypting Keys (DEKs) are used to encrypt message
 text and in the message integrity check (MIC) computation process.
 Interchange Keys (IKs) are used to encrypt DEKs for transmission with
 messages.  In an asymmetric key management architecture, certificates
 are used as a means to provide entities' public key components and
 other information in a fashion which is securely bound by a central
 authority.  The remainder of this section provides more information
 about these constructs.

5.1 Data Encrypting Keys (DEKs)

 Data Encrypting Keys (DEKs) are used for encryption of message text
 and for computation of message integrity check quantities (MICs).  It
 is strongly recommended that DEKs be generated and used on a one-time
 basis.  A transmitted message will incorporate a representation of
 the DEK encrypted under an appropriate interchange key (IK) for each
 the authorized recipient.

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

 DEK generation can be performed either centrally by key distribution
 centers (KDCs) or by endpoint systems.  Dedicated KDC systems may be
 able to implement better algorithms for random DEK generation than
 can be supported in endpoint systems.  On the other hand,
 decentralization allows endpoints to be relatively self-sufficient,
 reducing the level of trust which must be placed in components other
 than a message's originator and recipient.  Moreover, decentralized
 DEK generation at endpoints reduces the frequency with which senders
 must make real-time queries of (potentially unique) servers in order
 to send mail, enhancing communications availability.
 When symmetric cryptography is used, one advantage of centralized
 KDC-based generation is that DEKs can be returned to endpoints
 already encrypted under the IKs of message recipients rather than
 providing the IKs to the senders.  This reduces IK exposure and
 simplifies endpoint key management requirements.  This approach has
 less value if asymmetric cryptography is used for key management,
 since per-recipient public IK components are assumed to be generally
 available and per-sender secret IK components need not necessarily be
 shared with a KDC.

5.2 Interchange Keys (IKs)

 Interchange Keys (IKs) are used to encrypt Data Encrypting Keys.  In
 general, IK granularity is at the pairwise per-user level except for
 mail sent to address lists comprising multiple users.  In order for
 two principals to engage in a useful exchange of privacy-enhanced
 electronic mail using conventional cryptography, they must first
 share a common interchange key.  When symmetric cryptography is used,
 the interchange key consists of a single component.  When asymmetric
 cryptography is used, an originator and recipient must possess an
 asymmetric key's public and secret components, as appropriate.  This
 pair of components, when composed, constitute an interchange key.
 While this RFC does not prescribe the means by which interchange keys
 are provided to appropriate parties, it is useful to note that such
 means may be centralized (e.g., via key management servers) or
 decentralized (e.g., via pairwise agreement and direct distribution
 among users).  In any case, any given IK component is associated with
 a responsible Issuing Authority (IA).  When an IA generates and
 distributes an IK, associated control information is provided to
 direct how that IK is to be used.  In order to select the appropriate
 IK to use in message encryption, a sender must retain a
 correspondence between IK components and the recipients with which
 they are associated.  Expiration date information must also be
 retained, in order that cached entries may be invalidated and
 replaced as appropriate.

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

 Since a message may be sent with multiple IK component
 representations, corresponding to multiple intended recipients, each
 recipient must be able to determine which IK component is intended
 for it.  Moreover, if no corresponding IK component is available in
 the recipient's database when a message arrives, the recipient must
 be able to determine which IK component to request and to 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 privacy-enhanced message is transmitted, an indication of the
 IK components used for DEK encryption must be included.  To this end,
 the "X-Sender-ID:" and "X-Recipient-ID:" encapsulated header fields
 provide 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.  Indicator of IK usage mode (IK use indicator subfield).
       4.  Version/Expiration subfield.
 The colon character (":") is used to delimit the subfields within an
 "X-Sender-ID:" or "X-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):
 IKsubfld       :=       1*ia-char
 ia-char        :=       DIGIT / ALPHA / "'" / "+" / "(" / ")" /
                         "," / "." / "/" / "=" / "?" / "-" / "@" /
                         "%" / "!" / '"' / "_" / "<" / ">"
 An example X-Recipient-ID: field is as follows:
             X-Recipient-ID: linn@ccy.bbn.com:ptf-kmc:2:BMAC:ECB
 This example field indicates that IA "ptf-kmc" has issued an IK
 component for use on messages sent to "linn@ccy.bbn.com", that the IA

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

 has provided the number 2 as a version indicator for that IK
 component, that the BMAC MIC computation algorithm is to be used for
 the recipient, and that the IK component is to be used in ECB mode.

5.2.1 Subfield Definitions

 The following subsections define the subfields of "X-Sender-ID:" and
 "X-Recipient-ID:" fields.

5.2.1.1 Entity Identifier Subfield

 An entity identifier 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.

5.2.1.2 Issuing Authority Subfield

 An IA identifier subfield is constructed as an IKsubfld.  IA
 identifiers must be assigned in a manner which assures uniqueness.
 This can be done on a centralized or hierarchic basis.

5.2.1.3 Version/Expiration Subfield

 A version/expiration subfield is constructed as an IKsubfld.  The
 version/expiration subfield format may 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.

5.2.1.4 MIC Algorithm Identifier Subfield

 The MIC algorithm identifier, which occurs only within X-Recipient-ID
 fields, is used to identify the choice of message integrity check
 algorithm for a given recipient.  Appendix A of this RFC specifies
 the defined values for this subfield.

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

5.2.1.5 IK Use Indicator Subfield

 The IK use indicator subfield is an optional facility, provided to
 identify the encryption mode in which an IK component is to be used.
 Currently, this subfield may assume the following reserved string
 values: "ECB", "EDE", "RSA256", "RSA512", and "RSA1024"; the default
 value is "ECB".

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

5.3 Certificates

 In an asymmetric key management architecture, a certificate binds an
 entity's public key component to a representation of the entity's
 identity and other attributes of the entity.  A certificate's issuing
 authority signs the certificate, vouching for the correspondence
 between the entity's identity, attributes, and associated public key
 component.  Once signed, certificate copies may be posted on multiple
 servers in order to make recipients' certificates directly accessible
 to originators at dispersed locations.  This allows privacy-enhanced
 mail to be sent between an originator and a recipient without prior
 placement of a pairwise key at the originator and recipient, greatly
 enhancing mail system flexibility.  The properties of a certificate's
 authority-applied signature make it unnecessary to be concerned about
 the prospect that servers, or other entities, could undetectably
 modify certificate contents so as to associate a public key with an
 inappropriate entity.
 Per the 1988 CCITT Recommendations X.411 [12] and X.509 [13], a
 subject's certificate is defined to contain the following parameters:
         1.  A signature algorithm identifier, identifying the
             algorithm used by the certificate's issuer to compute the
             signature applied to the certificate.

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

         2.  Issuer identification, identifying the certificate's
             issuer with an O/R name.
         3.  Validity information, providing date and time limits
             before and after which the certificate should not be
             used.
         4.  Subject identification, identifying the certificate's
             subject with an O/R name.
         5.  Subject's public key.
         6.  Algorithm identifier, identifying the algorithm with
             which the subject's public key is to be used.
         7.  Signature, an asymmetrically encrypted, hashed version of
             the above parameters, computed by the certificate's
             issuer.
 The Recommendations specify an ASN.1 encoding to define a
 certificate.  Pending further study, it is recommended that
 electronic mail privacy enhancement implementations using asymmetric
 cryptography for key management employ this encoding for
 certificates.  Section 4.2.3 of RFC-987 [14] specifies a procedure
 for mapping RFC-822 addresses into the O/R names used in X.411/X.509
 certificates.

6. User Naming

6.1 Current Approach

 Unique naming of electronic mail users, as is needed in order to
 select corresponding keys correctly, is an important topic and one
 requiring significant study.  A logical association exists between
 key distribution and name/directory server functions; their
 relationship is a topic deserving further consideration.  These
 issues have not been fully resolved at this writing.  The current
 architecture relies on association of IK components with user names
 represented in a universal form ("user@host"), relying on the
 following properties:
     1.  The universal form must be specifiable by an IA as it
         distributes IK components and known to a UA as it processes
         received IK components and IK component identifiers.  If a
         UA or IA uses addresses in a local form which is different
         from the universal form, it must be able to perform an
         unambiguous mapping from the universal form into the local
         representation.

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

     2.  The universal form, when processed by a sender UA, must have
         a recognizable correspondence with the form of a recipient
         address as specified by a user (perhaps following local
         transformation from an alias into a universal form).
 It is difficult to ensure these properties throughout the Internet.
 For example, an MTS which transforms address representations between
 the local form used within an organization and the universal form as
 used for Internet mail transmission may cause property 2 to be
 violated.

6.2 Issues for Consideration

 The use of flat (non-hierarchic) electronic mail user identifiers,
 which are unrelated to the hosts on which the users reside, may offer
 value.  Personal characteristics, like social security numbers, might
 be considered.  Individually-selected identifiers could be registered
 with a central authority, but a means to resolve name conflicts would
 be necessary.
 A point of particular note is the desire to accommodate multiple
 names for a single individual, in order to represent and allow
 delegation of various roles in which that individual may act.  A
 naming mechanism that binds user roles to keys is needed.  Bindings
 cannot be immutable since roles sometimes change (e.g., the
 comptroller of a corporation is fired).
 It may be appropriate to examine the prospect of extending the
 DARPA/DoD domain system and its associated name servers to resolve
 user names to unique user IDs.  An additional issue arises with
 regard to mailing list support: name servers do not currently perform
 (potentially recursive) expansion of lists into users.  ISO and CSNet
 are working on user-level directory service mechanisms, which may
 also bear consideration.

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 prototype
 implementation.  This implementation is a standalone program which is
 invoked by a user, and lies above the existing UA sublayer.  In the
 UNIX(tm) 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

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

 message, the user prepares the message's text and invokes the
 standalone program (interacting with the program in order to provide
 address information and other data required to perform privacy
 enhancement processing), which in turn generates output suitable for
 transmission via the UA.  When a user receives a privacy-enhanced
 message, the UA 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.  This cache is,
 effectively, a simple database.  IK components are selected for
 transmitted messages based on the sender's identity and on recipient
 names, and corresponding "X-Sender-ID:" and "X-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
 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 "X-Sender-ID:"
 and "X-Recipient-ID:" fields.

8. Areas For Further Study

 The procedures defined in this RFC are sufficient to support pilot
 implementation of privacy-enhanced electronic mail transmission among
 cooperating parties in the Internet.  Further effort will be needed,
 however, to enhance robustness, generality, and interoperability.  In
 particular, further work is needed in the following areas:
     1.  User naming techniques, and their relationship to the domain
         system, name servers, directory services, and key management
         functions.
     2.  Standardization of Issuing Authority functions, including
         protocols for communications among IAs and between User
         Agents and IAs.
     3.  Specification of public key encryption algorithms to encrypt
         data encrypting keys.
     4.  Interoperability with X.400 mail.

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

 We anticipate generation of subsequent RFCs which will address these
 topics.

9. References

 This section identifies background references which may be useful to
 those contemplating use of the mechanisms defined in this RFC.
    ISO 7498/Part 2 - Security Architecture, prepared by ISO/TC97/SC
    21/WG 1 Ad hoc group on Security, extends the OSI Basic Reference
    Model to cover security aspects which are general architectural
    elements of communications protocols, and provides an annex with
    tutorial and background information.
    US Federal Information Processing Standards Publication (FIPS PUB)
    46, Data Encryption Standard, 15 January 1977, defines the
    encipherment algorithm used for message text encryption and
    Message Authentication Code (MAC) computation.
    FIPS PUB 81, DES Modes of Operation, 2 December 1980, defines
    specific modes in which the Data Encryption Standard algorithm may
    to be used to perform encryption.
    FIPS PUB 113, Computer Data Authentication, May 1985, defines a
    specific procedure for use of the Data Encryption Standard
    algorithm to compute a MAC.

A. Message Integrity Check Algorithms

 This appendix identifies the alternative algorithms which may be used
 to compute Message Integrity Check (MIC) values, and assigns them
 character string identifiers to be incorporated in "X-Recipient-ID:"
 fields to indicate the choice of algorithm employed for individual
 message recipients.
 MIC algorithms which utilize DEA-1 cryptography are computed using a
 key which is a variant of the DEK used for message text encryption.
 The variant is formed by modulo-2 addition of the hexadecimal
 quantity F0F0F0F0F0F0F0F0 to the encryption DEK.

A.1 Conventional MAC (MAC)

 A conventional MAC, denoted by the string "MAC", is computed using
 the DEA-1 algorithm in the fashion defined in FIPS PUB 113 [15].  Use
 of the conventional MAC is not recommended for multicast messages.
 The message's encapsulated text is padded at the end, per FIPS PUB
 113, with zero-valued octets as needed in order to form an integral
 number of 8-octet encryption quanta.  These padding octets are

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

 inserted implicitly and are not transmitted with a message.  The
 result of a conventional MAC computation is a single 64-bit value.

A.2 Bidirectional MAC (BMAC)

 A bidirectional MAC, denoted by the string "BMAC", yields a result
 which is transferred as a single 128-bit value.  The BMAC is computed
 in the following manner:  First, the encapsulated text is padded at
 the end with zero-valued octets as needed in order to form an
 integral number of 8-octet encryption quanta.  These padding octets
 are inserted implicitly and are not transmitted with a message.  A
 conventional MAC is computed on the padded form, and the resulting
 64-bits form the high-order 64-bits of the BMAC result.
 The low-order 64-bits of the BMAC result are also formed by computing
 a conventional MAC, but the order of the 8-octet encryption quanta is
 reversed for purposes of computation. In other words, the first
 quantum entered into this computation is the last quantum in the
 encapsulated text, and includes any added padding.  The first quantum
 in the text is the last quantum processed as input to this
 computation.  The octets within each 8-octet quantum are not
 reordered.

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.
   [2]  Information Processing Systems: Data Encipherment: Block
        Cipher Algorithm DEA 1.
   [3]  Federal Information Processing Standards Publication 46,
        Data Encryption Standard, 15 January 1977.
   [4]  Information Processing Systems: Data Encipherment: Modes of
        Operation of a 64-bit Block Cipher.
   [5]  Federal Information Processing Standards Publication 81,
        DES Modes of Operation, 2 December 1980.
   [6]  Addendum to the Transport Layer Protocol Definition for
        Providing Connection Oriented End to End Cryptographic Data
        Protection Using a 64-Bit Block Cipher, X3T1-85-50.3, draft
        of 19 December 1985, Gaithersburg, MD, p. 15.

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

   [7]  Postel, J., Simple Mail Transfer Protocol (RFC-821), August
        1982.
   [8]  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.
   [9]  Use of the SMTP canonicalization procedure at this stage
        was selected since it is widely used and implemented in the
        Internet community, not because SMTP interoperability with
        this intermediate result is required; no privacy-enhanced
        message will be passed to SMTP for transmission directly
        from this step in the four-phase transformation procedure.
   [10] Crocker, D., Standard for the Format of ARPA Internet Text
        Messages (RFC-822), August 1982.
   [11] Rose, M. T. and Stefferud, E. A., Proposed Standard for
        Message Encapsulation (RFC-934), January 1985.
   [12] CCITT Recommendation X.411 (1988), "Message Handling
        Systems: Message Transfer System: Abstract Service
        Definition and Procedures".
   [13] CCITT Recommendation X.509 (1988), "The Directory -
        Authentication Framework".
   [14] Kille, S. E., Mapping between X.400 and RFC-822 (RFC-987),
        June 1986.
   [15] Federal Information Processing Standards Publication 113,
        Computer Data Authentication, May 1985.

Linn [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1040.txt · Last modified: 1988/01/22 23:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki