1 

     2 

     3 

     4 

     5 

     6 

     7 Network Working Group                                            J. Linn

     8 Request for Comments: 1421                    IAB IRTF PSRG, IETF PEM WG

     9 Obsoletes: 1113                                            February 1993

    10 

    11 

    12            Privacy Enhancement for Internet Electronic Mail:

    13         Part I: Message Encryption and Authentication Procedures

    14 

    15 Status of this Memo

    16 

    17    This RFC specifies an IAB standards track protocol for the Internet

    18    community, and requests discussion and suggestions for improvements.

    19    Please refer to the current edition of the "IAB Official Protocol

    20    Standards" for the standardization state and status of this protocol.

    21    Distribution of this memo is unlimited.

    22 

    23 Acknowledgements

    24 

    25    This document is the outgrowth of a series of meetings of the Privacy

    26    and Security Research Group (PSRG) of the IRTF and the PEM Working

    27    Group of the IETF.  I would like to thank the members of the PSRG and

    28    the IETF PEM WG, as well as all participants in discussions on the

    29    "pem-dev@tis.com" mailing list, for their contributions to this

    30    document.

    31 

    32 1.  Executive Summary

    33 

    34    This document defines message encryption and authentication

    35    procedures, in order to provide privacy-enhanced mail (PEM) services

    36    for electronic mail transfer in the Internet.  It is intended to

    37    become one member of a related set of four RFCs.  The procedures

    38    defined in the current document are intended to be compatible with a

    39    wide range of key management approaches, including both symmetric

    40    (secret-key) and asymmetric (public-key) approaches for encryption of

    41    data encrypting keys.  Use of symmetric cryptography for message text

    42    encryption and/or integrity check computation is anticipated. RFC

    43    1422 specifies supporting key management mechanisms based on the use

    44    of public-key certificates.  RFC 1423 specifies algorithms, modes,

    45    and associated identifiers relevant to the current RFC and to RFC

    46    1422.  RFC 1424 provides details of paper and electronic formats and

    47    procedures for the key management infrastructure being established in

    48    support of these services.

    49 

    50    Privacy enhancement services (confidentiality, authentication,

    51    message integrity assurance, and non-repudiation of origin) are

    52    offered through the use of end-to-end cryptography between originator

    53    and recipient processes at or above the User Agent level.  No special

    54    processing requirements are imposed on the Message Transfer System at

    55 

    56 

    57 

    58 Linn                                                            [Page 1]

    59 

    60 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

    61 

    62 

    63    endpoints or at intermediate relay sites.  This approach allows

    64    privacy enhancement facilities to be incorporated selectively on a

    65    site-by-site or user-by-user basis without impact on other Internet

    66    entities.  Interoperability among heterogeneous components and mail

    67    transport facilities is supported.

    68 

    69    The current specification's scope is confined to PEM processing

    70    procedures for the RFC-822 textual mail environment, and defines the

    71    Content-Domain indicator value "RFC822" to signify this usage.

    72    Follow-on work in integration of PEM capabilities with other

    73    messaging environments (e.g., MIME) is anticipated and will be

    74    addressed in separate and/or successor documents, at which point

    75    additional Content-Domain indicator values will be defined.

    76 

    77 2.  Terminology

    78 

    79    For descriptive purposes, this RFC uses some terms defined in the OSI

    80    X.400 Message Handling System Model per the CCITT Recommendations.

    81    This section replicates a portion of (1984) X.400's Section 2.2.1,

    82    "Description of the MHS Model: Overview" in order to make the

    83    terminology clear to readers who may not be familiar with the OSI MHS

    84    Model.

    85 

    86    In the [MHS] model, a user is a person or a computer application.  A

    87    user is referred to as either an originator (when sending a message)

    88    or a recipient (when receiving one).  MH Service elements define the

    89    set of message types and the capabilities that enable an originator

    90    to transfer messages of those types to one or more recipients.

    91 

    92    An originator prepares messages with the assistance of his or her

    93    User Agent (UA).  A UA is an application process that interacts with

    94    the Message Transfer System (MTS) to submit messages.  The MTS

    95    delivers to one or more recipient UAs the messages submitted to it.

    96    Functions performed solely by the UA and not standardized as part of

    97    the MH Service elements are called local UA functions.

    98 

    99    The MTS is composed of a number of Message Transfer Agents (MTAs).

   100    Operating together, the MTAs relay messages and deliver them to the

   101    intended recipient UAs, which then make the messages available to the

   102    intended recipients.

   103 

   104    The collection of UAs and MTAs is called the Message Handling System

   105    (MHS).  The MHS and all of its users are collectively referred to as

   106    the Message Handling Environment.

   107 

   108 

   109 

   110 

   111 

   112 

   113 

   114 Linn                                                            [Page 2]

   115 

   116 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   117 

   118 

   119 3.  Services, Constraints, and Implications

   120 

   121    This RFC defines mechanisms to enhance privacy for electronic mail

   122    transferred in the Internet. The facilities discussed in this RFC

   123    provide privacy enhancement services on an end-to-end basis between

   124    originator and recipient processes residing at the UA level or above.

   125    No privacy enhancements are offered for message fields which are

   126    added or transformed by intermediate relay points between PEM

   127    processing components.

   128 

   129    If an originator elects to perform PEM processing on an outbound

   130    message, all PEM-provided security services are applied to the PEM

   131    message's body in its entirety; selective application to portions of

   132    a PEM message is not supported. Authentication, integrity, and (when

   133    asymmetric key management is employed) non-repudiation of origin

   134    services are applied to all PEM messages; confidentiality services

   135    are optionally selectable.

   136 

   137    In keeping with the Internet's heterogeneous constituencies and usage

   138    modes, the measures defined here are applicable to a broad range of

   139    Internet hosts and usage paradigms.  In particular, it is worth

   140    noting the following attributes:

   141 

   142         1.  The mechanisms defined in this RFC are not restricted to a

   143             particular host or operating system, but rather allow

   144             interoperability among a broad range of systems.  All

   145             privacy enhancements are implemented at the application

   146             layer, and are not dependent on any privacy features at

   147             lower protocol layers.

   148 

   149         2.  The defined mechanisms are compatible with non-enhanced

   150             Internet components.  Privacy enhancements are implemented

   151             in an end-to-end fashion which does not impact mail

   152             processing by intermediate relay hosts which do not

   153             incorporate privacy enhancement facilities.  It is

   154             necessary, however, for a message's originator to be

   155             cognizant of whether a message's intended recipient

   156             implements privacy enhancements, in order that encoding and

   157             possible encryption will not be performed on a message whose

   158             destination is not equipped to perform corresponding inverse

   159             transformations.  (Section 4.6.1.1.3 of this RFC describes a

   160             PEM message type ("MIC-CLEAR") which represents a signed,

   161             unencrypted PEM message in a form readable without PEM

   162             processing capabilities yet validatable by PEM-equipped

   163             recipients.)

   164 

   165         3.  The defined mechanisms are compatible with a range of mail

   166             transport facilities (MTAs).  Within the Internet,

   167 

   168 

   169 

   170 Linn                                                            [Page 3]

   171 

   172 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   173 

   174 

   175             electronic mail transport is effected by a variety of SMTP

   176             [2] implementations.  Certain sites, accessible via SMTP,

   177             forward mail into other mail processing environments (e.g.,

   178             USENET, CSNET, BITNET).  The privacy enhancements must be

   179             able to operate across the SMTP realm; it is desirable that

   180             they also be compatible with protection of electronic mail

   181             sent between the SMTP environment and other connected

   182             environments.

   183 

   184         4.  The defined mechanisms are compatible with a broad range of

   185             electronic mail user agents (UAs).  A large variety of

   186             electronic mail user agent programs, with a corresponding

   187             broad range of user interface paradigms, is used in the

   188             Internet.  In order that electronic mail privacy

   189             enhancements be available to the broadest possible user

   190             community, selected mechanisms should be usable with the

   191             widest possible variety of existing UA programs.  For

   192             purposes of pilot implementation, it is desirable that

   193             privacy enhancement processing be incorporable into a

   194             separate program, applicable to a range of UAs, rather than

   195             requiring internal modifications to each UA with which PEM

   196             services are to be provided.

   197 

   198         5.  The defined mechanisms allow electronic mail privacy

   199             enhancement processing to be performed on personal computers

   200             (PCs) separate from the systems on which UA functions are

   201             implemented.  Given the expanding use of PCs and the limited

   202             degree of trust which can be placed in UA implementations on

   203             many multi-user systems, this attribute can allow many users

   204             to process PEM with a higher assurance level than a strictly

   205             UA-integrated approach would allow.

   206 

   207         6.  The defined mechanisms support privacy protection of

   208             electronic mail addressed to mailing lists (distribution

   209             lists, in ISO parlance).

   210 

   211         7.  The mechanisms defined within this RFC are compatible with a

   212             variety of supporting key management approaches, including

   213             (but not limited to) manual pre-distribution, centralized

   214             key distribution based on symmetric cryptography, and the

   215             use of public-key certificates per RFC 1422.  Different

   216             key management mechanisms may be used for different

   217             recipients of a multicast message.  For two PEM

   218             implementations to interoperate, they must share a common

   219             key management mechanism; support for the mechanism defined

   220             in RFC 1422 is strongly encouraged.

   221 

   222 

   223 

   224 

   225 

   226 Linn                                                            [Page 4]

   227 

   228 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   229 

   230 

   231    In order to achieve applicability to the broadest possible range of

   232    Internet hosts and mail systems, and to facilitate pilot

   233    implementation and testing without the need for prior and pervasive

   234    modifications throughout the Internet, the following design

   235    principles were applied in selecting the set of features specified in

   236    this RFC:

   237 

   238         1.  This RFC's measures are restricted to implementation at

   239             endpoints and are amenable to integration with existing

   240             Internet mail protocols at the user agent (UA) level or

   241             above, rather than necessitating modifications to existing

   242             mail protocols or integration into the message transport

   243             system (e.g., SMTP servers).

   244 

   245         2.  The set of supported measures enhances rather than restricts

   246             user capabilities.  Trusted implementations, incorporating

   247             integrity features protecting software from subversion by

   248             local users, cannot be assumed in general.  No mechanisms

   249             are assumed to prevent users from sending, at their

   250             discretion, messages to which no PEM processing has been

   251             applied. In the absence of such features, it appears more

   252             feasible to provide facilities which enhance user services

   253             (e.g., by protecting and authenticating inter-user traffic)

   254             than to enforce restrictions (e.g., inter-user access

   255             control) on user actions.

   256 

   257         3.  The set of supported measures focuses on a set of functional

   258             capabilities selected to provide significant and tangible

   259             benefits to a broad user community.  By concentrating on the

   260             most critical set of services, we aim to maximize the added

   261             privacy value that can be provided with a modest level of

   262             implementation effort.

   263 

   264    Based on these principles, the following facilities are provided:

   265 

   266         1.  disclosure protection,

   267 

   268         2.  originator authenticity,

   269 

   270         3.  message integrity measures, and

   271 

   272         4.  (if asymmetric key management is used) non-repudiation of

   273             origin,

   274 

   275    but the following privacy-relevant concerns are not addressed:

   276 

   277         1.  access control,

   278 

   279 

   280 

   281 

   282 Linn                                                            [Page 5]

   283 

   284 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   285 

   286 

   287         2.  traffic flow confidentiality,

   288 

   289         3.  address list accuracy,

   290 

   291         4.  routing control,

   292 

   293         5.  issues relating to the casual serial reuse of PCs by

   294             multiple users,

   295 

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

   297 

   298         7.  automatic association of acknowledgments with the messages

   299             to which they refer, and

   300 

   301         8.  message duplicate detection, replay prevention, or other

   302             stream-oriented services

   303 

   304 4.  Processing of Messages

   305 

   306 4.1  Message Processing Overview

   307 

   308    This subsection provides a high-level overview of the components and

   309    processing steps involved in electronic mail privacy enhancement

   310    processing.  Subsequent subsections will define the procedures in

   311    more detail.

   312 

   313 4.1.1  Types of Keys

   314 

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

   316 

   317         1.  Data Encrypting Keys (DEKs) are used for encryption of

   318             message text and (with certain choices among a set of

   319             alternative algorithms) for computation of message integrity

   320             check (MIC) quantities.  In the asymmetric key management

   321             environment, DEKs are also used to encrypt the signed

   322             representations of MICs in PEM messages to which

   323             confidentiality has been applied. DEKs are generated

   324             individually for each transmitted message; no

   325             predistribution of DEKs is needed to support PEM

   326             transmission.

   327 

   328         2.  Interchange Keys (IKs) are used to encrypt DEKs for

   329             transmission within messages.  Ordinarily, the same IK will

   330             be used for all messages sent from a given originator to a

   331             given recipient over a period of time.  Each transmitted

   332             message includes a representation of the DEK(s) used for

   333             message encryption and/or MIC computation, encrypted under

   334             an individual IK per named recipient.  The representation is

   335 

   336 

   337 

   338 Linn                                                            [Page 6]

   339 

   340 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   341 

   342 

   343             associated with Originator-ID and Recipient-ID fields

   344             (defined in different forms so as to distinguish symmetric

   345             from asymmetric cases), which allow each individual

   346             recipient to identify the IK used to encrypt DEKs and/or

   347             MICs for that recipient's use.  Given an appropriate IK, a

   348             recipient can decrypt the corresponding transmitted DEK

   349             representation, yielding the DEK required for message text

   350             decryption and/or MIC validation.  The definition of an IK

   351             differs depending on whether symmetric or asymmetric

   352             cryptography is used for DEK encryption:

   353 

   354                  2a. When symmetric cryptography is used for DEK

   355                      encryption, an IK is a single symmetric key shared

   356                      between an originator and a recipient.  In this

   357                      case, the same IK is used to encrypt MICs as well

   358                      as DEKs for transmission.  Version/expiration

   359                      information and IA identification associated with

   360                      the originator and with the recipient must be

   361                      concatenated in order to fully qualify a symmetric

   362                      IK.

   363 

   364                  2b. When asymmetric cryptography is used, the IK

   365                      component used for DEK encryption is the public

   366                      component [8] of the recipient.  The IK component

   367                      used for MIC encryption is the private component of

   368                      the originator, and therefore only one encrypted

   369                      MIC representation need be included per message,

   370                      rather than one per recipient.  Each of these IK

   371                      components can be fully qualified in a Recipient-ID

   372                      or Originator-ID field, respectively.

   373                      Alternatively, an originator's IK component may be

   374                      determined from a certificate carried in an

   375                      "Originator-Certificate:" field.

   376 

   377 4.1.2  Processing Procedures

   378 

   379    When PEM processing is to be performed on an outgoing message, a DEK

   380    is generated [1] for use in message encryption and (if a chosen MIC

   381    algorithm requires a key) a variant of the DEK is formed for use in

   382    MIC computation.  DEK generation can be omitted for the case of a

   383    message where confidentiality is not to be applied, unless a chosen

   384    MIC computation algorithm requires a DEK.  Other parameters (e.g.,

   385    Initialization Vectors (IVs)) as required by selected encryption

   386    algorithms are also generated.

   387 

   388    One or more Originator-ID and/or "Originator-Certificate:" fields are

   389    included in a PEM message's encapsulated header to provide recipients

   390    with an identification component for the IK(s) used for message

   391 

   392 

   393 

   394 Linn                                                            [Page 7]

   395 

   396 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   397 

   398 

   399    processing.  All of a message's Originator-ID and/or "Originator-

   400    Certificate:" fields are assumed to correspond to the same principal;

   401    the facility for inclusion of multiple such fields accomodates the

   402    prospect that different keys, algorithms, and/or certification paths

   403    may be required for processing by different recipients.  When a

   404    message includes recipients for which asymmetric key management is

   405    employed as well as recipients for which symmetric key management is

   406    employed, a separate Originator-ID or "Originator-Certificate:" field

   407    precedes each set of recipients.

   408 

   409    In the symmetric case, per-recipient IK components are applied for

   410    each individually named recipient in preparation of ENCRYPTED, MIC-

   411    ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID-

   412    Symmetric:" field, interpreted in the context of the most recent

   413    preceding "Originator-ID-Symmetric:" field, serves to identify each

   414    IK.  In the asymmetric case, per-recipient IK components are applied

   415    only for ENCRYPTED messages, are independent of originator-oriented

   416    header elements, and are identified by "Recipient-ID-Asymmetric:"

   417    fields.  Each Recipient-ID field is followed by a "Key-Info:" field,

   418    which transfers the message's DEK encrypted under the IK appropriate

   419    for the specified recipient.

   420 

   421    When symmetric key management is used for a given recipient, the

   422    "Key-Info:" field following the corresponding "Recipient-ID-

   423    Symmetric:" field also transfers the message's computed MIC,

   424    encrypted under the recipient's IK. When asymmetric key management is

   425    used, a "MIC-Info:" field associated with an "Originator-ID-

   426    Asymmetric:" or "Originator-Certificate:" field carries the message's

   427    MIC, asymmetrically signed using the private component of the

   428    originator.  If the PEM message is of type ENCRYPTED (as defined in

   429    Section 4.6.1.1.1 of this RFC), the asymmetrically signed MIC is

   430    symmetrically encrypted using the same DEK, algorithm, encryption

   431    mode and other cryptographic parameters as used to encrypt the

   432    message text, prior to inclusion in the "MIC-Info:" field.

   433 

   434 4.1.2.1  Processing Steps

   435 

   436    A four-phase transformation procedure is employed in order to

   437    represent encrypted message text in a universally transmissible form

   438    and to enable messages encrypted on one type of host computer to be

   439    decrypted on a different type of host computer.  A plaintext message

   440    is accepted in local form, using the host's native character set and

   441    line representation.  The local form is converted to a canonical

   442    message text representation, defined as equivalent to the inter-SMTP

   443    representation of message text.  This canonical representation forms

   444    the input to the MIC computation step (applicable to ENCRYPTED, MIC-

   445    ONLY, and MIC-CLEAR messages) and the encryption process (applicable

   446    to ENCRYPTED messages only).

   447 

   448 

   449 

   450 Linn                                                            [Page 8]

   451 

   452 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   453 

   454 

   455    For ENCRYPTED PEM messages, the canonical representation is padded as

   456    required by the encryption algorithm, and this padded canonical

   457    representation is encrypted. The encrypted text (for an ENCRYPTED

   458    message) or the unpadded canonical form (for a MIC-ONLY message) is

   459    then encoded into a printable form.  The printable form is composed

   460    of a restricted character set which is chosen to be universally

   461    representable across sites, and which will not be disrupted by

   462    processing within and between MTS entities. MIC-CLEAR PEM messages

   463    omit the printable encoding step.

   464 

   465    The output of the previous processing steps is combined with a set of

   466    header fields carrying cryptographic control information.  The

   467    resulting PEM message is passed to the electronic mail system to be

   468    included within the text portion of a transmitted message. There is

   469    no requirement that a PEM message comprise the entirety of an MTS

   470    message's text portion; this allows PEM-protected information to be

   471    accompanied by (unprotected) annotations.  It is also permissible for

   472    multiple PEM messages (and associated unprotected text, outside the

   473    PEM message boundaries) to be represented within the encapsulated

   474    text of a higher-level PEM message. PEM message signatures are

   475    forwardable when asymmetric key management is employed; an authorized

   476    recipient of a PEM message with confidentiality applied can reduce

   477    that message to a signed but unencrypted form for forwarding purposes

   478    or can re-encrypt that message for subsequent transmission.

   479 

   480    When a PEM message is received, the cryptographic control fields

   481    within its encapsulated header provide the information required for

   482    each authorized recipient to perform MIC validation and decryption of

   483    the received message text.  For ENCRYPTED and MIC-ONLY messages, the

   484    printable encoding is converted to a bitstring.  Encrypted portions

   485    of the transmitted message are decrypted.  The MIC is validated.

   486    Then, the recipient PEM process converts the canonical representation

   487    to its appropriate local form.

   488 

   489 4.1.2.2  Error Cases

   490 

   491    A variety of error cases may occur and be detected in the course of

   492    processing a received PEM message. The specific actions to be taken

   493    in response to such conditions are local matters, varying as

   494    functions of user preferences and the type of user interface provided

   495    by a particular PEM implementation, but certain general

   496    recommendations are appropriate. Syntactically invalid PEM messages

   497    should be flagged as such, preferably with collection of diagnostic

   498    information to support debugging of incompatibilities or other

   499    failures.  RFC 1422 defines specific error processing requirements

   500    relevant to the certificate-based key management mechanisms defined

   501    therein.

   502 

   503 

   504 

   505 

   506 Linn                                                            [Page 9]

   507 

   508 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   509 

   510 

   511    Syntactically valid PEM messages which yield MIC failures raise

   512    special concern, as they may result from attempted attacks or forged

   513    messages.  As such, it is unsuitable to display their contents to

   514    recipient users without first indicating the fact that the contents'

   515    authenticity and integrity cannot be guaranteed and then receiving

   516    positive user confirmation of such a warning.  MIC-CLEAR messages

   517    (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns,

   518    as MIC failures on such messages may occur for a broader range of

   519    benign causes than are applicable to other PEM message types.

   520 

   521 4.2  Encryption Algorithms, Modes, and Parameters

   522 

   523    For use in conjunction with this RFC, RFC 1423 defines the

   524    appropriate algorithms, modes, and associated identifiers to be used

   525    for encryption of message text with DEKs.

   526 

   527    The mechanisms defined in this RFC incorporate facilities for

   528    transmission of cryptographic parameters (e.g., pseudorandom

   529    Initializing Vectors (IVs)) with PEM messages to which the

   530    confidentiality service is applied, when required by symmetric

   531    message encryption algorithms and modes specified in RFC 1423.

   532 

   533    Certain operations require encryption of DEKs, MICs, and digital

   534    signatures under an IK for purposes of transmission.  A header

   535    facility indicates the mode in which the IK is used for encryption.

   536    RFC 1423 specifies encryption algorithm and mode identifiers and

   537    minimum essential support requirements for key encryption processing.

   538 

   539    RFC 1422 specifies asymmetric, certificate-based key management

   540    procedures based on CCITT Recommendation X.509 to support the message

   541    processing procedures defined in this document. Support for the key

   542    management approach defined in RFC 1422 is strongly recommended.  The

   543    message processing procedures can also be used with symmetric key

   544    management, given prior distribution of suitable symmetric IKs, but

   545    no current RFCs specify key distribution procedures for such IKs.

   546 

   547 4.3  Privacy Enhancement Message Transformations

   548 

   549 4.3.1  Constraints

   550 

   551    An electronic mail encryption mechanism must be compatible with the

   552    transparency constraints of its underlying electronic mail

   553    facilities.  These constraints are generally established based on

   554    expected user requirements and on the characteristics of anticipated

   555    endpoint and transport facilities.  An encryption mechanism must also

   556    be compatible with the local conventions of the computer systems

   557    which it interconnects.  Our approach uses a canonicalization step to

   558    abstract out local conventions and a subsequent encoding step to

   559 

   560 

   561 

   562 Linn                                                           [Page 10]

   563 

   564 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   565 

   566 

   567    conform to the characteristics of the underlying mail transport

   568    medium (SMTP).  The encoding conforms to SMTP constraints.  Section

   569    4.5 of RFC 821 [2] details SMTP's transparency constraints.

   570 

   571    To prepare a message for SMTP transmission, the following

   572    requirements must be met:

   573 

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

   575             set.

   576 

   577         2.  Text lines, delimited by the character pair <CR><LF>, must

   578             be no more than 1000 characters long.

   579 

   580         3.  Since the string <CR><LF>.<CR><LF> indicates the end of a

   581             message, it must not occur in text prior to the end of a

   582             message.

   583 

   584    Although SMTP specifies a standard representation for line delimiters

   585    (ASCII <CR><LF>), numerous systems in the Internet use a different

   586    native representation to delimit lines.  For example, the <CR><LF>

   587    sequences delimiting lines in mail inbound to UNIX systems are

   588    transformed to single <LF>s as mail is written into local mailbox

   589    files.  Lines in mail incoming to record-oriented systems (such as

   590    VAX VMS) may be converted to appropriate records by the destination

   591    SMTP server [3].  As a result, if the encryption process generated

   592    <CR>s or <LF>s, those characters might not be accessible to a

   593    recipient UA program at a destination which uses different line

   594    delimiting conventions.  It is also possible that conversion between

   595    tabs and spaces may be performed in the course of mapping between

   596    inter-SMTP and local format; this is a matter of local option.  If

   597    such transformations changed the form of transmitted ciphertext,

   598    decryption would fail to regenerate the transmitted plaintext, and a

   599    transmitted MIC would fail to compare with that computed at the

   600    destination.

   601 

   602    The conversion performed by an SMTP server at a system with EBCDIC as

   603    a native character set has even more severe impact, since the

   604    conversion from EBCDIC into ASCII is an information-losing

   605    transformation.  In principle, the transformation function mapping

   606    between inter-SMTP canonical ASCII message representation and local

   607    format could be moved from the SMTP server up to the UA, given a

   608    means to direct that the SMTP server should no longer perform that

   609    transformation.  This approach has a major disadvantage: internal

   610    file (e.g., mailbox) formats would be incompatible with the native

   611    forms used on the systems where they reside.  Further, it would

   612    require modification to SMTP servers, as mail would be passed to SMTP

   613    in a different representation than it is passed at present.

   614 

   615 

   616 

   617 

   618 Linn                                                           [Page 11]

   619 

   620 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   621 

   622 

   623 4.3.2  Approach

   624 

   625    Our approach to supporting PEM across an environment in which

   626    intermediate conversions may occur defines an encoding for mail which

   627    is uniformly representable across the set of PEM UAs regardless of

   628    their systems' native character sets.  This encoded form is used (for

   629    specified PEM message types) to represent mail text in transit from

   630    originator to recipient, but the encoding is not applied to enclosing

   631    MTS headers or to encapsulated headers inserted to carry control

   632    information between PEM UAs.  The encoding's characteristics are such

   633    that the transformations anticipated between originator and recipient

   634    UAs will not prevent an encoded message from being decoded properly

   635    at its destination.

   636 

   637    Four transformation steps, described in the following four

   638    subsections, apply to outbound PEM message processing:

   639 

   640 4.3.2.1  Step 1: Local Form

   641 

   642    This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and

   643    MIC-CLEAR.  The message text is created in the system's native

   644    character set, with lines delimited in accordance with local

   645    convention.

   646 

   647 4.3.2.2  Step 2: Canonical Form

   648 

   649    This step is applicable to PEM message types ENCRYPTED, MIC-ONLY, and

   650    MIC-CLEAR.  The message text is converted to a universal canonical

   651    form, similar to the inter-SMTP representation [4] as defined in RFC

   652    821 [2] and RFC 822 [5]. The procedures performed in order to

   653    accomplish this conversion are dependent on the characteristics of

   654    the local form and so are not specified in this RFC.

   655 

   656    PEM canonicalization assures that the message text is represented

   657    with the ASCII character set and "<CR><LF>" line delimiters, but does

   658    not perform the dot-stuffing transformation discussed in RFC 821,

   659    Section 4.5.2.  Since a message is converted to a standard character

   660    set and representation before encryption, a transferred PEM message

   661    can be decrypted and its MIC can be validated at any type of

   662    destination host computer.  Decryption and MIC validation is

   663    performed before any conversions which may be necessary to transform

   664    the message into a destination-specific local form.

   665 

   666 4.3.2.3  Step 3: Authentication and Encryption

   667 

   668    Authentication processing is applicable to PEM message types

   669    ENCRYPTED, MIC-ONLY, and MIC-CLEAR.  The canonical form is input to

   670    the selected MIC computation algorithm in order to compute an

   671 

   672 

   673 

   674 Linn                                                           [Page 12]

   675 

   676 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   677 

   678 

   679    integrity check quantity for the message.  No padding is added to the

   680    canonical form before submission to the MIC computation algorithm,

   681    although certain MIC algorithms will apply their own padding in the

   682    course of computing a MIC.

   683 

   684    Encryption processing is applicable only to PEM message type

   685    ENCRYPTED.  RFC 1423 defines the padding technique used to support

   686    encryption of the canonically-encoded message text.

   687 

   688 4.3.2.4  Step 4: Printable Encoding

   689 

   690    This printable encoding step is applicable to PEM message types

   691    ENCRYPTED and MIC-ONLY.  The same processing is also employed in

   692    representation of certain specifically identified PEM encapsulated

   693    header field quantities as cited in Section 4.6.  Proceeding from

   694    left to right, the bit string resulting from step 3 is encoded into

   695    characters which are universally representable at all sites, though

   696    not necessarily with the same bit patterns (e.g., although the

   697    character "E" is represented in an ASCII-based system as hexadecimal

   698    45 and as hexadecimal C5 in an EBCDIC-based system, the local

   699    significance of the two representations is equivalent).

   700 

   701    A 64-character subset of International Alphabet IA5 is used, enabling

   702    6 bits to be represented per printable character.  (The proposed

   703    subset of characters is represented identically in IA5 and ASCII.)

   704    The character "=" signifies a special processing function used for

   705    padding within the printable encoding procedure.

   706 

   707    To represent the encapsulated text of a PEM message, the encoding

   708    function's output is delimited into text lines (using local

   709    conventions), with each line except the last containing exactly 64

   710    printable characters and the final line containing 64 or fewer

   711    printable characters.  (This line length is easily printable and is

   712    guaranteed to satisfy SMTP's 1000-character transmitted line length

   713    limit.) This folding requirement does not apply when the encoding

   714    procedure is used to represent PEM header field quantities; Section

   715    4.6 discusses folding of PEM encapsulated header fields.

   716 

   717    The encoding process represents 24-bit groups of input bits as output

   718    strings of 4 encoded characters. Proceeding from left to right across

   719    a 24-bit input group extracted from the output of step 3, each 6-bit

   720    group is used as an index into an array of 64 printable characters.

   721    The character referenced by the index is placed in the output string.

   722    These characters, identified in Table 1, are selected so as to be

   723    universally representable, and the set excludes characters with

   724    particular significance to SMTP (e.g., ".", "<CR>", "<LF>").

   725 

   726 

   727 

   728 

   729 

   730 Linn                                                           [Page 13]

   731 

   732 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   733 

   734 

   735    Special processing is performed if fewer than 24 bits are available

   736    in an input group at the end of a message.  A full encoding quantum

   737    is always completed at the end of a message.  When fewer than 24

   738    input bits are available in an input group, zero bits are added (on

   739    the right) to form an integral number of 6-bit groups.  Output

   740    character positions which are not required to represent actual input

   741    data are set to the character "=".  Since all canonically encoded

   742    output is an integral number of octets, only the following cases can

   743    arise: (1) the final quantum of encoding input is an integral

   744    multiple of 24 bits; here, the final unit of encoded output will be

   745    an integral multiple of 4 characters with no "=" padding, (2) the

   746    final quantum of encoding input is exactly 8 bits; here, the final

   747    unit of encoded output will be two characters followed by two "="

   748    padding characters, or (3) the final quantum of encoding input is

   749    exactly 16 bits; here, the final unit of encoded output will be three

   750    characters followed by one "=" padding character.

   751 

   752 

   753    Value Encoding  Value Encoding  Value Encoding  Value Encoding

   754        0 A            17 R            34 i            51 z

   755        1 B            18 S            35 j            52 0

   756        2 C            19 T            36 k            53 1

   757        3 D            20 U            37 l            54 2

   758        4 E            21 V            38 m            55 3

   759        5 F            22 W            39 n            56 4

   760        6 G            23 X            40 o            57 5

   761        7 H            24 Y            41 p            58 6

   762        8 I            25 Z            42 q            59 7

   763        9 J            26 a            43 r            60 8

   764       10 K            27 b            44 s            61 9

   765       11 L            28 c            45 t            62 +

   766       12 M            29 d            46 u            63 /

   767       13 N            30 e            47 v

   768       14 O            31 f            48 w         (pad) =

   769       15 P            32 g            49 x

   770       16 Q            33 h            50 y

   771 

   772                   Printable Encoding Characters

   773                              Table 1

   774 

   775 

   776 4.3.2.5  Summary of Transformations

   777 

   778    In summary, the outbound message is subjected to the following

   779    composition of transformations (or, for some PEM message types, a

   780    subset thereof):

   781 

   782          Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))

   783 

   784 

   785 

   786 Linn                                                           [Page 14]

   787 

   788 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   789 

   790 

   791    The inverse transformations are performed, in reverse order, to

   792    process inbound PEM messages:

   793 

   794        Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))

   795 

   796    Note that the local form and the functions to transform messages to

   797    and from canonical form may vary between the originator and recipient

   798    systems without loss of information.

   799 

   800 4.4  Encapsulation Mechanism

   801 

   802    The encapsulation techniques defined in RFC-934 [6] are adopted for

   803    encapsulation of PEM messages within separate enclosing MTS messages

   804    carrying associated MTS headers. This approach offers a number of

   805    advantages relative to a flat approach in which certain fields within

   806    a single header are encrypted and/or carry cryptographic control

   807    information.  As far as the MTS is concerned, the entirety of a PEM

   808    message will reside in an MTS message's text portion, not the MTS

   809    message's header portion. Encapsulation provides generality and

   810    segregates fields with user-to-user significance from those

   811    transformed in transit.  All fields inserted in the course of

   812    encryption/authentication processing are placed in the encapsulated

   813    header.  This facilitates compatibility with mail handling programs

   814    which accept only text, not header fields, from input files or from

   815    other programs.

   816 

   817    The encapsulation techniques defined in RFC-934 are consistent with

   818    existing Internet mail forwarding and bursting mechanisms.  These

   819    techniques are designed so that they may be used in a nested manner.

   820    The encapsulation techniques may be used to encapsulate one or more

   821    PEM messages for forwarding to a third party, possibly in conjunction

   822    with interspersed (non-PEM) text which serves to annotate the PEM

   823    messages.

   824 

   825    Two encapsulation boundaries (EB's) are defined for delimiting

   826    encapsulated PEM messages and for distinguishing encapsulated PEM

   827    messages from interspersed (non-PEM) text.  The pre-EB is the string

   828    "-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an

   829    encapsulated PEM message follows.  The post-EB is either (1) another

   830    pre-EB indicating that another encapsulated PEM message follows, or

   831    (2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating

   832    that any text that immediately follows is non-PEM text.  A special

   833    point must be noted for the case of MIC-CLEAR messages, the text

   834    portions of which may contain lines which begin with the "-"

   835    character and which are therefore subject to special processing per

   836    RFC-934 forwarding procedures.  When the string "- " must be

   837    prepended to such a line in the course of a forwarding operation in

   838    order to distinguish that line from an encapsulation boundary, MIC

   839 

   840 

   841 

   842 Linn                                                           [Page 15]

   843 

   844 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   845 

   846 

   847    computation is to be performed prior to prepending the "- " string.

   848    Figure 1 depicts the encapsulation of a single PEM message.

   849 

   850    This RFC places no a priori limits on the depth to which such

   851    encapsulation may be nested nor on the number of PEM messages which

   852    may be grouped in this fashion at a single nesting level for

   853    forwarding.  A implementation compliant with this RFC must not

   854    preclude a user from submitting or receiving PEM messages which

   855    exploit this encapsulation capability.  However, no specific

   856    requirements are levied upon implementations with regard to how this

   857    capability is made available to the user.  Thus, for example, a

   858    compliant PEM implementation is not required to automatically detect

   859    and process encapsulated PEM messages.

   860 

   861    In using this encapsulation facility, it is important to note that it

   862    is inappropriate to forward directly to a third party a message that

   863    is ENCRYPTED because recipients of such a message would not have

   864    access to the DEK required to decrypt the message.  Instead, the user

   865    forwarding the message must transform the ENCRYPTED message into a

   866    MIC-ONLY or MIC-CLEAR form prior to forwarding.  Thus, in order to

   867    comply with this RFC, a PEM implementation must provide a facility to

   868    enable a user to perform this transformation, while preserving the

   869    MIC associated with the original message.

   870 

   871    If a user wishes PEM-provided confidentiality protection for

   872    transmitted information, such information must occur in the

   873    encapsulated text of an ENCRYPTED PEM message, not in the enclosing

   874    MTS header or PEM encapsulated header. If a user wishes to avoid

   875 

   876 

   877 

   878 

   879 

   880 

   881 

   882 

   883 

   884 

   885 

   886 

   887 

   888 

   889 

   890 

   891 

   892 

   893 

   894 

   895 

   896 

   897 

   898 Linn                                                           [Page 16]

   899 

   900 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   901 

   902 

   903    Encapsulated Message

   904 

   905        Pre-Encapsulation Boundary (Pre-EB)

   906            -----BEGIN PRIVACY-ENHANCED MESSAGE-----

   907 

   908        Encapsulated Header Portion

   909            (Contains encryption control fields inserted in plaintext.

   910            Examples include "DEK-Info:" and "Key-Info:".

   911            Note that, although these control fields have line-oriented

   912            representations similar to RFC 822 header fields, the set

   913            of fields valid in this context is disjoint from those used

   914            in RFC 822 processing.)

   915 

   916        Blank Line

   917            (Separates Encapsulated Header from subsequent

   918            Encapsulated Text Portion)

   919 

   920        Encapsulated Text Portion

   921            (Contains message data encoded as specified in Section 4.3.)

   922 

   923        Post-Encapsulation Boundary (Post-EB)

   924            -----END PRIVACY-ENHANCED MESSAGE-----

   925 

   926 

   927                    Encapsulated Message Format

   928                             Figure 1

   929 

   930 

   931    disclosing the actual subject of a message to unintended parties, it

   932    is suggested that the enclosing MTS header contain a "Subject:" field

   933    indicating that "Encrypted Mail Follows".

   934 

   935    If an integrity-protected representation of information which occurs

   936    within an enclosing header (not necessarily in the same format as

   937    that in which it occurs within that header) is desired, that data can

   938    be included within the encapsulated text portion in addition to its

   939    inclusion in the enclosing MTS header.  For example, an originator

   940    wishing to provide recipients with a protected indication of a

   941    message's position in a series of messages could include within the

   942    encapsulated text a copy of a timestamp or message counter value

   943    possessing end-to-end significance and extracted from an enclosing

   944    MTS header field.  (Note: mailbox specifiers as entered by end users

   945    incorporate local conventions and are subject to modification at

   946    intermediaries, so inclusion of such specifiers within encapsulated

   947    text should not be regarded as a suitable alternative to the

   948    authentication semantics defined in RFC 1422 and based on X.500

   949    Distinguished Names.) The set of header information (if any) included

   950    within the encapsulated text of messages is a local matter, and this

   951 

   952 

   953 

   954 Linn                                                           [Page 17]

   955 

   956 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

   957 

   958 

   959    RFC does not specify formatting conventions to distinguish replicated

   960    header fields from other encapsulated text.

   961 

   962 4.5  Mail for Mailing Lists

   963 

   964    When mail is addressed to mailing lists, two different methods of

   965    processing can be applicable: the IK-per-list method and the IK-per-

   966    recipient method.  Hybrid approaches are also possible, as in the

   967    case of IK-per-list protection of a message on its path from an

   968    originator to a PEM-equipped mailing list exploder, followed by IK-

   969    per-recipient protection from the exploder to individual list

   970    recipients.

   971 

   972    If a message's originator is equipped to expand a destination mailing

   973    list into its individual constituents and elects to do so (IK-per-

   974    recipient), the message's DEK (and, in the symmetric key management

   975    case, MIC) will be encrypted under each per-recipient IK and all such

   976    encrypted representations will be incorporated into the transmitted

   977    message.  Note that per-recipient encryption is required only for the

   978    relatively small DEK and MIC quantities carried in the "Key-Info:"

   979    field, not for the message text which is, in general, much larger.

   980    Although more IKs are involved in processing under the IK-per-

   981    recipient method, the pairwise IKs can be individually revoked and

   982    possession of one IK does not enable a successful masquerade of

   983    another user on the list.

   984 

   985    If a message's originator addresses a message to a list name or

   986    alias, use of an IK associated with that name or alias as a entity

   987    (IK-per-list), rather than resolution of the name or alias to its

   988    constituent destinations, is implied. Such an IK must, therefore, be

   989    available to all list members. Unfortunately, it implies an

   990    undesirable level of exposure for the shared IK, and makes its

   991    revocation difficult.  Moreover, use of the IK-per-list method allows

   992    any holder of the list's IK to masquerade as another originator to

   993    the list for authentication purposes.

   994 

   995    Pure IK-per-list key management in the asymmetric case (with a common

   996    private key shared among multiple list members) is particularly

   997    disadvantageous in the asymmetric environment, as it fails to

   998    preserve the forwardable authentication and non-repudiation

   999    characteristics which are provided for other messages in this

  1000    environment.  Use of a hybrid approach with a PEM-capable exploder is

  1001    therefore particularly recommended for protection of mailing list

  1002    traffic when asymmetric key management is used; such an exploder

  1003    would reduce (per discussion in Section 4.4 of this RFC) incoming

  1004    ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before forwarding

  1005    them (perhaps re-encrypted under individual, per-recipient keys) to

  1006    list members.

  1007 

  1008 

  1009 

  1010 Linn                                                           [Page 18]

  1011 

  1012 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

  1013 

  1014 

  1015 4.6  Summary of Encapsulated Header Fields

  1016 

  1017    This section defines the syntax and semantics of the encapsulated

  1018    header fields to be added to messages in the course of privacy

  1019    enhancement processing.

  1020 

  1021    The fields are presented in three groups.  Normally, the groups will

  1022    appear in encapsulated headers in the order in which they are shown,

  1023    though not all fields in each group will appear in all messages.  The

  1024    following figures show the appearance of small example encapsulated

  1025    messages.  Figure 2 assumes the use of symmetric cryptography for key

  1026    management.  Figure 3 illustrates an example encapsulated ENCRYPTED

  1027    message in which asymmetric key management is used.

  1028 

  1029 

  1030    -----BEGIN PRIVACY-ENHANCED MESSAGE-----

  1031    Proc-Type: 4,ENCRYPTED

  1032    Content-Domain: RFC822

  1033    DEK-Info: DES-CBC,F8143EDE5960C597

  1034    Originator-ID-Symmetric: linn@zendia.enet.dec.com,,

  1035    Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3

  1036    Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,

  1037              B70665BB9BF7CBCDA60195DB94F727D3

  1038    Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4

  1039    Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,

  1040              E2EF532C65CBCFF79F83A2658132DB47

  1041 

  1042    LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M

  1043    8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk

  1044    J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot

  1045    dXd/H5LMDWnonNvPCwQUHt==

  1046    -----END PRIVACY-ENHANCED MESSAGE-----

  1047 

  1048           Example Encapsulated Message (Symmetric Case)

  1049                             Figure 2

  1050 

  1051 

  1052    Figure 4 illustrates an example encapsulated MIC-ONLY message in

  1053    which asymmetric key management is used; since no per-recipient keys

  1054    are involved in preparation of asymmetric-case MIC-ONLY messages,

  1055    this example should be processable for test purposes by arbitrary PEM

  1056    implementations.

  1057 

  1058    Fully-qualified domain names (FQDNs) for hosts, appearing in the

  1059    mailbox names found in entity identifier subfields of "Originator-

  1060    ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed in

  1061    a case-insensitive fashion.  Unless specified to the contrary, other

  1062    field arguments (including the user name components of mailbox names)

  1063 

  1064 

  1065 

  1066 Linn                                                           [Page 19]

  1067 

  1068 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

  1069 

  1070 

  1071    are to be processed in a case-sensitive fashion.

  1072 

  1073    In most cases, numeric quantities are represented in header fields as

  1074    contiguous strings of hexadecimal digits, where each digit is

  1075    represented by a character from the ranges "0"-"9" or upper case

  1076    "A"-"F".  Since public-key certificates and quantities encrypted

  1077 

  1078 

  1079 

  1080 

  1081 

  1082 

  1083 

  1084 

  1085 

  1086 

  1087 

  1088 

  1089 

  1090 

  1091 

  1092 

  1093 

  1094 

  1095 

  1096 

  1097 

  1098 

  1099 

  1100 

  1101 

  1102 

  1103 

  1104 

  1105 

  1106 

  1107 

  1108 

  1109 

  1110 

  1111 

  1112 

  1113 

  1114 

  1115 

  1116 

  1117 

  1118 

  1119 

  1120 

  1121 

  1122 Linn                                                           [Page 20]

  1123 

  1124 RFC 1421        Privacy Enhancement for Electronic Mail    February 1993

  1125 

  1126 

  1127    -----BEGIN PRIVACY-ENHANCED MESSAGE-----

  1128    Proc-Type: 4,ENCRYPTED

  1129    Content-Domain: RFC822

  1130    DEK-Info: DES-CBC,BFF968AA74691AC1

  1131    Originator-Certificate:

  1132     MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV

  1133     BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN

  1134     BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx

  1135     CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU