rfc1422.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                            S. Kent
Request for Comments: 1422                                           BBN
Obsoletes: 1114                                  IAB IRTF PSRG, IETF PEM
                                                           February 1993


           Privacy Enhancement for Internet Electronic Mail:
               Part II: Certificate-Based Key Management

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Acknowledgements

   This memo is the outgrowth of a series of meetings of the Privacy and
   Security Research Group of the Internet Research Task Force (IRTF)
   and the Privacy-Enhanced Electronic Mail Working Group of the
   Internet Engineering Task Force (IETF).  I would like to thank the
   members of the PSRG and the PEM WG for their comments and
   contributions at the meetings which led to the preparation of this
   document.  I also would like to thank contributors to the PEM-DEV
   mailing list who have provided valuable input which is reflected in
   this memo.

1.  Executive Summary

   This is one of a series of documents defining privacy enhancement
   mechanisms for electronic mail transferred using Internet mail
   protocols.  RFC 1421 [6] prescribes protocol extensions and
   processing procedures for RFC-822 mail messages, given that suitable
   cryptographic keys are held by originators and recipients as a
   necessary precondition.  RFC 1423 [7] specifies algorithms, modes and
   associated identifiers for use in processing privacy-enhanced
   messages, as called for in RFC 1421 and this document.  This document
   defines a supporting key management architecture and infrastructure,
   based on public-key certificate techniques, to provide keying
   information to message originators and recipients.  RFC 1424 [8]
   provides additional specifications for services in conjunction with
   the key management infrastructure described herein.

   The key management architecture described in this document is
   compatible with the authentication framework described in CCITT 1988
   X.509 [2].  This document goes beyond X.509 by establishing



Kent                                                            [Page 1]

RFC 1422           Certificate-Based Key Management        February 1993


   procedures and conventions for a key management infrastructure for
   use with Privacy Enhanced Mail (PEM) and with other protocols, from
   both the TCP/IP and OSI suites, in the future.  There are several
   motivations for establishing these procedures and conventions (as
   opposed to relying only on the very general framework outlined in
   X.509):

       -It is important that a certificate management infrastructure
           for use in the Internet community accommodate a range of
           clearly-articulated certification policies for both users
           and   organizations in a well-architected fashion.
           Mechanisms must be provided to enable each user to be
           aware of the policies governing any certificate which the
           user may encounter.  This requires the introduction
           and standardization of procedures and conventions that are
           outside the scope of X.509.

       -The procedures for authenticating originators and recipient in
           the course of message submission and delivery should be
           simple, automated and uniform despite the existence of
           differing certificate management policies.  For example,
           users should not have to engage in careful examination of a
           complex set of certification relationships in order to
           evaluate the credibility of a claimed identity.

       -The authentication framework defined by X.509 is designed to
           operate in the X.500 directory server environment.  However
           X.500 directory servers are not expected to be ubiquitous
           in the Internet in the near future, so some conventions
           are adopted to facilitate operation of the key management
           infrastructure in the near term.

       -Public key cryptosystems are central to the authentication
           technology of X.509 and those which enjoy the most
           widespread use are patented in the U.S.  Although this
           certification management scheme is compatible with
           the use of different digital signature algorithms, it is
           anticipated that the RSA cryptosystem will be used as
           the primary signature algorithm in establishing the
           Internet certification hierarchy.  Special license
           arrangements have been made to facilitate the
           use of this algorithm in the U.S. portion of Internet
           environment.

   The infrastructure specified in this document establishes a single
   root for all certification within the Internet, the Internet Policy
   Registration Authority (IPRA).  The IPRA establishes global policies,
   described in this document, which apply to all certification effected



Kent                                                            [Page 2]

RFC 1422           Certificate-Based Key Management        February 1993


   under this hierarchy.  Beneath IPRA root are Policy Certification
   Authorities (PCAs), each of which establishes and publishes (in the
   form of an informational RFC) its policies for registration of users
   or organizations.  Each PCA is certified by the IPRA. (It is
   desirable that there be a relatively small number of PCAs, each with
   a substantively different policy, to facilitate user familiarity with
   the set of PCA policies.  However there is no explicit requirement
   that the set of PCAs be limited in this fashion.)  Below PCAs,
   Certification Authorities (CAs) will be established to certify users
   and subordinate organizational entities (e.g., departments, offices,
   subsidiaries, etc.).  Initially, we expect the majority of users will
   be registered via organizational affiliation, consistent with current
   practices for how most user mailboxes are provided.  In this sense
   the registration is analogous to the issuance of a university or
   company ID card.

   Some CAs are expected to provide certification for residential users
   in support of users who wish to register independent of any
   organizational affiliation.  Over time, we anticipate that civil
   government entities which  already provide analogous identification
   services in other contexts, e.g.,  driver's licenses, may provide
   this service.  For users who wish anonymity while taking advantage of
   PEM privacy facilities, one or more PCAs will be established with
   policies that allow for registration of users, under subordinate CAs,
   who do not wish to disclose their identities.

2.  Overview of Approach

   This document defines a key management architecture based on the use
   of public-key certificates, primarily in support of the message
   encipherment and authentication procedures defined in RFC 1421.  The
   concept of public-key certificates is defined in X.509 and this
   architecture is a compliant subset of that envisioned in X.509.

   Briefly, a (public-key) certificate is a data structure which
   contains the name of a user (the "subject"), the public component
   (This document adopts 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.)  of that user, and the name of an
   entity (the "issuer") which vouches that the public component is
   bound to the named user.  This data, along with a time interval over
   which the binding is claimed to be valid, is cryptographically signed
   by the issuer using the issuer's private component.  The subject and
   issuer names in certificates are Distinguished Names (DNs) as defined
   in the directory system (X.500).



Kent                                                            [Page 3]

RFC 1422           Certificate-Based Key Management        February 1993


   Once signed, certificates can be stored in directory servers,
   transmitted via non-secure message exchanges, or distributed via any
   other means that make certificates easily accessible to message
   system users, without regard for the security of the transmission
   medium.  Certificates are used in PEM to provide the originator of a
   message with the (authenticated) public component of each recipient
   and to provide each recipient with the (authenticated) public
   component of the originator.  The following brief discussion
   illustrates the procedures for both originator and recipients.

   Prior to sending an encrypted message (using PEM), an originator must
   acquire a certificate for each recipient and must validate these
   certificates.  Briefly, validation is performed by checking the
   digital signature in the certificate, using the public component of
   the issuer whose private component was used to sign the certificate.
   The issuer's public component is made available via some out of band
   means (for the IPRA) or is itself distributed in a certificate to
   which this validation procedure is applied recursively.  In the
   latter case, the issuer of a user's certificate becomes the subject
   in a certificate issued by another certifying authority (or a PCA),
   thus giving rise to a certification hierarchy.  The validity interval
   for each certificate is checked and Certificate Revocation Lists
   (CRLs) are checked to ensure that none of the certificates employed
   in the validation process has been revoked by an issuer.

   Once a certificate for a recipient is validated, the public component
   contained in the certificate is extracted and used to encrypt the
   data encryption key (DEK), which, in turn, is used to encrypt the
   message itself.  The resulting encrypted DEK is incorporated into the
   Key-Info field of the message header.  Upon receipt of an encrypted
   message, a recipient employs his private component to decrypt this
   field, extracting the DEK, and then uses this DEK to decrypt the
   message.

   In order to provide message integrity and data origin authentication,
   the originator generates a message integrity code (MIC), signs
   (encrypts) the MIC using the private component of his public-key
   pair, and includes the resulting value in the message header in the
   MIC-Info field.  The certificate of the originator is (optionally)
   included in the header in the Certificate field as described in RFC
   1421.  This is done in order to facilitate validation in the absence
   of ubiquitous directory services.  Upon receipt of a privacy enhanced
   message, a recipient validates the originator's certificate (using
   the IPRA public component as the root of a certification path),
   checks to ensure that it has not been revoked, extracts the public
   component from the certificate, and uses that value to recover
   (decrypt) the MIC.  The recovered MIC is compared against the locally
   calculated MIC to verify the integrity and data origin authenticity



Kent                                                            [Page 4]

RFC 1422           Certificate-Based Key Management        February 1993


   of the message.

3.  Architecture

   3.1  Scope and Restrictions

   The architecture described below is intended to provide a basis for
   managing public-key cryptosystem values in support of privacy
   enhanced electronic mail in the Internet environment.  The
   architecture describes procedures for registering certification
   authorities and users, for generating and distributing certificates,
   and for generating and distributing CRLs.  RFC 1421 describes the
   syntax and semantics of header fields used to transfer certificates
   and to represent the DEK and MIC in this public-key context.
   Definitions of the algorithms, modes of use and associated
   identifiers are separated in RFC 1423 to facilitate the adoption of
   additional algorithms in the future.  This document focuses on the
   management aspects of certificate-based, public-key cryptography for
   privacy enhanced mail.

   The proposed architecture imposes conventions for the certification
   hierarchy which are not strictly required by the X.509 recommendation
   nor by the technology itself.  These conventions are motivated by
   several factors, primarily the need for authentication semantics
   compatible with automated validation and the automated determination