[要約] RFC 3647は、インターネットX.509公開鍵インフラストラクチャの証明書ポリシーと認証実践フレームワークに関する標準文書です。このRFCの目的は、証明書ポリシー(CP)と認証実践声明(CPS)の構造と内容に関するガイドラインを提供することにあります。これは、デジタル証明書の発行、管理、使用、および廃止に関わるポリシーと実践を明確に記述するために使用されます。関連するRFCにはRFC 5280（X.509証明書とCRLのプロファイル）などがあり、主にセキュリティ意識の高い通信や電子商取引で利用されます。
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
インターネットX.509公開キーインフラストラクチャの証明書ポリシーと認証実践フレームワーク
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）。全著作権所有。
Abstract
概要
This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document 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
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.
一般に、公開鍵証明書（以下「証明書」）は、エンティティ（個人、組織、アカウント、デバイス、サイトなど）が保持する公開鍵を、その使用に関連するエンティティを識別する一連の情報にバインドします。対応する秘密鍵。アイデンティティ証明書が関係するほとんどの場合、このエンティティは証明書の「サブジェクト」または「サブスクライバ」と呼ばれます。ただし、2つの例外には、デバイス（サブスクライバーは通常、デバイスを制御する個人または組織）と匿名証明書（個人または組織のIDが証明書自体から取得できない場合）が含まれます。他の種類の証明書は、公開鍵をエンティティのID以外の属性（役割、役職、信用力情報など）にバインドします。
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が厳密に情報または開示のドキュメントであることを意図する場合があります。
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]に記載されています。）
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.
このドキュメントの範囲は、CP（X.509で定義）またはCPS（DSGおよびPAGで定義）でカバーできるトピックの説明に限定されます。特に、このドキュメントでは、CPまたはCPSに含めることを検討する必要がある情報の種類について説明します。提示されているフレームワークは一般に、IDの保証を提供する目的でX.509バージョン3証明書形式の使用を想定していますが、資料がその証明書形式またはID証明書の使用に限定されることを意図していません。むしろ、このフレームワークは、他の証明書形式や、使用される可能性のあるID以外の保証を提供する証明書に適応可能であることを意図しています。
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.
スコープは、一般にセキュリティポリシー（組織のセキュリティポリシー、システムのセキュリティポリシー、データのラベル付けポリシーなど）の定義にまで及びません。さらに、このドキュメントでは特定のCPまたはCPSを定義していません。さらに、このドキュメントは、フレームワークを提示する際に、CPまたはCPSに特定の関連性があると見なすべきトピックを提示する柔軟なツールとして表示および使用する必要があります。CPまたはCPSを作成するための厳密な公式ではありません。
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.
このドキュメントは、読者がX.509、DSG、およびPAGで使用されるデジタル署名、証明書、および公開鍵基盤（PKI）の一般的な概念に精通していることを前提としています。
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).
アクティベーションデータ-暗号モジュールの操作に必要であり、保護する必要のあるキー以外のデータ値（PIN、パスフレーズ、または手動で保持するキー共有など）。
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.
CA証明書-別のCAによって発行された1つの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.
証明書ポリシー（CP）-特定のコミュニティや共通のセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示す名前付きのルールのセット。たとえば、特定のCPは、特定の価格範囲内で商品またはサービスを取引するための企業間取引に従事する当事者の認証に対する、あるタイプの証明書の適用可能性を示す場合があります。
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）-証明機関が証明書の発行、管理、失効、更新、またはキー更新で採用する実務の声明。
CPS Summary (or CPS Abstract) - A subset of the provisions of a complete CPS that is made public by a CA.
CPS要約（またはCPS要約）-CAによって公開される完全なCPSの規定のサブセット。
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
（1）個人または組織の特定の名前が、個人または組織の実際のアイデンティティに対応していることを確認し、
(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.
（2）その名前で何かを申請またはアクセスを求める個人または組織が、実際には、指名された個人または組織であることを確立する。身分証明書を求める人は、証明書申請者、PKI参加者内の信頼できる地位での雇用申請者、またはネットワークまたはソフトウェアアプリケーションへのアクセスを求める人（CAシステムへのアクセスを求めるCA管理者など）である可能性があります。
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).
発行証明機関（発行CA）-特定の証明書のコンテキストでは、発行CAは証明書を発行したCAです（サブジェクト証明機関も参照）。
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内でサブスクライバー、証明書利用者、CA、RA、証明書製造機関、リポジトリサービスプロバイダー、または同様のエンティティとして役割を果たす個人または組織。
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.
ポリシー修飾子-X.509証明書のCP識別子に付随する可能性のあるポリシー依存情報。このような情報には、該当するCPSのURLへのポインタまたは証明書利用者の合意を含めることができます。また、証明書またはその他の法的情報の使用条件を含むテキスト（またはテキストが表示される原因となる番号）が含まれる場合もあります。
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.
証明書利用者契約（RPA）-デジタル署名の検証や証明書のその他の使用に関して、通常、これらの当事者間の権利と責任を確立する、証明機関と証明書利用者の間の契約。
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.
一連の規定-このフレームワークで説明されているアプローチを採用したCPまたはCPSの表現に使用するための、一連の標準的なトピックにわたる実践および/またはポリシーステートメントのコレクション。
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).
サブジェクト証明機関（サブジェクトCA）-特定のCA証明書のコンテキストでは、サブジェクトCAは、公開鍵が証明書で証明されているCAです（発行証明機関も参照）。
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.
サブスクライバー契約-証明書の発行と管理に関する当事者の権利と責任を確立するCAとサブスクライバーの間の契約。
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.
検証-証明書申請者の識別プロセス。 「検証」は「識別」のサブセットであり、証明書申請者の識別を確立するコンテキストでの識別を指します。
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.
このセクションでは、CPおよびCPSの概念について説明し、サブスクライバー契約や証明書利用者契約などの他のPKIドキュメントとの関係について説明します。その他の関連する概念についても説明します。このセクションおよびその他のセクションで取り上げられている資料の一部は、X.509バージョン3で定義されている証明書ポリシー拡張に固有のものです。これらのセクションを除き、このフレームワークは、使用される可能性のある他の証明書形式に適応できるように設計されています。
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.
証明機関が証明書を発行するとき、特定の公開キーが特定のエンティティ（証明書のサブジェクトである証明書のサブジェクト）のIDや他の属性にバインドされているという証明書ユーザー（つまり、証明書利用者）にステートメントを提供します通常は加入者も）。ただし、証明書利用者がCAによるそのステートメントに依存する必要がある範囲は、証明書利用者または証明書利用者アプリケーションが証明書を使用する方法を制御または調整する証明書利用者またはエンティティによって評価される必要があります。異なる証明書は異なる慣行と手順に従って発行され、異なるアプリケーションや目的に適している場合があります。
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].
CPは通常、2つの主要なカテゴリに分類されます。まず、一部のCPは、「特定のコミュニティに対する証明書の適用可能性を示します」[ISO1]。これらのCPは、証明書の使用に関する要件とコミュニティのメンバーに関する要件を示しています。たとえば、CPは、資格のある証明書を発行するCAのETSIポリシー要件[ETS]など、地理的コミュニティのニーズに焦点を当てる場合があります。また、この種のCPは、金融サービス[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.
典型的なCPの2番目のカテゴリは、「共通のセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示します。」これらのCPは、証明書のアプリケーションまたは使用のセットを識別し、これらのアプリケーションまたは使用には特定のレベルのセキュリティが必要であることを伝えます。次に、これらのアプリケーションまたは使用に適したPKI要件を示します。このカテゴリー内のCPは、関連するCPに従って発行された証明書と比較して、証明書によって提供される特定の「保証レベル」にセット要件を適切に設定することがよくあります。これらの保証レベルは、証明書の「クラス」または「タイプ」に対応している場合があります。
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表示を採用しています。
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バッジを提示し、トークンを保護し、許可された目的でのみトークンを発行する条件として使用することを要求する加入者契約に署名する必要がある場合があります。証明書。
The following extension fields in an X.509 certificate are used to support CPs:
X.509証明書の次の拡張フィールドは、CPをサポートするために使用されます。
* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.
* 証明書ポリシー拡張。 *ポリシーマッピング拡張機能。および*ポリシー制約拡張。
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.
証明書パスを処理するとき、証明書利用者アプリケーションに受け入れられるCPは、パス内のすべての証明書、つまりCA証明書とエンドエンティティ証明書に存在する必要があります。
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.
たとえば、内国歳入庁は納税申告を保護する目的で納税者に証明書を発行する場合があります。内国歳入庁は、不正な証明書を発行者などに誤って発行するリスクを理解し、それに対処することができます。しかし、誰かが数百万ドルの価値のある企業秘密を暗号化するための基礎として、内国歳入庁の税務申告証明書を使用したと仮定します。メッセージを復号化します。内国歳入庁は、証明書ポリシー拡張の重要性を指摘して、加入者と証明書利用者が証明書を誤用したことを示すことにより、そのような状況での損害賠償請求から身を守ろうとする場合があります。クリティカルフラグの付いた証明書ポリシー拡張は、このような状況でCAへのリスクを軽減することを目的としています。
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.
ポリシーマッピング拡張機能は、CA証明書でのみ使用できます。このフィールドにより、証明機関は、自身のドメイン内の特定のポリシーを、対象の証明機関のドメイン内の他の特定のポリシーと同等と見なすことができることを示すことができます。
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のオブジェクト識別子を含むドメイン。
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.
[ポリシーの制約]フィールドのその他のオプション機能は、証明機関が証明パス内の後続の証明機関によるポリシーマッピングを無効にする機能です。ドメイン外で認証する場合は、ポリシーマッピングを無効にするのが賢明です。これは、推移的な信頼によるリスクの制御に役立ちます。たとえば、ドメインAはドメインBを信頼し、ドメインBはドメインCを信頼しますが、ドメインAはドメインCを強制的に信頼する必要はありません。
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).
（a）CPSポインター修飾子には、CAによって公開されたCPS、CPSサマリー、RPA、またはPDSへのポインターが含まれています。ポインターは、ユニフォームリソース識別子（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.
ポリシー修飾子を使用して、ジェネリックまたはパラメーター化されたCPの定義をサポートできます。基本CPが提供する場合、ポリシー修飾子タイプを定義して、証明書ごとに、一般的な定義を埋める追加の特定のポリシーの詳細を伝えることができます。
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.
「認証実務声明は、その信頼できるシステムの詳細と、その運用において、および証明書の発行をサポートするために採用する実務について、認証機関による宣言の形を取る場合があります。」この形式のCPSは最も一般的なタイプであり、長さと詳細レベルが異なる場合があります。
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.
一部のPKIは、実践に関する詳細で詳細な説明を作成する必要がない場合があります。たとえば、CA自体が依存パーティであり、そのサービスの性質と信頼性をすでに認識している場合があります。他の場合では、PKIは、セキュリティが確保されているアプリケーションが危険にさらされた場合にわずかなリスクしか引き起こさないという非常に低いレベルの保証しか提供しない証明書を提供する場合があります。これらの場合、PKIを確立する組織は、さまざまなPKI参加者の役割に応じて、サブスクライバー契約、証明書利用者契約、またはサブスクライバーと証明書利用者の条件を組み合わせた契約を作成またはCAに使用させることだけができます。そのようなPKIでは、その合意が、そのPKI内の1つ以上のCAによって使用される唯一の「慣行の陳述」として役立つ場合があります。その結果、その合意はCPSと見なされることもあり、そのような権利または字幕を付けることができます。
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.
CPSは自動的に契約を構成することはなく、契約のようにPKI参加者を自動的に拘束することもありません。ドキュメントがサブスクライバーまたは証明書利用者の合意とCPSの二重の目的を果たす場合、ドキュメントは契約であることが意図されており、サブスクライバーまたは証明書利用者の合意が通常そうであると見なされる範囲で拘束力のある契約を構成します。ただし、ほとんどのCPSは、このような2つの目的を果たしません。したがって、ほとんどの場合、個別の文書が当事者間の契約関係を作成し、その文書にCPSの一部またはすべてが参照により組み込まれている場合にのみ、CPSの条件が契約条件として拘束力を持ちます。さらに、特定のPKIが（CPS全体ではなく）CPSサマリーを採用している場合、CPSサマリーは、該当するすべての加入者または依拠当事者の合意に組み込むことができます。
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.
将来、裁判所または適用される法定または規制法は、証明書自体が、参照により組み込まれるように設計されたメカニズム（証明書ポリシー拡張やその修飾子など）まで、契約関係を作成できる文書であることを宣言する可能性があります）特定の文書にその使用条件が記載されていることを示します。ただし、当面の間、一部の加入者契約および依拠当事者契約は、参照によりCPSを組み込んでいる場合があり、そのため、その条件はかかる契約の当事者を拘束するものとします。
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.
単一のCPSを持つCAは、複数のCPをサポートする場合があります（さまざまなアプリケーションの目的で、および/またはさまざまな証明書利用者コミュニティによって使用されます）。また、同一でないCPSを持つ複数のCAが同じ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:
したがって、CPとCPSの主な違いは、次のように要約できます。
(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.
（a）PKIはCPを使用して、その内部の参加者が実行する必要があることを示す要件を確立します。単一のCAまたは組織は、CPSを使用して、CPの要件をどのように満たすか、またはその慣行と制御をどのように実装するかを開示できます。
(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).
（b）CPは、相互認証、一方的認証、またはその他の手段を通じて相互運用を促進します。したがって、複数のCAを対象としています。対照的に、CPSは単一のCAまたは組織の声明です。その目的は相互運用を促進することではありません（そうすることは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.
（c）CPSは一般にCPよりも詳細であり、証明書を発行する1つ以上のCPで指定された要件をCAがどのように満たすかを指定します。
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で説明します。
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.
セクション3.5で述べたように、サブスクライバー契約、証明書利用者契約、またはサブスクライバーと証明書利用者の条件を組み合わせた契約もCPSとして機能する場合があります。ただし、他のPKIでは、加入者または証明書利用者の合意に、参照によりCPまたはCPSの条件の一部またはすべてが組み込まれる場合があります。さらに、他のPKIは、CPまたはCPSから加入者に適用可能な条件を抽出し、参照によりCPまたはCPSを組み込むことなく、そのような条件を自己完結型の加入者合意に入れる場合があります。彼らは、同じ方法を使用して、CPおよび/またはCPSから証明書利用者の条件を抽出し、そのような条件を自己完結型の証明書利用者契約に配置できます。このような自己完結型の合意を作成することには、消費者がレビューしやすいドキュメントを作成できるという利点があります。場合によっては、加入者または依拠当事者は、適用法の下では「消費者」であると見なされ、特定の法的または規制上の保護の対象となります。民法の国の法制度の下では、参照によってCPまたはCPSを組み込むことは、組み込まれたCPまたはCPSの条件に消費者を拘束するのに効果的でない場合があります。
CPs and CPSs may be incorporated by reference in other documents, including:
CPおよびCPSは、以下を含む他の文書に参照により組み込まれる場合があります。
* 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.
PDSは、CPSサマリーと同様の機能を果たします。これは、PKIまたはCAに関する重要な詳細のサブセットのみを含む比較的短いドキュメントです。ただし、CPSの要約とは異なる場合があります。その目的は、単にCPSの要約された形式ではなく、PKIの全体的な性質に関する情報の要約として機能することです。
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.
さらに、その目的は、未公開のCPSに含まれるセキュリティ機密情報を保護するのではなく、PKIに関する情報を抽出することですが、PDSもその機能を果たすことができます。
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.
執筆者がCPまたはCPSを参照したり、参照または契約またはPDSに組み込んだりするのと同じように、要件を確立したり開示したりするときに、CPまたはCPSが他のドキュメントを参照する場合があります。たとえば、CPは、標準の証明書プロファイルを記載した外部ドキュメントを参照することにより、証明書のコンテンツの要件を設定できます。外部文書を参照することにより、CPまたはCPSは、CPまたはCPS内の他の文書から長い規定を再印刷することなく、詳細な要件を課したり、詳細な開示を行うことができます。さらに、CPまたはCPSでドキュメントを参照することは、（CPSサマリーの公開に加えて、またはその代わりに）公開情報とセキュリティの機密情報の間で開示を分割するもう1つの便利な方法です。たとえば、PKIは、CPまたはCPSを公開し、CAの高セキュリティゾーンのサイト構築パラメーターを機密情報として保持する場合があります。その場合、CPまたはCPSは、詳細なサイト構築パラメーターを含む外部のマニュアルまたはドキュメントを参照できます。
Documents that a PKI may wish to refer to in a CP or CPS include:
PKIがCPまたはCPSで参照することを希望する可能性のあるドキュメントには、次のものがあります。
* 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]を参照
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.
一連の規定は、以下のセクション5に記載されているトピックをカバーすることにより、このフレームワークで説明されているアプローチを採用するCPまたはCPSの表現に使用するための一連の標準トピックにまたがる実践および/またはポリシーステートメントのコレクションです。これらについては、以下のセクション4でも詳しく説明します。
A CP can be expressed as a single set of provisions.
CPは、規定の単一セットとして表現できます。
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:
CPSは、各コンポーネントが1つ以上の証明書ポリシーの要件に対処する単一のプロビジョニングセットとして表現することも、組織化された一連のプロビジョニングの集まりとして表現することもできます。たとえば、CPSは次の組み合わせで表すことができます。
(a) a list of certificate policies supported by the CPS;
（a）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
（b）（a）の各CPについて、そのポリシーで規定されていないか、またはCAの裁量（CPS内）に明示的に委ねられていない詳細を記入することにより、そのCPに対応するステートメントを含む一連の規定。そのようなステートメントは、この特定のCPSが特定のCPの要件をどのように実装するかを述べるのに役立ちます。または
(c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of CP.
（c）CPに関係なく、CAでの認証慣行に関する記述を含む一連の規定。
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:
このフレームワークは、次のように、9つの主要コンポーネントの観点から、一連の規定の内容の概要を示しています。
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.
この単純なフレームワークは、加入者契約および依拠当事者契約以外の契約にも役立ちます。たとえば、特定のサービスをRAまたは認証製造局（CMA）にアウトソーシングしたいCAは、このフレームワークをチェックリストとして使用して、登録局契約またはアウトソーシング契約を作成すると便利な場合があります。同様に、2つのCAは、相互認証、一方的な認証、またはその他の相互運用性の合意を起草する目的で、この単純なフレームワークを使用することを望む場合があります。
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で説明されているサブコンポーネントの下にサブコンポーネントのレベルを追加できます。
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.
このセクションでは、セクション3.7で紹介した単純な規定のフレームワークの内容を拡張します。したがって、このセクションで識別されるトピックは、詳細なCPまたは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.
多くのトピックが識別されていますが、CPまたはCPSがそのようなトピックごとに具体的なステートメントを含める必要はありません。むしろ、特定のCPまたはCPSは、特定のCPまたはCPSが要件を課さない、または開示しないコンポーネント、サブコンポーネント、または要素について「規定なし」と述べる場合があります。この意味で、トピックのリストは、CPまたはCPSのライターが検討するトピックのチェックリストと見なすことができます。
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.
「規定がない」場合でも、すべてのコンポーネントとサブコンポーネントをCPまたはCPSに含めることをお勧めします。これは、そのトピックに関する規定を含めるか除外するかを意識的に決定したことを読者に示します。このドラフティングスタイルは、トピックの不注意による脱落を防ぎながら、たとえばポリシーマッピングを決定するときに、さまざまな証明書ポリシーまたはCPSの比較を容易にします。
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.
CPでは、特定のコンポーネント、サブコンポーネント、要素を未指定のままにして、必要な情報をポリシー修飾子またはポリシー修飾子が指すドキュメントに示すことを規定することができます。このようなCPは、パラメーター化された定義と見なすことができます。一連の規定では、必要なポリシー修飾子タイプを参照または定義し、適用可能なデフォルト値を指定する必要があります。
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.
このコンポーネントは、一連の条項を識別および導入し、ドキュメント（CPまたはCPSのいずれかが記述されている）が対象としているエンティティおよびアプリケーションの種類を示します。
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.
このサブコンポーネントは、作成されるドキュメントの一般的な概要を提供します。このサブコンポーネントは、CPまたはCPSが適用されるPKIの概要を提供するためにも使用できます。たとえば、PKI内の証明書によって提供されるさまざまなレベルの保証を設定できます。特定のPKIの複雑さと範囲によっては、PKIの図による表現が役立つ場合があります。
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.
このサブコンポーネントは、ASN.1オブジェクト識別子を含む、ドキュメントに適用可能な名前またはその他の識別子を提供します。このようなドキュメント名の例としては、米国連邦政府によるセキュアメールに関するポリシーがあります。
This subcomponent describes the identity or types of entities that fill the roles of participants within a PKI, namely:
このサブコンポーネントは、PKI内の参加者の役割を満たすエンティティのIDまたはタイプを説明します。
* 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関連サービスを提供するその他のエンティティなど、その他の参加者。
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.
さまざまなレベルの保証を記述するCPまたはCPSの場合、このサブコンポーネントは、さまざまなレベルの保証に適切または不適切なアプリケーションまたはアプリケーションのタイプを記述することができます。
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.
このサブコンポーネントには、このCPまたはCPSの起草、登録、維持、および更新を担当する組織の名前とメールアドレスが含まれます。また、連絡先の名前、電子メールアドレス、電話番号、およびFAX番号も含まれます。実際の人に名前を付ける代わりに、ドキュメントに役職や役割、電子メールのエイリアス、その他の一般的な連絡先情報を付けることができます。場合によっては、組織は、連絡先担当者が単独で、または他の人と組み合わせて、ドキュメントに関する質問に回答できると述べている場合があります。
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.
さらに、正式または非公式のポリシー機関が、CAがPKI内での運用またはPKIとの相互運用を許可されるかどうかを決定する責任がある場合、CAのCPSがポリシー機関のCPに適していることを承認することを望む場合があります。その場合、このサブコンポーネントには、名前またはタイトル、電子メールアドレス（またはエイリアス）、電話番号、ファックス番号、およびそのような決定を行うエンティティのその他の一般的な情報を含めることができます。最後に、この場合、このサブコンポーネントには、この決定が行われる手順も含まれます。
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.
このサブコンポーネントには、ドキュメント内で使用される定義された用語の定義のリスト、およびドキュメント内の頭字語とその意味のリストが含まれています。
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などの公開された情報オブジェクトのアクセス制御。
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.
このコンポーネントは、証明書の発行前にCAまたはRAに対してエンドユーザー証明書申請者のIDやその他の属性を認証するために使用される手順を記述します。さらに、このコンポーネントは、IDを認証するための手順と、CA、RA、またはPKIで運用または相互運用する他のエンティティになることを求めるエンティティの申請者を受け入れるための基準を示します。また、鍵の再発行または失効を要求する当事者がどのように認証されるかについても説明します。このコンポーネントは、特定の名前での商標権の認識を含む、命名慣行にも対処します。
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.
* 商標の認識、認証、および役割。
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):
このサブコンポーネントには、各サブジェクトタイプ（CA、RA、サブスクライバー、またはその他の参加者）の初期登録の識別および認証手順に関する次の要素が含まれています。
* 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がそのような操作または相互運用に適しているかどうかを判断する基準が含まれます。そのような相互運用には、相互認証、一方的な認証、または他の形式の相互運用が含まれる場合があります。
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):
このサブコンポーネントは、各サブジェクトタイプ（CA、RA、サブスクライバー、および他の参加者）の鍵の再生成の識別および認証手順に関する次の要素を扱います。
* 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検証と同じプロセスの使用です。
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.
このサブコンポーネントは、各サブジェクトタイプ（CA、RA、サブスクライバー、およびその他の参加者）による失効要求の識別および認証手順を説明します。例としては、対応する公開鍵を取り消す必要がある秘密鍵でデジタル署名された失効リクエストや、RAによるデジタル署名リクエストなどがあります。
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.
このコンポーネントは、証明書のライフサイクルに関して、CA、サブジェクトCA、RA、サブスクライバー、または他の参加者の発行に課される要件を指定するために使用されます。
Within each subcomponent, separate consideration may need to be given to subject CAs, RAs, subscribers, and other participants.
各サブコンポーネント内で、サブジェクトCA、RA、サブスクライバー、およびその他の参加者に個別の考慮が必要になる場合があります。
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は、証明書アプリケーションを受け取るために登録プロセスを確立する責任があります。同様に、証明書申請者は、証明書申請に関する正確な情報を提供する責任があります。
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.
このサブコンポーネントは、証明書アプリケーションの処理手順を説明するために使用されます。たとえば、発行元のCAおよびRAは、証明書アプリケーションを検証するための識別および認証手順を実行する場合があります。このような手順を実行すると、CAまたはRAは、おそらく特定の基準の適用時に、証明書の適用を承認または拒否します。最後に、このサブコンポーネントは、CAおよび/またはRAが証明書アプリケーションに作用して処理する必要がある時間制限を設定します。
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サイトから証明書をダウンロードできるようにする情報を電子メールで送信する手順です。
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に送信します。
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を参照）に記載されている必要または許可されたメカニズムのいずれかを使用して証明書のステータスをチェックし、適用される証明書利用者の条件に同意する責任を負う証明書に依存しています。
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による他のエンティティへの証明書発行の通知。
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による他のエンティティへの証明書発行の通知。
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:
このサブコンポーネントは、サブスクライバーの公開鍵以外の証明書の情報の変更に起因する新しい証明書（6）の発行に関連する次の要素を説明するために使用されます。
* 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による他のエンティティへの証明書発行の通知。
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.
* 停止が続く期間。
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.
* そのようなサービスのオプション機能。
This subcomponent addresses procedures used by the subscriber to end subscription to the CA services, including:
このサブコンポーネントは、以下を含むCAサービスへのサブスクリプションを終了するためにサブスクライバーによって使用される手順を扱います。
* 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).
* サブスクリプションの終了時の証明書の失効（サブスクリプションの終了が証明書の期限切れによるものか、サービスの終了によるものかによって異なります）。
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):
このサブコンポーネントには次の要素が含まれ、エスクロー、および/または秘密鍵エスクローサービスが（CAまたはその他の信頼できるサードパーティを通じて）利用可能な場合の秘密鍵の回復に関連するポリシーと実践を識別します。
* 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.
* セッションキーのカプセル化と回復のポリシーと実践を含むドキュメントの識別、またはそのようなポリシーと実践のリスト。
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.
このコンポーネントは、発行CAがキー生成、サブジェクト認証、証明書の発行、証明書の取り消し、監査、およびアーカイブの機能を安全に実行するために使用する非技術的なセキュリティ制御（つまり、物理的、手続き的、および人的制御）を記述します。
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.
このコンポーネントは、リポジトリ、サブジェクトCA、RA、サブスクライバー、およびその他の参加者に対する非技術的なセキュリティコントロールを定義するためにも使用できます。対象のCA、RA、サブスクライバー、およびその他の参加者に対する非技術的なセキュリティ管理は、同じ、類似、または非常に異なる可能性があります。
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.
セキュリティが不足していると、CAの操作が危険にさらされ、誤った情報を含む証明書やCRLが作成されたり、CAの秘密鍵が危険にさらされたりするため、これらの非技術的なセキュリティコントロールは証明書を信頼するうえで重要です。
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.
各サブコンポーネント内では、一般に、各エンティティタイプ、つまり発行元CA、リポジトリ、サブジェクトCA、RA、サブスクライバー、およびその他の参加者に個別の考慮事項を与える必要があります。
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.
* オフサイトバックアップ。
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.
このコンポーネントには、同じ個人が実行できない役割に関する職務の分離も含まれます。
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.
* 初期トレーニング、再トレーニング、その他の際に担当者に提供されるドキュメント。
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.
* たとえば、システムのセキュリティを侵害する潜在的な試みを識別するツールを介して監査データが実行される脆弱性評価。
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つのコピーが比較されるという要件など、アーカイブ情報を取得および検証する手順。
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.
このサブコンポーネントは、CAによる鍵の再生成に続いて、CAのユーザーに新しい公開鍵を提供する手順を説明します。これらの手順は、現在のキーを提供する手順と同じです。また、新しいキーは、古いキーを使用して署名された証明書で認証される場合があります。
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.
* 自然災害またはその他の災害後の事業継続性を確保するための企業の能力。このような機能には、操作を回復できるリモートホットサイトの可用性が含まれる場合があります。また、自然災害やその他の災害が発生した後、元のサイトまたはリモートサイトで安全な環境が再確立される前に、施設を保護するための手順を含めることもできます。たとえば、地震で被害を受けたサイトからの機密性の高い物質の盗難を防ぐための手順。
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.
このサブコンポーネントは、CAおよびRAの保管記録のIDを含む、CAまたはRAの終了および終了通知の手順に関する要件について説明します。
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.
このコンポーネントは、発行CAがその暗号キーとアクティベーションデータ（PIN、パスワード、または手動で保持するキー共有など）を保護するために講じたセキュリティ対策を定義するために使用されます。このコンポーネントは、リポジトリ、サブジェクトCA、サブスクライバー、およびその他の参加者に制約を課して、秘密鍵、秘密鍵のアクティベーションデータ、および重要なセキュリティパラメーターを保護するためにも使用できます。安全な鍵管理は、すべての秘密鍵と秘密鍵、およびアクティベーションデータが保護され、許可された担当者のみが使用できるようにするために重要です。
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.
このコンポーネントは、キーの生成、ユーザー認証、証明書の登録、証明書の失効、監査、およびアーカイブの機能を安全に実行するために発行CAが使用する他の技術的なセキュリティコントロールについても説明します。技術的管理には、ライフサイクルセキュリティ管理（ソフトウェア開発環境のセキュリティ、信頼できるソフトウェア開発方法論を含む）と運用セキュリティ管理が含まれます。
This component can also be used to define other technical security controls on repositories, subject CAs, RAs, subscribers, and other participants.
このコンポーネントは、リポジトリ、サブジェクトCA、RA、サブスクライバー、および他の参加者に対する他の技術的なセキュリティコントロールを定義するためにも使用できます。
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:
鍵ペアの生成とインストールは、発行CA、リポジトリ、サブジェクトCA、RA、およびサブスクライバーについて検討する必要があります。これらのタイプのエンティティそれぞれについて、次の質問に回答する必要がある可能性があります。
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:
秘密鍵保護と暗号化モジュールの要件は、発行元CA、リポジトリ、サブジェクトCA、RA、およびサブスクライバーで考慮する必要があります。これらのタイプのエンティティそれぞれについて、次の質問に回答する必要がある可能性があります。
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などの規格への準拠、関連するレベル、およびレーティングを参照することで表現できます。
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:
発行元のCA、リポジトリ、サブジェクトCA、RA、サブスクライバー、およびその他の参加者について、キー管理の他の側面を考慮する必要があります。これらのタイプのエンティティそれぞれについて、次の質問に回答する必要がある可能性があります。
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. 加入者に発行された証明書の運用期間はどれくらいですか。サブスクライバーのキーペアの使用期間またはアクティブな有効期間はどのくらいですか？
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.
アクティベーションデータとは、PIN、パスフレーズ、またはキー分割スキームで使用される秘密キーの一部など、秘密キーまたは秘密キーを含む暗号化モジュールを操作するために必要な秘密キー全体以外のデータ値のことです。アクティベーションデータを保護することで、秘密キーの不正使用が防止され、発行元のCA、サブジェクトCA、RA、およびサブスクライバーについて考慮する必要がある場合があります。このような考慮事項は、生成からアーカイブおよび破壊までのアクティベーションデータのライフサイクル全体に対処する必要がある可能性があります。エンティティタイプ（発行CA、リポジトリ、サブジェクトCA、RA、サブスクライバー、およびその他の参加者）ごとに、4.6.1から4.6.3にリストされているすべての質問は、アクティブ化データに関してではなく、アクティベーションデータに関して回答する必要がある可能性があります。キーに関して。
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このサブコンポーネントは、製品評価分析、テスト、プロファイリング、製品認証、および/または行われる製品認定関連のアクティビティの要件にも対応できます。
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）などに基づくライフサイクルセキュリティ評価にも対応できます。 。
This subcomponent addresses network security related controls, including firewalls.
このサブコンポーネントは、ファイアウォールを含むネットワークセキュリティ関連の制御に対処します。
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.
このサブコンポーネントは、さまざまなデータでのタイムスタンプの使用に関する要件または慣行に対処します。また、タイムスタンプアプリケーションが信頼できるタイムソースを使用する必要があるかどうかについても説明します。
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.
このコンポーネントは、証明書の形式を指定するために使用されます。CRLやOCSPが使用されている場合は、CRLやOCSP形式を指定します。これには、使用されるプロファイル、バージョン、および拡張機能に関する情報が含まれます。
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拡張のセマンティクスの処理。
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エントリ拡張とその重要度。
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拡張とその重要度。
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.
* 評価の結果（評価対象のエンティティ、他の参加者、一般大衆など）を見る権利、誰が提供するか（評価者または評価対象のエンティティなど）、およびそれらの伝達方法。
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.
このコンポーネントは、一般的なビジネスおよび法的事項をカバーします。フレームワークのセクション9.1および9.2は、さまざまなサービスに課される料金のビジネス上の問題と、進行中の操作のためのリソースを維持し、彼らに対して主張された要求に応じて判決または和解を支払うための参加者の財政的責任について説明します。残りのセクションは、一般的に法的トピックに関係しています。
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.
フレームワークのセクション9.3以降、トピックの順序は、一般的なソフトウェアライセンス契約またはその他の技術契約のトピックの順序と同じまたは類似しています。その結果、このフレームワークは、CPとCPSだけでなく、関連するPKI関連の契約、特に加入者契約、および依拠当事者の契約にも使用できます。この順序付けは、弁護士がこのフレームワークに準拠しているCP、CPS、およびその他のドキュメントを確認するのに役立つことを目的としています。
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.
このコンポーネント内の多くの法的サブコンポーネントに関して、CPまたはCPSの起草者は、加入者または信頼者に直接適用される契約条件をドキュメントに含めることを選択できます。たとえば、CPまたはCPSは、加入者および信頼者に適用される責任の制限を規定する場合があります。契約条件を含めることは、CPまたはCPS自体が契約または契約の一部である場合に適切である可能性があります。
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を作成するときに、責任を制限するための特定の規定を適用する関連する加入者または信頼者の合意を使用することを説明する場合があります。
This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs, such as:
このサブコンポーネントには、CA、リポジトリ、またはRAから請求される料金に関する次のような適用可能な規定が含まれています。
* 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.
* 返金について。
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:
このサブコンポーネントには、認証サービスを提供するCA、RA、およびその他の参加者が利用可能なリソースに関連する要件または開示が含まれており、運用PKIの責任のパフォーマンスをサポートし、判決または和解を支払う義務がある場合に支払能力を維持し、損害を支払うそのような操作から生じる請求に関連して。そのような規定には以下が含まれます。
* 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の使用に関連して他の参加者に第一者保険または保証の保護を提供するプログラムを持っているという声明。
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.
* 機密情報を受け取ってそれを侵害から保護し、それを使用したり第三者に開示したりしない参加者の責任。
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:
このサブコンポーネントは、参加者、特にCA、RA、およびリポジトリが、証明書の申請者、加入者、および他の参加者の個人を特定できる個人情報を提供するために必要となる可能性がある保護に関連しています。具体的には、このサブコンポーネントは、適用される法律に関連する範囲で、以下に対処します。
* 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.
* 参加者が私的または政府の手続き、または法的手続きにおける司法、行政手続きに従って個人情報を開示する権利または要求される状況。
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.
このサブコンポーネントは、特定の参加者がCP、CPS、証明書、名前、および鍵で所有または主張できる、またはライセンスの対象となる、著作権、特許、商標、企業秘密などの知的財産権に対処します参加者。
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.
このサブコンポーネントには、CPまたはCPSに従って作成されているさまざまなエンティティの表明および保証を含めることができます。たとえば、契約として機能するCPSには、証明書に含まれる情報が正確であるというCAの保証が含まれる場合があります。あるいは、CPSには、証明書に含まれる情報が、十分な注意を払って特定のID認証手順を実行した後、CAが知る限りにおいて真実であることを保証する、それほど広範囲ではない保証が含まれる場合があります。このサブコンポーネントには、サブスクライバーまたは証明書利用者の合意など、特定の合意に表明および保証が表示されるという要件も含めることができます。たとえば、CPには、すべてのCAがサブスクライバー契約を利用するという要件が含まれている可能性があり、サブスクライバー契約には、証明書の情報が正確であるというCAによる保証が含まれている必要があります。表明および保証を行う可能性のある参加者には、CA、RA、サブスクライバー、証明書利用者、およびその他の参加者が含まれます。
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は、免責事項が、加入者または信頼者の合意などの関連する合意に表示されるという要件を含む場合があります。
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.
このサブコンポーネントには、CPまたはCPSにおける責任の制限、またはCPまたはCPSに関連付けられた契約（加入者または証明書利用者の契約など）に現れるまたは現れる必要のある制限を含めることができます。これらの制限は、2つのカテゴリの1つに分類される可能性があります。回復可能な損害の要素に関する制限と、損害賠償額とも呼ばれる、回復可能な損害の量に関する制限です。多くの場合、契約には、偶発的および結果的損害、場合によっては懲罰的損害などの損害の要素の回復を妨げる条項が含まれています。多くの場合、契約には、一方または他方の回復の可能性を一定の金額またはベンチマークに対応する金額（ベンダーが契約に基づいて支払った金額など）に制限する条項が含まれています。
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が許可するもの。
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:
このサブコンポーネントには、CPまたはCPSが有効である期間と、ドキュメント、ドキュメントの一部、または特定の参加者へのその適用性を終了できる状況を含めることができます。さらに、または代わりに、CPまたはCPSには、特定の期間および終了条項が加入者または依拠当事者の合意などの合意に現れるという要件が含まれる場合があります。特に、そのような用語には次のものが含まれます。
* 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.
* ドキュメントの終了の結果。たとえば、契約の特定の規定は、その終了後も存続し、引き続き効力を持つ可能性があります。例には、知的財産権の承認および機密保持規定が含まれます。また、解約により、機密情報を開示した当事者に機密情報を返却する責任が生じます。
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.
このサブコンポーネントでは、1人の参加者が別の参加者と1対1で通信できるようにする、または通信する必要がある方法について説明します。たとえば、RAはCAとの契約を終了したいことをCAに通知したい場合があります。このサブコンポーネントは、パブリケーションおよびリポジトリの機能とは異なります。これは、このサブコンポーネントで説明されている個々の通信とは異なり、リポジトリへのパブリケーションおよびポストは、すべての依存パーティなどの受信者の幅広い対象者への通信を目的としているためです。このサブコンポーネントは、通信のメカニズムを確立し、デジタル署名された電子メール通知を指定されたアドレスに送信し、その後、署名された電子メールの受信確認を送信するなど、そのような通信をルーティングするために使用する連絡先情報を示します。
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）の変更が必要になる状況。
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.
このサブコンポーネントは、CP、CPS、および/または合意から生じる紛争を解決するために利用される手順について説明します。このような手順の例には、特定のフォーラムで、または代替の紛争解決メカニズムによって紛争を解決するという要件が含まれます。
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.
このサブコンポーネントは、特定の法域の法律が対象のCPまたはCPSまたは契約の解釈および施行を規定するという声明を述べています。
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は、そのような要件を課すと主張するか、そのような規定が他の契約に記載されることを要求する場合があります。
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:
このサブコンポーネントには、契約に「定型条項」と呼ばれることもあるその他の条項が含まれています。このサブコンポーネントでカバーされる条項は、CP、CPS、または契約に含まれる場合があり、以下が含まれます。
* 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人以上の当事者が履行した契約の履行を弁解するために使用されます。通常、免除されたパフォーマンスの期間は、イベントによって引き起こされた遅延の期間と釣り合っています。この条項は、特定の状況および条件の下での契約の終了を規定する場合もあります。 「不可抗力」を構成すると見なされるイベントには、いわゆる「神の行為」、戦争、テロ、ストライキ、自然災害、サプライヤーやベンダーの実行の失敗、またはインターネットやその他のインフラストラクチャの失敗が含まれる場合があります。不可抗力条項は、フレームワークの他の部分および該当するサービスレベル契約と整合するように作成する必要があります。たとえば、ビジネス継続性と災害復旧の責任と能力により、停電時にバックアップ電力を維持する義務など、当事者の合理的な管理の範囲内でいくつかのイベントが発生する可能性があります。
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の作成者は、このサブコンポーネント内に、別のサブコンポーネントでカバーされていないプロビジョニングを配置できます。
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.
X.509によると、証明書ポリシー（CP）は、「特定のコミュニティや共通のセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示す名前付きのルールのセット」です。証明書とそのバインディングが特定のアプリケーションに十分信頼できるか、そうでなければ適切であるかどうかを決定するのを助けるために、証明書利用者はCPを使用できます。
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).
証明書に組み込まれたバインディングを信頼パーティが信頼できる度合いは、いくつかの要因に依存します。これらの要因には、認証局（CA）がサブジェクトを認証する際の慣行が含まれます。サブスクライバーの責任の範囲（たとえば、秘密キーの保護）を含むCAの運用ポリシー、手順、および技術的なセキュリティ管理、およびCAの規定された責任と責任の条件（たとえば、保証、免責事項）保証、および責任の制限）。
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.
このドキュメントは、認証局、登録局、リポジトリ、サブスクライバー、および証明書利用者の暗号化モジュールの技術的、手続き的、人的、および物理的なセキュリティの側面に対処するためのフレームワークを提供し、証明書の生成、公開、更新、再キーを保証します、使用、および取り消しは安全な方法で行われます。具体的には、セクション4.3識別と認証（I＆A）。セクション4.4証明書のライフサイクル運用要件。セクション4.5施設管理、および運用管理。セクション4.6技術的なセキュリティ管理;セクション4.7証明書CRL、およびOCSPプロファイル。セクション4.8コンプライアンス監査およびその他の評価は、CA、RA、リポジトリ、サブスクライバーシステム、証明書利用者システムなどのPKIエンティティの安全な運用を保証することを目的としています。
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).
このセクションには、CPまたはCPSライターが使用するためのチェックリストまたは（さらに開発を進めて）標準テンプレートとして機能することを目的とした、一連の規定の推奨される概要が含まれています。このような共通の概要により、次のことが容易になります。
(b) Comparison of a CPS with a CP to ensure that the CPS faithfully implements the policy.
（b）CPSをCPと比較して、CPSがポリシーを忠実に実装していることを確認します。
(c) Comparison of two CPSs.
（c）2つのCPSの比較。
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.
RFCに準拠するために、準拠しているCPまたはCPSの起草者は、この概要に従うことを強くお勧めします。代替のアウトラインの使用は推奨されませんが、偏差の適切な正当化が提供され、このアウトラインで説明されている各項目が提供されている場所を簡単に識別できるようにマッピングテーブルが提供されている場合は受け入れられます。
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その他の規定
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.
法的な観点から見ると、新しいセクション9は、ソフトウェアライセンスやその他の技術契約と同様の順序でトピックをフレームワークに配置するため、技術弁護士にとって馴染み深いため、有用です。さらに、全体としてのフレームワークは、加入者、証明書利用者、またはその他のPKI関連の合意のフレームワークとしても機能します。この変更は、CPおよびCPS文書の法的レビューと入力をより効率的にすることを目的としています。セクション9では、個人情報のプライバシー、責任条件、文書の有効期間など、新しい法的トピックも追加されます。
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
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
------------------------------------------------------
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
throughout
portions of the
framework that
apply to CAs
------------------------------------------------------
2.1.2 RA Obligations Integrated
throughout
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,
9.9
------------------------------------------------------
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,
9.16.1,9.16.3
------------------------------------------------------
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,
4.8.7
------------------------------------------------------
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
Revocation/Suspension
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.7
------------------------------------------------------
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.9.3
------------------------------------------------------
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.10
------------------------------------------------------
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.10
------------------------------------------------------
4.4.13 Other Forms
of Revocation
Advertisements 4.9.11, 4.10
------------------------------------------------------
4.4.14 Checking Requirements
for Other Forms of
Revocation
Advertisements 4.9.6, 4.9.11,
4.10
------------------------------------------------------
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.9.11
------------------------------------------------------
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
correspond.
NEW RFC SECTION ORIGINAL RFC 2527
SECTION
------------------------------------------------------
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,
2.1.4
------------------------------------------------------
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.3
------------------------------------------------------
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.8.3
------------------------------------------------------
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.4.13
------------------------------------------------------
4.10.2 Service Availability 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
4.10.3 Operational Features 4.4.9, 4.4.11,
4.4.13
------------------------------------------------------
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.
------------------------------------------------------
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,
2.8.3-2.8.7
------------------------------------------------------
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,
2.8.3
------------------------------------------------------
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
------------------------------------------------------
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.
この改訂作業の大部分は、マイケル・バウムからの絶え間ないインスピレーションの結果です。マイケルパワー、マイクジェンキンス、アリススタージョンもいくつかの貢献をしました。
[ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce, 1996.
[ABA1]アメリカ法曹協会、デジタル署名ガイドライン：証明機関と安全な電子商取引のための法的インフラストラクチャ、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 http://www.verisign.com/repository/pubs/index.html.
[BAU1]マイケル。 S. Baum、連邦認証局の責任とポリシー、NIST-GCR-94-654、1994年6月、http：//www.verisign.com/repository/pubs/index.htmlから入手可能。
[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.
[GOC]カナダ政府PKIポリシー管理局、「カナダ政府の公開鍵インフラストラクチャのデジタル署名および機密証明書ポリシー」v.3.02、1999年4月。
[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月。
1. A paper copy of the ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details. The DSG may also be downloaded without charge from the ABA website at http://www.abanet.org/scitech/ec/isc/digital_signature.html.
1. ABAデジタル署名ガイドラインのコピーは、ABAから購入できます。注文の詳細については、http：//www.abanet.comを参照してください。 DSGは、ABA Webサイト（http://www.abanet.org/scitech/ec/isc/digital_signature.html）から無料でダウンロードすることもできます。
2. A draft of the PKI Assessment Guidelines may be downloaded without charge from the ABA website at http://www.abanet.org/scitech/ec/isc/pag/pag.html.
2. PKI評価ガイドラインのドラフトは、ABA Webサイト（http://www.abanet.org/scitech/ec/isc/pag/pag.html）から無料でダウンロードできます。
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個の部分のうち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 <http://www.aicpa.org>.
10. <http://www.aicpa.org>を参照してください。
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、エンドエンティティなど）によって異なる場合があります。
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-アメリカ合衆国
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: chokhani@orionsec.com
電話：（703）237-4621ファックス：（703）237-4920メール：chokhani@orionsec.com
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: wford@verisign.com
電話：（617）642-0139メール：wford@verisign.com
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: rsabett@cooley.com
電話：（703）456-8137ファックス：（703）456-8100メール：rsabett@cooley.com
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: cmerrill@mccarter.com Stephen S. Wu Infoliance, Inc. 800 West El Camino Real Suite 180 Mountain View, CA 94040
電話：（973）622-4444ファックス：（973）624-7070メール：cmerrill@mccarter.com 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: swu@infoliance.com
電話：（650）917-8045ファックス：（650）618-1454メール：swu@infoliance.com
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.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその継承者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。