NOTES

     [1]  Key generation for MIC computation and message text encryption
          may either be performed by the sending host or by a
          centralized server.  This RFC does not constrain this design
          alternative.  Section 5.1 identifies possible advantages of a
          centralized server approach if symmetric key management is
          employed.

     [2]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
          RFC 821, August 1982.

     [3]  This transformation should occur only at an SMTP endpoint, not
          at an intervening relay, but may take place at a gateway
          system linking the SMTP realm with other environments.

     [4]  Use of a canonicalization procedure similar to that of SMTP
          was selected because its functions are widely used and
          implemented within the Internet mail community, not for
          purposes of SMTP interoperability with this intermediate
          result.

     [5]  Crocker, D., "Standard for the Format of ARPA Internet Text
          Messages", STD 11, RFC 822, August 1982.

     [6]  Rose, M. T. and Stefferud, E. A., "Proposed Standard for
          Message Encapsulation", RFC 934, January 1985.

     [7]  CCITT Recommendation X.509 (1988), "The Directory -
          Authentication Framework".

     [8]  Throughout this RFC we have adopted the terms "private
          component" and "public component" to refer to the quantities
          which are, respectively, kept secret and made publicly
          available in asymmetric cryptosystems.  This convention is
          adopted to avoid possible confusion arising from use of the
          term "secret key" to refer to either the former quantity or to
          a key in a symmetric cryptosystem.