rfc1114.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,242 行 · 第 1/5 页

Network Working Group                                            S. Kent
Request for Comments:  1114                                        BBNCC
                                                                 J. Linn
                                                                     DEC
                                                  IAB Privacy Task Force
                                                             August 1989


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

STATUS OF THIS MEMO

   This RFC suggests a draft standard elective 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.  We would like to thank the members of the Privacy Task
   Force for their comments and contributions at the meetings which led
   to the preparation of this RFC: David Balenson, Curt Barker, Matt
   Bishop, Morrie Gasser, Russ Housley, Dan Nessett, Mike Padlipsky, Rob
   Shirey, and Steve Wilbur.

Table of Contents

   1.  Executive Summary                                               2
   2.  Overview of Approach                                            3
   3.  Architecture                                                    4
   3.1  Scope and Restrictions                                         4
   3.2  Relation to X.509 Architecture                                 7
   3.3  Entities' Roles and Responsibilities                           7
   3.3.1  Users and User Agents                                        8
   3.3.2  Organizational Notaries                                      9
   3.3.3  Certification Authorities                                   11
   3.3.3.1  Interoperation Across Certification Hierarchy Boundaries  14
   3.3.3.2  Certificate Revocation                                    15
   3.4  Certificate Definition and Usage                              17
   3.4.1  Contents and Use                                            17
   3.4.1.1  Version Number                                            18
   3.4.1.2  Serial Number                                             18
   3.4.1.3  Subject Name                                              18
   3.4.1.4  Issuer Name                                               19
   3.4.1.5  Validity Period                                           19
   3.4.1.6  Subject Public Component                                  20



Kent & Linn                                                     [Page 1]

RFC 1114              Mail Privacy: Key Management           August 1989


   3.4.1.7  Certificate Signature                                     20
   3.4.2  Validation Conventions                                      20
   3.4.3  Relation with X.509 Certificate Specification               22
   NOTES                                                              24

1.  Executive Summary

   This is one of a series of RFCs defining privacy enhancement
   mechanisms for electronic mail transferred using Internet mail
   protocols.  RFC-1113 (the successor to RFC 1040) 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-1115 specifies
   algorithms for use in processing privacy-enhanced messages, as called
   for in RFC-1113.  This RFC defines a supporting key management
   architecture and infrastructure, based on public-key certificate
   techniques, to provide keying information to message originators and
   recipients.  A subsequent RFC, the fourth in this series, will
   provide detailed specifications, paper and electronic application
   forms, etc. for the key management infrastructure described herein.

   The key management architecture described in this RFC is compatible
   with the authentication framework described in X.509.  The major
   contributions of this RFC lie not in the specification of computer
   communication protocols or algorithms but rather in procedures and
   conventions for the key management infrastructure.  This RFC
   incorporates numerous conventions to facilitate near term
   implementation.  Some of these conventions may be superceded in time
   as the motivations for them no longer apply, e.g., when X.500 or
   similar directory servers become well established.

   The RSA cryptographic algorithm, covered in the U.S. by patents
   administered through RSA Data Security, Inc. (hereafter abbreviated
   RSADSI) has been selected for use in this key management system.
   This algorithm has been selected because it provides all the
   necessary algorithmic facilities, is "time tested" and is relatively
   efficient to implement in either software or hardware.  It is also
   the primary algorithm identified (at this time) for use in
   international standards where an asymmetric encryption algorithm is
   required.  Protocol facilities (e.g., algorithm identifiers) exist to
   permit use of other asymmetric algorithms if, in the future, it
   becomes appropriate to employ a different algorithm for key
   management.  However, the infrastructure described herein is specific
   to use of the RSA algorithm in many respects and thus might be
   different if the underlying algorithm were to change.

   Current plans call for RSADSI to act in concert with subscriber
   organizations as a "certifying authority" in a fashion described



Kent & Linn                                                     [Page 2]

RFC 1114              Mail Privacy: Key Management           August 1989


   later in this RFC.  RSADSI will offer a service in which it will sign
   a certificate which has been generated by a user and vouched for
   either by an organization or by a Notary Public.  This service will
   carry a $25 biennial fee which includes an associated license to use
   the RSA algorithm in conjunction with privacy protection of
   electronic mail.  Users who do not come under the purview of the RSA
   patent, e.g., users affiliated with the U.S. government or users
   outside of the U.S., may make use of different certifying authorities
   and will not require a license from RSADSI.  Procedures for
   interacting with these other certification authorities, maintenance
   and distribution of revoked certificate lists from such authorities,
   etc. are outside the scope of this RFC.  However, techniques for
   validating certificates issued by other authorities are contained
   within the RFC to ensure interoperability across the resulting
   jurisdictional boundaries.

2.  Overview of Approach

   This RFC defines a key management architecture based on the use of
   public-key certificates, in support of the message encipherment and
   authentication procedures defined in RFC-1113.  In the proposed
   architecture, a "certification authority" representing an
   organization applies a digital signature to a collection of data
   consisting of a user's public component, various information that
   serves to identify the user, and the identity of the organization
   whose signature is affixed.  (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 publically
   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.)  This establishes a binding between these user
   credentials, the user's public component and the organization which
   vouches for this binding.  The resulting signed, data item is called
   a certificate.  The organization identified as the certifying
   authority for the certificate is the "issuer" of that certificate.

   In signing the certificate, the certification authority vouches for
   the user's identification, especially as it relates to the user's
   affiliation with the organization.  The digital signature is affixed
   on behalf of that organization and is in a form which can be
   recognized by all members of the privacy-enhanced electronic mail
   community.  Once generated, certificates can be stored in directory
   servers, transmitted via unsecure message exchanges, or distributed
   via any other means that make certificates easily accessible to
   message originators, without regard for the security of the
   transmission medium.




Kent & Linn                                                     [Page 3]

RFC 1114              Mail Privacy: Key Management           August 1989


   Prior to sending an encrypted message, 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
   (described later) or is itself distributed in a certificate to which
   this validation procedure is applied recursively.

   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) that is used to encrypt the message itself.

   The resulting encrypted DEK is incorporated into the X-Key-Info field
   of the message header.  Upon receipt of an encrypted message, a
   recipient employs his secret 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 secret component of his public-key pair,
   and includes the resulting value in the message header in the X-MIC-
   Info field.  The certificate of the originator is also included in
   the header in the X-Certificate field as described in RFC-1113, 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, 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 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 (see RFC-1113) in the Internet environment.
   The architecture describes procedures for ordering certificates from
   issuers, for generating and distributing certificates, and for "hot
   listing" of revoked certificates.  Concurrent with the issuance of
   this RFC, RFC 1040 has been updated and reissued as RFC-1113 to
   describe the syntax and semantics of new or revised header fields
   used to transfer certificates, represent the DEK and MIC in this
   public-key context, and to segregate algorithm definitions into a
   separate RFC to facilitate the addition of other algorithms in the
   future.  This RFC focuses on the management aspects of certificate-



Kent & Linn                                                     [Page 4]

RFC 1114              Mail Privacy: Key Management           August 1989


   based, public-key cryptography for privacy enhanced mail while RFC-
   1113 addresses representation and processing aspects of such mail,
   including changes required by this key management technology.

   The proposed architecture imposes conventions for certification paths
   which are not strictly required by the X.509 recommendation nor by
   the technology itself.  The decision to impose these conventions is
   based in part on constraints imposed by the status of the RSA
   cryptosystem within the U.S. as a patented algorithm, and in part on
   the need for an organization to assume operational responsibility for
   certificate management in the current (minimal) directory system
   infrastructure for electronic mail.  Over time, we anticipate that
   some of these constraints, e.g., directory service availability, will
   change and the procedures specified in the RFC will be reviewed and
   modified as appropriate.

   At this time, we propose a system in which user certificates
   represent the leaves in a shallow (usually two tier) certification
   hierarchy (tree).  Organizations which act as issuers are represented