Network Working Group                                        S. Chokhani
Request for Comments: 3647                Orion Security Solutions, Inc.
Obsoletes: 2527                                                  W. Ford
Category: Informational                                   VeriSign, Inc.
                                                               R. Sabett
                                                      Cooley Godward LLP
                                                              C. Merrill
                                                 McCarter & English, LLP
                                                                   S. Wu
                                                        Infoliance, Inc.
                                                           November 2003

Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(C)The Internet Society(2003)。全著作権所有。



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 supersedes RFC 2527.

このドキュメントは、証明機関、ポリシー機関、および証明書に依存したい関心のあるコミュニティなどの公開鍵インフラストラクチャー内の参加者のために、証明書ポリシーまたは認証実務声明の作成者を支援するためのフレームワークを提示します。特に、このフレームワークは、潜在的に(筆者の裁量で)証明書ポリシーまたは認証実務ステートメントでカバーする必要があるトピックの包括的なリストを提供します。このドキュメントはRFC 2527に優先します。

Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Background . . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Purpose. . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.3.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.  Certificate Policy . . . . . . . . . . . . . . . . . . .  9
       3.2.  Certificate Policy Examples. . . . . . . . . . . . . . . 11
       3.3.  X.509 Certificate Fields . . . . . . . . . . . . . . . . 12
             3.3.1.  Certificate Policies Extension . . . . . . . . . 12
             3.3.2.  Policy Mappings Extension. . . . . . . . . . . . 13
             3.3.3.  Policy Constraints Extension . . . . . . . . . . 13
             3.3.4.  Policy Qualifiers. . . . . . . . . . . . . . . . 14
       3.4.  Certification Practice Statement . . . . . . . . . . . . 15
       3.5.  Relationship Between CP and CPS. . . . . . . . . . . . . 16
       3.6.  Relationship Among CPs, CPSs, Agreements, and
             Other Documents. . . . . . . . . . . . . . . . . . . . . 17
       3.7.  Set of Provisions. . . . . . . . . . . . . . . . . . . . 20
   4.  Contents of a Set of Provisions. . . . . . . . . . . . . . . . 21
       4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . 22
             4.1.1.  Overview . . . . . . . . . . . . . . . . . . . . 22
             4.1.2.  Document Name and Identification . . . . . . . . 22
             4.1.3.  PKI Participants . . . . . . . . . . . . . . . . 23
             4.1.4.  Certificate Usage. . . . . . . . . . . . . . . . 24
             4.1.5.  Policy Administration. . . . . . . . . . . . . . 24
             4.1.6.  Definitions and Acronyms . . . . . . . . . . . . 24
       4.2.  Publication and Repository Responsibilities. . . . . . . 25
       4.3.  Identification and Authentication (I&A). . . . . . . . . 25
             4.3.1.  Naming . . . . . . . . . . . . . . . . . . . . . 25
             4.3.2.  Initial Identity Validation. . . . . . . . . . . 26
             4.3.3.  I&A for Re-key Requests. . . . . . . . . . . . . 27
             4.3.4.  I&A for Revocation Requests. . . . . . . . . . . 27
       4.4.  Certificate Life-Cycle Operational Requirements. . . . . 27
             4.4.1.  Certificate Application. . . . . . . . . . . . . 28
             4.4.2.  Certificate Application Processing . . . . . . . 28
             4.4.3.  Certificate Issuance . . . . . . . . . . . . . . 28
             4.4.4.  Certificate Acceptance . . . . . . . . . . . . . 29
             4.4.5.  Key Pair and Certificate Usage . . . . . . . . . 29
             4.4.6.  Certificate Renewal. . . . . . . . . . . . . . . 30
             4.4.7.  Certificate Re-key . . . . . . . . . . . . . . . 30
             4.4.8.  Certificate Modification . . . . . . . . . . . . 31
             4.4.9.  Certificate Revocation and Suspension. . . . . . 31
             4.4.10. Certificate Status Services. . . . . . . . . . . 33
             4.4.11. End of Subscription. . . . . . . . . . . . . . . 33
             4.4.12. Key Escrow and Recovery. . . . . . . . . . . . . 33
       4.5.  Facility, Management, and Operational Controls . . . . . 33
             4.5.1.  Physical Security Controls . . . . . . . . . . . 34
             4.5.2.  Procedural Controls. . . . . . . . . . . . . . . 35
             4.5.3.  Personnel Controls . . . . . . . . . . . . . . . 35
             4.5.4.  Audit Logging Procedures . . . . . . . . . . . . 36
             4.5.5.  Records Archival . . . . . . . . . . . . . . . . 37
             4.5.6.  Key Changeover . . . . . . . . . . . . . . . . . 38
             4.5.7.  Compromise and Disaster Recovery . . . . . . . . 38
             4.5.8.  CA or RA Termination . . . . . . . . . . . . . . 38
        4.6. Technical Security Controls. . . . . . . . . . . . . . . 39
             4.6.1.  Key Pair Generation and Installation . . . . . . 39
             4.6.2.  Private Key Protection and Cryptographic
                     Module Engineering Controls. . . . . . . . . . . 40
             4.6.3.  Other Aspects of Key Pair Management . . . . . . 42
             4.6.4.  Activation Data. . . . . . . . . . . . . . . . . 42
             4.6.5.  Computer Security Controls . . . . . . . . . . . 42
             4.6.6.  Life Cycle Security Controls . . . . . . . . . . 43
             4.6.7.  Network Security Controls. . . . . . . . . . . . 43
             4.6.8.  Timestamping . . . . . . . . . . . . . . . . . . 43
       4.7.  Certificate, CRL, and OCSP Profiles. . . . . . . . . . . 44
             4.7.1.  Certificate Profile. . . . . . . . . . . . . . . 44
             4.7.2.  CRL Profile. . . . . . . . . . . . . . . . . . . 44
             4.7.3.  OCSP Profile . . . . . . . . . . . . . . . . . . 44
       4.8.  Compliance Audit and Other Assessment. . . . . . . . . . 45
       4.9.  Other Business and Legal Matters . . . . . . . . . . . . 45
             4.9.1.  Fees . . . . . . . . . . . . . . . . . . . . . . 46
             4.9.2.  Financial Responsibility . . . . . . . . . . . . 47
             4.9.3.  Confidentiality of Business Information. . . . . 47
             4.9.4.  Privacy of Personal Information. . . . . . . . . 48
             4.9.5.  Intellectual Property Rights . . . . . . . . . . 48
             4.9.6.  Representations and Warranties . . . . . . . . . 48
             4.9.7.  Disclaimers of Warranties. . . . . . . . . . . . 49
             4.9.8.  Limitations of Liability . . . . . . . . . . . . 49
             4.9.9.  Indemnities. . . . . . . . . . . . . . . . . . . 49
             4.9.10. Term and Termination . . . . . . . . . . . . . . 50
             4.9.11. Individual notices and communications
                     with participants. . . . . . . . . . . . . . . . 50
             4.9.12. Amendments . . . . . . . . . . . . . . . . . . . 50
             4.9.13. Dispute Resolution Procedures. . . . . . . . . . 51
             4.9.14. Governing Law. . . . . . . . . . . . . . . . . . 51
             4.9.15. Compliance with Applicable Law . . . . . . . . . 51
             4.9.16. Miscellaneous Provisions . . . . . . . . . . . . 51
             4.9.17. Other Provisions . . . . . . . . . . . . . . . . 53
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 53
   6.  Outline of a Set of Provisions . . . . . . . . . . . . . . . . 53
   7.  Comparison to RFC 2527 . . . . . . . . . . . . . . . . . . . . 60
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 88
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
   10. Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
   12. List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . 91
   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 92
   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94
1. Introduction
1. はじめに
1.1. Background
1.1. バックグラウンド

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

証明書は、その証明書を介して配布されたサブジェクトの公開鍵と、含まれるサブジェクトのIDおよび/または他の属性との間のバインディングを使用し、その正確さに依存する必要がある「証明書ユーザー」または「証明書利用者」によって使用されます。その証明書で。証明書利用者は、証明書のサブジェクトからのデジタル署名を検証するエンティティであることが多く、デジタル署名は電子メール、Webフォーム、電子ドキュメント、またはその他のデータに関連付けられています。証明書利用者のその他の例としては、サブスクライバーへの暗号化された電子メールの送信者、Secure Sockets Layer(SSL)セッション中にサーバー証明書に依存するWebブラウザーのユーザー、およびオンライン情報へのアクセスを制御するサーバーを操作するエンティティなどがあります。アクセス制御メカニズムとしてのクライアント証明書。要約すると、証明書利用者とは、証明書の公開鍵を使用するエンティティです(署名の検証や暗号化のため)。証明書に組み込まれたバインディングを信頼パーティが信頼できる度合いは、いくつかの要因に依存します。これらの要因には、認証局(CA)がサブジェクトを認証する際の慣行が含まれます。 CAの運用ポリシー、手順、およびセキュリティ管理。サブスクライバーの責任の範囲(たとえば、秘密鍵の保護)。 CAの責任と義務の規定の条件(たとえば、保証、保証の否認、および責任の制限)。

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]. The legal and liability aspects presented in Section 4.9 are outcomes of a collaborative effort between IETF PKIX working group and the American Bar Association (ABA) members who have worked on legal acceptance of digital signature and role of PKI in that acceptance.

バージョン3のX.509証明書には、1つ以上の特定の証明書ポリシーがその証明書に適用されることを宣言するフィールドが含まれている場合があります[ISO1]。 X.509によると、証明書ポリシー(CP)は、「特定のコミュニティや共通のセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示す名前付きのルールのセット」です。証明書とそのバインディングが特定のアプリケーションに十分信頼できるか、そうでなければ適切であるかどうかを決定するのを助けるために、証明書利用者はCPを使用できます。 CPの概念は、インターネットプライバシー拡張メール[PEM1]のために開発され、[BAU1]で拡張されたポリシーステートメントの概念の派生物です。セクション4.9に示す法的および責任の側面は、IETF PKIXワーキンググループと、デジタル署名の法的承認とその承認におけるPKIの役割に取り組んだ米国弁護士協会(ABA)メンバーとの共同作業の成果です。

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

証明書の発行およびその他の管理においてCAが従う慣行のより詳細な説明は、CAが発行または参照する認証実務声明(CPS)に含まれている場合があります。米国弁護士会情報セキュリティ委員会のデジタル署名ガイドライン(以下「DSG」)(1)および情報セキュリティ委員会のPKI評価ガイドライン(以下「PAG」)(2)によれば、「CPSは、証明機関は証明書の発行に雇用しています。」 [ABA1、ABA2]一般に、CPSはすべての証明書ライフサイクルサービス(発行、管理、失効、更新または再キーイングなど)に関連する慣行も説明し、CPSは他のビジネス、法的、および技術的な問題に関する詳細を提供します。 CPまたはCPSに含まれる条件は、PKIの参加者を契約として拘束する場合と拘束力がない場合があります。 CPまたはCPS自体が契約であると主張する場合があります。ただし、より一般的には、合意には参照によりCPまたはCPSが組み込まれているため、合意の当事者をその条件の一部またはすべてに拘束することを試みる場合があります。たとえば、一部のPKIは、CPまたは(より一般的には)参照により加入者とCAまたはRAの間の契約(「加入者契約」と呼ばれます)または依存パーティとCAの間の契約に組み込まれているCPSを利用できます。 (「依拠当事者合意」または「RPA」と呼ばれる)。ただし、他の場合では、CPまたはCPSに契約上の意味はまったくありません。 PKIは、これらのCPとCPSが厳密に情報または開示のドキュメントであることを意図する場合があります。

1.2. Purpose
1.2. 目的

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].)

このドキュメントの目的は2つあります。最初に、このドキュメントは、CPとCPSの概念を説明し、これら2つの概念の違いを説明し、加入者と信頼者の合意との関係を説明することを目的としています。第2に、このドキュメントは、証明書ポリシーまたはCPSの作成者とユーザーがこれらのドキュメントを作成して理解するのを支援するフレームワークを提示することを目的としています。特に、フレームワークは、CPまたはCPSを策定する際に考慮する必要がある要素を識別します。目的は、特定の証明書ポリシーまたはCPS自体を定義することではありません。さらに、このドキュメントは、CPまたはCPSに含まれるべき特定の要件または慣行に関する法的助言または推奨事項を提供することを目的としていません。 (ただし、このような推奨事項は[ABA2]に記載されています。)

1.3. Scope
1.3. 範囲

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 assurances other than identity that may come into use.


The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy). Further, this document does not define a specific CP or CPS. Moreover, in presenting a framework, this document should be viewed and used as a flexible tool presenting topics that should be considered of particular relevance to CPs or CPSs, and not as a rigid formula for producing CPs or CPSs.


This document assumes that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure (PKI), as used in X.509, the DSG, and the PAG.


2. Definitions
2. 定義

This document makes use of the following defined terms:


Activation data - Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share).


Authentication - The process of establishing that individuals, organizations, or things are who or what they claim to be. In the context of a PKI, authentication can be the process of establishing that an individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization. This corresponds to the second process involved with identification, as shown in the definition of "identification" below. Authentication can also refer to a security service that provides assurances that individuals, organizations, or things are who or what they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message's sender.

認証-個人、組織、または物事が、だれであるかまたは何であるかを主張することを確立するプロセス。 PKIのコンテキストでは、認証は、特定の名前で何かを申請またはアクセスを求める個人または組織が、実際には適切な個人または組織であることを確立するプロセスです。これは、以下の「識別」の定義に示すように、識別に関連する2番目のプロセスに対応します。認証は、個人、組織、または事物が彼らが誰であるかまたは何であるかを主張する保証、またはメッセージまたは他のデータが特定の個人、組織、またはデバイスから発信されたものである保証を提供するセキュリティサービスを指すこともあります。したがって、メッセージのデジタル署名がメッセージの送信者を認証すると言われています。

CA-certificate - A certificate for one CA's public key issued by another CA.


Certificate policy (CP) - A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.


Certification path - An ordered sequence of certificates that, together with the public key of the initial object in the path, can be processed to obtain that of the final object in the path.


Certification Practice Statement (CPS) - A statement of the practices that a certification authority employs in issuing, managing, revoking, and renewing or re-keying certificates.


CPS Summary (or CPS Abstract) - A subset of the provisions of a complete CPS that is made public by a CA.


Identification - The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes:

識別-個人または組織のアイデンティティを確立するプロセス。つまり、個人または組織が特定の個人または組織であることを示すため。 PKIのコンテキストでは、識別は2つのプロセスを指します。

(1) establishing that a given name of an individual or organization corresponds to a real-world identity of an individual or organization, and


(2) establishing that an individual or organization applying for or seeking access to something under that name is, in fact, the named individual or organization. A person seeking identification may be a certificate applicant, an applicant for employment in a trusted position within a PKI participant, or a person seeking access to a network or software application, such as a CA administrator seeking access to CA systems.


Issuing certification authority (issuing CA) - In the context of a particular certificate, the issuing CA is the CA that issued the certificate (see also Subject certification authority).


Participant - An individual or organization that plays a role within a given PKI as a subscriber, relying party, CA, RA, certificate manufacturing authority, repository service provider, or similar entity.


PKI Disclosure Statement (PDS) - An instrument that supplements a CP or CPS by disclosing critical information about the policies and practices of a CA/PKI. A PDS is a vehicle for disclosing and emphasizing information normally covered in detail by associated CP and/or CPS documents. Consequently, a PDS is not intended to replace a CP or CPS.

PKI開示ステートメント(PDS)-CA / PKIのポリシーと実践に関する重要な情報を開示することにより、CPまたはCPSを補足する手段。 PDSは、関連するCPおよび/またはCPSドキュメントで通常詳細にカバーされる情報を開示および強調するための手段です。したがって、PDSはCPまたはCPSを置き換えるものではありません。

Policy qualifier - Policy-dependent information that may accompany a CP identifier in an X.509 certificate. Such information can include a pointer to the URL of the applicable CPS or relying party agreement. It may also include text (or number causing the appearance of text) that contains terms of the use of the certificate or other legal information.


Registration authority (RA) - An entity that is responsible for one or more of the following functions: the identification and authentication of certificate applicants, the approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke or suspend their certificates, and approving or rejecting requests by subscribers to renew or re-key their certificates. RAs, however, do not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is sometimes used in other documents for the same concept.]

登録機関(RA)-次の機能の1つ以上を担当するエンティティ:証明書申請者の識別と認証、証明書申請の承認または拒否、特定の状況下での証明書の取り消しまたは一時停止の開始、失効するサブスクライバー要求の処理または、証明書を一時停止し、サブスクライバーによる証明書の更新またはキー更新の要求を承認または拒否します。ただし、RAは証明書に署名または発行しません(つまり、RAはCAに代わって特定のタスクを委任されます)。 [注:ローカル登録局(LRA)という用語は、同じ概念の他のドキュメントでも使用されることがあります。]

Relying party - A recipient of a certificate who acts in reliance on that certificate and/or any digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.


Relying party agreement (RPA) - An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those parties regarding the verification of digital signatures or other uses of certificates.


Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the approach described in this framework.


Subject certification authority (subject CA) - In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority).


Subscriber - A subject of a certificate who is issued a certificate.


Subscriber Agreement - An agreement between a CA and a subscriber that establishes the right and responsibilities of the parties regarding the issuance and management of certificates.


Validation - The process of identification of certificate applicants. "Validation" is a subset of "identification" and refers to identification in the context of establishing the identity of certificate applicants.

検証-証明書申請者の識別プロセス。 「検証」は「識別」のサブセットであり、証明書申請者の識別を確立するコンテキストでの識別を指します。

3. Concepts
3. 概念

This section explains the concepts of CP and CPS, and describes their relationship with other PKI documents, such as subscriber agreements and relying party agreements. Other related concepts are also described. Some of the material covered in this section and in some other sections is specific to certificate policies extensions as defined X.509 version 3. Except for those sections, this framework is intended to be adaptable to other certificate formats that may come into use.


3.1. Certificate Policy
3.1. 証明書ポリシー

When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to the identity and/or other attributes of a particular entity (the certificate subject, which is usually also the subscriber). The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party or entity controlling or coordinating the way relying parties or relying party applications use certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.


The X.509 standard defines a CP as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements" [ISO1]. An X.509 Version 3 certificate may identify a specific applicable CP, which may be used by a relying party to decide whether or not to trust a certificate, associated public key, or any digital signatures verified using the public key for a particular purpose.

X.509標準は、CPを「特定のコミュニティやアプリケーションに共通のセキュリティ要件を持つアプリケーションクラスへの証明書の適用可能性を示す名前付きのルールのセット」[ISO1]として定義しています。 X.509バージョン3証明書は、証明書、関連する公開鍵、または特定の目的のために公開鍵を使用して検証されたデジタル署名を信頼するかどうかを決定するために証明書利用者が使用できる特定の適用可能なCPを識別します。

CPs typically fall into two major categories. First, some CPs "indicate the applicability of a certificate to a particular community" [ISO1]. These CPs set forth requirements for certificate usage and requirements on members of a community. For instance, a CP may focus on the needs of a geographical community, such as the ETSI policy requirements for CAs issuing qualified certificates [ETS]. Also, a CP of this kind may focus on the needs of a specific vertical-market community, such as financial services [IDT].


The second category of typical CPs "indicate the applicability of a certificate to a . . . class of application with common security requirements." These CPs identify a set of applications or uses for certificates and say that these applications or uses require a certain level of security. They then set forth PKI requirements that are appropriate for these applications or uses. A CP within this category often makes sets requirements appropriate for a certain "level of assurance" provided by certificates, relative to certificates issued pursuant to related CPs. These levels of assurance may correspond to "classes" or "types" of certificates.


For instance, the Government of Canada PKI Policy Management Authority (GOC PMA) has established eight certificate policies in a single document [GOC], four policies for certificates used for digital signatures and four policies for certificates used for confidentiality encryption. For each of these applications, the document establishes four levels of assurances: rudimentary, basic, medium, and high. The GOC PMA described certain types of digital signature and confidentiality uses in the document, each with a certain set of security requirements, and grouped them into eight categories. The GOC PMA then established PKI requirements for each of these categories, thereby creating eight types of certificates, each providing rudimentary, basic, medium, or high levels of assurance. The progression from rudimentary to high levels corresponds to increasing security requirements and corresponding increasing levels of assurance.

たとえば、カナダ政府のPKIポリシー管理局(GOC PMA)は、単一のドキュメント[GOC]で8つの証明書ポリシーを確立しました。デジタル署名に使用される証明書の4つのポリシーと、機密性暗号化に使用される証明書の4つのポリシーです。これらのアプリケーションのそれぞれについて、ドキュメントは4つのレベルの保証を確立します:基本、基本、中、高。 GOC PMAは、ドキュメント内の特定の種類のデジタル署名と機密性の使用について説明し、それぞれに特定のセキュリティ要件があり、それらを8つのカテゴリにグループ化しました。その後、GOC PMAはこれらの各カテゴリのPKI要件を確立し、それによって8種類の証明書を作成し、それぞれが初歩的な、基本的な、中程度の、または高いレベルの保証を提供します。初歩的なレベルから高いレベルへの移行は、セキュリティ要件の増加と対応する保証レベルの増加に対応しています。

A CP is represented in a certificate by a unique number called an "Object Identifier" (OID). That OID, or at least an "arc", can be registered. An "arc" is the beginning of the numerical sequence of an OID and is assigned to a particular organization. The registration process follows the procedures specified in ISO/IEC and ITU standards. The party that registers the OID or arc also can publish the text of the CP, for examination by relying parties. Any one certificate will typically declare a single CP or, possibly, be issued consistent with a small number of different policies. Such declaration appears in the Certificate Policies extension of a X.509 Version 3 certificate. When a CA places multiple CPs within a certificate's Certificate Policies extension, the CA is asserting that the certificate is appropriate for use in accordance with any of the listed CPs.

証明書では、CPは「オブジェクト識別子」(OID)と呼ばれる一意の番号で表されます。そのOID、または少なくとも「アーク」を登録できます。 「アーク」はOIDの数値シーケンスの始まりであり、特定の組織に割り当てられます。登録プロセスは、ISO / IECおよびITU規格で指定された手順に従います。 OIDまたはアークを登録する当事者は、依拠当事者による検査のために、CPのテキストを公開することもできます。 1つの証明書は通常、単一のCPを宣言するか、場合によっては、少数の異なるポリシーと一致して発行されます。このような宣言は、X.509バージョン3証明書の証明書ポリシー拡張に表示されます。 CAが証明書の証明書ポリシー拡張内に複数のCPを配置する場合、CAは、リストされているCPのいずれかに従って証明書が使用に適していることを表明しています。

CPs also constitute a basis for an audit, accreditation, or another assessment of a CA. Each CA can be assessed against one or more certificate policies or CPSs that it is recognized as implementing. When one CA issues a CA-certificate for another CA, the issuing CA must assess the set of certificate policies for which it trusts the subject CA (such assessment may be based upon an assessment with respect to the certificate policies involved). The assessed set of certificate policies is then indicated by the issuing CA in the CA-certificate. The X.509 certification path processing logic employs these CP indications in its well-defined trust model.

CPは、CAの監査、認定、または別の評価の基礎も構成します。各CAは、実装していると認識されている1つ以上の証明書ポリシーまたはCPSに対して評価できます。あるCAが別のCAに対してCA証明書を発行する場合、発行元のCAは、対象のCAを信頼する証明書ポリシーのセットを評価する必要があります(そのような評価は、関連する証明書ポリシーに関する評価に基づく場合があります)。評価された証明書ポリシーのセットは、発行元のCAによってCA証明書に示されます。 X.509証明書パス処理ロジックは、明確に定義された信頼モデルでこれらのCP表示を採用しています。

3.2. Certificate Policy Examples
3.2. 証明書ポリシーの例

For example purposes, suppose that the International Air Transport Association (IATA) undertakes to define some certificate policies for use throughout the airline industry, in a PKI operated by IATA in combination with PKIs operated by individual airlines. Two CPs might be defined - the IATA General-Purpose CP, and the IATA Commercial-Grade CP.

例として、IATAが運営するPKIと個々の航空会社が運営するPKIを組み合わせて、国際航空運送協会(IATA)が航空業界全体で使用するいくつかの証明書ポリシーを定義するとします。 IATA汎用CPとIATA商用グレードCPの2つのCPが定義される場合があります。

The IATA General-Purpose CP could be used by industry personnel for protecting routine information (e.g., casual electronic mail) and for authenticating connections from World Wide Web browsers to servers for general information retrieval purposes. The key pairs may be generated, stored, and managed using low-cost, software-based systems, such as commercial browsers. Under this policy, a certificate may be automatically issued to anybody listed as an employee in the corporate directory of IATA or any member airline who submits a signed certificate request form to a network administrator in his or her organization.

IATA汎用CPは、日常的な情報(例:カジュアルな電子メール)を保護し、一般的な情報を取得する目的でWorld Wide Webブラウザからサーバーへの接続を認証するために、業界の担当者が使用できます。キーペアは、商用ブラウザなどの低コストのソフトウェアベースのシステムを使用して生成、保存、および管理できます。このポリシーでは、IATAの企業ディレクトリに従業員としてリストされているすべての人、または組織のネットワーク管理者に署名済みの証明書リクエストフォームを送信するすべてのメンバーの航空会社に、証明書が自動的に発行されます。

The IATA Commercial-Grade CP could be used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA could require that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens could be provided to airline employees with disbursement authority. These authorized individuals might then be required to present themselves to the corporate security office, show a valid identification badge, and sign a subscriber agreement requiring them to protect the token and use it only for authorized purposes, as a condition of being issued a token and a certificate.

IATA Commercial-Grade CPは、航空会社間の金融取引または拘束力のある契約上の交換を保護するために使用できます。このポリシーの下で、IATAは、認定された鍵ペアを生成し、承認された暗号化ハードウェアトークンに保存することを要求できます。証明書とトークンは、支払い権限を持つ航空会社の従業員に提供できます。次に、これらの許可された個人は、企業のセキュリティオフィスに自分自身を提示し、有効なIDバッジを提示し、トークンを保護し、許可された目的でのみトークンを発行する条件として使用することを要求する加入者契約に署名する必要がある場合があります。証明書。

3.3. X.509 Certificate Fields
3.3. X.509証明書フィールド

The following extension fields in an X.509 certificate are used to support CPs:


* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.

* 証明書ポリシー拡張。 *ポリシーマッピング拡張機能。および*ポリシー制約拡張。

3.3.1. Certificate Policies Extension
3.3.1. 証明書ポリシー拡張

A Certificate Policies field lists CPs that the certification authority declares are applicable. Using the example of the IATA General-Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees would contain the object identifier for General-Purpose policy. The certificates issued to the employees with disbursement authority would contain the object identifiers for both the General-Purpose policy and the Commercial-Grade policy. The inclusion of both object identifiers in the certificates means that they would be appropriate for either the General-Purpose or Commercial-Grade policies. The Certificate Policies field may also optionally convey qualifier values for each identified policy; the use of qualifiers is discussed in Section 3.4.

[証明書ポリシー]フィールドには、証明機関が適用可能であると宣言するCPが一覧表示されます。セクション3.2で定義されているIATA汎用ポリシーおよび商業グレードポリシーの例を使用すると、航空会社の正規従業員に発行される証明書には、汎用ポリシーのオブジェクト識別子が含まれます。支払い権限を持つ従業員に発行された証明書には、汎用ポリシーと商用グレードポリシーの両方のオブジェクト識別子が含まれます。証明書に両方のオブジェクト識別子を含めることは、それらが汎用ポリシーまたは商用グレードポリシーのいずれかに適していることを意味します。 「証明書ポリシー」フィールドは、オプションで、識別された各ポリシーの修飾子の値を伝えることもできます。修飾子の使用については、セクション3.4で説明します。

When processing a certification path, a CP that is acceptable to the relying party application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.


If the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. Specifically, it indicates that the use of the certificate is restricted to one of the identified policies, i.e., the certification authority is declaring that the certificate must only be used in accordance with the provisions of at least one of the listed CPs. This field is intended to protect the certification authority against claims for damages asserted by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable CP.

[Certificate Policies]フィールドにクリティカルのフラグが付けられている場合、これは上記と同じ目的を果たしますが、追加の役割もあります。具体的には、証明書の使用が識別されたポリシーの1つに制限されていることを示します。つまり、証明機関は、リストされたCPの少なくとも1つの規定に従ってのみ証明書を使用する必要があることを宣言しています。このフィールドは、該当するCPに規定されているように、証明書を不適切な目的または不適切な方法で使用した証明書利用者によって主張された損害の請求から認証局を保護することを目的としています。

For example, the Internal Revenue Service might issue certificates to taxpayers for the purpose of protecting tax filings. The Internal Revenue Service understands and can accommodate the risks of erroneously issuing a bad certificate, e.g., to an imposter. Suppose, however, that someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary trade secrets, which subsequently fell into the wrong hands because of a cryptanalytic attack by an attacker who is able to decrypt the message. The Internal Revenue Service may want to defend itself against claims for damages in such circumstances by pointing to the criticality of the Certificate Policies extension to show that the subscriber and relying party misused the certificate. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the CA in such situations.


3.3.2. Policy Mappings Extension
3.3.2. ポリシーマッピング拡張

The Policy Mappings extension may only be used in CA-certificates. This field allows a certification authority to indicate that certain policies in its own domain can be considered equivalent to certain other policies in the subject certification authority's domain.


For example, suppose that for purposes of facilitating interoperability, the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify the public keys of each others' certification authorities for the purposes of mutually securing their respective business-to-business exchanges. Further, suppose that both companies have pre-existing financial transaction protection policies called ace-e-commerce and abc-e-commerce, respectively. One can see that simply generating cross-certificates between the two domains will not provide the necessary interoperability, as the two companies' applications are configured with, and employee certificates are populated with, their respective certificate policies. One possible solution is to reconfigure all of the financial applications to require either policy and to reissue all the certificates with both policies appearing in their Certificate Policies extensions. Another solution, which may be easier to administer, uses the Policy Mapping field. If this field is included in a cross-certificate for the ABC Corporation certification authority issued by the ACE Corporation certification authority, it can provide a statement that the ABC's financial transaction protection policy (i.e., abc-e-commerce) can be considered equivalent to that of the ACE Corporation (i.e., ace-e-commerce). With such a statement included in the cross-certificate issued to ABC, relying party applications in the ACE domain requiring the presence of the object identifier for the ace-e-commerce CP can also accept, process, and rely upon certificates issued within the ABC domain containing the object identifier for the abc-e-commerce CP.

たとえば、相互運用性を促進する目的で、ACE CorporationがABC Corporationと契約を結び、それぞれの企業間取引を相互に保護する目的で、互いの認証局の公開鍵を相互認証するとします。さらに、両社がそれぞれace-e-commerceおよびabc-e-commerceと呼ばれる既存の金融取引保護ポリシーを持っているとします。 2つのドメイン間でクロス証明書を生成するだけでは、必要な相互運用性が提供されないことがわかります。これは、2つの企業のアプリケーションがそれぞれの証明書ポリシーで構成され、従業員証明書が入力されるためです。 1つの可能な解決策は、いずれかのポリシーを要求するようにすべての金融アプリケーションを再構成し、証明書ポリシー拡張に両方のポリシーが現れるようにすべての証明書を再発行することです。管理が容易な別のソリューションでは、ポリシーマッピングフィールドを使用します。このフィールドがACE Corporation証明機関によって発行されたABC Corporation証明機関の相互認証に含まれている場合、ABCの金融取引保護ポリシー(つまり、abc-e-commerce)は以下と同等と見なすことができるというステートメントを提供できます。 ACE Corporationのそれ(すなわち、ace-e-commerce)。 ABCに発行されたクロス証明書にそのようなステートメントが含まれていると、ACEドメインのエースeコマースCPのオブジェクト識別子の存在を必要とする証明書利用者アプリケーションも、ABC内で発行された証明書を受け入れ、処理し、信頼することができます。 abc-e-commerce CPのオブジェクト識別子を含むドメイン。

3.3.3. Policy Constraints Extension
3.3.3. ポリシー制約拡張

The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit CP indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a relying party to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular CP is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of CP. When a certification authority in the trusted domain, however, certifies outside the domain, it can activate the requirement that a specific CP's object identifier appear in subsequent certificates in the certification path.

ポリシー制約拡張は、2つのオプション機能をサポートしています。 1つ目は、証明機関が証明パス内の後続のすべての証明書に明示的なCP表示が存在することを要求する機能です。証明書パスの最初の証明書は、証明書利用者によって信頼されたドメインの一部であると見なされる場合があります。つまり、認証局はあらゆる目的で信頼されているため、証明書ポリシー拡張で特定のCPは必要ありません。このような証明書には、CPの明示的な表示が含まれている必要はありません。ただし、信頼されたドメインの証明機関がドメイン外で証明する場合、特定のCPのオブジェクト識別子が証明パスの後続の証明書に表示されるという要件をアクティブにすることができます。

The other optional feature in the Policy Constraints field is the ability for a certification authority to disable policy mapping by subsequent certification authorities in a certification path. It may be prudent to disable policy mapping when certifying outside the domain. This can assist in controlling risks due to transitive trust, e.g., a domain A trusts domain B, domain B trusts domain C, but domain A does not want to be forced to trust domain C.


3.3.4. Policy Qualifiers
3.3.4. ポリシー修飾子

The Certificate Policies extension field has a provision for conveying, along with each CP identifier, additional policy-dependent information in a qualifier field. The X.509 standard does not mandate the purpose for which this field is to be used, nor does it prescribe the syntax for this field. Policy qualifier types can be registered by any organization.

証明書ポリシー拡張フィールドには、各CP識別子とともに、修飾子フィールドで追加のポリシー依存情報を伝達するための規定があります。 X.509標準は、このフィールドが使用される目的を義務付けておらず、このフィールドの構文も規定していません。ポリシー修飾子タイプは、どの組織でも登録できます。

The following policy qualifier types are defined in PKIX RFC 3280 [PKI1]:

以下のポリシー修飾子タイプは、PKIX RFC 3280 [PKI1]で定義されています。

(a) The CPS Pointer qualifier contains a pointer to a CPS, CPS Summary, RPA, or PDS published by the CA. The pointer is in the form of a uniform resource identifier (URI).


(b) The User Notice qualifier contains a text string that is to be displayed to subscribers and relying parties prior to the use of the certificate. The text string may be an IA5String or a BMPString - a subset of the ISO 100646-1 multiple octet coded character set. A CA may invoke a procedure that requires that the relying party acknowledge that the applicable terms and conditions have been disclosed and/or accepted.

(b)User Notice修飾子には、証明書の使用前にサブスクライバおよび信頼者に表示されるテキスト文字列が含まれています。テキスト文字列は、IA5StringまたはBMPString(ISO 100646-1複数オクテットコード化文字セットのサブセット)にすることができます。 CAは、適用される条件が開示および/または承諾されたことを依拠当事者が確認することを要求する手順を呼び出すことができます。

Policy qualifiers can be used to support the definition of generic, or parameterized, CPs. Provided the base CP so provides, policy qualifier types can be defined to convey, on a per-certificate basis, additional specific policy details that fill in the generic definition.


3.4. Certification Practice Statement
3.4. 認定実務声明

The term certification practice statement (CPS) is defined by the DSG and PAG as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1, ABA2] As stated above, a CPS establishes practices concerning lifecycle services in addition to issuance, such as certificate management (including publication and archiving), revocation, and renewal or re-keying. In the DSG, the ABA expands this definition with the following comments:

証明実践ステートメント(CPS)という用語は、DSGとPAGによって次のように定義されています。「証明機関が証明書の発行に採用する実践のステートメント」。 [ABA1、ABA2]上記のように、CPSは、証明書管理(公開とアーカイブを含む)、失効、更新または再キーイングなどの発行に加えて、ライフサイクルサービスに関する慣行を確立します。 DSGでは、ABAは次のコメントでこの定義を拡張します。

"A certification practice statement may take the form of a declaration by the certification authority of the details of its trustworthy system and the practices it employs in its operations and in support of issuance of a certificate . . . ." This form of CPS is the most common type, and can vary in length and level of detail.


Some PKIs may not have the need to create a thorough and detailed statement of practices. For example, the CA may itself be the relying party and would already be aware of the nature and trustworthiness of its services. In other cases, a PKI may provide certificates providing only a very low level of assurances where the applications being secured may pose only marginal risks if compromised. In these cases, an organization establishing a PKI may only want to write or have CAs use a subscriber agreement, relying party agreement, or agreement combining subscriber and relying party terms, depending on the role of the different PKI participants. In such a PKI, that agreement may serve as the only "statement of practices" used by one or more CAs within that PKI. Consequently, that agreement may also be considered a CPS and can be entitled or subtitled as such.


Likewise, since a detailed CPS may contain sensitive details of its system, a CA may elect not to publish its entire CPS. It may instead opt to publish a CPS Summary (or CPS Abstract). The CPS Summary would contain only those provisions from the CPS that the CA considers to be relevant to the participants in the PKI (such as the responsibilities of the parties or the stages of the certificate lifecycle). A CPS Summary, however, would not contain those sensitive provisions of the full CPS that might provide an attacker with useful information about the CA's operations. Throughout this document, the use of "CPS" includes both a detailed CPS and a CPS Summary (unless otherwise specified).

同様に、詳細なCPSにはシステムの機密情報が含まれている可能性があるため、CAはCPS全体を公開しないことを選択できます。代わりに、CPSサマリー(またはCPSアブストラクト)の公開を選択する場合があります。 CPSの概要には、CAがPKIの参加者に関連があると見なしたCPSの規定(当事者の責任や証明書のライフサイクルの段階など)のみが含まれます。ただし、CPSの概要には、攻撃者にCAの運用に関する有用な情報を提供する可能性のある完全なCPSの機密規定は含まれません。このドキュメント全体を通して、「CPS」の使用には、詳細なCPSとCPSサマリーの両方が含まれます(特に指定されていない限り)。

CPSs do not automatically constitute contracts and do not automatically bind PKI participants as a contract would. Where a document serves the dual purpose of being a subscriber or relying party agreement and CPS, the document is intended to be a contract and constitutes a binding contract to the extent that a subscriber or relying party agreement would ordinarily be considered as such. Most CPSs, however, do not serve such a dual purpose. Therefore, in most cases, a CPS's terms have a binding effect as contract terms only if a separate document creates a contractual relationship between the parties and that document incorporates part or all of the CPS by reference. Further, if a particular PKI employs a CPS Summary (as opposed to the entire CPS), the CPS Summary could be incorporated into any applicable subscriber or relying party agreement.


In the future, a court or applicable statutory or regulatory law may declare that a certificate itself is a document that is capable of creating a contractual relationship, to the extent its mechanisms designed for incorporation by reference (such as the Certificate Policies extension and its qualifiers) indicate that terms of its use appear in certain documents. In the meantime, however, some subscriber agreements and relying party agreements may incorporate a CPS by reference and therefore make its terms binding on the parties to such agreements.


3.5. Relationship Between Certificate Policy and Certification Practice Statement

3.5. 証明書ポリシーと認証実務声明の関係

The CP and CPS address the same set of topics that are of interest to the relying party in terms of the degree to and purpose for which a public key certificate should be trusted. Their primary difference is in the focus of their provisions. A CP sets forth the requirements and standards imposed by the PKI with respect to the various topics. In other words, the purpose of the CP is to establish what participants must do. A CPS, by contrast, states how a CA and other participants in a given domain implement procedures and controls to meet the requirements stated in the CP. In other words, the purpose of the CPS is to disclose how the participants perform their functions and implement controls.

CPとCPSは、公開鍵証明書を信頼する必要がある度合いと目的の観点から、証明書利用者にとって関心のある同じ一連のトピックを扱います。主な違いは、規定の焦点にあります。 CPは、さまざまなトピックに関してPKIによって課される要件と標準を規定します。つまり、CPの目的は、参加者が実行する必要があることを確立することです。対照的に、CPSは、特定のドメインのCAおよび他の参加者が、CPに記載されている要件を満たすための手順と制御をどのように実装するかを示しています。つまり、CPSの目的は、参加者が機能を実行し、制御を実装する方法を開示することです。

An additional difference between a CP and CPS relates the scope of coverage of the two kinds of documents. Since a CP is a statement of requirements, it best serves as the vehicle for communicating minimum operating guidelines that must be met by interoperating PKIs. Thus, a CP generally applies to multiple CAs, multiple organizations, or multiple domains. By contrast, a CPS applies only to a single CA or single organization and is not generally a vehicle to facilitate interoperation.

CPとCPSの追加の違いは、2種類のドキュメントの対象範囲に関係します。 CPは要件のステートメントであるため、相互運用するPKIが満たす必要のある最小限の運用ガイドラインを伝達する手段として最適です。したがって、CPは通常、複数のCA、複数の組織、または複数のドメインに適用されます。対照的に、CPSは単一のCAまたは単一の組織にのみ適用され、通常、相互運用を促進する手段ではありません。

A CA with a single CPS may support multiple CPs (used for different application purposes and/or by different relying party communities). Also, multiple CAs, with non-identical CPSs, may support the same CP.


For example, the Federal Government might define a government-wide CP for handling confidential human resources information. The CP will be a broad statement of the general requirements for participants within the Government's PKI, and an indication of the types of applications for which it is suitable for use. Each department or agency wishing to operate a certification authority in this PKI may be required to write its own certification practice statement to support this CP by explaining how it meets the requirements of the CP. At the same time, a department's or agency's CPS may support other certificate policies.

たとえば、連邦政府は、機密の人的資源情報を処理するための政府全体のCPを定義する場合があります。 CPは、政府のPKI内の参加者の一般的な要件の幅広い説明であり、CPの使用に適したアプリケーションのタイプを示します。このPKIで認証局を運用することを希望する各部門または機関は、CPの要件をどのように満たすかを説明することにより、このCPをサポートするための独自の認証実務声明を書く必要がある場合があります。同時に、部門または機関のCPSが他の証明書ポリシーをサポートする場合があります。

An additional difference between a CP and CPS concerns the level of detail of the provisions in each. Although the level of detail may vary among CPSs, a CPS will generally be more detailed than a CP. A CPS provides a detailed description of procedures and controls in place to meet the CP requirements, while a CP is more general.

CPとCPSの追加の違いは、それぞれの規定の詳細レベルに関係します。詳細レベルはCPS間で異なる場合がありますが、CPSは一般にCPよりも詳細です。 CPSは、CPがより一般的である一方で、CP要件を満たすために実施されている手順と制御の詳細な説明を提供します。

The main differences between CPs and CPSs can therefore be summarized as follows:


(a) A PKI uses a CP to establish requirements that state what participants within it must do. A single CA or organization can use a CPS to disclose how it meets the requirements of a CP or how it implements its practices and controls.


(b) A CP facilitates interoperation through cross-certification, unilateral certification, or other means. Therefore, it is intended to cover multiple CAs. By contrast, a CPS is a statement of a single CA or organization. Its purpose is not to facilitate interoperation (since doing so is the function of a CP).


(c) A CPS is generally more detailed than a CP and specifies how the CA meets the requirements specified in the one or more CPs under which it issues certificates.


In addition to populating the certificate policies extension with the applicable CP object identifier, a certification authority may include, in certificates it issues, a reference to its certification practice statement. A standard way to do this, using a CP qualifier, is described in Section 3.4.

証明書ポリシー拡張に適切なCPオブジェクトIDを設定することに加えて、証明機関は、発行する証明書に、その証明実践ステートメントへの参照を含めることができます。 CP修飾子を使用してこれを行う標準的な方法については、セクション3.4で説明します。

3.6. Relationship Among CPs, CPSs, Agreements, and Other Documents
3.6. CP、CPS、契約、およびその他の文書間の関係

CPs and CPSs play a central role in documenting the requirements and practices of a PKI. Nonetheless, they are not the only documents relevant to a PKI. For instance, subscriber agreements and relying party agreements play a critical role in allocating responsibilities to subscribers and relying parties relating to the use of certificates and key pairs. They establish the terms and conditions under which certificates are issued, managed, and used. The term subscriber agreement is defined by the PAG as: "An agreement between a CA and a subscriber that establishes the right and obligations of the parties regarding the issuance and management of certificates." [ABA2] The PAG defines a relying party agreement as: "An agreement between a certification authority and relying party that typically establishes the rights and obligations between those parties regarding the verification of digital signatures or other uses of certificates." [ABA2]

CPとCPSは、PKIの要件と実践を文書化する上で中心的な役割を果たします。それでも、PKIに関連するドキュメントはこれらだけではありません。たとえば、サブスクライバー契約と証明書利用者契約は、証明書とキーペアの使用に関するサブスクライバーと証明書利用者への責任の割り当てにおいて重要な役割を果たします。証明書が発行、管理、および使用される条件を確立します。加入者合意という用語は、PAGによって「証明書の発行と管理に関する当事者の権利と義務を確立するCAと加入者の間の合意」として定義されています。 [ABA2] PAGは、証明書利用者の合意を次のように定義しています。「デジタル署名の検証または証明書のその他の使用に関して、通常、これらの当事者間に権利と義務を確立する証明機関と証明書利用者との間の合意」 [ABA2]

As mentioned in Section 3.5, a subscriber agreement, relying party agreement, or an agreement that combines subscriber and relying party terms may also serve as a CPS. In other PKIs, however, a subscriber or relying party agreement may incorporate some or all of the terms of a CP or CPS by reference. Yet other PKIs may distill from a CP and/or CPS the terms that are applicable to a subscriber and place such terms in a self-contained subscriber agreement, without incorporating a CP or CPS by reference. They may use the same method to distill relying party terms from a CP and/or CPS and place such terms in a self-contained relying party agreement. Creating such self-contained agreements has the advantage of creating documents that are easier for consumers to review. In some cases, subscribers or relying parties may be deemed to be "consumers" under applicable law, who are subject to certain statutory or regulatory protections. Under the legal systems of civil law countries, incorporating a CP or CPS by reference may not be effective to bind consumers to the terms of an incorporated CP or CPS.


CPs and CPSs may be incorporated by reference in other documents, including:


* Interoperability agreements (including agreements between CAs for cross-certification, unilateral certification, or other forms of interoperation),

* 相互運用性の合意(相互認証、一方的な認証、またはその他の形式の相互運用のためのCA間の合意を含む)、

* Vendor agreements (under which a PKI vendor agrees to meet standards set forth in a CP or CPS), or

* ベンダー契約(PKIベンダーがCPまたはCPSに定められた標準を満たすことに同意するもの)、または

* A PDS. See [ABA2]

* PDS。 [ABA2]を参照

A PDS serves a similar function to a CPS Summary. It is a relatively short document containing only a subset of critical details about a PKI or CA. It may differ from a CPS Summary, however, in that its purpose is to act as a summary of information about the overall nature of the PKI, as opposed to simply a condensed form of the CPS.


Moreover, its purpose is to distill information about the PKI, as opposed to protecting security sensitive information contained in an unpublished CPS, although a PDS could also serve that function.


Just as writers may wish to refer to a CP or CPS or incorporate it by reference in an agreement or PDS, a CP or CPS may refer to other documents when establishing requirements or making disclosures. For instance, a CP may set requirements for certificate content by referring to an external document setting forth a standard certificate profile. Referencing external documents permits a CP or CPS to impose detailed requirements or make detailed disclosures without having to reprint lengthy provisions from other documents within the CP or CPS. Moreover, referencing a document in a CP or CPS is another useful way of dividing disclosures between public information and security sensitive confidential information (in addition to or as an alternative to publishing a CPS Summary). For example, a PKI may want to publish a CP or CPS, but maintain site construction parameters for CA high security zones as confidential information. In that case, the CP or CPS could reference an external manual or document containing the detailed site construction parameters.


Documents that a PKI may wish to refer to in a CP or CPS include:


* A security policy,

* セキュリティポリシー

* Training, operational, installation, and user manuals (which may contain operational requirements),

* トレーニング、運用、インストール、およびユーザーマニュアル(運用要件が含まれる場合があります)、

* Standards documents that apply to particular aspects of the PKI (such as standards specifying the level of protection offered by any hardware tokens used in the PKI or standards applicable to the site construction),

* PKIの特定の側面に適用される標準文書(PKIで使用されるハードウェアトークンによって提供される保護レベルを指定する標準、またはサイト構築に適用される標準など)、

* Key management plans,

* 主要な管理計画、

* Human resource guides and employment manuals (which may describe some aspects of personnel security practices), and

* 人事ガイドおよび雇用マニュアル(要員のセキュリティ慣行のいくつかの側面を説明している場合があります)、および

* E-mail policies (which may discuss subscriber and relying party responsibilities, as well as the implications of key management, if applicable). See [ABA2]

* 電子メールポリシー(サブスクライバーと証明書利用者の責任、および該当する場合はキー管理の影響について説明する場合があります)。 [ABA2]を参照

3.7. Set of Provisions
3.7. 規定のセット

A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics for use in expressing a CP or CPS employing the approach described in this framework by covering the topic appearing in Section 5 below. They are also described in detail in Section 4 below.


A CP can be expressed as a single set of provisions.


A CPS can be expressed as a single set of provisions with each component addressing the requirements of one or more certificate policies, or, alternatively, as an organized collection of sets of provisions. For example, a CPS could be expressed as a combination of the following:


(a) a list of certificate policies supported by the CPS;


(b) for each CP in (a), a set of provisions that contains statements responding to that CP by filling in details not stipulated in that policy or expressly left to the discretion of the CA (in its CPS) ; such statements serve to state how this particular CPS implements the requirements of the particular CP; or


(c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of CP.


The statements provided in (b) and (c) may augment or refine the stipulations of the applicable CP, but generally must not conflict with any of the stipulations of such CP. In certain cases, however, a policy authority may permit exceptions to the requirements in a CP, because certain compensating controls of the CA are disclosed in its CPS that allow the CA to provide assurances that are equivalent to the assurances provided by CAs that are in full compliance with the CP.

(b)および(c)で提供されるステートメントは、該当するCPの規定を強化または改善する場合がありますが、一般に、そのようなCPの規定のいずれとも矛盾してはなりません。ただし、特定のケースでは、ポリシー当局は、CPの要件に対する例外を許可する場合があります。これは、CAの特定の代替コントロールがCPSに開示されており、CAが、 CPへの完全な準拠。

This framework outlines the contents of a set of provisions, in terms of nine primary components, as follows:


1. Introduction 2. Publication and Repository 3. Identification and Authentication 4. Certificate Life-Cycle Operational Requirements 5. Facilities, Management, and Operational Controls 6. Technical Security Controls 7. Certificate, CRL, and OCSP Profile 8. Compliance audit 9. Other Business and Legal Matters PKIs can use this simple framework of nine primary components to write a simple CP or CPS. Moreover, a CA can use this same framework to write a subscriber agreement, relying party agreement, or agreement containing subscriber and relying party terms. If a CA uses this simple framework to construct an agreement, it can use paragraph 1 as an introduction or recitals, it can set forth the responsibilities of the parties in paragraphs 2-8, and it can use paragraph 9 to cover the business and legal issues described in more detail, using the ordering of Section 4.9 below (such as representations and warranties, disclaimers, and liability limitations). The ordering of topics in this simple framework and the business and legal matters Section 4.9 is the same as (or similar to) the ordering of topics in a typical software or other technology agreement. Therefore, a PKI can establish a set of core documents (with a CP, CPS, subscriber agreement, and relying party agreement) all having the same structure and ordering of topics, thereby facilitating comparisons and mappings among these documents and among the corresponding documents of other PKIs.

1.はじめに2.公開とリポジトリ3.識別と認証4.証明書のライフサイクル運用要件5.設備、管理、および運用管理6.技術的セキュリティ管理7.証明書、CRL、およびOCSPプロファイル8.コンプライアンス監査9。その他のビジネスおよび法的事項PKIは、9つの主要コンポーネントのこの単純なフレームワークを使用して、単純なCPまたはCPSを作成できます。さらに、CAはこの同じフレームワークを使用して、加入者契約、証明書利用者契約、または加入者と証明書利用者の条件を含む契約を作成できます。 CAがこの単純なフレームワークを使用して合意を構築する場合、パラグラフ1を導入部またはリサイタルとして使用でき、パラグラフ2〜8に当事者の責任を示し、パラグラフ9を使用してビジネスと法的事項をカバーできます。以下のセクション4.9の順序を使用して、より詳細に説明されている問題(表明および保証、免責事項、責任の制限など)この単純なフレームワークのトピックの順序と、ビジネスおよび法的事項のセクション4.9は、一般的なソフトウェアまたはその他の技術契約のトピックの順序と同じ(または類似)です。したがって、PKIは、トピックの構造と順序がすべて同じである一連のコアドキュメント(CP、CPS、サブスクライバー合意、および証明書利用者合意)を確立できます。これにより、これらのドキュメント間および対応するドキュメント間の比較とマッピングが容易になります。その他のPKI。

This simple framework may also be useful for agreements other than subscriber agreements and relying party agreements. For instance, a CA wishing to outsource certain services to an RA or certificate manufacturing authority (CMA) may find it useful to use this framework as a checklist to write a registration authority agreement or outsourcing agreement. Similarly, two CAs may wish to use this simple framework for the purpose of drafting a cross-certification, unilateral certification, or other interoperability agreement.


In short, the primary components of the simple framework (specified above) may meet the needs of drafters of short CPs, CPSs, subscriber agreements, and relying party agreements. Nonetheless, this framework is extensible, and its coverage of the nine components is flexible enough to meet the needs of drafters of comprehensive CPs and CPSs. Specifically, components appearing above can be further divided into subcomponents, and a subcomponent may comprise multiple elements. Section 4 provides a more detailed description of the contents of the above components, and their subcomponents. Drafters of CPs and CPSs are permitted to add additional levels of subcomponents below the subcomponents described in Section 4 for the purpose of meeting the needs of the drafter's particular PKI.

簡単に言うと、シンプルなフレームワークの主要コンポーネント(上記で指定)は、短いCP、CPS、加入者合意、および依拠当事者合意の起草者のニーズを満たすことができます。それにもかかわらず、このフレームワークは拡張可能であり、9つのコンポーネントのカバレッジは、包括的なCPおよびCPSの起草者のニーズを満たすのに十分な柔軟性があります。具体的には、上記のコンポーネントはさらにサブコンポーネントに分割でき、サブコンポーネントは複数の要素で構成されます。セクション4では、上記のコンポーネントとそのサブコンポーネントの内容の詳細を説明します。 CPとCPSのドラフトは、起草者の特定のPKIのニーズを満たすために、セクション4で説明されているサブコンポーネントの下にサブコンポーネントのレベルを追加できます。

4. Contents of a Set of Provisions
4. 一連の規定の内容

This section expands upon the contents of the simple framework of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a detailed CP or CPS.


While many topics are identified, it is not necessary for a CP or a CPS to include a concrete statement for every such topic. Rather, a particular CP or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular CP or CPS imposes no requirements or makes no disclosure. In this sense, the list of topics can be considered a checklist of topics for consideration by the CP or CPS writer.


It is recommended that each and every component and subcomponent be included in a CP or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude a provision concerning that topic. This drafting style protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions.


In a CP, it is possible to leave certain components, subcomponents, and/or elements unspecified, and to stipulate that the required information will be indicated in a policy qualifier, or the document to which a policy qualifier points. Such CPs can be considered parameterized definitions. The set of provisions should reference or define the required policy qualifier types and should specify any applicable default values.


4.1. Introductions
4.1. はじめに

This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the document (either the CP or the CPS being written) is targeted.


4.1.1. Overview
4.1.1. 概観

This subcomponent provides a general introduction to the document being written. This subcomponent can also be used to provide a synopsis of the PKI to which the CP or CPS applies. For example, it may set out different levels of assurance provided by certificates within the PKI. Depending on the complexity and scope of the particular PKI, a diagrammatic representation of the PKI might be useful here.


4.1.2. Document Name and Identification
4.1.2. 文書名と識別

This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the document. An example of such a document name would be the US Federal Government Policy for Secure E-mail.


4.1.3. PKI Participants
4.1.3. PKI参加者

This subcomponent describes the identity or types of entities that fill the roles of participants within a PKI, namely:


* Certification authorities, i.e., the entities that issue certificates. A CA is the issuing CA with respect to the certificates it issues and is the subject CA with respect to the CA certificate issued to it. CAs may be organized in a hierarchy in which an organization's CA issues certificates to CAs operated by subordinate organizations, such as a branch, division, or department within a larger organization.

* 証明機関、つまり証明書を発行するエンティティ。 CAは、発行する証明書に関する発行CAであり、発行されたCA証明書に関するサブジェクトCAです。 CAは、組織のCAが、大規模な組織内の支社、部門、部門などの下位組織が運営するCAに証明書を発行する階層に編成することができます。

* Registration authorities, i.e., the entities that establish enrollment procedures for end-user certificate applicants, perform identification and authentication of certificate applicants, initiate or pass along revocation requests for certificates, and approve applications for renewal or re-keying certificates on behalf of a CA. Subordinate organizations within a larger organization can act as RAs for the CA serving the entire organization, but RAs may also be external to the CA.

* 登録機関、つまり、エンドユーザーの証明書申請者の登録手順を確立し、証明書申請者の識別と認証を実行し、証明書の失効要求を開始または送信し、CAに代わって証明書の更新または再キーイングの申請を承認するエンティティ。より大きな組織内の下位組織は、組織全体にサービスを提供するCAのRAとして機能できますが、RAはCAの外部にある場合もあります。

* Subscribers. Examples of subscribers who receive certificates from a CA include employees of an organization with its own CA, banking or brokerage customers, organizations hosting e-commerce sites, organizations participating in a business-to-business exchange, and members of the public receiving certificates from a CA issuing certificates to the public at large.

* チャンネル登録者。 CAから証明書を受け取るサブスクライバーの例には、独自のCAを持つ組織の従業員、銀行または証券会社の顧客、eコマースサイトをホストしている組織、企業間取引に参加している組織、および証明書を受け取っているパブリックのメンバーが含まれます。一般に証明書を発行するCA。

* Relying parties. Examples of relying parties include employees of an organization having its own CA who receive digitally signed e-mails from other employees, persons buying goods and services from e-commerce sites, organizations participating in a business-to-business exchange who receive bids or orders from other participating organizations, and individuals and organizations doing business with subscribers who have received their certificates from a CA issuing certificates to the public. Relying parties may or may not also be subscribers within a given PKI.

* 依存パーティ。証明書利用者の例には、他の従業員からデジタル署名された電子メールを受信する独自​​のCAを持つ組織の従業員、電子商取引サイトから商品やサービスを購入する人、入札または注文を受け取る企業間取引に参加する組織が含まれます。他の参加組織、および証明書を発行するCAから証明書を公に受け取った加入者とビジネスを行う個人および組織から。証明書利用者は、特定のPKI内のサブスクライバーである場合とそうでない場合があります。

* Other participants, such as certificate manufacturing authorities, providers of repository services, and other entities providing PKI-related services.

* 証明書製造機関、リポジトリサービスのプロバイダー、およびPKI関連サービスを提供するその他のエンティティなど、その他の参加者。

4.1.4. Certificate Usage
4.1.4. 証明書の使用

This subcomponent contains:


* A list or the types of applications for which the issued certificates are suitable, such as electronic mail, retail transactions, contracts, and a travel order, and/or

* 電子メール、小売取引、契約、旅行注文など、発行された証明書が適しているアプリケーションのリストまたはタイプ、および/または

* A list or the types of applications for which use of the issued certificates is prohibited.

* 発行された証明書の使用が禁止されているアプリケーションのリストまたは種類。

In the case of a CP or CPS describing different levels of assurance, this subcomponent can describe applications or types of applications that are appropriate or inappropriate for the different levels of assurance.


4.1.5. Policy Administration
4.1.5. ポリシー管理

This subcomponent includes the name and mailing address of the organization that is responsible for the drafting, registering, maintaining, and updating of this CP or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person. As an alternative to naming an actual person, the document may name a title or role, an e-mail alias, and other generalized contact information. In some cases, the organization may state that its contact person, alone or in combination with others, is available to answer questions about the document.


Moreover, when a formal or informal policy authority is responsible for determining whether a CA should be allowed to operate within or interoperate with a PKI, it may wish to approve the CPS of the CA as being suitable for the policy authority's CP. If so, this subcomponent can include the name or title, electronic mail address (or alias), telephone number, fax number, and other generalized information of the entity in charge of making such a determination. Finally, in this case, this subcomponent also includes the procedures by which this determination is made.


4.1.6. Definitions and Acronyms
4.1.6. 定義と頭字語

This subcomponent contains a list of definitions for defined terms used within the document, as well as a list of acronyms in the document and their meanings.


4.2. Publication and Repository Responsibilities
4.2. 公開とリポジトリの責任

This component contains any applicable provisions regarding:


* An identification of the entity or entities that operate repositories within the PKI, such as a CA, certificate manufacturing authority, or independent repository service provider;

* CA、証明書製造局、独立したリポジトリサービスプロバイダーなど、PKI内でリポジトリを操作するエンティティの識別情報。

* The responsibility of a PKI participant to publish information regarding its practices, certificates, and the current status of such certificates, which may include the responsibilities of making the CP or CPS publicly available using various mechanisms and of identifying components, subcomponents, and elements of such documents that exist but are not made publicly available, for instance, security controls, clearance procedures, or trade secret information due to their sensitivity;

* PKI参加者がその慣行、証明書、およびそのような証明書の現在のステータスに関する情報を公開する責任。これには、さまざまなメカニズムを使用してCPまたはCPSを公開し、コンポーネント、サブコンポーネント、およびその要素を識別する責任を含む場合があります。存在しているが公開されていないドキュメント(セキュリティ管理、クリアランス手順、企業秘密情報など)。

* When information must be published and the frequency of publication; and

* 情報を公開する必要がある場合とその頻度。そして

* Access control on published information objects including CPs, CPS, certificates, certificate status, and CRLs.

* CP、CPS、証明書、証明書ステータス、CRLなどの公開された情報オブジェクトのアクセス制御。

4.3. Identification and Authentication
4.3. 識別と認証

This component describes the procedures used to authenticate the identity and/or other attributes of an end-user certificate applicant to a CA or RA prior to certificate issuance. In addition, the component sets forth the procedures for authenticating the identity and the criteria for accepting applicants of entities seeking to become CAs, RAs, or other entities operating in or interoperating with a PKI. It also describes how parties requesting re-key or revocation are authenticated. This component also addresses naming practices, including the recognition of trademark rights in certain names.


4.3.1. Naming
4.3.1. ネーミング

This subcomponent includes the following elements regarding naming and identification of the subscribers:


* Types of names assigned to the subject, such as X.500 distinguished names; RFC-822 names; and X.400 names;

* X.500識別名など、件名に割り当てられた名前のタイプ。 RFC-822名。およびX.400の名前。

* Whether names have to be meaningful or not;(3)

* 名前が意味を持つ必要があるかどうか;(3)

* Whether or not subscribers can be anonymous or pseudonymous, and if they can, what names are assigned to or can be used by anonymous subscribers;

* サブスクライバーを匿名または仮名にできるかどうか、およびできる場合は、匿名サブスクライバーに割り当てられている、または匿名サブスクライバーが使用できる名前。

* Rules for interpreting various name forms, such as the X.500 standard and RFC-822;

* X.500標準やRFC-822など、さまざまな名前の形式を解釈するための規則。

* Whether names have to be unique; and

* 名前が一意である必要があるかどうか。そして

* Recognition, authentication, and the role of trademarks.

* 商標の認識、認証、および役割。

4.3.2. Initial Identity Validation
4.3.2. 最初の本人確認

This subcomponent contains the following elements for the identification and authentication procedures for the initial registration for each subject type (CA, RA, subscriber, or other participant):


* If and how the subject must prove possession of the companion private key for the public key being registered, for example, a digital signature in the certificate request message;(4)

* サブジェクトが、登録されている公開鍵のコンパニオン秘密鍵の所有を証明する必要がある場合、その方法(たとえば、証明書要求メッセージのデジタル署名)(4)

* Identification and authentication requirements for organizational identity of subscriber or participant (CA; RA; subscriber (in the case of certificates issued to organizations or devices controlled by an organization), or other participant), for example, consulting the database of a service that identifies organizations or inspecting an organization's articles of incorporation;

* サブスクライバーまたは参加者(CA、RA、サブスクライバー(組織または組織によって制御されるデバイスに発行された証明書の場合)、または他の参加者)の組織IDの識別および認証要件、たとえば、特定するサービスのデータベースの参照組織または組織の定款の検査;

* Identification and authentication requirements for an individual subscriber or a person acting on behalf of an organizational subscriber or participant (CA, RA, in the case of certificates issued to organizations or devices controlled by an organization, the subscriber, or other participant),(5) including:

* 個々のサブスクライバーまたは組織のサブスクライバーまたは参加者(CA、RA、組織、サブスクライバー、または他の参加者によって制御される組織またはデバイスに対して発行された証明書の場合)の代理として行動する人の識別および認証要件、(5 )含む:

* Type of documentation and/or number of identification credentials required;

* 必要な書類の種類および/または身分証明書の数;

* How a CA or RA authenticates the identity of the organization or individual based on the documentation or credentials provided;

* CAまたはRAが、提供されたドキュメントまたは資格情報に基づいて組織または個人のIDを認証する方法。

* If the individual must personally present to the authenticating CA or RA;

* 個人が認証CAまたはRAに個人的に提示する必要がある場合。

* How an individual as an organizational person is authenticated, such as by reference to duly signed authorization documents or a corporate identification badge.

* 正当に署名された承認ドキュメントや企業IDバッジなどを参照して、組織の個人としての個人を認証する方法。

* List of subscriber information that is not verified (called "non-verified subscriber information") during the initial registration;

* 初期登録時に検証されない加入者情報(「検証されていない加入者情報」と呼ばれます)のリスト。

* Validation of authority involves a determination of whether a person has specific rights, entitlements, or permissions, including the permission to act on behalf of an organization to obtain a certificate; and

* 権限の検証には、証明書を取得するために組織に代わって行動する許可を含む、特定の権利、資格、または許可があるかどうかの決定が含まれます。そして

* In the case of applications by a CA wishing to operate within, or interoperate with, a PKI, this subcomponent contains the criteria by which a PKI, CA, or policy authority determines whether or not the CA is suitable for such operations or interoperation. Such interoperation may include cross-certification, unilateral certification, or other forms of interoperation.

* PKI内での操作または相互運用を希望するCAによるアプリケーションの場合、このサブコンポーネントには、PKI、CA、またはポリシー機関がCAがそのような操作または相互運用に適しているかどうかを判断する基準が含まれます。そのような相互運用には、相互認証、一方的な認証、または他の形式の相互運用が含まれる場合があります。

4.3.3. Identification and Authentication for Re-key Requests
4.3.3. 鍵更新要求の識別と認証

This subcomponent addresses the following elements for the identification and authentication procedures for re-key for each subject type (CA, RA, subscriber, and other participants):


* Identification and authentication requirements for routine re-key, such as a re-key request that contains the new key and is signed using the current valid key; and

* 新しい鍵を含み、現在の有効な鍵を使用して署名された鍵の再発行リクエストなど、定期的な鍵の再発行の識別と認証の要件。そして

* Identification and authentication requirements for re-key after certificate revocation. One example is the use of the same process as the initial identity validation.

* 証明書失効後の鍵再生成の識別と認証の要件。 1つの例は、最初のID検証と同じプロセスの使用です。

4.3.4. Identification and Authentication for Revocation Requests
4.3.4. 失効リクエストの識別と認証

This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, subscriber, and other participant). Examples include a revocation request digitally signed with the private key whose companion public key needs to be revoked, and a digitally signed request by the RA.


4.4. Certificate Life-Cycle Operational Requirements
4.4. 証明書のライフサイクル運用要件

This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.


Within each subcomponent, separate consideration may need to be given to subject CAs, RAs, subscribers, and other participants.


4.4.1. Certificate Application
4.4.1. 証明書申請

This subcomponent is used to address the following requirements regarding subject certificate application:


* Who can submit a certificate application, such as a certificate subject or the RA; and

* 証明書のサブジェクトやRAなどの証明書申請を提出できる人;そして

* Enrollment process used by subjects to submit certificate applications and responsibilities in connection with this process. An example of this process is where the subject generates the key pair and sends a certificate request to the RA. The RA validates and signs the request and sends it to the CA. A CA or RA may have the responsibility of establishing an enrollment process in order to receive certificate applications. Likewise, certificate applicants may have the responsibility of providing accurate information on their certificate applications.

* このプロセスに関連して証明書の申請と責任を提出するためにサブジェクトが使用する登録プロセス。このプロセスの例は、サブジェクトがキーペアを生成し、証明書要求をRAに送信する場合です。 RAは要求を検証して署名し、CAに送信します。 CAまたはRAは、証明書アプリケーションを受け取るために登録プロセスを確立する責任があります。同様に、証明書申請者は、証明書申請に関する正確な情報を提供する責任があります。

4.4.2. Certificate Application Processing
4.4.2. 証明書申請処理

This subcomponent is used to describe the procedure for processing certificate applications. For example, the issuing CA and RA may perform identification and authentication procedures to validate the certificate application. Following such steps, the CA or RA will either approve or reject the certificate application, perhaps upon the application of certain criteria. Finally, this subcomponent sets a time limit during which a CA and/or RA must act on and process a certificate application.


4.4.3. Certificate Issuance
4.4.3. 証明書の発行

This subcomponent is used to describe the following certificate issuance related elements:


* Actions performed by the CA during the issuance of the certificate, for example a procedure whereby the CA validates the RA signature and RA authority and generates a certificate; and

* 証明書の発行中にCAによって実行されるアクション。たとえば、CAがRA署名とRA機関を検証して証明書を生成する手順。そして

* Notification mechanisms, if any, used by the CA to notify the subscriber of the issuance of the certificate; an example is a procedure under which the CA e-mails the certificate to the subscriber or the RA or e-mails information permitting the subscriber to download the certificate from a web site.

* 証明書の発行をサブスクライバーに通知するためにCAが使用する通知メカニズム(ある場合)。例は、CAがサブスクライバーまたはRAに証明書を電子メールで送信するか、サブスクライバーがWebサイトから証明書をダウンロードできるようにする情報を電子メールで送信する手順です。

4.4.4. Certificate Acceptance
4.4.4. 証明書の承認

This subcomponent addresses the following:


* The conduct of an applicant that will be deemed to constitute acceptance of the certificate. Such conduct may include affirmative steps to indicate acceptance, actions implying acceptance, or a failure to object to the certificate or its content. For instance, acceptance may be deemed to occur if the CA does not receive any notice from the subscriber within a certain time period; a subscriber may send a signed message accepting the certificate; or a subscriber may send a signed message rejecting the certificate where the message includes the reason for rejection and identifies the fields in the certificate that are incorrect or incomplete.

* 証明書の受理を構成するとみなされる申請者の行為。そのような行為には、承認、承認を意味する行動、または証明書またはその内容に対する異議申し立ての失敗を示す肯定的な手順が含まれる場合があります。たとえば、CAが特定の期間内に加入者から通知を受信しない場合、承諾が発生したと見なされる場合があります。加入者は、証明書を受け入れる署名付きメッセージを送信できます。または、サブスクライバーは、証明書を拒否する署名付きメッセージを送信できます。メッセージには拒否の理由が含まれており、証明書のフィールドが正しくないか不完全であることを示します。

* Publication of the certificate by the CA. For example, the CA may post the certificate to an X.500 or LDAP repository.

* CAによる証明書の公開。たとえば、CAは証明書をX.500またはLDAPリポジトリに投稿できます。

* Notification of certificate issuance by the CA to other entities. As an example, the CA may send the certificate to the RA.

* CAによる他のエンティティへの証明書発行の通知。例として、CAは証明書をRAに送信します。

4.4.5. Key Pair and Certificate Usage
4.4.5. 鍵ペアと証明書の使用

This subcomponent is used to describe the responsibilities relating to the use of keys and certificates, including:


* Subscriber responsibilities relating to use of the subscriber's private key and certificate. For example, the subscriber may be required to use a private key and certificate only for appropriate applications as set forth in the CP and in consistency with applicable certificate content (e.g., key usage field). Use of a private key and certificate are subject to the terms of the subscriber agreement, the use of a private key is permitted only after the subscriber has accepted the corresponding certificate, or the subscriber must discontinue use of the private key following the expiration or revocation of the certificate.

* サブスクライバーの秘密キーと証明書の使用に関するサブスクライバーの責任。たとえば、サブスクライバーは、CPに記載されている適切なアプリケーションに対してのみ、適用される証明書の内容(たとえば、キー使用法フィールド)と整合性のある秘密鍵と証明書の使用を要求される場合があります。秘密鍵と証明書の使用は、加入者契約の条件に従います。秘密鍵の使用は、加入者が対応する証明書を受け入れた後にのみ許可されます。または、加入者は、有効期限または失効後に秘密鍵の使用を中止する必要があります。証明書の。

* Relying party responsibilities relating to the use of a subscriber's public key and certificate. For instance, a relying party may be obligated to rely on certificates only for appropriate applications as set forth in the CP and in consistency with applicable certificate content (e.g., key usage field), successfully perform public key operations as a condition of relying on a certificate, assume responsibility to check the status of a certificate using one of the required or permitted mechanisms set forth in the CP/CPS (see Section 4.4.9 below), and assent to the terms of the applicable relying party agreement as a condition of relying on the certificate.

*サブスクライバーの公開キーと証明書の使用に関する証明書利用者の責任。たとえば、証明書利用者は、CPに記載されている適切なアプリケーションについてのみ証明書に依存し、該当する証明書の内容(たとえば、キー使用法フィールド)に準拠し、証明書に依存する条件として公開鍵操作を正常に実行する義務がある場合があります。証明書、CP / CPS(下記のセクション4.4.9を参照)に記載されている必要または許可されたメカニズムのいずれかを使用して証明書のステータスをチェックし、適用される証明書利用者の条件に同意する責任を負う証明書に依存しています。

4.4.6. Certificate Renewal
4.4.6. 証明書の更新

This subcomponent is used to describe the following elements related to certificate renewal. Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber or other participant's public key or any other information in the certificate:


* Circumstances under which certificate renewal takes place, such as where the certificate life has expired, but the policy permits the same key pair to be reused;

* 証明書の有効期限が切れている場合など、証明書の更新が行われる状況。ただし、ポリシーでは同じキーペアの再利用が許可されています。

* Who may request certificate renewal, for instance, the subscriber, RA, or the CA may automatically renew an end-user subscriber certificate;

* たとえば、サブスクライバー、RA、またはCAが証明書の更新を要求できるのは、エンドユーザーサブスクライバー証明書を自動的に更新する場合です。

* A CA or RA's procedures to process renewal requests to issue the new certificate, for example, the use of a token, such as a password, to re-authenticate the subscriber, or procedures that are the same as the initial certificate issuance;

* 新しい証明書を発行するための更新要求を処理するCAまたはRAの手順(たとえば、パスワードなどのトークンの使用、サブスクライバーの再認証)、または最初の証明書の発行と同じ手順。

* Notification of the new certificate to the subscriber;

* サブスクライバーへの新しい証明書の通知。

* Conduct constituting acceptance of the certificate;

* 証明書の受理を構成する行為;

* Publication of the certificate by the CA; and

* CAによる証明書の公開。そして

* Notification of certificate issuance by the CA to other entities.

* CAによる他のエンティティへの証明書発行の通知。

4.4.7. Certificate Re-key
4.4.7. 証明書の再キー

This subcomponent is used to describe the following elements related to a subscriber or other participant generating a new key pair and applying for the issuance of a new certificate that certifies the new public key:


* Circumstances under which certificate re-key can or must take place, such as after a certificate is revoked for reasons of key compromise or after a certificate has expired and the usage period of the key pair has also expired;

* 鍵の侵害の理由で証明書が失効した後、または証明書の有効期限が切れて鍵ペアの使用期間も満了した後など、証明書の再鍵を実行できる、または行う必要がある状況。

* Who may request certificate re-key, for example, the subscriber;

* 誰が証明書の再キーを要求するかもしれません、例えば、加入者;

* A CA or RA's procedures to process re-keying requests to issue the new certificate, such as procedures that are the same as the initial certificate issuance;

* 新しい証明書を発行するためのキー更新要求を処理するためのCAまたはRAの手順(最初の証明書の発行と同じ手順など)。

* Notification of the new certificate to the subscriber;

* サブスクライバーへの新しい証明書の通知。

* Conduct constituting acceptance of the certificate;

* 証明書の受理を構成する行為;

* Publication of the certificate by the CA; and

* CAによる証明書の公開。そして

* Notification of certificate issuance by the CA to other entities.

* CAによる他のエンティティへの証明書発行の通知。

4.4.8. Certificate Modification
4.4.8. 証明書の変更

This subcomponent is used to describe the following elements related to the issuance of a new certificate (6) due to changes in the information in the certificate other than the subscriber public key:


* Circumstances under which certificate modification can take place, such as name change, role change, reorganization resulting in a change in the DN;

* 名前の変更、役割の変更、DNの変更をもたらす再編成など、証明書の変更が行われる状況。

* Who may request certificate modification, for instance, subscribers, human resources personnel, or the RA;

* たとえば、加入者、人事担当者、またはRAなど、証明書の変更を要求できる人。

* A CA or RA's procedures to process modification requests to issue the new certificate, such as procedures that are the same as the initial certificate issuance;

* 新しい証明書を発行するための変更要求を処理するCAまたはRAの手順(最初の証明書の発行と同じ手順など)。

* Notification of the new certificate to the subscriber;

* サブスクライバーへの新しい証明書の通知。

* Conduct constituting acceptance of the certificate;

* 証明書の受理を構成する行為;

* Publication of the certificate by the CA; and

* CAによる証明書の公開。そして

* Notification of certificate issuance by the CA to other entities.

* CAによる他のエンティティへの証明書発行の通知。

4.4.9. Certificate Revocation and Suspension
4.4.9. 証明書の失効と一時停止

This subcomponent addresses the following:


* Circumstances under which a certificate may be suspended and circumstances under which it must be revoked, for instance, in cases of subscriber employment termination, loss of cryptographic token, or suspected compromise of the private key;

* 証明書が一時停止される可能性のある状況、および例えば、加入者の雇用の終了、暗号トークンの喪失、または秘密鍵の侵害の疑いがある場合に、証明書を取り消す必要がある状況。

* Who can request the revocation of the participant's certificate, for example, the subscriber, RA, or CA in the case of an end-user subscriber certificate.

* 参加者の証明書(エンドユーザーサブスクライバー証明書の場合はサブスクライバー、RA、CAなど)の失効を要求できるユーザー。

* Procedures used for certificate revocation request, such as a digitally signed message from the RA, a digitally signed message from the subscriber, or a phone call from the RA;

* RAからのデジタル署名付きメッセージ、サブスクライバーからのデジタル署名付きメッセージ、またはRAからの電話など、証明書の取り消し要求に使用される手順。

* The grace period available to the subscriber, within which the subscriber must make a revocation request;

* サブスクライバーが利用できる猶予期間。この猶予期間内にサブスクライバーは失効要求を行う必要があります。

* The time within which CA must process the revocation request;

* CAが失効リクエストを処理する必要のある時間。

* The mechanisms, if any, that a relying party may use or must use in order to check the status of certificates on which they wish to rely;

* 依存パーティが依存したい証明書のステータスをチェックするために、依存パーティが使用する、または使用する必要があるメカニズム。

* If a CRL mechanism is used, the issuance frequency;

* CRLメカニズムが使用されている場合、発行頻度。

* If a CRL mechanism is used, maximum latency between the generation of CRLs and posting of the CRLs to the repository (in other words, the maximum amount of processing- and communication-related delays in posting CRLs to the repository after the CRLs are generated);

* CRLメカニズムが使用されている場合、CRLの生成とCRLのリポジトリーへのポストの間の最大待ち時間(つまり、CRLが生成された後のリポジトリーへのCRLのポストにおける処理および通信関連の最大遅延) ;

* On-line revocation/status checking availability, for instance, OCSP and a web site to which status inquiries can be submitted;

* オンラインの失効/ステータスチェックの可用性。たとえば、OCSPやステータスの問い合わせを送信できるWebサイト。

* Requirements on relying parties to perform on-line revocation/status checks;

* オンライン失効/ステータスチェックを実行するための依拠当事者の要件。

* Other forms of revocation advertisements available;

* 利用可能な失効広告の他の形式。

* Any variations of the above stipulations for which suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation).

* 中断または取り消しが秘密鍵の侵害の結果である上記の規定のバリエーション(中断または取り消しの他の理由とは対照的)。

* Circumstances under which a certificate may be suspended;

* 証明書が一時停止される可能性のある状況。

* Who can request the suspension of a certificate, for example, the subscriber, human resources personnel, a supervisor of the subscriber, or the RA in the case of an end-user subscriber certificate;

* 誰が証明書の一時停止を要求できるか、たとえば、加入者、人事担当者、加入者の監督者、またはエンドユーザーの加入者証明書の場合はRA。

* Procedures to request certificate suspension, such as a digitally signed message from the subscriber or RA, or a phone call from the RA; and

* サブスクライバーまたはRAからのデジタル署名付きメッセージ、またはRAからの電話など、証明書の一時停止を要求する手順。そして

* How long the suspension may last.

* 停止が続く期間。

4.4.10. Certificate Status Services
4.4.10. 証明書ステータスサービス

This subcomponent addresses the certificate status checking services available to the relying parties, including:


* The operational characteristics of certificate status checking services;

* 証明書ステータスチェックサービスの運用特性。

* The availability of such services, and any applicable policies on unavailability; and

* そのようなサービスの利用可能性、および利用不可に関する適用可能なポリシー。そして

* Any optional features of such services.

* そのようなサービスのオプション機能。

4.4.11. End of Subscription
4.4.11. サブスクリプションの終了

This subcomponent addresses procedures used by the subscriber to end subscription to the CA services, including:


* The revocation of certificates at the end of subscription (which may differ, depending on whether the end of subscription was due to the expiration of the certificate or termination of the service).

* サブスクリプションの終了時の証明書の失効(サブスクリプションの終了が証明書の期限切れによるものか、サービスの終了によるものかによって異なります)。

4.4.12. Key Escrow and Recovery
4.4.12. キーエスクローと回復

This subcomponent contains the following elements to identify the policies and practices relating to the escrowing, and/or recovery of private keys where private key escrow services are available (through the CA or other trusted third parties):


* Identification of the document containing private key escrow and recovery policies and practices or a listing of such policies and practices; and

* 秘密鍵のエスクローと回復のポリシーと実践を含む文書の識別、またはそのようなポリシーと実践のリスト。そして

* Identification of the document containing session key encapsulation and recovery policies and practices or a listing of such policies and practices.

* セッションキーのカプセル化と回復のポリシーと実践を含むドキュメントの識別、またはそのようなポリシーと実践のリスト。

4.5. Management, Operational, and Physical Controls
4.5. 管理、運用、および物理的制御

This component describes non-technical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to securely perform the functions of key generation, subject authentication, certificate issuance, certificate revocation, auditing, and archiving.


This component can also be used to define non-technical security controls on repositories, subject CAs, RAs, subscribers, and other participants. The non-technical security controls for the subject CAs, RAs, subscribers, and other participants could be the same, similar, or very different.


These non-technical security controls are critical to trusting the certificates since lack of security may compromise CA operations resulting for example, in the creation of certificates or CRLs with erroneous information or compromising the CA private key.


Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, the issuing CA, repository, subject CAs, RAs, subscribers, and other participants.


4.5.1. Physical Security Controls
4.5.1. 物理的セキュリティ管理

In this subcomponent, the physical controls on the facility housing the entity systems are described. Topics addressed may include:


* Site location and construction, such as the construction requirements for high-security zones and the use of locked rooms, cages, safes, and cabinets;

* 高セキュリティゾーンの建設要件、施錠された部屋、ケージ、金庫、キャビネットの使用など、サイトの場所と建設。

* Physical access, i.e., mechanisms to control access from one area of the facility to another or access into high-security zones, such as locating CA operations in a secure computer room monitored by guards or security alarms and requiring movement from zone to zone to be accomplished using a token, biometric readers, and/or access control lists;

* 物理的アクセス、つまり、施設のある領域から別の領域へのアクセス、または高セキュリティゾーンへのアクセスを制御するメカニズム。たとえば、警備員またはセキュリティアラームによって監視されている安全なコンピュータールームでCAの操作を特定し、ゾーンからゾーンへの移動を要求するトークン、生体認証リーダー、および/またはアクセス制御リストを使用して達成されます。

* Power and air conditioning;

* 電源とエアコン。

* Water exposures;

* 水への暴露;

* Fire prevention and protection;

* 防火と保護;

* Media storage, for example, requiring the storage of backup media in a separate location that is physically secure and protected from fire and water damage;

* メディアの保管。たとえば、物理的に安全で火災や水害から保護された別の場所にバックアップメディアを保管する必要があります。

* Waste disposal; and

* 廃棄物処理;そして

* Off-site backup.

* オフサイトバックアップ。

4.5.2. Procedural Controls
4.5.2. 手続き管理

In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role. Examples of trusted roles include system administrators, security officers, and system auditors.


For each task identified, the number of individuals required to perform the task (n out m rule) should be stated for each role. Identification and authentication requirements for each role may also be defined.

識別された各タスクについて、タスクを実行するために必要な個人の数(n out mルール)を各ロールに記載する必要があります。各ロールの識別と認証の要件も定義できます。

This component also includes the separation of duties in terms of the roles that cannot be performed by the same individuals.


4.5.3. Personnel Security Controls
4.5.3. 人事セキュリティ管理

This subcomponent addresses the following:


* Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experiences, and official government clearances that candidates for these positions must have before being hired;

* 信頼された役割またはその他の重要な役割を満たすための条件として、担当者が持っている必要がある資格、経験、およびクリアランス。例としては、資格、職歴、およびこれらの役職の候補者が採用される前に持っていなければならない政府の認可が含まれます。

* Background checks and clearance procedures that are required in connection with the hiring of personnel filling trusted roles or perhaps other important roles; such roles may require a check of their criminal records, references, and additional clearances that a participant undertakes after a decision has been made to hire a particular person;

* 信頼できる役割またはおそらく他の重要な役割を担当する人材の採用に関連して必要となる身元調査とクリアランス手順。そのような役割では、特定の人を雇うことを決定した後に参加者が行う犯罪歴、参照、および追加の許可のチェックが必要になる場合があります。

* Training requirements and training procedures for each role following the hiring of personnel;

* 人材採用後の各ロールのトレーニング要件とトレーニング手順。

* Any retraining period and retraining procedures for each role after completion of initial training;

* 最初のトレーニングの完了後の各役割の再トレーニング期間と再トレーニング手順。

* Frequency and sequence for job rotation among various roles;

* さまざまな役割間のジョブローテーションの頻度と順序。

* Sanctions against personnel for unauthorized actions, unauthorized use of authority, and unauthorized use of entity systems for the purpose of imposing accountability on a participant's personnel;

* 参加者の担当者に説明責任を課すことを目的とした、不正行為、権限の不正使用、およびエンティティシステムの不正使用に対する職員に対する制裁。

* Controls on personnel that are independent contractors rather than employees of the entity; examples include:

* 事業体の従業員ではなく独立した請負業者である要員の管理。例は次のとおりです。

- Bonding requirements on contract personnel;

- 契約担当者の結合要件;

- Contractual requirements including indemnification for damages due to the actions of the contractor personnel;

- 請負業者の担当者の行為による損害の補償を含む契約上の要件。

- Auditing and monitoring of contractor personnel; and

- 請負業者の監査と監視;そして

- Other controls on contracting personnel.

- 契約社員に関するその他の管理。

* Documentation to be supplied to personnel during initial training, retraining, or otherwise.

* 初期トレーニング、再トレーニング、その他の際に担当者に提供されるドキュメント。

4.5.4. Audit Logging Procedures
4.5.4. 監査ロギング手順

This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining a secure environment. Elements include the following:


* Types of events recorded, such as certificate lifecycle operations, attempts to access the system, and requests made to the system;

* 証明書のライフサイクル操作、システムへのアクセスの試行、システムに対して行われた要求など、記録されたイベントのタイプ。

* Frequency with which audit logs are processed or archived, for example, weekly, following an alarm or anomalous event, or when ever the audit log is n% full;

* 監査ログが処理またはアーカイブされる頻度。たとえば、毎週、アラームまたは異常イベントの後、または監査ログがn%いっぱいになったとき。

* Period for which audit logs are kept;

* 監査ログが保持される期間。

* Protection of audit logs:

* 監査ログの保護:

- Who can view audit logs, for example only the audit administrator;

- 誰が監査ログを表示できるか(例えば、監査管理者のみ)。

- Protection against modification of audit logs, for instance a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of rotating the audit file; and

- 監査ログの変更に対する保護。たとえば、誰も監査レコードを変更または削除できない、または監査管理者だけが監査ファイルをローテーションの一部として削除できるという要件。そして

- Protection against deletion of audit logs.

- 監査ログの削除に対する保護。

* Audit log back up procedures;

* 監査ログのバックアップ手順。

* Whether the audit log accumulation system is internal or external to the entity;

* 監査ログ蓄積システムがエンティティの内部か外部か。

* Whether the subject who caused an audit event to occur is notified of the audit action; and

* 監査イベントを発生させた対象者に監査アクションが通知されるかどうか。そして

* Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.

* たとえば、システムのセキュリティを侵害する潜在的な試みを識別するツールを介して監査データが実行される脆弱性評価。

4.5.5. Records Archival
4.5.5. レコードのアーカイブ

This subcomponent is used to describe general records archival (or records retention) policies, including the following:


* Types of records that are archived, for example, all audit data, certificate application information, and documentation supporting certificate applications;

* アーカイブされるレコードのタイプ。たとえば、すべての監査データ、証明書アプリケーション情報、および証明書アプリケーションをサポートするドキュメント。

* Retention period for an archive;

* アーカイブの保存期間。

* Protection of an archive:

* アーカイブの保護:

- Who can view the archive, for example, a requirement that only the audit administrator may view the archive;

- 誰がアーカイブを表示できるか(たとえば、監査管理者のみがアーカイブを表示できるという要件)。

- Protection against modification of the archive, such as securely storing the data on a write once medium;

- ライトワンスメディアにデータを安全に保存するなど、アーカイブの変更に対する保護。

- Protection against deletion of the archive;

- アーカイブの削除に対する保護。

- Protection against the deterioration of the media on which the archive is stored, such as a requirement for data to be migrated periodically to fresh media; and

- データを定期的に新しいメディアに移行する必要があるなど、アーカイブが保存されているメディアの劣化に対する保護。そして

- Protection against obsolescence of hardware, operating systems, and other software, by, for example, retaining as part of the archive the hardware, operating systems, and/or other software in order to permit access to and use of archived records over time.

- ハードウェア、オペレーティングシステム、およびその他のソフトウェアの陳腐化に対する保護。たとえば、アーカイブされたレコードへのアクセスと使用を許可するために、ハードウェア、オペレーティングシステム、および/またはその他のソフトウェアをアーカイブの一部として保持します。

* Archive backup procedures;

* アーカイブのバックアップ手順。

* Requirements for time-stamping of records;

* レコードのタイムスタンプの要件。

* Whether the archive collection system is internal or external; and

* アーカイブコレクションシステムが内部か外部か。そして

* Procedures to obtain and verify archive information, such as a requirement that two separate copies of the archive data be kept under the control of two persons, and that the two copies be compared in order to ensure that the archive information is accurate.

* アーカイブデータの2つの別々のコピーが2人の管理下に置かれ、アーカイブ情報が正確であることを確認するために2つのコピーが比較されるという要件など、アーカイブ情報を取得および検証する手順。

4.5.6. Key Changeover
4.5.6. キーチェンジオーバー

This subcomponent describes the procedures to provide a new public key to a CA's users following a re-key by the CA. These procedures may be the same as the procedure for providing the current key. Also, the new key may be certified in a certificate signed using the old key.


4.5.7. Compromise and Disaster Recovery
4.5.7. 妥協と災害復旧

This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately:


* Identification or listing of the applicable incident and compromise reporting and handling procedures.

* 該当するインシデントの識別またはリスト、および妥協の報告と処理手順。

* The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to be corrupted. These procedures describe how a secure environment is re-established, which certificates are revoked, whether the entity key is revoked, how the new entity public key is provided to the users, and how the subjects are re-certified.

* コンピューティングリソース、ソフトウェア、データが破損している、または破損している疑いがある場合に使用される回復手順。これらの手順では、安全な環境が再確立される方法、取り消される証明書、エンティティキーが取り消されるかどうか、新しいエンティティ公開鍵がユーザーに提供される方法、およびサブジェクトが再認証される方法について説明します。

* The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is re-established, how the new entity public key is provided to the users, and how the subjects are re-certified.

* エンティティキーが侵害された場合に使用される回復手順。これらの手順では、安全な環境を再確立する方法、新しいエンティティの公開キーをユーザーに提供する方法、およびサブジェクトを再認証する方法について説明します。

* The entity's capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a remote hot-site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a remote site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.

* 自然災害またはその他の災害後の事業継続性を確保するための企業の能力。このような機能には、操作を回復できるリモートホットサイトの可用性が含まれる場合があります。また、自然災害やその他の災害が発生した後、元のサイトまたはリモートサイトで安全な環境が再確立される前に、施設を保護するための手順を含めることもできます。たとえば、地震で被害を受けたサイトからの機密性の高い物質の盗難を防ぐための手順。

4.5.8. CA or RA Termination
4.5.8. CAまたはRAの終了

This subcomponent describes requirements relating to procedures for termination and termination notification of a CA or RA, including the identity of the custodian of CA and RA archival records.


4.6. Technical Security Controls
4.6. 技術的なセキュリティ管理

This component is used to define the security measures taken by the issuing CA to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually-held key shares). This component may also be used to impose constraints on repositories, subject CAs, subscribers, and other participants to protect their private keys, activation data for their private keys, and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.


This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, auditing, and archiving. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls.


This component can also be used to define other technical security controls on repositories, subject CAs, RAs, subscribers, and other participants.


4.6.1. Key Pair Generation and Installation
4.6.1. 鍵ペアの生成とインストール

Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these types of entities, the following questions potentially need to be answered:


1. Who generates the entity public, private key pair? Possibilities include the subscriber, RA, or CA. Also, how is the key generation performed? Is the key generation performed by hardware or software?

1. エンティティの公開鍵と秘密鍵のペアを生成するのは誰ですか?可能性には、加入者、RA、またはCAが含まれます。また、キー生成はどのように実行されますか?鍵の生成はハードウェアまたはソフトウェアによって実行されますか?

2. How is the private key provided securely to the entity? Possibilities include a situation where the entity has generated it and therefore already has it, handing the entity the private key physically, mailing a token containing the private key securely, or delivering it in an SSL session.

2. 秘密鍵はどのようにしてエンティティに安全に提供されますか?可能性としては、エンティティがそれを生成してすでに持っている、エンティティに秘密鍵を物理的に渡す、秘密鍵を含むトークンを安全にメールで送信する、SSLセッションで配信するなどがあります。

3. How is the entity's public key provided securely to the certification authority? Some possibilities are in an online SSL session or in a message signed by the RA.

3. エンティティの公開鍵はどのようにして認証局に安全に提供されますか?いくつかの可能性は、オンラインSSLセッションまたはRAによって署名されたメッセージにあります。

4. In the case of issuing CAs, how is the CA's public key provided securely to potential relying parties? Possibilities include handing the public key to the relying party securely in person, physically mailing a copy securely to the relying party, or delivering it in a SSL session.

4. CAを発行する場合、CAの公開キーはどのようにして潜在的な依存者に安全に提供されますか?可能性としては、公開鍵を証明書利用者に直接安全に渡すこと、コピーを証明書利用者に物理的に安全に郵送すること、またはSSLセッションで配信することが含まれます。

5. What are the key sizes? Examples include a 1,024 bit RSA modulus and a 1,024 bit DSA large prime.

5. 鍵のサイズは何ですか?例には、1,024ビットのRSAモジュラスと1,024ビットのDSAラージプライムがあります。

6. Who generates the public key parameters, and is the quality of the parameters checked during key generation?

6. 誰が公開鍵パラメータを生成し、パラメータの品質は鍵生成中にチェックされますか?

7. For what purposes may the key be used, or for what purposes should usage of the key be restricted? For X.509 certificates, these purposes should map to the key usage flags in X.509 Version 3 certificates.

7. キーはどのような目的で使用できますか、またはキーの使用をどのような目的で制限する必要がありますか? X.509証明書の場合、これらの目的はX.509バージョン3証明書のキー使用法フラグにマップする必要があります。

4.6.2. Private Key Protection and Cryptographic Module Engineering Controls

4.6.2. 秘密鍵の保護と暗号化モジュールのエンジニアリング管理

Requirements for private key protection and cryptographic modules need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers. For each of these types of entities, the following questions potentially need to be answered:


1. What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the keys certified by the infrastructure required to be generated using modules compliant with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests.

1. 鍵を生成するために使用される暗号化モジュールに必要な標準がある場合、それはどのようなものですか?暗号化モジュールは、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで構成できます。たとえば、US FIPS 140-1に準拠したモジュールを使用して生成する必要があるインフラストラクチャによって認証されたキーはありますか?その場合、必要なモジュールのFIPS 140-1レベルは何ですか?暗号化モジュールの境界の識別、入力/出力、役割とサービス、有限状態機械、物理的セキュリティ、ソフトウェアセキュリティ、オペレーティングシステムのセキュリティ、アルゴリズムのコンプライアンス、電磁気など、暗号化モジュールに関連する他のエンジニアリングまたは他の制御はありますか?互換性、およびセルフテスト。

2. Is the private key under n out of m multi-person control?(7) If yes, provide n and m (two person control is a special case of n out of m, where n = m = 2)?

2. 秘密鍵はm人中のn人の制御下にありますか?(7)はいの場合、nとmを提供します(2人制御はm中n人の特別な場合で、n = m = 2)?

3. Is the private key escrowed?(8) If so, who is the escrow agent, what form is the key escrowed in (examples include plaintext, encrypted, split key), and what are the security controls on the escrow system?

3. 秘密鍵はエスクローされますか?(8)エスクローエージェントである場合、エスクローエージェントはどのような形式でエスクローされますか(例にはプレーンテキスト、暗号化、分割キーが含まれます)、エスクローシステムのセキュリティコントロールは何ですか?

4. Is the private key backed up? If so, who is the backup agent, what form is the key backed up in (examples include plaintext, encrypted, split key), and what are the security controls on the backup system?

4. 秘密鍵はバックアップされていますか?もしそうなら、誰がバックアップエージェントであり、どの形式でキーがバックアップされますか(例には、プレーンテキスト、暗号化、分割キーが含まれます)、バックアップシステムのセキュリティコントロールは何ですか?

5. Is the private key archived? If so, who is the archival agent, what form is the key archived in (examples include plaintext, encrypted, split key), and what are the security controls on the archival system?

5. 秘密鍵はアーカイブされていますか?もしそうなら、誰がアーカイブエージェントであり、どの形式のキーがアーカイブされているか(例には、プレーンテキスト、暗号化、分割キーが含まれます)、アーカイブシステムのセキュリティコントロールは何ですか?

6. Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (i.e., plaintext, encrypted, or split key)?

6. 秘密鍵を暗号化モジュールに転送したり、暗号化モジュールから転送したりできる状況はありますか?誰がそのような転送操作を実行することが許可されていますか?転送中の秘密鍵はどのような形式ですか(つまり、平文、暗号化、または分割鍵)?

7. How is the private key stored in the module (i.e., plaintext, encrypted, or split key)?

7. 秘密キーはどのようにモジュールに保存されますか(つまり、平文、暗号化、または分割キー)?

8. Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?

8. 誰が秘密鍵をアクティブ化(使用)できますか?秘密キーをアクティブにするために実行する必要があるアクション(ログイン、電源オン、PINの提供、トークン/キーの挿入、自動など)は何ですか?キーがアクティブになると、キーは無期限にアクティブになりますか、1回アクティブになりますか、または定義された期間アクティブになりますか?

9. Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration.

9. 秘密鍵を無効にできるのは誰ですか?秘密鍵を非アクティブ化する方法の例には、ログアウト、電源のオフ、トークン/キーの削除、自動非アクティブ化、および期限切れが含まれます。

10. Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and overwriting the key.

10. 誰が秘密鍵を破壊できますか?秘密鍵を破棄する方法の例には、トークンの降伏、トークンの破棄、および鍵の上書きが含まれます。

11. Provide the capabilities of the cryptographic module in the following areas: identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests. Capability may be expressed through reference to compliance with a standard such as U.S. FIPS 140-1, associated level, and rating.

11. 次の領域で暗号化モジュールの機能を提供します。暗号化モジュールの境界の識別、入力/出力、役割とサービス、有限状態機械、物理的セキュリティ、ソフトウェアセキュリティ、オペレーティングシステムセキュリティ、アルゴリズムコンプライアンス、電磁両立性、セルフテスト。能力は、U.S。FIPS 140-1などの規格への準拠、関連するレベル、およびレーティングを参照することで表現できます。

4.6.3. Other Aspects of Key Pair Management
4.6.3. 鍵ペア管理のその他の側面

Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, subscribers, and other participants. For each of these types of entities, the following questions potentially need to be answered:


1. Is the public key archived? If so, who is the archival agent and what are the security controls on the archival system? Also, what software and hardware need to be preserved as part of the archive to permit use of the public key over time? Note: this subcomponent is not limited to requiring or describing the use of digital signatures with archival data, but rather can address integrity controls other than digital signatures when an archive requires tamper protection. Digital signatures do not provide tamper protection or protect the integrity of data; they merely verify data integrity. Moreover, the archival period may be greater than the cryptanalysis period for the public key needed to verify any digital signature applied to archival data.

1. 公開鍵はアーカイブされていますか?もしそうなら、誰がアーカイブエージェントであり、アーカイブシステムのセキュリティ管理は何ですか?また、公開鍵を長期間使用できるようにするには、アーカイブの一部としてどのソフトウェアとハ​​ードウェアを保持する必要がありますか?注:このサブコンポーネントは、アーカイブデータでのデジタル署名の使用の要求または説明に限定されず、アーカイブが改ざん保護を必要とする場合に、デジタル署名以外の整合性制御に対処できます。デジタル署名は、改ざん防止やデータの完全性の保護を提供しません。データの整合性を確認するだけです。さらに、アーカイブ期間は、アーカイブデータに適用されたデジタル署名を検証するために必要な公開鍵の暗号解読期間よりも長い場合があります。

2. What is the operational period of the certificates issued to the subscriber. What are the usage periods, or active lifetimes, for the subscriber's key pair?

2. 加入者に発行された証明書の運用期間はどれくらいですか。サブスクライバーのキーペアの使用期間またはアクティブな有効期間はどのくらいですか?

4.6.4. Activation Data
4.6.4. アクティベーションデータ

Activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, passphrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key, and potentially needs to be considered for the issuing CA, subject CAs, RAs, and subscribers. Such consideration potentially needs to address the entire life-cycle of the activation data from generation through archival and destruction. For each of the entity types (issuing CA, repository, subject CA, RA, subscriber, and other participants), all of the questions listed in 4.6.1 through 4.6.3 potentially need to be answered with respect to activation data rather than with respect to keys.


4.6.5. Computer Security Controls
4.6.5. コンピューターのセキュリティ管理

This subcomponent is used to describe computer security controls such as: use of the trusted computing base concept, discretionary access control, labels, mandatory access controls, object re-use, audit, identification and authentication, trusted path, security testing, and penetration testing. Product assurance may also be addressed.


A computer security rating for computer systems may be required. The rating could be based, for example, on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken.

コンピューターシステムのコンピューターのセキュリティ評価が必要になる場合があります。格付けは、たとえば、Trusted System Evaluation Criteria(TCSEC)、Canadian Trusted Products Evaluation Criteria、European Information Technology Security Evaluation Criteria(ITSEC)、Common Criteria for Information Technology Security Evaluation、ISO / IEC 15408に基づいています。 1999このサブコンポーネントは、製品評価分析、テスト、プロファイリング、製品認証、および/または行われる製品認定関連のアクティビティの要件にも対応できます。

4.6.6. Life Cycle Security Controls
4.6.6. ライフサイクルのセキュリティ管理

This subcomponent addresses system development controls and security management controls.


System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of failsafe design and implementation techniques (e.g., defensive programming) and development facility security.


Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.


This subcomponent can also address life-cycle security ratings based, for example, on the Trusted Software Development Methodology (TSDM) level IV and V, independent life-cycle security controls audit, and the Software Engineering Institute's Capability Maturity Model (SEI-CMM).

このサブコンポーネントは、信頼できるソフトウェア開発方法論(TSDM)レベルIVおよびV、独立したライフサイクルセキュリティ管理監査、ソフトウェアエンジニアリングインスティテュートの能力成熟度モデル(SEI-CMM)などに基づくライフサイクルセキュリティ評価にも対応できます。 。

4.6.7. Network Security Controls
4.6.7. ネットワークセキュリティコントロール

This subcomponent addresses network security related controls, including firewalls.


4.6.8. Time-stamping
4.6.8. タイムスタンプ

This subcomponent addresses requirements or practices relating to the use of timestamps on various data. It may also discuss whether or not the time-stamping application must use a trusted time source.


4.7. Certificate and CRL Profiles
4.7. 証明書とCRLプロファイル

This component is used to specify the certificate format and, if CRLs and/or OCSP are used, the CRL and/or OCSP format. This includes information on profiles, versions, and extensions used.


4.7.1. Certificate Profile
4.7.1. 証明書プロファイル

This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):

このサブコンポーネントは、次のようなトピックに対処します(IETF PKIX RFC 3280で定義されているものなど、別のプロファイル定義を参照する可能性があります)。

* Version number(s) supported;

* サポートされているバージョン番号。

* Certificate extensions populated and their criticality;

* 設定された証明書の拡張とその重要度。

* Cryptographic algorithm object identifiers;

* 暗号化アルゴリズムのオブジェクト識別子。

* Name forms used for the CA, RA, and subscriber names;

* CA、RA、およびサブスクライバーの名前に使用される名前フォーム。

* Name constraints used and the name forms used in the name constraints;

* 使用される名前制約と名前制約で使用される名前形式。

* Applicable CP OID(s);

* 該当するCP OID;

* Usage of the policy constraints extension;

* ポリシー制約拡張の使用法。

* Policy qualifiers syntax and semantics; and

* ポリシー修飾子の構文とセマンティクス。そして

* Processing semantics for the critical CP extension.

* 重要なCP拡張のセマンティクスの処理。

4.7.2. CRL Profile
4.7.2. CRLプロファイル

This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):

このサブコンポーネントは、次のようなトピックに対処します(IETF PKIX RFC 3280で定義されているものなど、別のプロファイル定義を参照する可能性があります)。

* Version numbers supported for CRLs; and

* CRLでサポートされるバージョン番号。そして

* CRL and CRL entry extensions populated and their criticality.

* 設定されているCRLおよびCRLエントリ拡張とその重要度。

4.7.3. OCSP Profile
4.7.3. OCSPプロファイル

This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the IETF RFC 2560 profile):

このサブコンポーネントは、次のようなトピックに対処します(IETF RFC 2560プロファイルなど、別のプロファイル定義を参照する可能性があります)。

* Version of OCSP that is being used as the basis for establishing an OCSP system; and

* OCSPシステムを確立するための基礎として使用されているOCSPのバージョン。そして

* OCSP extensions populated and their criticality.

* 実装されているOCSP拡張とその重要度。

4.8. Compliance Audit and Other Assessment
4.8. コンプライアンス監査およびその他の評価

This component addresses the following:


* The list of topics covered by the assessment and/or the assessment methodology used to perform the assessment; examples include WebTrust for CAs (9) and SAS 70 (10).

* 評価の対象となるトピックのリスト、および/または評価の実行に使用される評価方法論。例には、CA(9)およびSAS 70(10)用のWebTrustが含まれます。

* Frequency of compliance audit or other assessment for each entity that must be assessed pursuant to a CP or CPS, or the circumstances that will trigger an assessment; possibilities include an annual audit, pre-operational assessment as a condition of allowing an entity to be operational, or investigation following a possible or actual compromise of security.

* CPまたはCPSに従って評価する必要がある各エンティティのコンプライアンス監査またはその他の評価の頻度、または評価をトリガーする状況。可能性としては、年次監査、エンティティの運用を許可する条件としての運用前の評価、またはセキュリティの可能性のあるまたは実際の妥協後の調査が含まれます。

* The identity and/or qualifications of the personnel performing the audit or other assessment.

* 監査またはその他の評価を実行する担当者の身元および/または資格。

* The relationship between the assessor and the entity being assessed, including the degree of independence of the assessor.

* 評価者と評価されるエンティティとの間の関係(評価者の独立性の程度を含む)。

* Actions taken as a result of deficiencies found during the assessment; examples include a temporary suspension of operations until deficiencies are corrected, revocation of certificates issued to the assessed entity, changes in personnel, triggering special investigations or more frequent subsequent compliance assessments, and claims for damages against the assessed entity.

* 評価中に発見された不備の結果として取られた措置例としては、欠陥が修正されるまでの運用の一時的な停止、評価対象のエンティティに発行された証明書の失効、人事異動、特別調査またはより頻繁な後続のコンプライアンス評価のトリガー、評価対象のエンティティに対する損害賠償請求などがあります。

* Who is entitled to see results of an assessment (e.g., assessed entity, other participants, the general public), who provides them (e.g., the assessor or the assessed entity), and how they are communicated.

* 評価の結果(評価対象のエンティティ、他の参加者、一般大衆など)を見る権利、誰が提供するか(評価者または評価対象のエンティティなど)、およびそれらの伝達方法。

4.9. その他のビジネスおよび法的事項

This component covers general business and legal matters. Sections 9.1 and 9.2 of the framework discuss the business issues of fees to be charged for various services and the financial responsibility of participants to maintain resources for ongoing operations and for paying judgments or settlements in response to claims asserted against them. The remaining sections are generally concerned with legal topics.


Starting with Section 9.3 of the framework, the ordering of topics is the same as or similar to the ordering of topics in a typical software licensing agreement or other technology agreement. Consequently, this framework may not only be used for CPs and CPSs, but also associated PKI-related agreements, especially subscriber agreements, and relying party agreements. This ordering is intended help lawyers review CPs, CPSs, and other documents adhering to this framework.


With respect to many of the legal subcomponents within this component, a CP or CPS drafter may choose to include in the document terms and conditions that apply directly to subscribers or relying parties. For instance, a CP or CPS may set forth limitations of liability that apply to subscribers and relying parties. The inclusion of terms and conditions is likely to be appropriate where the CP or CPS is itself a contract or part of a contract.


In other cases, however, the CP or CPS is not a contract or part of a contract; instead, it is configured so that its terms and conditions are applied to the parties by separate documents, which may include associated agreements, such as subscriber or relying party agreements. In that event, a CP drafter may write a CP so as to require that certain legal terms and conditions appear (or not appear) in such associated agreements. For example, a CP might include a subcomponent stating that a certain limitation of liability term must appear in a CA's subscriber and relying party agreements. Another example is a CP that contains a subcomponent prohibiting the use of a subscriber or relying party agreement containing a limitation upon CA liability inconsistent with the provisions of the CP. A CPS drafter may use legal subcomponents to disclose that certain terms and conditions appear in associated subscriber, relying party, or other agreements in use by the CA. A CPS might explain, for instance, that the CA writing it uses an associated subscriber or relying party agreement that applies a particular provision for limiting liability.

ただし、他の場合では、CPまたはCPSは契約または契約の一部ではありません。代わりに、契約条件が、サブスクライバーまたは信頼者の合意などの関連する合意を含む可能性のある個別のドキュメントによって当事者に適用されるように構成されています。その場合、CP起草者は、関連する契約に特定の法的条件が表示される(または表示されない)ことを要求するようにCPを作成できます。たとえば、CPには、責任期間の特定の制限がCAのサブスクライバーおよび証明書利用者の合意に表示される必要があることを示すサブコンポーネントが含まれる場合があります。別の例は、CPの規定と矛盾するCA責任の制限を含む、サブスクライバーまたは信頼者の合意の使用を禁止するサブコンポーネントを含むCPです。 CPS起草者は、法的なサブコンポーネントを使用して、特定の契約条件が、関連するサブスクライバー、証明書利用者、またはCAによって使用されているその他の契約に表示されることを開示する場合があります。 CPSは、たとえば、CAがCAを作成するときに、責任を制限するための特定の規定を適用する関連する加入者または信頼者の合意を使用することを説明する場合があります。

4.9.1. Fees
4.9.1. 料金

This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs, such as:


* Certificate issuance or renewal fees;

* 証明書の発行または更新料;

* Certificate access fees;

* 証明書アクセス料;

* Revocation or status information access fees;

* 失効またはステータス情報アクセス料金。

* Fees for other services such as providing access to the relevant CP or CPS; and

* 関連するCPまたはCPSへのアクセスの提供など、他のサービスの料金。そして

* Refund policy.

* 返金について。

4.9.2. Financial Responsibility
4.9.2. 経済的責任

This subcomponent contains requirements or disclosures relating to the resources available to CAs, RAs, and other participants providing certification services to support performance of their operational PKI responsibilities, and to remain solvent and pay damages in the event they are liable to pay a judgment or settlement in connection with a claim arising out of such operations. Such provisions include:


* A statement that the participant maintains a certain amount of insurance coverage for its liabilities to other participants;

* 参加者が他の参加者への責任について一定額の保険を維持しているという声明。

* A statement that a participant has access to other resources to support operations and pay damages for potential liability, which may be couched in terms of a minimum level of assets necessary to operate and cover contingencies that might occur within a PKI, where examples include assets on the balance sheet of an organization, a surety bond, a letter of credit, and a right under an agreement to an indemnity under certain circumstances; and

* 参加者が他のリソースにアクセスして操作をサポートし、潜在的な責任に対して損害賠償を払うという声明組織の貸借対照表、保証債、信用状、および特定の状況下での補償に対する合意に基づく権利。そして

* A statement that a participant has a program that offers first-party insurance or warranty protection to other participants in connection with their use of the PKI.

* 参加者が、PKIの使用に関連して他の参加者に第一者保険または保証の保護を提供するプログラムを持っているという声明。

4.9.3. Confidentiality of Business Information
4.9.3. ビジネス情報の機密性

This subcomponent contains provisions relating to the treatment of confidential business information that participants may communicate to each other, such as business plans, sales information, trade secrets, and information received from a third party under a nondisclosure agreement. Specifically, this subcomponent addresses:


* The scope of what is considered confidential information,

* 機密情報と見なされるものの範囲、

* The types of information that are considered to be outside the scope of confidential information, and

* 機密情報の範囲外と見なされる情報の種類、および

* The responsibilities of participants that receive confidential information to secure it from compromise, and refrain from using it or disclosing it to third parties.

* 機密情報を受け取ってそれを侵害から保護し、それを使用したり第三者に開示したりしない参加者の責任。

4.9.4. Privacy of Personal Information
4.9.4. 個人情報のプライバシー

This subcomponent relates to the protection that participants, particularly CAs, RAs, and repositories, may be required to afford to personally identifiable private information of certificate applicants, subscribers, and other participants. Specifically, this subcomponent addresses the following, to the extent pertinent under applicable law:


* The designation and disclosure of the applicable privacy plan that applies to a participant's activities, if required by applicable law or policy;

* 該当する法律またはポリシーで要求される場合、参加者の活動に適用される該当するプライバシー計画の指定と開示。

* Information that is or is not considered private within the PKI;

* PKI内で非公開と見なされる、または見なされない情報。

* Any responsibility of participants that receive private information to secure it, and refrain from using it and from disclosing it to third parties;

* 個人情報を受け取ってそれを保護し、それを使用したり第三者に開示したりしない参加者の責任。

* Any requirements as to notices to, or consent from individuals regarding use or disclosure of private information; and

* 個人情報の使用または開示に関する個人への通知または同意に関する要件;そして

* Any circumstances under which a participant is entitled or required to disclose private information pursuant to judicial, administrative process in a private or governmental proceeding, or in any legal proceeding.

* 参加者が私的または政府の手続き、または法的手続きにおける司法、行政手続きに従って個人情報を開示する権利または要求される状況。

4.9.5. Intellectual Property Rights
4.9.5. 知的財産権

This subcomponent addresses the intellectual property rights, such as copyright, patent, trademarks, or trade secrets, that certain participants may have or claim in a CP, CPS, certificates, names, and keys, or are the subject of a license to or from participants.


4.9.6. Representations and Warranties
4.9.6. 表明および保証

This subcomponent can include representations and warranties of various entities that are being made pursuant to the CP or CPS. For example, a CPS that serves as a contract might contain a CA's warranty that information contained in the certificate is accurate. Alternatively, a CPS might contain a less extensive warranty to the effect that the information in the certificate is true to the best of the CA's knowledge after performing certain identity authentication procedures with due diligence. This subcomponent can also include requirements that representations and warranties appear in certain agreements, such as subscriber or relying party agreements. For instance, a CP may contain a requirement that all CAs utilize a subscriber agreement, and that a subscriber agreement must contain a warranty by the CA that information in the certificate is accurate. Participants that may make representations and warranties include CAs, RAs, subscribers, relying parties, and other participants.


4.9.7. Disclaimers of Warranties
4.9.7. 保証の否認

This subcomponent can include disclaimers of express warranties that may otherwise be deemed to exist in an agreement, and disclaimers of implied warranties that may otherwise be imposed by applicable law, such as warranties of merchantability or fitness for a particular purpose. The CP or CPS may directly impose such disclaimers, or the CP or CPS may contain a requirement that disclaimers appear in associated agreements, such as subscriber or relying party agreements.

このサブコンポーネントには、契約に存在すると見なされる可能性がある明示的保証の免責事項、および商品性の保証や特定の目的への適合性など、適用法によって課せられる可能性がある黙示的保証の免責事項を含めることができます。 CPまたはCPSは、そのような免責事項を直接課す場合があります。または、CPまたはCPSは、免責事項が、加入者または信頼者の合意などの関連する合意に表示されるという要件を含む場合があります。

4.9.8. Limitations of Liability
4.9.8. 責任の制限

This subcomponent can include limitations of liability in a CP or CPS or limitations that appear or must appear in an agreement associated with the CP or CPS, such as a subscriber or relying party agreement. These limitations may fall into one of two categories: limitations on the elements of damages recoverable and limitations on the amount of damages recoverable, also known as liability caps. Often, contracts contain clauses preventing the recovery of elements of damages such as incidental and consequential damages, and sometimes punitive damages. Frequently, contracts contain clauses that limit the possible recovery of one party or the other to an amount certain or to an amount corresponding to a benchmark, such as the amount a vendor was paid under the contract.


4.9.9. Indemnities
4.9.9. 補償

This subcomponent includes provisions by which one party makes a second party whole for losses or damage incurred by the second party, typically arising out of the first party's conduct. They may appear in a CP, CPS, or agreement. For example, a CP may require that subscriber agreements contain a term under which a subscriber is responsible for indemnifying a CA for losses the CA sustains arising out of a subscriber's fraudulent misrepresentations on the certificate application under which the CA issued the subscriber an inaccurate certificate. Similarly, a CPS may say that a CA uses a relying party agreement, under which relying parties are responsible for indemnifying a CA for losses the CA sustains arising out of use of a certificate without properly checking revocation information or use of a certificate for purposes beyond what the CA permits.

このサブコンポーネントには、通常、第一者の行為から生じる、第二者が被った損失または損害について、一方の当事者が第二者を完全にする規定が含まれます。それらは、CP、CPS、または合意に表示される場合があります。たとえば、CPは、サブスクライバー契約が、CAがサブスクライバーにサブスクライバーに不正確な証明書を発行した証明書アプリケーションに関するサブスクライバーの詐欺的な不実表示に起因するCAが被る損失について、サブスクライバーがCAに補償する責任を負う条件を含めることを要求する場合があります。同様に、CPSは、CAが証明書利用者の合意を使用すると言っている場合があります。証明書利用者は、証明書の使用による失効情報または証明書の使用を適切に確認せずに、CAが被った損失についてCAに補償する責任があります。 CAが許可するもの。

4.9.10. Term and Termination
4.9.10. 期間と終了

This subcomponent can include the time period in which a CP or a CPS remains in force and the circumstances under which the document, portions of the document, or its applicability to a particular participant can be terminated. In addition or alternatively, the CP or CPS may include requirements that certain term and termination clauses appear in agreements, such as subscriber or relying party agreements. In particular, such terms can include:


* The term of a document or agreement, that is, when the document becomes effective and when it expires if it is not terminated earlier.

* ドキュメントまたは契約の期間。つまり、ドキュメントが有効になり、早期に終了しなかった場合に期限切れになります。

* Termination provisions stating circumstances under which the document, certain portions of it, or its application to a particular participant ceases to remain in effect.

* 終了規定では、ドキュメント、ドキュメントの特定の部分、または特定の参加者への適用が引き続き有効でなくなる状況について説明します。

* Any consequences of termination of the document. For example, certain provisions of an agreement may survive its termination and remain in force. Examples include acknowledgements of intellectual property rights and confidentiality provisions. Also, termination may trigger a responsibility of parties to return confidential information to the party that disclosed it.

* ドキュメントの終了の結果。たとえば、契約の特定の規定は、その終了後も存続し、引き続き効力を持つ可能性があります。例には、知的財産権の承認および機密保持規定が含まれます。また、解約により、機密情報を開示した当事者に機密情報を返却する責任が生じます。

4.9.11. Individual notices and communications with participants
4.9.11. 個々の通知と参加者とのコミュニケーション

This subcomponent discusses the way in which one participant can or must communicate with another participant on a one-to-one basis in order for such communications to be legally effective. For example, an RA may wish to inform the CA that it wishes to terminate its agreement with the CA. This subcomponent is different from publication and repository functions, because unlike individual communications described in this subcomponent, publication and posting to a repository are for the purpose of communicating to a wide audience of recipients, such as all relying parties. This subcomponent may establish mechanisms for communication and indicate the contact information to be used to route such communications, such as digitally signed e-mail notices to a specified address, followed by a signed e-mail acknowledgement of receipt.


4.9.12. Amendments
4.9.12. 修正

It will occasionally be necessary to amend a CP or CPS. Some of these changes will not materially reduce the assurance that a CP or its implementation provides, and will be judged by the policy administrator to have an insignificant effect on the acceptability of certificates. Such changes to a CP or CPS need not require a change in the CP OID or the CPS pointer (URL). On the other hand, some changes to a specification will materially change the acceptability of certificates for specific purposes, and these changes may require corresponding changes to the CP OID or CPS pointer qualifier (URL).

CPまたはCPSを修正する必要がある場合があります。これらの変更の一部は、CPまたはその実装が提供する保証を実質的に低下させることはなく、ポリシー管理者によって証明書の受け入れ可能性に取るに足らない影響を与えると判断されます。 CPまたはCPSに対するこのような変更は、CP OIDまたはCPSポインター(URL)の変更を必要としません。一方、仕様に対する一部の変更は、特定の目的のための証明書の受け入れ可能性を大幅に変更し、これらの変更には、CP OIDまたはCPSポインター修飾子(URL)に対する対応する変更が必要になる場合があります。

This subcomponent may also contain the following information:


* The procedures by which the CP or CPS and/or other documents must, may be, or are amended. In the case of CP or CPS amendments, change procedures may include a notification mechanism to provide notice of proposed amendments to affected parties, such as subscribers and relying parties, a comment period, a mechanism by which comments are received, reviewed and incorporated into the document, and a mechanism by which amendments become final and effective.

* CPまたはCPSおよび/またはその他の文書が必要とする、修正される、または修正される手順。 CPまたはCPSの修正の場合、変更手順には、修正案の通知をサブスクライバーや信頼者などの影響を受ける当事者に通知する通知メカニズム、コメント期間、コメントが受信され、レビューされてに組み込まれるメカニズムが含まれる場合があります。文書、および修正が最終的かつ有効になるメカニズム。

* The circumstances under which amendments to the CP or CPS would require a change in CP OID or CPS pointer (URL).

* CPまたはCPSの修正により、CP OIDまたはCPSポインター(URL)の変更が必要になる状況。

4.9.13. Dispute Resolution Procedures
4.9.13. 紛争解決手順

This subcomponent discusses procedures utilized to resolve disputes arising out of the CP, CPS, and/or agreements. Examples of such procedures include requirements that disputes be resolved in a certain forum or by alternative dispute resolution mechanisms.


4.9.14. Governing Law
4.9.14. 準拠法

This subcomponent sets forth a statement that the law of a certain jurisdiction governs the interpretation and enforcement of the subject CP or CPS or agreements.


4.9.15. Compliance with Applicable Law
4.9.15. 準拠法の遵守

This subcomponent relates to stated requirements that participants comply with applicable law, for example, laws relating to cryptographic hardware and software that may be subject to the export control laws of a given jurisdiction. The CP or CPS could purport to impose such requirements or may require that such provisions appear in other agreements.

このサブコンポーネントは、参加者が適用法、たとえば、所与の管轄区域の輸出規制法の対象となる可能性のある暗号化ハードウェアおよびソフトウェアに関連する法律を遵守するという規定の要件に関連しています。 CPまたはCPSは、そのような要件を課すと主張するか、そのような規定が他の契約に記載されることを要求する場合があります。

4.9.16. Miscellaneous Provisions
4.9.16. その他の規定

This subcomponent contains miscellaneous provisions, sometimes called "boilerplate provisions," in contracts. The clauses covered in this subcomponent may appear in a CP, CPS, or agreements and include:


* An entire agreement clause, which typically identifies the document or documents comprising the entire agreement between the parties and states that such agreements supersede all prior and contemporaneous written or oral understandings relating to the same subject matter;

* 当事者間の完全な合意を構成する1つまたは複数の文書を通常識別し、そのような合意が、同じ主題に関する以前の同時の書面または口頭による理解に取って代わると述べている完全な合意条項。

* An assignment clause, which may act to limit the ability of a party in an agreement, assigning its rights under the agreement to another party (such as the right to receive a stream of payments in the future) or limiting the ability of a party to delegate its obligations under the agreement;

* 契約条項の当事者の能力を制限するように機能する、契約に基づくその権利を別の当事者に割り当てる(将来的に一連の支払いを受ける権利など)、または当事者の能力を協定に基づく義務を委任する。

* A severability clause, which sets forth the intentions of the parties in the event that a court or other tribunal determines that a clause within an agreement is, for some reason, invalid or unenforceable, and whose purpose is frequently to prevent the unenforceability of one clause from causing the whole agreement to be unenforceable; and

* 分離可能性条項。これは、裁判所またはその他の裁判所が、契約内の条項が何らかの理由で無効または執行不可能であると判断した場合の当事者の意図を示し、その目的は、1つの条項の執行不能を防止することであることが多い合意全体を執行不能にすることから;そして

* An enforcement clause, which may state that a party prevailing in any dispute arising out of an agreement is entitled to attorneys' fees as part of its recovery, or may state that a party's waiver of one breach of contract does not constitute a continuing waiver or a future waiver of other breaches of contract.

* 契約から生じた紛争に勝訴している当事者がその回復の一環として弁護士費用を請求する権利があると述べている執行条項、または契約違反の当事者の権利放棄が継続的な権利放棄を構成しない、または他の契約違反の将来の放棄。

* A force majeure clause, commonly used to excuse the performance of one or more parties to an agreement due to an event outside the reasonable control of the affected party or parties. Typically, the duration of the excused performance is commensurate with the duration of the delay caused by the event. The clause may also provide for the termination of the agreement under specified circumstances and conditions. Events considered to constitute a "force majeure" may include so-called "Acts of God," wars, terrorism, strikes, natural disasters, failures of suppliers or vendors to perform, or failures of the Internet or other infrastructure. Force majeure clauses should be drafted so as to be consistent with other portions of the framework and applicable service level agreements. For instance, responsibilities and capabilities for business continuity and disaster recovery may place some events within the reasonable control of the parties, such as an obligation to maintain backup electrical power in the face of power outages.

* 不可抗力条項。通常、影響を受ける当事者の合理的な制御の及ばない事態により、1人以上の当事者が履行した契約の履行を弁解するために使用されます。通常、免除されたパフォーマンスの期間は、イベントによって引き起こされた遅延の期間と釣り合っています。この条項は、特定の状況および条件の下での契約の終了を規定する場合もあります。 「不可抗力」を構成すると見なされるイベントには、いわゆる「神の行為」、戦争、テロ、ストライキ、自然災害、サプライヤーやベンダーの実行の失敗、またはインターネットやその他のインフラストラクチャの失敗が含まれる場合があります。不可抗力条項は、フレームワークの他の部分および該当するサービスレベル契約と整合するように作成する必要があります。たとえば、ビジネス継続性と災害復旧の責任と能力により、停電時にバックアップ電力を維持する義務など、当事者の合理的な管理の範囲内でいくつかのイベントが発生する可能性があります。

4.9.17. Other Provisions
4.9.17. その他の規定

This subcomponent is a "catchall" location where additional responsibilities and terms can be imposed on PKI participants that do not neatly fit within one of the other components or subcomponents of the framework. CP and CPS writers can place any provision within this subcomponent that is not covered by another subcomponent.

このサブコンポーネントは「キャッチオール」の場所であり、フレームワークの他のコンポーネントまたはサブコンポーネントの1つに適切に収まらないPKI参加者に追加の責任と条件を課すことができます。 CPおよびCPSの作成者は、このサブコンポーネント内に、別のサブコンポーネントでカバーされていないプロビジョニングを配置できます。

5. Security Considerations
5. セキュリティに関する考慮事項

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 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 technical security controls, including 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).


This document provides a framework to address technical, procedural, personnel, and physical security aspects of Certification Authorities, Registration Authorities, repositories, subscribers, and relying party cryptographic modules, in order to ensure that the certificate generation, publication, renewal, re-key, usage, and revocation is done in a secure manner. Specifically, Section 4.3 Identification and Authentication (I&A); Section 4.4 Certificate Life-Cycle Operational Requirements; Section 4.5 Facility Management, and Operational Controls; Section 4.6 Technical Security Controls; Section 4.7 Certificate CRL, and OCSP Profiles; and Section 4.8 Compliance Audit and Other Assessment, are oriented towards ensuring secure operation of the PKI entities such as CA, RA, repository, subscriber systems, and relying party systems.


6. Outline of a Set of Provisions
6. 一連の規定の概要

This section contains a recommended outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by CP or CPS writers. Such a common outline will facilitate: (a) Comparison of two certificate policies during cross-certification or other forms of interoperation (for the purpose of equivalency mapping).


(b) Comparison of a CPS with a CP to ensure that the CPS faithfully implements the policy.


(c) Comparison of two CPSs.


In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to this outline. While use of an alternate outline is discouraged, it may be accepted if a proper justification is provided for the deviation and a mapping table is provided to readily discern where each of the items described in this outline is provided.


1. INTRODUCTION 1.1 Overview 1.2 Document name and identification 1.3 PKI participants 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 Subscribers 1.3.4 Relying parties 1.3.5 Other participants 1.4 Certificate usage 1.4.1. Appropriate certificate uses 1.4.2 Prohibited certificate uses 1.5 Policy administration 1.5.1 Organization administering the document 1.5.2 Contact person 1.5.3 Person determining CPS suitability for the policy 1.5.4 CPS approval procedures 1.6 Definitions and acronyms 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 Repositories 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories 3. IDENTIFICATION AND AUTHENTICATION (11) 3.1 Naming 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Anonymity or pseudonymity of subscribers 3.1.4 Rules for interpreting various name forms 3.1.5 Uniqueness of names 3.1.6 Recognition, authentication, and role of trademarks 3.2 Initial identity validation 3.2.1 Method to prove possession of private key 3.2.2 Authentication of organization identity 3.2.3 Authentication of individual identity 3.2.4 Non-verified subscriber information 3.2.5 Validation of authority 3.2.6 Criteria for interoperation 3.3 Identification and authentication for re-key requests 3.3.1 Identification and authentication for routine re-key 3.3.2 Identification and authentication for re-key after revocation 3.4 Identification and authentication for revocation request 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11) 4.1 Certificate Application 4.1.1 Who can submit a certificate application 4.1.2 Enrollment process and responsibilities 4.2 Certificate application processing 4.2.1 Performing identification and authentication functions 4.2.2 Approval or rejection of certificate applications 4.2.3 Time to process certificate applications 4.3 Certificate issuance 4.3.1 CA actions during certificate issuance 4.3.2 Notification to subscriber by the CA of issuance of certificate 4.4 Certificate acceptance 4.4.1 Conduct constituting certificate acceptance 4.4.2 Publication of the certificate by the CA 4.4.3 Notification of certificate issuance by the CA to other entities 4.5 Key pair and certificate usage 4.5.1 Subscriber private key and certificate usage 4.5.2 Relying party public key and certificate usage 4.6 Certificate renewal 4.6.1 Circumstance for certificate renewal 4.6.2 Who may request renewal 4.6.3 Processing certificate renewal requests 4.6.4 Notification of new certificate issuance to subscriber 4.6.5 Conduct constituting acceptance of a renewal certificate 4.6.6 Publication of the renewal certificate by the CA 4.6.7 Notification of certificate issuance by the CA to other entities 4.7 Certificate re-key 4.7.1 Circumstance for certificate re-key 4.7.2 Who may request certification of a new public key 4.7.3 Processing certificate re-keying requests 4.7.4 Notification of new certificate issuance to subscriber 4.7.5 Conduct constituting acceptance of a re-keyed certificate 4.7.6 Publication of the re-keyed certificate by the CA 4.7.7 Notification of certificate issuance by the CA to other entities 4.8 Certificate modification 4.8.1 Circumstance for certificate modification 4.8.2 Who may request certificate modification 4.8.3 Processing certificate modification requests 4.8.4 Notification of new certificate issuance to subscriber 4.8.5 Conduct constituting acceptance of modified certificate 4.8.6 Publication of the modified certificate by the CA 4.8.7 Notification of certificate issuance by the CA to other entities 4.9 Certificate revocation and suspension 4.9.1 Circumstances for revocation 4.9.2 Who can request revocation 4.9.3 Procedure for revocation request 4.9.4 Revocation request grace period 4.9.5 Time within which CA must process the revocation request 4.9.6 Revocation checking requirement for relying parties 4.9.7 CRL issuance frequency (if applicable) 4.9.8 Maximum latency for CRLs (if applicable) 4.9.9 On-line revocation/status checking availability 4.9.10 On-line revocation checking requirements 4.9.11 Other forms of revocation advertisements available 4.9.12 Special requirements re key compromise 4.9.13 Circumstances for suspension 4.9.14 Who can request suspension 4.9.15 Procedure for suspension request 4.9.16 Limits on suspension period 4.10 Certificate status services 4.10.1 Operational characteristics 4.10.2 Service availability 4.10.3 Optional features 4.11 End of subscription 4.12 Key escrow and recovery 4.12.1 Key escrow and recovery policy and practices 4.12.2 Session key encapsulation and recovery policy and practices 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11) 5.1 Physical controls 5.1.1 Site location and construction 5.1.2 Physical access 5.1.3 Power and air conditioning 5.1.4 Water exposures 5.1.5 Fire prevention and protection 5.1.6 Media storage 5.1.7 Waste disposal 5.1.8 Off-site backup 5.2 Procedural controls 5.2.1 Trusted roles 5.2.2 Number of persons required per task 5.2.3 Identification and authentication for each role 5.2.4 Roles requiring separation of duties 5.3 Personnel controls 5.3.1 Qualifications, experience, and clearance requirements 5.3.2 Background check procedures 5.3.3 Training requirements 5.3.4 Retraining frequency and requirements 5.3.5 Job rotation frequency and sequence 5.3.6 Sanctions for unauthorized actions 5.3.7 Independent contractor requirements 5.3.8 Documentation supplied to personnel 5.4 Audit logging procedures 5.4.1 Types of events recorded 5.4.2 Frequency of processing log 5.4.3 Retention period for audit log 5.4.4 Protection of audit log 5.4.5 Audit log backup procedures 5.4.6 Audit collection system (internal vs. external) 5.4.7 Notification to event-causing subject 5.4.8 Vulnerability assessments 5.5 Records archival 5.5.1 Types of records archived 5.5.2 Retention period for archive 5.5.3 Protection of archive 5.5.4 Archive backup procedures 5.5.5 Requirements for time-stamping of records 5.5.6 Archive collection system (internal or external) 5.5.7 Procedures to obtain and verify archive information 5.6 Key changeover 5.7 Compromise and disaster recovery 5.7.1 Incident and compromise handling procedures 5.7.2 Computing resources, software, and/or data are corrupted 5.7.3 Entity private key compromise procedures 5.7.4 Business continuity capabilities after a disaster 5.8 CA or RA termination 6. TECHNICAL SECURITY CONTROLS (11) 6.1 Key pair generation and installation 6.1.1 Key pair generation 6.1.2 Private key delivery to subscriber 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to relying parties 6.1.5 Key sizes 6.1.6 Public key parameters generation and quality checking 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.2.1 Cryptographic module standards and controls 6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow 6.2.4 Private key backup 6.2.5 Private key archival 6.2.6 Private key transfer into or from a cryptographic module 6.2.7 Private key storage on cryptographic module 6.2.8 Method of activating private key 6.2.9 Method of deactivating private key 6.2.10 Method of destroying private key 6.2.11 Cryptographic Module Rating 6.3 Other aspects of key pair management 6.3.1 Public key archival 6.3.2 Certificate operational periods and key pair usage periods 6.4 Activation data 6.4.1 Activation data generation and installation 6.4.2 Activation data protection 6.4.3 Other aspects of activation data 6.5 Computer security controls 6.5.1 Specific computer security technical requirements 6.5.2 Computer security rating 6.6 Life cycle technical controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security controls 6.7 Network security controls 6.8 Time-stamping 7. CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate profile 7.1.1 Version number(s) 7.1.2 Certificate extensions 7.1.3 Algorithm object identifiers 7.1.4 Name forms 7.1.5 Name constraints 7.1.6 Certificate policy object identifier 7.1.7 Usage of Policy Constraints extension 7.1.8 Policy qualifiers syntax and semantics 7.1.9 Processing semantics for the critical Certificate Policies extension 7.2 CRL profile 7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions 7.3 OCSP profile 7.3.1 Version number(s) 7.3.2 OCSP extensions 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 Frequency or circumstances of assessment 8.2 Identity/qualifications of assessor 8.3 Assessor's relationship to assessed entity 8.4 Topics covered by assessment 8.5 Actions taken as a result of deficiency 8.6 Communication of results 9. OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees 9.1.1 Certificate issuance or renewal fees 9.1.2 Certificate access fees 9.1.3 Revocation or status information access fees 9.1.4 Fees for other services 9.1.5 Refund policy 9.2 Financial responsibility 9.2.1 Insurance coverage 9.2.2 Other assets 9.2.3 Insurance or warranty coverage for end-entities 9.3 Confidentiality of business information 9.3.1 Scope of confidential information 9.3.2 Information not within the scope of confidential information 9.3.3 Responsibility to protect confidential information 9.4 Privacy of personal information 9.4.1 Privacy plan 9.4.2 Information treated as private 9.4.3 Information not deemed private 9.4.4 Responsibility to protect private information 9.4.5 Notice and consent to use private information 9.4.6 Disclosure pursuant to judicial or administrative process 9.4.7 Other information disclosure circumstances 9.5 Intellectual property rights 9.6 Representations and warranties 9.6.1 CA representations and warranties 9.6.2 RA representations and warranties 9.6.3 Subscriber representations and warranties 9.6.4 Relying party representations and warranties 9.6.5 Representations and warranties of other participants 9.7 Disclaimers of warranties 9.8 Limitations of liability 9.9 Indemnities 9.10 Term and termination 9.10.1 Term 9.10.2 Termination 9.10.3 Effect of termination and survival 9.11 Individual notices and communications with participants 9.12 Amendments 9.12.1 Procedure for amendment 9.12.2 Notification mechanism and period 9.12.3 Circumstances under which OID must be changed 9.13 Dispute resolution provisions 9.14 Governing law 9.15 Compliance with applicable law 9.16 Miscellaneous provisions 9.16.1 Entire agreement 9.16.2 Assignment 9.16.3 Severability 9.16.4 Enforcement (attorneys' fees and waiver of rights) 9.16.5 Force Majeure 9.17 Other provisions

1.はじめに1.1概要1.2ドキュメント名と識別1.3 PKI参加者1.3.1証明機関1.3.2登録機関1.3.3サブスクライバー1.3.4証明書利用者1.3.5その他の参加者1.4証明書の使用1.4.1。適切な証明書の使用1.4.2禁止された証明書の使用1.5ポリシーの管理1.5.1文書を管理する組織1.5.2担当者1.5.3ポリシーに対するCPSの適合性を決定する人1.5.4 CPSの承認手順1.6定義と略語2.公開とリポジトリの責任2.1リポジトリ2.2認証情報の公開2.3公開の時間または頻度2.4リポジトリのアクセス制御3.識別と認証(11)3.1命名3.1.1名前のタイプ3.1.2意味のある名前の必要性3.1.3匿名性または偽名性サブスクライバー3.1.4さまざまな名前の形式を解釈するための規則3.1.5名前の一意性3.1.6商標の認識、認証、および役割3.2初期の本人確認3.2.1秘密鍵の所有を証明する方法3.2.2組織の本人確認3.2。 3個人の身元の認証3.2.4検証されていない加入者情報3.2.5権限の検証3.2.6基準相互運用用3.3鍵の再発行要求の識別と認証3.3.1定期的な鍵の再発行の識別と認証3.3.2失効後の鍵の再発行の識別と認証3.4失効要求の識別と認証4.証明書のライフサイクル運用要件( 11)4.1証明書アプリケーション4.1.1証明書アプリケーションを送信できるユーザー4.1.2登録プロセスと責任4.2証明書アプリケーションの処理4.2.1識別および認証機能の実行4.2.2証明書アプリケーションの承認または拒否4.2.3証明書アプリケーションの処理時間4.3証明書の発行4.3.1証明書の発行中のCAのアクション4.3.2 CAによる加入者への証明書の発行の通知4.4証明書の受け入れ4.4.1証明書の受け入れを構成する行為4.4.2 CAによる証明書の発行4.4.3証明書の通知CAから他のエンティティへの発行4.5キーペアとCE rtificateの使用4.5.1サブスクライバーの秘密キーと証明書の使用4.5.2証明書利用者の公開キーと証明書の使用4.6証明書の更新4.6.1証明書の更新の状況4.6.2更新をリクエストできるユーザー4.6.3証明書の更新リクエストの処理4.6.4通知加入者への新しい証明書の発行4.6.5更新証明書の受け入れを構成する行為4.6.6 CAによる更新証明書の公開4.6.7 CAによる他のエンティティへの証明書発行の通知4.7証明書の再キー4.7.1証明書の状況re-key 4.7.2誰が新しい公開鍵の認証を要求できるか4.7.3証明書の再入力要求の処理4.7.4サブスクライバーへの新しい証明書の発行の通知4.7.5 re-keyed証明書の受け入れを構成する行為4.7.6発行CAによる鍵の再発行された証明書の発行4.7.7 CAによる他のエンティティへの証明書発行の通知4.8証明書の変更4.8.1証明書moの状況dification 4.8.2証明書の変更をリクエストできるユーザー4.8.3証明書の変更リクエストの処理4.8.4サブスクライバーへの新しい証明書の発行の通知4.8.5変更された証明書の受け入れを構成する行為4.8.6 CAによる変更された証明書の公開4.8.7通知CAによる他のエンティティへの証明書発行の制限4.9証明書の失効と一時停止4.9.1失効の状況4.9.2失効を要求できる者4.9.3失効要求の手順4.9.4失効要求の猶予期間4.9.5 CAが処理する必要のある時間失効要求4.9.6証明書利用者の失効確認要件4.9.7 CRLの発行頻度(該当する場合)4.9.8 CRLの最大待機時間(該当する場合)4.9.9オンラインでの失効/ステータス確認の可用性4.9.10オンライン失効確認の要件4.9.11利用可能な失効通知の他の形式4.9.12鍵の侵害に関する特別な要件4.9.13停止の状況4.9.14一時停止をリクエストできるユーザー4.9.15一時停止リクエストの手順4.9.16一時停止期間の制限4.10証明書ステータスサービス4.10.1操作特性4.10.2サービスの可用性4.10.3オプション機能4.11サブスクリプションの終了4.12キーのエスクローとリカバリ4.12 .1鍵のエスクローと回復のポリシーと慣行4.12.2セッション鍵のカプセル化と回復のポリシーと慣行5.設備、管理、および運用管理(11)5.1物理的制御5.1.1サイトの場所と建設5.1.2物理的アクセス5.1.3電力および空調5.1.4水への暴露5.1.5防火および保護5.1.6メディアの保管5.1.7廃棄物処理5.1.8オフサイトバックアップ5.2手順の管理5.2.1信頼できる役割5.2.2タスクごとに必要な人数5.2.3各役割の識別と認証5.2.4職務の分離を必要とする役割5.3人事管理5.3.1資格、経験、およびクリアランスの要件5.3.2バックグラウンドチェックの手順5.3。 3トレーニング要件5.3.4再トレーニングの頻度と要件5.3.5ジョブローテーションの頻度と順序5.3.6不正行為に対する制裁5.3.7独立した請負業者の要件5.3.8担当者に提供される文書5.4監査ログ手順5.4.1記録されるイベントの種類5.4 .2ログの処理頻度5.4.3監査ログの保存期間5.4.4監査ログの保護5.4.5監査ログのバックアップ手順5.4.6監査収集システム(内部と外部)5.4.7イベントの原因となるサブジェクトへの通知5.4 .8脆弱性評価5.5レコードのアーカイブ5.5.1アーカイブされたレコードのタイプ5.5.2アーカイブの保持期間5.5.3アーカイブの保護5.5.4アーカイブのバックアップ手順5.5.5レコードのタイムスタンプの要件5.5.6アーカイブコレクションシステム(内部または外部)5.5.7アーカイブ情報を取得して確認する手順5.6キーの切り替え5.7侵害と障害復旧5.7.1インシデントと侵害の処理手順5.7.2コンピューティングリソース、ソフトウェア、データが破損している5.7.3エンティティの秘密鍵の侵害手順5.7.4災害後のビジネス継続性機能5.8 CAまたはRAの終了6.技術的なセキュリティ管理(11)6.1鍵ペアの生成とインストール6.1.1鍵ペア生成6.1.2サブスクライバーへの秘密キー配信6.1.3証明書発行者への公開キー配信6.1.4証明書利用者へのCA公開キー配信6.1.5キーサイズ6.1.6公開キーパラメーターの生成と品質チェック6.1.7キーの使用目的( X.509 v3のキー使用法フィールドに従って)6.2秘密キーの保護と暗号化モジュールのエンジニアリングコントロール6.2.1暗号化モジュールの標準とコントロール6.2.2秘密キー(mのうちn)マルチパーソンコントロール6.2.3秘密キーのエスクロー6.2。 4秘密鍵のバックアップ6.2.5秘密鍵のアーカイブ6.2.6暗号化モジュールとの間の秘密鍵の転送6.2.7暗号化モジュール上の秘密鍵のストレージ6.2.8秘密鍵をアクティブ化する方法6.2.9秘密鍵を非アクティブ化する方法6.2.10方法 秘密鍵を破棄する方法6.2.11暗号モジュールの評価6.3鍵ペア管理のその他の側面6.3.1公開鍵のアーカイブ6.3.2証明書の運用期間と鍵ペアの使用期間6.4アクティベーションデータ6.4.1アクティベーションデータの生成とインストール6.4.2アクティベーションデータ保護6.4.3アクティベーションデータの他の側面6.5コンピューターのセキュリティ管理6.5.1特定のコンピューターのセキュリティ技術要件6.5.2コンピューターのセキュリティ評価6.6ライフサイクルの技術管理6.6.1システム開発の管理6.6.2セキュリティ管理の管理6.6.3ライフサイクルのセキュリティコントロール6.7ネットワークセキュリティコントロール6.8タイムスタンプ7.証明書、CRL、およびOCSPプロファイル7.1証明書プロファイル7.1.1バージョン番号7.1.2証明書拡張7.1.3アルゴリズムオブジェクト識別子7.1.4名前形式7.1.5名前制約7.1.6証明書ポリシーオブジェクト識別子7.1.7ポリシー制約拡張の使用法7.1.8ポリシー修飾子の構文とセマンティクス7.1.9 criの処理セマンティクス有効な証明書ポリシー拡張7.2 CRLプロファイル7.2.1バージョン番号7.2.2 CRLおよびCRLエントリ拡張7.3 OCSPプロファイル7.3.1バージョン番号7.3.2 OCSP拡張8.コンプライアンス監査およびその他の評価8.1頻度または状況評価の内容8.2評価者の身元/資格8.3評価者と評価者の関係8.4評価の対象となるトピック8.5不備の結果として取られた措置8.6結果の通知9.その他の事業と法的事項9.1料金9.1.1証明書の発行または更新料9.1。 2証明書アクセス料金9.1.3失効またはステータス情報アクセス料金9.1.4その他のサービスの料金9.1.5返金ポリシー9.2財務責任9.2.1保険の適用範囲9.2.2その他の資産9.2.3エンドエンティティの保険または保証の適用範囲9.3ビジネス情報の機密性9.3.1機密情報の範囲9.3.2機密情報の範囲外の情報9.3.3機密情報を保護する責任ormation 9.4個人情報のプライバシー9.4.1プライバシー計画9.4.2個人情報として扱われる情報9.4.3個人情報とみなされない情報9.4.4個人情報を保護する責任9.4.5個人情報の使用に関する通知と同意9.4.6司法に基づく開示または管理プロセス9.4.7その他の情報開示の状況9.5知的財産権9.6表明および保証9.6.1 CAの表明および保証9.6.2 RAの表明および保証9.6.3加入者の表明および保証9.6.4依拠当事者の表明および保証9.6.5他の参加者の表明および保証9.7保証の否認9.8責任の制限9.9補償9.10期間および終了9.10.1期間9.10.2終了9.10.3終了および存続の影響9.11個々の通知および参加者との通信9.12修正9.12.1手続き修正9.12.2通知メカニズムと期間9.12.3サーカムスタOIDを変更する必要がある場合9.13紛争解決規定9.14準拠法9.15適用法の遵守9.16その他の規定9.16.1完全合意9.16.2譲渡9.16.3分離可能性9.16.4施行(弁護士費用および権利放棄)9.16。 5不可抗力9.17その他の規定

7. Comparison to RFC 2527
7. RFC 2527との比較

This framework represents an incremental improvement over RFC 2527. The new framework benefits from the experience gained in the course of deploying CP and CPS documents under RFC 2527. Further, this new framework is based on coordination with the American Bar Association Information Security Committee within the Section of Science and Technology Law. The ISC wrote the PKI Assessment Guidelines [ABA2], which embodies a great deal of technical, business, and legal experience in PKI operations. In particular, representatives of the ISC made changes to the framework to better suite it to the legal environment and make it more accessible to lawyers.

このフレームワークは、RFC 2527の段階的な改善を表しています。新しいフレームワークは、RFC 2527の下でCPおよびCPSドキュメントを展開する過程で得られた経験から恩恵を受けます。さらに、この新しいフレームワークは、科学技術法のセクション。 ISCはPKI評価ガイドライン[ABA2]を作成しました。このガイドラインは、PKI運用における技術、ビジネス、および法的経験の多くを具体化しています。特に、ISCの代表者はフレームワークに変更を加え、法的環境により適したものにし、弁護士がよりアクセスしやすいようにしました。

>From a technical perspective, the changes to the RFC 2527 framework were minimal and incremental, rather than revolutionary. Sections 3-7 have largely been preserved, with modest reorganization and new topics. For example, the new framework includes a revision of Section 4 of the framework to include a full treatment of the certificate life-cycle, the addition of key escrow, key encapsulation, and key recovery policies and practices, and OCSP. Section 2 audit functions now appear alone in Section 8, and Section 2 focuses exclusively on repository functions. The business and legal matters in RFC 2527's Section 2 now appear in a new Section 9.

>技術的な観点から見ると、RFC 2527フレームワークへの変更は革命的なものではなく、最小限で段階的なものでした。セクション3から7は大部分が保存されており、適度な再編成と新しいトピックがあります。たとえば、新しいフレームワークには、フレームワークのセクション4の改訂が含まれており、証明書のライフサイクルの完全な取り扱い、キーのエスクローの追加、キーのカプセル化、キーの回復のポリシーと実践、およびOCSPが含まれています。セクション2の監査機能はセクション8に単独で表示されるようになり、セクション2はリポジトリー機能にのみ焦点を当てています。 RFC 2527のセクション2のビジネスおよび法的事項は、新しいセクション9に表示されます。

From a legal perspective, the new Section 9 is useful because it places topics in the framework in an ordering that is similar to software licensing and other technology agreements and thus is familiar to technology lawyers. Moreover, the framework as a whole can double as a framework for a subscriber, relying party, or other PKI-related agreement. The changes are intended to make legal review of, and input into, CP and CPS documents more efficient. Section 9 also adds new legal topics, such as the privacy of personal information, liability terms, and duration of the effectiveness of the document.


Section 1 of the new framework is largely the same as RFC 2527, although it increases coverage of PKI participants by breaking out subscribers from relying parties and adding a section for other participants. It changes the "applicability" section to one covering appropriate and prohibited uses of certificates. Also, it moves CPS approval procedures from RFC 2527's Section 8.3 into a collected policy administration section. Finally, Section 1.6 adds a place to list definitions and acronyms.

新しいフレームワークのセクション1はRFC 2527とほぼ同じですが、サブスクライバーを依存パーティから切り離し、他の参加者用のセクションを追加することにより、PKI参加者のカバレッジを増やします。 「適用可能性」セクションを、証明書の適切で禁止された使用をカバーするセクションに変更します。また、CPS承認手順をRFC 2527のセクション8.3から収集されたポリシー管理セクションに移動します。最後に、セクション1.6は定義と頭字語をリストする場所を追加します。

Section 2 of the new framework is a reorganization of Section 2.6 of the old framework. Section 3 of the new framework is based on a division of the old Section 3.1 into two parts for naming and identification and authentication issues. It adds new issues, such as the permissibility of pseudonyms and anonymity. Old Section 4 topics on audit logging, record archives, key changeover, compromise and disaster recovery, and CA termination have moved to Section 5. The remaining Section 4 topics have been expanded and reorganized to cover a complete certificate lifecycle. New topics include items implicit in the RFC 2527 Section 4, but now explicit, such as certificate application processing, certificate modification, and the end of subscription.

新しいフレームワークのセクション2は、古いフレームワークのセクション2.6の再編成です。新しいフレームワークのセクション3は、ネーミングと識別および認証の問題のために、古いセクション3.1を2つの部分に分割したものに基づいています。それは、仮名と匿名性の許容性などの新しい問題を追加します。監査ログ、レコードアーカイブ、キーの切り替え、侵害と障害復旧、およびCAの終了に関する古いセクション4のトピックは、セクション5に移動しました。残りのセクション4トピックは、完全な証明書ライフサイクルをカバーするように拡張および再編成されました。新しいトピックには、RFC 2527セクション4で暗黙的であった項目が含まれますが、現在は証明書アプリケーションの処理、証明書の変更、サブスクリプションの終了などが明示されています。

New Sections 5.1 through 5.3 are almost identical to their counterparts in RFC 2527. The remainder of the new Section 5 is the topics moved from RFC 2527's Section 4, in the order that they appeared in Section 4. Section 6 of the new framework is almost the same as the old Section 6, with some exceptions, such as the consolidation of old Section 6.8 (cryptographic module engineering controls) into Section 6.2.1 (now called "cryptographic module standards and controls") and the addition of time-stamping in a new Section 6.8. Section 7 is almost identical to the old Section 7, the major change being the addition of a section covering OCSP profile. Section 8 is almost identical to RFC 2527's Section 2.7.

新しいセクション5.1から5.3は、RFC 2527の対応するセクションとほぼ同じです。新しいセクション5の残りの部分は、RFC 2527のセクション4から移動されたトピックであり、セクション4に記載された順になっています。新しいフレームワークのセクション6はほぼ古いセクション6.8(暗号化モジュールエンジニアリングコントロール)をセクション6.2.1(現在は「暗号化モジュール標準とコントロール」と呼ばれる)に統合し、タイムスタンプを追加するなど、いくつかの例外を除いて、古いセクション6と同じです。新しいセクション6.8。セクション7は古いセクション7とほとんど同じですが、主な変更はOCSPプロファイルをカバーするセクションの追加です。セクション8はRFC 2527のセクション2.7とほとんど同じです。

New Section 9 contains business and legal topics that were covered in RFC 2527's Section 2, including fees, financial responsibility, confidentiality, and intellectual property. It adds a section on the privacy of personal information, which has become a significant policy issue. The "liability" Section 2.2 in RFC 2527 now appears in Sections 9.6 through 9.9, covering representations and warranties, disclaimers, limitations of liability, and indemnities. Section 9.10 adds a section concerning the duration of the effectiveness of documentation. Section 9.12 collects terms concerning the way in which a document (CP, CPS, agreement, or other document) may be amended, formerly appearing in Section 8.1. Section 9 includes "legal boilerplate" topics, some of which were in the old Section 2. Finally, Section 9.17 is a catch-all "other provisions" section where drafters can place information that does not fit well into any other section of the framework.

新しいセクション9には、RFC 2527のセクション2でカバーされたビジネスおよび法的トピックが含まれ、料金、財務責任、機密性、および知的財産が含まれます。重要な政策問題となっている個人情報のプライバシーに関するセクションを追加します。 RFC 2527の「責任」セクション2.2がセクション9.6〜9.9に表示されるようになり、表明と保証、免責事項、責任の制限、および補償をカバーしています。セクション9.10では、ドキュメントの有効期間に関するセクションが追加されています。セクション9.12は、ドキュメント(CP、CPS、契約、またはその他のドキュメント)の修正方法に関する用語を収集します。以前はセクション8.1に表示されていました。セクション9には、「法的定型文」のトピックが含まれ、その一部は古いセクション2にありました。最後に、セクション9.17は、ドラフト作成者がフレームワークの他のセクションにうまく適合しない情報を配置できる、包括的な「その他の条項」セクションです。 。

The following matrix shows the sections in the old RFC 2527 framework and their successor sections in the new framework.

次のマトリックスは、古いRFC 2527フレームワークのセクションと、新しいフレームワークの後続セクションを示しています。

   ORIGINAL RFC 2527                     NEW RFC SECTION
   1. Introduction                             1.
   1.1 Overview                                1.1
   1.2 Identification                          1.2
   1.3 Community and
       Applicability                           1.3
   1.3.1 Certification
         Authorities                           1.3.1
   1.3.2 Registration Authorities              1.3.2
   1.3.3 End entities                          1.3.3,
   1.3.4 Applicability                         1.4, 4.5
   1.4 Contact Details                         1.5
   1.4.1 Specification Administration
         Organization                          1.5.1
   1.4.2 Contact Person                        1.5.2
   1.4.3 Person Determining CPS
         Suitability for the Policy            1.5.3
   2. General Provisions                       2, 8, 9
   2.1 Obligations                             2.6.4
   2.1.1 1A Obligations                  Integrated
                                         portions of the
                                         framework that
                                         apply to CAs
   2.1.2 RA Obligations                  Integrated
                                         portions of the
                                         framework that
                                         apply to RAs
   2.1.3 Subscriber Obligations          4.1.2, 4.4, 4.5,
                                         4.5.1, 4.6.5,
                                         4.7.5, 4.8.1,
                                         4.8.5, 4.9.1,
                                         4.9.2, 4.9.13,
                                         4.9.15, 5., 6.,
                                         9.6.3, 9.9
   2.1.4 Relying Party Obligations     4.5, 4.5.2, 4.9.6,
                                       5., 6., 9.6.4, 9.9
   2.1.5 Repository Obligations        2., 4.4.2, 4.4.3,
                                       4.6.6, 4.6.7,
                                       4.7.6, 4.7.7,
                                       4.8.6, 4.8.7
   2.2 Liability                       9.6, 9.7, 9.8, 9.9
   2.2.1 CA Liability                  9.6.1, 9.7., 9.8,
   2.2.2 RA Liability                  9.6.2, 9.7, 9.8, 9.9
   2.3 Financial Responsibility                9.2
   2.3.1 Indemnification by Relying
         Parties                               9.9
   2.3.2 Fiduciary Relationships               9.7
   2.4 Interpretation and Enforcement          9.16
   2.4.1 Governing Law                         9.14, 9.15
   2.4.2 Severability, Survival,
         Merger, Notice                9.10.3, 9.11,
   2.4.3 Dispute Resolution
         Procedures                    9.13, 9.16.4
   2.5 Fees                                    9.1
   2.5.1 Certificate Issuance
         or Renewal Fees                       9.1.1
   2.5.2 Certificate Access Fees               9.1.2
   2.5.3 Revocation or Status
         Information Access Fees               9.1.3
   2.5.4 Fees for Other Services Such
         as Policy Information                 9.1.4
   2.5.5 Refund Policy                         9.1.5
   2.6 Publication and Repository              2.
   2.6.1 Publication of CA
         Information                    2.2, 4.4.2,
                                        4.4.3, 4.6.6,
                                        4.6.7, 4.7.6,
                                        4.7.7, 4.8.6,
   2.6.2 Frequency of Publication              2.3
   2.6.3 Access Controls                       2.4
   2.6.4 Repositories                          2.1
   2.7 Compliance Audit                        8.
   2.7.1 Frequency of Entity Compliance
         Audit                                 8.1
   2.7.2 Identity/Qualifications of
         Auditor                               8.2
   2.7.3 Auditor's Relationship to Audited
         Party                                 8.3
   2.7.4 Topics Covered by Audit               8.4
   2.7.5 Actions Taken as a Result of
         Deficiency                            8.5
   2.7.6 Communications of Results             8.6
   2.8 Confidentiality                         9.3, 9.4
   2.8.1 Types of Information to be
         Kept Confidential              9.3.1, 9.4.2
   2.8.2 Types of Information Not
         Considered Confidential        9.3.2, 9.4.3
   2.8.3 Disclosure of Certificate
         Information                    9.3.1, 9.3.2,
                                        9.3.3, 9.4.2,
                                        9.4.3, 9.4.4
   2.8.4 Release to Law Enforcement
         Officials                      9.3.3, 9.4.6
   2.8.5 Release as Part of Civil
   Discovery                            9.3.3, 9.4.6
   2.8.6 Disclosure Upon Owner's
         Request                        9.3.3, 9.4.7
   2.8.7 Other Information Release
         Circumstances                  9.3.3, 9.4.7
   2.9 Intellectual Property Rights            9.5
   3. Identification and Authentication        3.
   3.1 Initial Registration                    3.1, 3.2
   3.1.1 Type of Names                         3.1.1
   3.1.2 Need for Names to be
         Meaningful                     3.1.2, 3.1.3
   3.1.3 Rules for Interpreting
         Various Name Forms                    3.1.4
   3.1.4 Uniqueness of Names                   3.1.5
   3.1.5 Name Claim Dispute
         Resolution Procedure                  3.1.6
   3.1.6 Recognition, Authentication,
         and Role of Trademarks                3.1.6
   3.1.7 Method to Prove Possession
         of Private Key                        3.2.1
   3.1.8 Authentication of
         Organization Identity                 3.2.2
   3.1.9 Authentication of
         Individual Identity                   3.2.3
   3.2 Routine Rekey                    3.3.1, 4.6, 4.7
   3.3 Rekey After Revocation                  3.3.2
   3.4 Revocation Request                      3.4
   4.  Operational Requirements                4., 5.
   4.1 Certificate Application          4.1, 4.2, 4.6,
   4.2 Certificate Issuance             4.2, 4.3, 4.4.3,
                                        4.6, 4.7, 4.8.4,
                                        4.8.6, 4.8.7
   4.3 Certificate Acceptance           4.3.2, 4.4, 4.6,
                                        4.7, 4.8.4-4.8.7
   4.4 Certificate Suspension
       and Revocation                          4.8, 4.9
   4.4.1 Circumstances for Revocation   4.8.1, 4.9.1
   4.4.2 Who Can Request Revocation     4.8.2, 4.9.2
   4.4.3 Procedure for Revocation
         Request                        4.8.3-4.8.7,
   4.4.4 Revocation Request
         Grace Period                          4.9.4
   4.4.5 Circumstances for Suspension          4.9.13
   4.4.6 Who Can Request Suspension            4.9.14
   4.4.7 Procedure for Suspension
         Request                               4.9.15
   4.4.8 Limits on Suspension Period           4.9.16
   4.4.9 CRL Issuance Frequency
         (If Applicable)                  4.9.7, 4.9.8,
   4.4.10 CRL Checking Requirements       4.9.6, 4.10
   4.4.11 On-Line Revocation/
          Status Checking
          Availability                    4.9.9, 4.10
   4.4.12 On-Line Revocation
          Checking Requirements           4.9.6, 4.9.10,
   4.4.13 Other Forms
          of Revocation
          Advertisements                  4.9.11, 4.10
   4.4.14 Checking Requirements
          for Other Forms of
          Advertisements                  4.9.6, 4.9.11,
   4.4.15 Special Requirements re
          Key Compromise                        4.9.12
   4.5 Security Audit Procedures                5.4
   4.5.1 Types of Events Recorded               5.4.1
   4.5.2 Frequency of Processing Log            5.4.2
   4.5.3 Retention Period for Audit
         Log                                    5.4.3
   4.5.4 Protection of Audit Log                5.4.4
   4.5.5 Audit Log Backup Procedures            5.4.5
   4.5.6 Audit Collection System
         (Internal vs. External)                5.4.6
   4.5.7 Notification to Event-Causing
         Subject                                5.4.7
   4.5.8 Vulnerability Assessments              5.4.8
   4.6 Records Archival                         5.5
   4.6.1 Types of Records Archived              5.5.1
   4.6.2 Retention Period for Archive           5.5.2
   4.6.3 Protection of Archive                  5.5.3
   4.6.4 Archive Backup Procedures              5.5.4
   4.6.5 Requirements for
         Time-Stamping of Records               5.5.5
   4.6.6 Archive Collection System
         (Internal or External)                 5.5.6
   4.6.6 Procedures to Obtain and
         Verify Archive Information             5.5.7
   4.7 Key Changeover                           5.6
   4.8 Compromise and Disaster
       Recovery                           5.7, 5.7.1
   4.8.1 Computing Resources, Software,
         and/or Data Are Corrupted              5.7.2
   4.8.2 Entity Public
         Key is Revoked                   4.9.7, 4.9.9,
   4.8.3 Entity Key is Compromised             5.7.3
   4.8.4 Secure Facility After a Natural
         or Other Type of Disaster             5.7.4
   4.9 CA Termination                          5.8
   5. Physical, Procedural, and
      Personnel Security Controls              5.
   5.1 Physical Controls                       5.1
   5.1.1 Site Location and Construction        5.1.1
   5.1.2 Physical Access                       5.1.2
   5.1.3 Power and Air Conditioning            5.1.3
   5.1.4 Water Exposures                       5.1.4
   5.1.5 Fire Prevention and Protection        5.1.5
   5.1.6 Media Storage                         5.1.6
   5.1.7 Waste Disposal                        5.1.7
   5.1.8 Off-Site Backup                       5.1.8
   5.2 Procedural Controls                     5.2
   5.2.1 Trusted Roles                    5.2.1, 5.2.4
   5.2.2 Number of Persons
         Required per Task                5.2.2, 5.2.4
   5.2.3 Identification and
         Authentication for Each Role          5.2.3
   5.3 Personnel Controls                      5.3
   5.3.1 Background, Qualifications,
         Experience, and Clearance
         Requirements                          5.3.1
   5.3.2 Background Check Procedures           5.3.2
   5.3.3 Training Requirements                 5.3.3
   5.3.4 Retraining Frequency
         and Requirements                      5.3.4
   5.3.5 Job Rotation Frequency
         and Sequence                          5.3.5
   5.3.6 Sanctions for
         Unauthorized Actions                  5.3.6
   5.3.7 Contracting Personnel
         Requirements                          5.3.7
   5.3.8 Documentation Supplied to
         Personnel                             5.3.8
   6. Technical Security Controls              6.
   6.1 Key Pair Generation and
       Installation                            6.1
   6.1.1 Key Pair Generation                   6.1.1
   6.1.2 Private Key Delivery to Entity        6.1.2
   6.1.3 Public Key Delivery to
         Certificate Issuer                    6.1.3
   6.1.4 CA Public Key Delivery to Users       6.1.4
   6.1.5 Key Sizes                             6.1.5
   6.1.6 Public Key Parameters Generation      6.1.6
   6.1.7 Parameter Quality Checking            6.1.6
   6.1.8 Hardware/Software Key Generation      6.1.1
   6.1.9 Key Usage Purposes
         (as per X.509 v3 Key Usage Field)     6.1.9
   6.2 Private Key Protection                  6.2
   6.2.1 Standards for Cryptographic
         Module                                6.2.1
   6.2.2 Private Key (n out of m)
         Multi-Person Control                  6.2.2
   6.2.3 Private Key Escrow                    6.2.3
   6.2.4 Private Key Backup                    6.2.4
   6.2.5 Private Key Archival                  6.2.5
   6.2.6 Private Key Entry Into
         Cryptographic Module              6.2.6, 6.2.7
   6.2.7 Method of Activating
         Private Key                           6.2.8
   6.2.8 Method of Deactivating
         Private Key                           6.2.9
   6.2.9 Method of Destroying Private
         Key                                   6.2.10
   6.3 Other Aspects of Key Pair
       Management                              6.3
   6.3.1 Public Key Archival                   6.3.1
   6.3.2 Usage Periods for the Public
         and Private Keys                      6.3.2
   6.4 Activation Data                         6.4
   6.4.1 Activation Data Generation
         and Installation                      6.4.1
   6.4.2 Activation Data Protection            6.4.2
   6.4.3 Other Aspects of Activation
         Data                                  6.4.3
   6.5 Computer Security Controls              6.5
   6.5.1 Specific Computer Security
         Technical Requirements                6.5.1
   6.5.2 Computer Security Rating              6.5.2
   6.6 Life Cycle Technical Controls           6.6
   6.6.1 System Development Controls           6.6.1
   6.6.2 Security Management Controls          6.6.2
   6.6.3 Life Cycle Security Controls          6.6.3
   6.7 Network Security Controls               6.7
   6.8 Cryptographic Module
       Engineering Controls                 6.2.1, 6.2,
                                            6.2.1, 6.2.11
   7.Certificate and CRL Profiles              7.
   7.1 Certificate Profile                     7.1
   7.1.1 Version Number(s)                     7.1.1
   7.1.2 Certificate Extensions                7.1.2
   7.1.3 Algorithm Object Identifiers          7.1.3
   7.1.4 Name Forms                            7.1.4
   7.1.5 Name Constraints                      7.1.5
   7.1.6 Certificate Policy Object
         Identifier                            7.1.6
   7.1.7 Usage of Policy Constraints
         Extension                             7.1.7
   7.1.8 Policy Qualifiers Syntax
         and Semantics                         7.1.8
   7.1.9 Processing Semantics for
         the Critical Certificate
         Policies Extension                    7.1.9
   7.2 CRL Profile                             7.2
   7.2.1 Version Number(s)                     7.2.1
   7.2.2 CRL and CRL Entry Extensions          7.2.1
   8. Specification Administration             N/A
   8.1 Specification Change
       Procedures                              9.12
   8.2 Publication and Notification
       Policies                                2.2, 2.3
   8.3 CPS Approval Procedures                 1.5.4
   The following matrix shows the sections in the new framework and the
   sections in RFC 2527 to which the headings in the new framework
   NEW RFC SECTION                      ORIGINAL RFC 2527
   1. Introduction                             1.
   1.1 Overview                                1.1
   1.2 Document Name and Identification        1.2
   1.3 PKI Participants                        1.3
   1.3.1 Certification Authorities             1.3.1
   1.3.2 Registration Authorities              1.3.2
   1.3.3 Subscribers                           1.3.3
   1.3.4 Relying Parties                       1.3.3
   1.3.5 Other Participants                    N/A
   1.4 Certificate Usage                       1.3.4
   1.4.1 Appropriate Certificate Uses          1.3.4
   1.4.2 Prohibited Certificate Uses           1.3.4
   1.5 Policy Administration                   1.4
   1.5.1 Organization Administering
         the Document                          1.4.1
   1.5.2 Contact Person                        1.4.2
   1.5.3 Person Determining CPS
         Suitability for the Policy            1.4.3
   1.5.4 CPS Approval Procedures               8.3
   1.6 Definitions and Acronyms                N/A
   2. Publication and Repository
      Responsibilities                         2.1.5, 2.6
   2.1 Repositories                            2.6.4
   2.2 Publication of Certification
       Information                             2.6.1, 8.2
   2.3 Time or Frequency of
       Publication                             2.6.2, 8.2
   2.4 Access Controls on Repositories         2.6.3
   3. Identification and Authentication        3.
   3.1 Naming                                  3.1
   3.1.1 Type of Names                         3.1.1
   3.1.2 Need for Names to be Meaningful       3.1.2
   3.1.3. Anonymity or Pseudonymity of
          Subscribers                          3.1.2
   3.1.4 Rules for Interpreting Various
         Name Forms                            3.1.3
   3.1.5 Uniqueness of Names                   3.1.4
   3.1.6 Recognition, Authentication,
         and Role of Trademarks           3.1.5, 3.1.6
   3.2 Initial Identity Validation             3.1
   3.2.1 Method to Prove Possession
         of Private Key                        3.1.7
   3.2.2 Authentication of
         Organization Identity                 3.1.8
   3.2.3 Authentication of Individual
         Identity                              3.1.9
   3.2.4 Non-Verified Subscriber
         Information                           N/A
   3.2.5 Validation of Authority               3.1.9
   3.2.6 Criteria for Interoperation           4.1
   3.3 Identification and Authentication
       for Re-Key Requests                     3.2, 3.3
   3.3.1 Identification and
         Authentication for Routine
         Re-Key                                3.2
   3.3.2 Identification and
         Authentication for Re-Key
         After Revocation                      3.3
   3.4 Identification and Authentication
       for Revocation Request                  3.4
   4. Certificate Life-Cycle
      Operational Requirements                 4.
   4.1 Certificate Application                 4.1
   4.1.1 Who Can Submit a Certificate
         Application                           4.1
   4.1.2 Enrollment Process and
         Responsibilities                      2.1.3, 4.1
   4.2 Certificate Application
       Processing                              4.1, 4.2
   4.2.1 Performing Identification
         and Authentication Functions          4.1, 4.2
   4.2.2 Approval or Rejection of
         Certificate Applications              4.1, 4.2
   4.2.3 Time to Process
         Certificate Applications              4.1, 4.2
   4.3 Certificate Issuance                    4.2
   4.3.1 CA Actions During
         Certificate Issuance                  4.2
   4.3.2 Notifications to Subscriber by
         the CA of Issuance of Certificate     4.2, 4.3
   4.4 Certificate Acceptance                  2.1.3, 4.3
   4.4.1 Conduct Constituting
         Certificate Acceptance                4.3
   4.4.2 Publication of the
         Certificate by the CA          2.1.5, 2.6.1, 4.3
   4.4.3 Notification of
         Certificate Issuance by
         the CA to Other Entities       2.1.5, 2.6.1,
                                        4.2, 4.3
   4.5 Key Pair and
       Certificate Usage                1.3.4, 2.1.3,
   4.5.1 Subscriber Private Key
         and Certificate Usage          1.3.4, 2.1.3
   4.5.2 Relying Party Public
         Key and Certificate
         Usage                          1.3.4, 2.1.4
   4.6 Certificate Renewal              3.2, 4.1, 4.2,
   4.6.1 Circumstances for
         Certificate Renewal            3.2, 4.1
   4.6.2 Who May Request Renewal        3.2, 4.1
   4.6.3 Processing Certificate
         Renewal Requests               3.2, 4.1, 4.2
   4.6.4 Notification of New
         Certificate Issuance to
         Subscriber                     3.2, 4.2, 4.3
   4.6.5 Conduct Constituting
         Acceptance of a Renewal
         Certificate                    2.1.3, 3.2, 4.3
   4.6.6 Publication of the
         Renewal Certificate
         by the CA                      2.1.5, 2.6.1,
                                        3.2, 4.3
   4.6.7 Notification of
         Certificate Issuance by
         the CA to Other Entities       2.1.5, 2.6.1, 3.2,
                                        4.2, 4.3
   4.7 Certificate Re-Key               3.2, 4.1, 4.2, 4.3
   4.7.1 Circumstances for
         Certificate Re-Key             3.2, 4.1
   4.7.2 Who May Request Certification
         of a New Public Key            3.2, 4.1
   4.7.3 Processing Certificate
         Re-Keying Requests             3.2, 4.1, 4.2
   4.7.4 Notification of New
         Certificate Issuance to
         Subscriber                     3.2, 4.2, 4.3
   4.7.5 Conduct Constituting
         Acceptance of a
         Re-Keyed Certificate           2.1.3, 3.2, 4.3
   4.7.6 Publication of the
         Re-Keyed Certificate
         by the CA                      2.1.5, 2.6.1,
                                        3.2, 4.3
   4.7.7 Notification of Certificate
         Issuance by the CA
         to Other Entities              2.1.5, 2.6.1,
                                        3.2, 4.2, 4.3
   4.8 Certificate Modification                4.4
   4.8.1 Circumstances for
         Certificate Modification       2.1.3, 4.4.1
   4.8.2 Who May Request Certificate
         Modification                   4.4.2
   4.8.3 Processing Certificate
         Modification Requests          4.4.3
   4.8.4 Notification of New
         Certificate Issuance to
         Subscriber                     4.2, 4.3, 4.4.3
   4.8.5 Conduct Constituting
         Acceptance of Modified
         Certificate                    2.1.3, 4.3, 4.4.3
   4.8.6 Publication of the Modified
         Certificate by
         the CA                         2.1.5, 2.6.1,
                                        4.2, 4.3, 4.4.3
   4.8.7 Notification of
         Certificate Issuance by
         the CA to Other
         Entities                       2.1.5, 2.6.1,
                                        4.2, 4.3, 4.4.3
   4.9 Certificate Revocation
       and Suspension                          4.4
   4.9.1 Circumstances for Revocation   2.1.3, 4.4.1
   4.9.2 Who Can Request Revocation     4.4.2
   4.9.3 Procedure for Revocation
         Request                        2.1.3, 4.4.3
   4.9.4 Revocation Request Grace
         Period                                4.4.4
   4.9.5 Time Within Which CA Must
         Process the Revocation Request    N/A
   4.9.6 Revocation Checking
         Requirements for Relying
         Parties                         2.1.4, 4.4.10,
                                         4.4.12, 4.4.14
   4.9.7 CRL Issuance Frequency          4.4.9, 4.8.3
   4.9.8 Maximum Latency for CRLs        4.4.9
   4.9.9 On-Line Revocation/Status
         Checking Availability           4.4.11, 4.8.3
   4.9.10 On-Line Revocation
          Checking Requirements          4.4.12
   4.9.11 Other Forms of Revocation
          Advertisements Available       4.4.13, 4.4.14,
   4.9.12 Special Requirements re
          Key Compromise                 4.4.15
   4.9.13 Circumstances for Suspension   2.1.3, 4.4.5
   4.9.14 Who Can Request Suspension     4.4.6
   4.9.15 Procedure for
          Suspension Request             2.1.3, 4.4.7
   4.9.16 Limits on Suspension Period    4.4.8
   4.10 Certificate Status Services      4.4.9-4.4.14
   4.10.1 Operational
          Characteristics                4.4.9, 4.4.11,
   4.10.2 Service Availability           4.4.9, 4.4.11,
   4.10.3 Operational Features           4.4.9, 4.4.11,
   4.11 End of Subscription                       N/A
   4.12 Key Escrow and Recovery                  6.2.3
   4.12.1 Key Escrow and Recovery Policy
          and Practices                          6.2.3
   4.12.2 Session Key Encapsulation
          and Recovery Policy and
          Practices                              6.2.3
   5. Facility, Management, and
      Operational Controls               2.1.3, 2.1.4,
                                         4., 5.
   5.1 Physical Controls                         5.1
   5.1.1 Site Location and Construction          5.1.1
   5.1.2 Physical Access                         5.1.2
   5.1.3 Power and Air Conditioning              5.1.3
   5.1.4 Water Exposures                         5.1.4
   5.1.5 Fire Prevention and Protection          5.1.5
   5.1.6 Media Storage                           5.1.6
   5.1.7 Waste Disposal                          5.1.7
   5.1.8 Off-Site Backup                         5.1.8
   5.2 Procedural Controls                       5.2
   5.2.1 Trusted Roles                           5.2.1
   5.2.2 Number of Persons Required
         per Task                                5.2.2
   5.2.3 Identification and
         Authentication for Each Role            5.2.3
   5.2.4 Roles Requiring Separation
         of Duties                          5.2.1, 5.2.2
   5.3 Personnel Controls                        5.3
   5.3.1 Qualifications, Experience,
         and Clearance Requirements         5.3.1
   5.3.2 Background Check Procedures        5.3.2
   5.3.3 Training Requirements              5.3.3
   5.3.4 Retraining Frequency
         and Requirements                   5.3.4
   5.3.5 Job Rotation Frequency
         and Sequence                       5.3.5
   5.3.6 Sanctions for Unauthorized
         Actions                            5.3.6
   5.3.7 Independent Contractor
         Requirements                       5.3.7
   5.3.8 Documentation Supplied to
         Personnel                          5.3.8
   5.4 Audit Logging Procedures             4.5
   5.4.1 Types of Events Recorded           4.5.1
   5.4.2 Frequency of Processing Log        4.5.2
   5.4.3 Retention Period for Audit
         Log                                4.5.3
   5.4.4 Protection of Audit Log            4.5.4
   5.4.5 Audit Log Backup Procedures        4.5.5
   5.4.6 Audit Collection System
         (Internal vs. External)            4.5.6
   5.4.7 Notification to Event-Causing
         Subject                            4.5.7
   5.4.8 Vulnerability Assessments          4.5.8
   5.5 Records Archival                     4.6
   5.5.1 Types of Records Archived          4.6.1
   5.5.2 Retention Period for Archive       4.6.2
   5.5.3 Protection of Archive              4.6.3
   5.5.4 Archive Backup Procedures          4.6.4
   5.5.5 Requirements for Time-Stamping
         of Records                         4.6.5
   5.5.6 Archive Collection System
         (Internal or External)             4.6.6
   5.5.7 Procedures to Obtain and
         Verify Archive
         Information                        4.6.7
   5.6 Key Changeover                       4.7
   5.7 Compromise and Disaster Recovery     4.8
   5.7.1 Incident and Compromise
         Handling Procedures                4.8
   5.7.2 Computing Resources, Software,
         and/or Data Are Corrupted          4.8.1
   5.7.3 Entity Private Key
         Compromise Procedures              4.8.3
   5.7.4 Business Continuity
         Capabilities After a
         Disaster                           4.8.4
   5.8 CA or RA Termination                 4.9
   6. Technical Security Controls           2.1.3, 2.1.4,
   6.1 Key Pair Generation and
       Installation                         6.1
   6.1.1 Key Pair Generation                6.1.1, 6.1.8
   6.1.2 Private Key Delivery to
         Subscriber                         6.1.2
   6.1.3 Public Key Delivery to
         Certificate Issuer                 6.1.3
   6.1.4 CA Public Key Delivery to
         Relying Parties                    6.1.4
   6.1.5 Key Sizes                          6.1.5
   6.1.6 Public Key Parameters Generation
         and Quality Checking               6.1.6, 6.1.7
   6.1.7 Key Usage Purposes
         (as per X.509 v3
         Key Usage Field)                   6.1.9
   6.2   Private Key Protection and
         Cryptographic Module
         Engineering Controls               6.2, 6.8
   6.2.1 Cryptographic Module Standards
         and Controls                       6.2.1, 6.8
   6.2.2 Private Key (n out of m)
         Multi-Person Control               6.2.2
   6.2.3 Private Key Escrow                 6.2.3
   6.2.4 Private Key Backup                 6.2.4
   6.2.5 Private Key Archival               6.2.5
   6.2.6 Private Key Transfer Into
         or From a Cryptographic
         Module                             6.2.6
   6.2.7 Private Key Storage on
         Cryptographic Module               6.2.6
   6.2.8 Method of Activating Private
         Key                                6.2.7
   6.2.9 Method of Deactivating
         Private Key                        6.2.8
   6.2.10 Method of Destroying
          Private Key                       6.2.9
   6.2.11 Cryptographic Module Rating       6.2.1, 6.8
   6.3 Other Aspects of Key Pair
       Management                           6.3
   6.3.1 Public Key Archival                6.3.1
   6.3.2 Certificate Operational
         Periods and Key Pair Usage
         Periods                            6.3.2
   6.4 Activation Data                      6.4
   6.4.1 Activation Data Generation
         and Installation                   6.4.1
   6.4.2 Activation Data Protection         6.4.2
   6.4.3 Other Aspects of Activation
         Data                               6.4.3
   6.5 Computer Security Controls           6.5
   6.5.1 Specific Computer Security
         Technical Requirements             6.5.1
   6.5.2 Computer Security Rating           6.5.2
   6.6 Life Cycle Technical Controls        6.6
   6.6.1 System Development Controls        6.6.1
   6.6.2 Security Management Controls       6.6.2
   6.6.3 Life Cycle Security Controls       6.6.3
   6.7 Network Security Controls            6.7
   6.8 Time-Stamping                        N/A
   7. Certificate, CRL, and
      OCSP Profiles                         7.
   7.1 Certificate Profile                  7.1
   7.1.1 Version Number(s)                  7.1.1
   7.1.2 Certificate Extensions             7.1.2
   7.1.3 Algorithm Object Identifiers       7.1.3
   7.1.4 Name Forms                         7.1.4
   7.1.5 Name Constraints                   7.1.5
   7.1.6 Certificate Policy
         Object Identifier                  7.1.6
   7.1.7 Usage of Policy Constraints
         Extension                          7.1.7
   7.1.8 Policy Qualifiers Syntax
         and Semantics                      7.1.8
   7.1.9 Processing Semantics for the
         Critical Certificate Policies
         Extension                          7.1.9
   7.2 CRL Profile                          7.2
   7.2.1 Version Number(s)                  7.2.1
   7.2.2 CRL and CRL Entry Extensions       7.2.1
   7.3 OCSP Profile                         N/A
   7.3.1 Version Number(s)                  N/A
   7.3.2 OCSP Extensions                    N/A
   8. Compliance Audit and Other
      Assessments                           2.7
   8.1 Frequency and Circumstances
       of Assessment                        2.7.1
   8.2 Identity/Qualifications of
       Assessor                             2.7.2
   8.3 Assessor's Relationship to
       Assessed Entity                      2.7.3
   8.4 Topics Covered by Assessment         2.7.4
   8.5 Actions Taken as a Result
       of Deficiency                        2.7.5
   8.6 Communications of Results            2.7.6
   9. Other Business and Legal
      Matters                               2.
   9.1 Fees                                 2.5
   9.1.1 Certificate Issuance or
         Renewal Fees                       2.5.1
   9.1.2 Certificate Access Fees            2.5.2
   9.1.3 Revocation or Status
         Information Access Fees            2.5.3
   9.1.4 Fees for Other Services            2.5.4
   9.1.5 Refund Policy                      2.5.5
   9.2 Financial Responsibility             2.3
   9.2.1 Insurance Coverage                 2.3
   9.2.2 Other Assets                       2.3
   9.2.3 Insurance or Warranty Coverage
         for End-Entities                   2.3
   9.3 Confidentiality of Business
       Information                          2.8
   9.3.1 Scope of Confidential
         Information                        2.8.1, 2.8.3
   9.3.2 Information Not Within the
         Scope of Confidential
         Information                        2.8.2, 2.8.3
   9.3.3 Responsibility to Protect
         Confidential Information           2.8,
   9.4 Privacy of Personal Information      2.8
   9.4.1 Privacy Plan                       N/A
   9.4.2 Information Treated as Private     2.8.1, 2.8.3
   9.4.3 Information Not Deemed Private     2.8.2, 2.8.3
   9.4.4 Responsibility to Protect
         Private Information                2.8, 2.8.1,
   9.4.5 Notice and Consent to Use
         Private Information                N/A
   9.4.6 Disclosure Pursuant to
         Judicial or Administrative
         Process                            2.8.4-2.8.5
   9.4.7 Other Information Disclosure
         Circumstances                      2.8.6-2.8.7
   9.5 Intellectual Property rights         2.9
   9.6 Representations and Warranties       2.2
   9.6.1 CA Representations and
         Warranties                         2.2.1
   9.6.2 RA Representations and
         Warranties                         2.2.2
   9.6.3 Subscriber Representations
         and Warranties                     2.1.3
   9.6.4 Relying Party Representations
         and Warranties                     2.1.4
   9.6.5 Representations and Warranties
         of Other Participants                 N/A
   9.7 Disclaimers of Warranties            2.2, 2.3.2
   9.8 Limitations of Liability                2.2
   9.9 Indemnities                          2.1.3, 2.1.4,
                                            2.2, 2.3.1
   9.10 Term and Termination                   N/A
   9.10.1 Term                                 N/A
   9.10.2 Termination                          N/A
   9.10.3 Effect of Termination and
          Survival                             N/A
   9.11 Individual Notices and
        Communications with Participants       2.4.2
   9.12 Amendments                             8.1
   9.12.1 Procedure for Amendment              8.1
   9.12.2 Notification Mechanism
          and Period                           8.1
   9.12.3 Circumstances Under Which OID
          Must be Changed                      8.1
   9.13 Dispute Resolution Provisions          2.4.3
   9.14 Governing Law                          2.4.1
   9.15 Compliance with Applicable Law         2.4.1
   9.16 Miscellaneous Provisions               2.4
   9.16.1 Entire Agreement                     2.4.2
   9.16.2 Assignment                           N/A
   9.16.3 Severability                         2.4.2
   9.16.4 Enforcement (Attorney's Fees
          and Waiver of Rights)                2.4.3
   9.17 Other Provisions                       N/A
8. Acknowledgements
8. 謝辞

The development of the predecessor document (RFC 2527) was supported by the Government of Canada's Policy Management Authority (PMA) Committee, the National Security Agency, the National Institute of Standards and Technology (NIST), and the American Bar Association Information Security Committee Accreditation Working Group.

先行文書(RFC 2527)の開発は、カナダ政府の政策管理局(PMA)委員会、国家安全保障局、国立標準技術研究所(NIST)、および米国弁護士会情報セキュリティ委員会の認定によってサポートされましたワーキンググループ。

This revision effort is largely a result of constant inspiration from Michael Baum. Michael Power, Mike Jenkins, and Alice Sturgeon have also made several contributions.


9. References
9. 参考文献

[ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce, 1996.


[ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, Public Draft For Comment, June 2001.

[ABA2] American Bar Association、PKI​​評価ガイドライン、v0.30、パブリックドラフトフォーコメント、2001年6月。

[BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR-94-654, June 1994, available at

[BAU1]マイケル。 S. Baum、連邦認証局の責任とポリシー、NIST-GCR-94-654、1994年6月、から入手可能。

[ETS] European Telecommunications Standards Institute, "Policy Requirements for Certification Authorities Issuing Qualified Certificates," ETSI TS 101 456, Version 1.1.1, December 2000.

[ETS] European Telecommunications Standards Institute、「認定された証明書を発行する認証局のポリシー要件」、ETSI TS 101 456、バージョン1.1.1、2000年12月。

[GOC] Government of Canada PKI Policy Management Authority, "Digital Signature and Confidentiality Certificate Policies for the Government of Canada Public Key Infrastructure," v.3.02, April 1999.


[IDT] Identrus, LLC, "Identrus Identity Certificate Policy" IP-IPC Version 1.7, March 2001.

[IDT] Identrus、LLC、「Identrus Identity Certificate Policy」IP-IPCバージョン1.7、2001年3月。

[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 2000 edition, use 1997 edition.)

[ISO1] ISO / IEC 9594-8 / ITU-T勧告X.509、「情報技術-オープンシステム相互接続:ディレクトリ:認証フレームワーク」、1997年版。 (2000年版未定、1997年版使用)

[PEM1] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.

[PEM1]ケントS.、「インターネット電子メールのプライバシー強化:パートII:証明書ベースのキー管理」、RFC 1422、1993年2月。

[PKI1] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.

[PKI1] Housley、R.、Polk、W。Ford、W。およびD. Solo、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List(CRL)Profile」、RFC 3280、2002年4月。

[CPF] Chokhani, S. and W. Ford, "Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Statement Framework", RFC 2527, March 1999.

[CPF] Chokhani、S。およびW. Ford、「Internet X.509 Public Key Infrastructure、Certificate Policy and Certification Practices Statement Framework」、RFC 2527、1999年3月。

10. Notes
10. ノート

1. A paper copy of the ABA Digital Signature Guidelines can be purchased from the ABA. See for ordering details. The DSG may also be downloaded without charge from the ABA website at

1. ABAデジタル署名ガイドラインのコピーは、ABAから購入できます。注文の詳細については、http://www.abanet.comを参照してください。 DSGは、ABA Webサイト(から無料でダウンロードすることもできます。

2. A draft of the PKI Assessment Guidelines may be downloaded without charge from the ABA website at

2. PKI評価ガイドラインのドラフトは、ABA Webサイト(から無料でダウンロードできます。

3. The term "meaningful" means that the name form has commonly understood semantics to determine the identity of a person and/or organization. Directory names and RFC 822 names may be more or less meaningful.

3. 「意味のある」という用語は、名前の形式が、人や組織のアイデンティティを決定するための意味論を一般的に理解していることを意味します。ディレクトリ名とRFC 822名は多かれ少なかれ意味があります。

4. The subject may not need to prove to the CA that the subject has possession of the private key corresponding to the public key being registered if the CA generates the subject's key pair on the subject's behalf.

4. CAがサブジェクトの代わりにサブジェクトのキーペアを生成する場合、サブジェクトは、サブジェクトが登録されている公開キーに対応する秘密キーを所有していることをCAに証明する必要がない場合があります。

5. Examples of means to identify and authenticate individuals include biometric means (such as thumb print, ten finger print, and scan of the face, palm, or retina), a driver's license, a credit card, a company badge, and a government badge.

5. 個人を識別および認証する手段の例には、生体認証手段(親指の指紋、10の指紋、顔、手のひら、網膜のスキャンなど)、運転免許証、クレジットカード、会社のバッジ、政府のバッジなどがあります。

6. Certificate "modification" does not refer to making a change to an existing certificate, since this would prevent the verification of any digital signatures on the certificate and cause the certificate to be invalid. Rather, the concept of "modification" refers to a situation where the information referred to in the certificate has changed or should be changed, and the CA issues a new certificate containing the modified information. One example is a subscriber that changes his or her name, which would necessitate the issuance of a new certificate containing the new name.

6. 証明書の「変更」は、既存の証明書に変更を加えることを意味しません。これにより、証明書のデジタル署名の検証が妨げられ、証明書が無効になるためです。むしろ、「変更」の概念は、証明書で参照される情報が変更された、または変更されるべき状況を指し、CAは変更された情報を含む新しい証明書を発行します。 1つの例は、自分の名前を変更するサブスクライバーで、新しい名前を含む新しい証明書の発行が必要になります。

7. The n out of m rule allows a private key to be split in m parts. The m parts may be given to m different individuals. Any n parts out of the m parts may be used to fully reconstitute the private key, but having any n-1 parts provides one with no information about the private key.

7. mのうちnのルールでは、秘密鍵をmの部分に分割できます。 m個の部分は、m人の異なる個人に与えられてもよい。 m個の部分のうちn個の部分を使用して秘密鍵を完全に再構成できますが、n-1個の部分があると、秘密鍵に関する情報が提供されません。

8. A private key may be escrowed, backed up, or archived. Each of these functions has a different purpose. Thus, a private key may go through any subset of these functions depending on the requirements. The purpose of escrow is to allow a third party (such as an organization or government) to obtain the private key without the cooperation of the subscriber. The purpose of back up is to allow the subscriber to reconstitute the key in case of the destruction or corruption of the key for business continuity purposes. The purpose of archives is to provide for reuse of the private key in the future, e.g., use to decrypt a document.

8. 秘密鍵はエスクロー、バックアップ、またはアーカイブできます。これらの機能にはそれぞれ異なる目的があります。したがって、秘密鍵は、要件に応じてこれらの機能のサブセットを通過する場合があります。エスクローの目的は、第三者(組織や政府など)が加入者の協力なしに秘密鍵を取得できるようにすることです。バックアップの目的は、ビジネス継続性の目的でキーが破壊または破損した場合に、サブスクライバーがキーを再構成できるようにすることです。アーカイブの目的は、秘密鍵を将来再利用できるようにすることです。たとえば、ドキュメントの復号化に使用できます。

9. WebTrust refers to the "WebTrust Program for Certification Authorities," from the American Institute of Certified Public Accountants, Inc., and the Canadian Institute of Chartered Accountants.

9. WebTrustは、American Institute of Certified Public Accountants、Inc.およびCanadian Institute of Chartered Accountantsの「認証局向けWebTrustプログラム」を指します。

10. See <>.

10. <>を参照してください。

11. All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities.

11. 以下の項目のすべてまたは一部は、さまざまなタイプのエンティティ(CA、RA、エンドエンティティなど)によって異なる場合があります。

11. List of Acronyms
11. 頭字語のリスト

ABA - American Bar Association CA - Certification Authority CP - Certificate Policy CPS - Certification Practice Statement CRL - Certificate Revocation List DAM - Draft Amendment FIPS - Federal Information Processing Standard I&A - Identification and Authentication IEC - International Electrotechnical Commission IETF - Internet Engineering Task Force IP - Internet Protocol ISO - International Organization for Standardization ITU - International Telecommunications Union NIST - National Institute of Standards and Technology OID - Object Identifier PIN - Personal Identification Number PKI - Public Key Infrastructure PKIX - Public Key Infrastructure (X.509) (IETF Working Group) RA - Registration Authority RFC - Request For Comment URL - Uniform Resource Locator US - United States

ABA-アメリカ法曹協会CA-証明機関CP-証明書ポリシーCPS-証明書実務声明CRL-証明書失効リストDAM-改正草案FIPS-連邦情報処理標準I&A-識別および認証IEC-国際電気標準会議IETF-インターネット技術特別調査委員会IP -インターネットプロトコルISO-国際標準化機構ITU-国際電気通信連合NIST-国立標準技術研究所OID-オブジェクト識別子PIN-個人識別番号PKI-公開鍵インフラストラクチャPKIX-公開鍵インフラストラクチャ(X.509)(IETFワーキンググループ)RA-Registration Authority RFC-Request For Comment URL-Uniform Resource Locator US-アメリカ合衆国

12. Authors' Addresses
12. 著者のアドレス

Santosh Chokhani Orion Security Solutions, Inc. 3410 N. Buchanan Street Arlington, VA 22207

Santosh Chokhani Orion Security Solutions、Inc. 3410 N. Buchanan Street Arlington、VA 22207

Phone: (703) 237-4621 Fax: (703) 237-4920 EMail:


Warwick Ford VeriSign, Inc. 6 Ellery Square Cambridge, MA 02138

Warwick Ford VeriSign、Inc.6 Ellery Square Cambridge、MA 02138

Phone: (617) 642-0139 EMail:


Randy V. Sabett, J.D., CISSP Cooley Godward LLP One Freedom Square, Reston Town Center 11951 Freedom Drive Reston, VA 20190-5656

Randy V. Sabett、J.D.、CISSP Cooley Godward LLP One Freedom Square、Reston Town Center 11951 Freedom Drive Reston、VA 20190-5656

Phone: (703) 456-8137 Fax: (703) 456-8100 EMail:


Charles (Chas) R. Merrill McCarter & English, LLP Four Gateway Center 100 Mulberry Street Newark, New Jersey 07101-0652

Charles(Chas)R. Merrill McCarter&English、LLP Four Gateway Center 100 Mulberry Street Newark、New Jersey 07101-0652

Phone: (973) 622-4444 Fax: (973) 624-7070 EMail: Stephen S. Wu Infoliance, Inc. 800 West El Camino Real Suite 180 Mountain View, CA 94040

電話:(973)622-4444ファックス:(973)624-7070メール Stephen S.Wu Infoliance、Inc.800 West El Camino Real Suite 180 Mountain View、CA 94040

Phone: (650) 917-8045 Fax: (650) 618-1454 EMail:


13. 完全な著作権表示

Copyright (C) The Internet Society (2003). All Rights Reserved.

Copyright(C)The Internet Society(2003)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.






Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。