draft-ietf-pkix-ipki-new-rfc2527-01.txt

PKIX的RFC英文文档

PKIX Working Group            S. Chokhani  (CygnaCom Solutions, Inc.)
Internet Draft                W. Ford      (VeriSign, Inc.)
                              R. Sabett    (Cooley Godward LLP) 
                              C. Merrill   (McCarter & English, LLP) 
                              S. Wu        (Infoliance, Inc.)
                                                                
Expires in six months from                            January 3, 2002

             Internet X.509 Public Key Infrastructure

      Certificate Policy and Certification Practices Framework

             < draft-ietf-pkix-ipki-new-rfc2527-01.txt >

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.  Internet-Drafts are working documents of 
the Internet Engineering Task Force (IETF), its areas, and its working 
groups.  Note that other groups may also distribute working documents 
as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of 6 months 
and may be updated, replaced, or may become obsolete by other 
documents at any time.  It is inappropriate to use Internet-Drafts 
as reference material or to cite them other than as work in 
progress.

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

To view the entire list of current Internet-Drafts, please check the 
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Copyright (C) The Internet Society 2001. All Rights Reserved.
 
Abstract

This document presents a framework to assist the writers of 
certificate policies or certification practice statements for 
participants within public key infrastructures, such as 
certification authorities, policy authorities, and communities of 
interest that wish to rely on certificates.  In particular, the 
framework provides a comprehensive list of topics that potentially 
(at the writer's discretion) need to be covered in a certificate 
policy or a certification practice statement.  This document is 
being submitted to the RFC Editor with a request for publication as 
an Informational RFC that will supercede RFC 2527 [CPF].

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 1]

                     TABLE OF CONTENTS
1.	INTRODUCTION							 3
1.1		BACKGROUND							 3
1.2  		PURPOSE							 5
1.3  		SCOPE								 5
2.	DEFINITIONS								 6
3.	CONCEPTS								 8
3.1		CERTIFICATE POLICY					 8
3.2		CERTIFICATE POLICY EXAMPLES				10
3.3		X.509 CERTIFICATE FIELDS				10
3.3.1			Certificate Policies Extension		10
3.3.2			Policy Mappings Extension			11
3.3.3			Policy Constraints Extension			12
3.3.4			Policy Qualifiers					12
3.4		CERTIFICATION PRACTICE STATEMENT			13
3.5		RELATIONSHIP BETWEEN CP AND CPS			14
3.6		RELATIONSHIP AMONG CPs, CPSs, AGREEMENTS, AND 
				OTHER DOCUMENTS				15
3.7		SET OF PROVISIONS						17
4.	CONTENTS OF A SET OF PROVISIONS				19
4.1		INTRODUCTION						19
4.1.1			Overview						19
4.1.2  		Document Name and Identification		20
4.1.3			PKI Participants					20
4.1.4			Certificate usage					21
4.1.5			Policy Administration				21
4.1.6			Definitions and acronyms			21
4.2		PUBLICATION AND REPOSITORY RESPONSIBILITIES	21
4.3		IDENTIFICATION AND AUTHENTICATION (I&A)		22
4.3.1			Naming						22
4.3.2			Initial Identity Validation			22
4.3.3			I&A for Re-key Requests				23
4.3.4			I&A for Revocation Requests			23
4.4		CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS	24
4.4.1			Certificate Application				24
4.4.2			Certificate Application Processing		24
4.4.3			Certificate Issuance				24
4.4.4			Certificate Acceptance				25
4.4.5			Key Pair and Certificate Usage		25
4.4.6			Certificate Renewal				26
4.4.7			Certificate Re-key				26
4.4.8			Certificate Modification			27
4.4.9			Certificate Revocation and Suspension	27
4.4.10		Certificate Status Services			28
4.4.11		End of Subscription				28
4.4.12		Key Escrow and Recovery				29
4.5		FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS  29
4.5.1			Physical Security Controls			29
4.5.2			Procedural Controls				30
4.5.3			Personnel Controls				30
4.5.4			Audit Logging Procedures			31
4.5.5			Records Archival					31
4.5.6			Key Changeover					32
4.5.7			Compromise and Disaster Recovery		32
4.5.8			CA or RA Termination				33

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 2]
4.6		TECHNICAL SECURITY CONTROLS				33
4.6.1			Key Pair Generation and Installation	33
4.6.2			Private Key Protection and Cryptographic 
			 Module Engineering Controls			34
4.6.3			Other Aspects of Key Pair Management	36
4.6.4			Activation Data					36
4.6.5			Computer Security Controls			36
4.6.6			Life Cycle Security Controls			37
4.6.7			Network Security Controls			37
4.6.8			Timestamping					37
4.7		CERTIFICATE, CRL, AND OCSP PROFILES			37
4.7.1			Certificate Profile				37
4.7.2			CRL Profile						38
4.7.3			OCSP Profile					38
4.8		COMPLIANCE AUDIT AND OTHER ASSESSMENT		38
4.9		OTHER BUSINESS AND LEGAL MATTERS			39
4.9.1			Fees							40
4.9.2			Financial Responsibility			40
4.9.3			Confidentiality of Business Information	40
4.9.4			Privacy of Personal Information		41
4.9.5			Intellectual Property Rights			41
4.9.6			Representations and Warranties		41
4.9.7			Disclaimers of Warranties			42
4.9.8			Limitations of Liability			42
4.9.9			Indemnities						42
4.9.10		Term and Termination				42
4.9.11		Individual notices and communications
				with participants				43
4.9.12		Amendments						43
4.9.13		Dispute Resolution Procedures			44
4.9.14		Governing Law					44
4.9.15		Compliance with Applicable Law		44
4.9.16		Miscellaneous Provisions			44
4.9.17		Other Provisions					45
5.	OUTLINE OF A SET OF PROVISIONS				45
6.	ACKNOWLEDGMENTS							51
7.	REFERENCES								52
8.	AUTHORS' ADDRESSES						53
	NOTES									53
	LIST OF ACRONYMS							54

-----------------------------------------------------------------

1. INTRODUCTION

1.1  BACKGROUND

In general, a public-key certificate (hereinafter "certificate") 
binds a public key held by an entity (such as person, organization, 
account, device, or site) to a set of information that identifies 
the entity associated with use of the corresponding private key.  In 
most cases involving identity certificates, this entity is known as 
the "subject" or "subscriber" of the certificate.  Two exceptions, 
however, include devices (in which the subscriber is usually the 
individual or organization controlling the device) and anonymous 

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 3]

certificates (in which the identity of the individual or 
organization is not available from the certificate itself).  
Other types of certificates bind public keys to attributes of an 
entity other than the entity's identity, such as a role, a title, or 
creditworthiness information.  

A certificate is used by a "certificate user" or "relying party" 
that needs to use, and rely upon the accuracy of, the binding 
between the subject public key distributed via that certificate and 
the identity and/or other attributes of the subject contained in 
that certificate.  A relying party is frequently an entity that 
verifies a digital signature from the certificate's subject where 
the digital signature is associated with an email, web form, 
electronic document, or other data.  Other examples of relying 
parties can include a sender of encrypted email to the subscriber, a 
user of a web browser relying on a server certificate during a 
secure sockets layer (SSL) session, and an entity operating a server 
that controls access to online information using client certificates 
as an access control mechanism.  In summary, a relying party is an 
entity that uses a public key in a certificate (for signature 
verification and/or encryption).  The degree to which a relying 
party can trust the binding embodied in a certificate depends on 
several factors.  These factors can include the practices followed 
by the certification authority (CA) in authenticating the subject; 
the CA's operating policy, procedures, and security controls; the 
scope of the subscriber's responsibilities (for example, in 
protecting the private key); and the stated responsibilities and 
liability terms and conditions of the CA (for example, warranties, 
disclaimers of warranties, and limitations of liability).
 
A Version 3 X.509 certificate may contain a field declaring that one 
or more specific certificate policies apply to that certificate 
[ISO1].  According to X.509, a certificate policy (CP) is "a named 
set of rules that indicates the applicability of a certificate to a 
particular community and/or class of applications with common 
security requirements."  A CP may be used by a relying party to help 
in deciding whether a certificate, and the binding therein, are 
sufficiently trustworthy and otherwise appropriate for a particular 
application.  The CP concept is an outgrowth of the policy statement 
concept developed for Internet Privacy Enhanced Mail [PEM1] and 
expanded upon in [BAU1].
 
A more detailed description of the practices followed by a CA in 
issuing and otherwise managing certificates may be contained in a 
certification practice statement (CPS) published by or referenced by 
the CA.  According to the American Bar Association Information 
Security Committee's Digital Signature Guidelines (hereinafter 
"DSG")(1) and the Information Security Committee's PKI Assessment 
Guidelines (hereinafter "PAG")(2), "a CPS is a statement of the 
practices which a certification authority employs in issuing 
certificates." [ABA1, ABA2]  In general, CPSs also describe practices
relating to all certificate lifecycle services (e.g., issuance, 
management, revocation, and renewal or re-keying), and CPSs provide 
details concerning other business, legal, and technical matters.

Chokhani, Ford, Sabett, Merrill, & Wu    INTERNET DRAFT    [Page 4]
The terms contained in a CP or CPS may or may not be binding upon a 
PKI's participants as a contract.  A CP or CPS may itself purport to 
be a contract.  More commonly, however, an agreement may incorporate 
a CP or CPS by reference and therefore attempt to bind the parties of 
the agreement to some or all of its terms.  For example, some PKIs 
may utilize a CP or (more commonly) a CPS that is incorporated by 
reference in the agreement between a subscriber and a CA or RA 
(called a "subscriber agreement") or the agreement between a relying 
party and a CA (called a "relying party agreement" or "RPA").  In 
other cases, however, a CP or CPS has no contractual significance at 
all.  A PKI may intend these CPs and CPSs to be strictly 
informational or disclosure documents.

1.2  PURPOSE

The purpose of this document is twofold.  First, the document aims 
to explain the concepts of a CP and a CPS, describe the differences 
between these two concepts, and describe their relationship to 
subscriber and relying party agreements.  Second, this document aims 
to present a framework to assist the writers and users of 
certificate policies or CPSs in drafting and understanding these 
documents.  In particular, the framework identifies the elements 
that may need to be considered in formulating a CP or a CPS.  The 
purpose is not to define particular certificate policies or CPSs, 
per se.  Moreover, this document does not aim to provide legal advice 
or recommendations as to particular requirements or practices that 
should be contained within CPs or CPSs.  (Such recommendations, 
however, appear in [ABA2].) 

1.3  SCOPE

The scope of this document is limited to discussion of the topics 
that can be covered in a CP (as defined in X.509) or CPS (as defined 
in the DSG and PAG).  In particular, this document describes the 
types of information that should be considered for inclusion in a CP 
or a CPS.  While the framework as presented generally assumes use of 
the X.509 version 3 certificate format for the purpose of providing 
assurances of identity, it is not intended that the material be 
restricted to use of that certificate format or identity 
certificates.  Rather, it is intended that this framework be 
adaptable to other certificate formats and to certificates providing