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