[要約] RFC 2527は、インターネットX.509公開鍵基盤証明書ポリシーおよび認証プラクティスフレームワークに関する規格です。このRFCの目的は、証明書のポリシーと認証プラクティスのフレームワークを提供し、信頼性のある公開鍵基盤を構築することです。
Network Working Group S. Chokhani
Request for Comments: 2527 CygnaCom Solutions, Inc.
Category: Informational W. Ford
VeriSign, Inc.
March 1999
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 (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. 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 definition or a certification practice statement.
このドキュメントは、認証局および公開鍵インフラストラクチャの証明書ポリシーまたは認証実践ステートメントの作成者を支援するためのフレームワークを示しています。特に、このフレームワークは、潜在的に（筆者の裁量で）証明書ポリシー定義または認証実務ステートメントでカバーする必要があるトピックの包括的なリストを提供します。
A public-key certificate (hereinafter "certificate") binds a public-key value to a set of information that identifies the entity (such as person, organization, account, or site) associated with use of the corresponding private key (this entity is known as the "subject" of the certificate). A certificate is used by a "certificate user" or "relying party" that needs to use, and rely upon the accuracy of, the public key distributed via that certificate (a certificate user is typically an entity that is verifying a digital signature from the certificate's subject or an entity sending encrypted data to the subject). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors. These factors include the practices followed by the certification authority (CA) in authenticating the subject; the CA's operating policy, procedures, and security controls; the subject's obligations (for example, in protecting the private key); and the stated undertakings and legal obligations of the CA (for example, warranties and limitations on liability).
公開鍵証明書（以下「証明書」）は、公開鍵の値を、対応する秘密鍵の使用に関連付けられたエンティティ（個人、組織、アカウント、サイトなど）を識別する一連の情報にバインドします（このエンティティは証明書の「サブジェクト」として知られています）。証明書は、その証明書を介して配布された公開鍵を使用し、その正確さに依存する必要がある「証明書ユーザー」または「証明書利用者」によって使用されます（証明書ユーザーは通常、証明書のデジタル署名を検証するエンティティです証明書のサブジェクトまたは暗号化されたデータをサブジェクトに送信するエンティティ）。証明書ユーザーが証明書に組み込まれたバインディングを信頼できる度合いは、いくつかの要因に依存します。これらの要因には、認証局（CA）がサブジェクトを認証する際の慣行が含まれます。 CAの運用ポリシー、手順、およびセキュリティ管理。サブジェクトの義務（たとえば、秘密鍵の保護における）; CAの規定された約束および法的義務（たとえば、保証および責任の制限）。
A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies applies to that certificate [ISO1]. According to X.509, a certificate policy is "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." A certificate policy may be used by a certificate user to help in deciding whether a certificate, and the binding therein, is sufficiently trustworthy for a particular application. The certificate policy concept is an outgrowth of the policy statement concept developed for Internet Privacy Enhanced Mail [PEM1] and expanded upon in [BAU1].
バージョン3のX.509証明書には、1つ以上の特定の証明書ポリシーがその証明書に適用されることを宣言するフィールドが含まれている場合があります[ISO1]。 X.509によると、証明書ポリシーは「特定のコミュニティや共通のセキュリティ要件を持つアプリケーションのクラスへの証明書の適用可能性を示す名前付きのルールのセット」です。証明書ポリシーは、証明書とそのバインディングが特定のアプリケーションに対して十分に信頼できるかどうかを判断するのに役立つために、証明書ユーザーによって使用されます。証明書ポリシーの概念は、インターネットプライバシー強化メール[PEM1]用に開発され、[BAU1]で拡張されたポリシーステートメントの概念の派生物です。
A more detailed description of the practices followed by a CA in issuing and otherwise managing certificates may be contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association Digital Signature Guidelines (hereinafter "ABA Guidelines"), "a CPS is a statement of the practices which a certification authority employs in issuing certificates." [ABA1]
証明書の発行およびその他の管理においてCAが従う慣行のより詳細な説明は、CAが発行または参照する認証実務声明（CPS）に含まれている場合があります。米国弁護士会デジタル署名ガイドライン（以下「ABAガイドライン」）によると、「CPSは、認証局が証明書の発行に採用する慣行の声明です。」 [ABA1]
The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se.
このドキュメントの目的は、証明書ポリシーとCPSの間の明確な関係を確立し、証明書ポリシーまたはCPSの作成者がタスクを支援するためのフレームワークを提示することです。特に、フレームワークは、証明書ポリシーまたはCPSを策定する際に考慮する必要がある要素を識別します。目的は、特定の証明書ポリシーまたはCPS自体を定義することではありません。
The scope of this document is limited to discussion of the contents of a certificate policy (as defined in X.509) or CPS (as defined in the ABA Guidelines). In particular, this document describes the types of information that should be considered for inclusion in a certificate policy definition or a CPS. While the framework as presented generally assumes use of the X.509 version 3 certificate format, it is not intended that the material be restricted to use of that certificate format. Rather, it is intended that this framework be adaptable to other certificate formats that may come into use.
このドキュメントの範囲は、証明書ポリシー（X.509で定義されている）またはCPS（ABAガイドラインで定義されている）の内容の説明に限定されています。特に、このドキュメントでは、証明書ポリシー定義またはCPSに含めることを検討する必要がある情報の種類について説明します。提示されているフレームワークは一般にX.509バージョン3証明書形式の使用を前提としていますが、資料がその証明書形式の使用に限定されることは意図されていません。むしろ、このフレームワークは、使用される可能性のある他の証明書形式に適応可能であることが意図されています。
The scope does not extend to defining security policies generally (such as organization security policy, system security policy, or data labeling policy) beyond the policy elements that are considered of particular relevance to certificate policies or CPSs.
スコープは、証明書ポリシーまたはCPSとの特定の関連性があると見なされるポリシー要素を超えて、一般にセキュリティポリシー（組織のセキュリティポリシー、システムセキュリティポリシー、またはデータのラベル付けポリシーなど）の定義にまで及びません。
This document does not define a specific certificate policy or CPS.
このドキュメントでは、特定の証明書ポリシーまたはCPSを定義していません。
It is assumed that the reader is familiar with the general concepts of digital signatures, certificates, and public-key infrastructure, as used in X.509 and the ABA Guidelines.
読者は、X.509およびABAガイドラインで使用されているデジタル署名、証明書、および公開鍵インフラストラクチャの一般的な概念に精通していることを前提としています。
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、パスフレーズ、または手動で保持するキー共有など）。
CA-certificate - A certificate for one CA's public key issued by another CA.
CA証明書-別のCAによって発行された1つのCAの公開鍵の証明書。
Certificate policy - 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 certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.
証明書ポリシー-共通のセキュリティ要件を持つ特定のコミュニティやアプリケーションクラスへの証明書の適用可能性を示す名前付きのルールセット。たとえば、特定の証明書ポリシーは、特定の価格範囲内で商品を取引するための電子データ交換トランザクションの認証に対する証明書のタイプの適用性を示す場合があります。
Certification path - An ordered sequence of certificates which, 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 which a certification authority employs in issuing certificates.
証明実践ステートメント（CPS）-証明機関が証明書の発行に採用する実践のステートメント。
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です（サブジェクト証明機関も参照）。
Policy qualifier - Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate.
ポリシー修飾子-X.509証明書の証明書ポリシー識別子に付随するポリシー依存情報。
Registration authority (RA) - An entity that is responsible for identification and authentication of certificate subjects, but that does 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 used elsewhere for the same concept.] Relying party - A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.
登録機関（RA）-証明書のサブジェクトの識別と認証を担当するが、証明書に署名または発行しないエンティティ（つまり、RAはCAに代わって特定のタスクを委任されます）。 [注：ローカル登録機関（LRA）という用語は、同じ概念の別の場所で使用されます。]証明書利用者-その証明書および/またはその証明書を使用して検証されたデジタル署名に依存して行動する証明書の受信者。このドキュメントでは、「証明書ユーザー」と「証明書利用者」は同じ意味で使用されています。
Set of provisions - A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
一連の規定-証明書ポリシーの定義またはこのフレームワークで説明されているアプローチを採用した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です（発行証明機関も参照）。
This section explains the concepts of certificate policy and CPS, and describes their relationship. 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.
このセクションでは、証明書ポリシーとCPSの概念について説明し、それらの関係について説明します。その他の関連する概念についても説明します。このセクションおよびその他のセクションで説明されている内容の一部は、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 a particular entity (the certificate subject). However, the extent to which the certificate user should rely on that statement by the CA needs to be assessed by the certificate user. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.
証明機関が証明書を発行するとき、特定の公開キーが特定のエンティティ（証明書のサブジェクト）にバインドされていることを証明書ユーザー（つまり、証明書利用者）に提示します。ただし、証明書ユーザーがCAによってそのステートメントに依存する必要がある範囲は、証明書ユーザーによって評価される必要があります。異なる証明書は異なる慣行と手順に従って発行され、異なるアプリケーションや目的に適している場合があります。
The X.509 standard defines a certificate policy 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 contain an indication of certificate policy, which may be used by a certificate user to decide whether or not to trust a certificate for a particular purpose.
X.509標準では、証明書ポリシーを「特定のコミュニティやアプリケーションに共通のセキュリティ要件を持つアプリケーションクラスへの証明書の適用可能性を示す名前付きのルールのセット」[ISO1]として定義しています。 X.509バージョン3証明書には、証明書ポリシーの表示が含まれている場合があります。これは、証明書ユーザーが特定の目的で証明書を信頼するかどうかを決定するために使用できます。
A certificate policy, which needs to be recognized by both the issuer and user of a certificate, is represented in a certificate by a unique, registered Object Identifier. The registration process follows the procedures specified in ISO/IEC and ITU standards. The party that registers the Object Identifier also publishes a textual specification of the certificate policy, for examination by certificate users. Any one certificate will typically declare a single certificate policy or, possibly, be issued consistent with a small number of different policies.
証明書の発行者とユーザーの両方が認識する必要がある証明書ポリシーは、一意の登録済みオブジェクト識別子によって証明書に表されます。登録プロセスは、ISO / IECおよびITU規格で指定された手順に従います。オブジェクト識別子を登録する当事者は、証明書ユーザーによる検査のために、証明書ポリシーのテキスト仕様も公開します。いずれの証明書も、通常、単一の証明書ポリシーを宣言するか、場合によっては、少数の異なるポリシーに従って発行されます。
Certificate policies also constitute a basis for accreditation of CAs. Each CA is accredited against one or more certificate policies which 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 accreditation 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 certificate policy indications in its well-defined trust model.
証明書ポリシーは、CAの認定の基礎も構成します。各CAは、実装されていると認識されている1つ以上の証明書ポリシーに対して認定されています。あるCAが別のCAのCA証明書を発行する場合、発行元のCAは、対象のCAを信頼する証明書ポリシーのセットを評価する必要があります（そのような評価は、関連する証明書ポリシーに関する認定に基づく場合があります）。評価された証明書ポリシーのセットは、発行元のCAによってCA証明書に示されます。 X.509証明書パス処理ロジックは、明確に定義された信頼モデルでこれらの証明書ポリシー指示を使用します。
For example purposes, suppose that IATA undertakes to define some certificate policies for use throughout the airline industry, in a public-key infrastructure operated by IATA in combination with public-key infrastructures operated by individual airlines. Two certificate policies are defined - the IATA General-Purpose policy, and the IATA Commercial-Grade policy.
例として、IATAが、個々の航空会社が運営する公開鍵インフラストラクチャと組み合わせて、IATAが運営する公開鍵インフラストラクチャで、航空業界全体で使用するための証明書ポリシーを定義することを約束したとします。 IATA汎用ポリシーとIATA商用グレードポリシーの2つの証明書ポリシーが定義されています。
The IATA General-Purpose policy is intended for use 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 General-Purposeポリシーは、日常的な情報（例：カジュアルな電子メール）を保護し、一般的な情報を取得する目的でWorld Wide Webブラウザからサーバーへの接続を認証するための業界担当者による使用を目的としています。キーペアは、商用ブラウザなどの低コストのソフトウェアベースのシステムを使用して生成、保存、および管理できます。このポリシーでは、IATAの企業ディレクトリに従業員としてリストされているすべての人、または組織のネットワーク管理者に署名済みの証明書リクエストフォームを送信するすべてのメンバーの航空会社に、証明書が自動的に発行されます。
The IATA Commercial-Grade policy is used to protect financial transactions or binding contractual exchanges between airlines. Under this policy, IATA requires that certified key pairs be generated and stored in approved cryptographic hardware tokens. Certificates and tokens are provided to airline employees with disbursement authority. These authorized individuals are required to present themselves to the corporate security office, show a valid identification badge, and sign an undertaking to protect the token and use it only for authorized purposes, before a token and a certificate are issued.
IATA商用グレードポリシーは、航空会社間の金融取引または拘束力のある契約上の交換を保護するために使用されます。このポリシーの下で、IATAは認定された鍵ペアを生成し、承認された暗号化ハードウェアトークンに保存することを要求します。証明書とトークンは、支払い権限を持つ航空会社の従業員に提供されます。これらの許可された個人は、企業のセキュリティオフィスに身を置き、有効な身分証明書を提示し、トークンと証明書が発行される前に、トークンを保護し、許可された目的でのみ使用するための約束に署名する必要があります。
The following extension fields in an X.509 certificate are used to support certificate policies:
X.509証明書の次の拡張フィールドは、証明書ポリシーをサポートするために使用されます。
* Certificate Policies extension; * Policy Mappings extension; and * Policy Constraints extension.
* 証明書ポリシー拡張。 *ポリシーマッピング拡張機能。および*ポリシー制約拡張。
The Certificate Policies extension has two variants - one with the field flagged non-critical and one with the field flagged critical. The purpose of the field is different in the two cases.
証明書ポリシー拡張には2つのバリアントがあります。1つは非クリティカルのフラグが付けられたフィールド、もう1つはクリティカルのフラグが付けられたフィールドです。フィールドの目的は、2つのケースで異なります。
A non-critical Certificate Policies field lists certificate policies that the certification authority declares are applicable. However, use of the certificate is not restricted to the purposes indicated by the applicable policies. Using the example of the IATA General-Purpose and Commercial-Grade policies defined in Section 3.2, the certificates issued to regular airline employees will contain the object identifier for certificate policy for the General-Purpose policy. The certificates issued to the employees with disbursement authority will contain the object identifiers for both the General-Purpose policy and the Commercial-Grade policy. The Certificate Policies field may also optionally convey qualifier values for each identified policy; use of qualifiers is discussed in Section 3.4.
重要でない証明書ポリシーフィールドには、証明機関が適用可能であると宣言した証明書ポリシーが一覧表示されます。ただし、証明書の使用は、該当するポリシーで示されている目的に限定されません。セクション3.2で定義されているIATA汎用ポリシーおよび商用グレードポリシーの例を使用すると、航空会社の正規従業員に発行される証明書には、汎用ポリシーの証明書ポリシーのオブジェクト識別子が含まれます。支払い権限を持つ従業員に発行された証明書には、汎用ポリシーと商用グレードポリシーの両方のオブジェクト識別子が含まれます。 「証明書ポリシー」フィールドは、オプションで、識別された各ポリシーの修飾子の値を伝えることもできます。修飾子の使用については、セクション3.4で説明します。
The non-critical Certificate Policies field is designed to be used by applications as follows. Each application is pre-configured to know what policy it requires. Using the example in Section 3.2, electronic mail applications and Web servers will be configured to require the General-Purpose policy. However, an airline's financial applications will be configured to require the Commercial-Grade policy for validating financial transactions over a certain dollar value.
重要でない証明書ポリシーフィールドは、次のようにアプリケーションで使用されるように設計されています。各アプリケーションは、どのポリシーが必要かを知るように事前構成されています。セクション3.2の例を使用して、電子メールアプリケーションとWebサーバーは、汎用ポリシーを要求するように構成されます。ただし、航空会社の金融アプリケーションは、特定のドル額を超える金融取引を検証するために商用グレードのポリシーを要求するように構成されます。
When processing a certification path, a certificate policy that is acceptable to the certificate-using application must be present in every certificate in the path, i.e., in CA-certificates as well as end entity certificates.
証明書パスを処理するとき、証明書を使用するアプリケーションに受け入れられる証明書ポリシーは、パス内のすべての証明書、つまりCA証明書とエンドエンティティ証明書に存在する必要があります。
If the Certificate Policies field is flagged critical, it serves the same purpose as described above but also has an additional role. 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 one of the listed certificate policies. This field is intended to protect the certification authority against damage claims by a relying party who has used the certificate for an inappropriate purpose or in an inappropriate manner, as stipulated in the applicable certificate policy definition.
[Certificate Policies]フィールドにクリティカルのフラグが付けられている場合、これは上記と同じ目的を果たしますが、追加の役割もあります。これは、証明書の使用が識別されたポリシーの1つに制限されていることを示します。つまり、証明機関は、証明書はリストされた証明書ポリシーのいずれかの規定に従ってのみ使用する必要があることを宣言しています。このフィールドは、該当する証明書ポリシー定義で規定されているように、証明書を不適切な目的または不適切な方法で使用した証明書利用者による損害請求から認証局を保護することを目的としています。
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 accidentally issuing a bad certificate, e.g., to a wrongly-authenticated person. However, suppose someone used an Internal Revenue Service tax-filing certificate as the basis for encrypting multi-million-dollar-value proprietary secrets which subsequently fell into the wrong hands because of an error in issuing the Internal Revenue Service certificate. The Internal Revenue Service may want to protect itself against claims for damages in such circumstances. The critical-flagged Certificate Policies extension is intended to mitigate the risk to the certificate issuer in such situations.
たとえば、内国歳入庁は納税申告を保護する目的で納税者に証明書を発行する場合があります。内国歳入庁は、誤って認証された人などに誤って無効な証明書を発行するリスクを理解し、それに対処することができます。ただし、内部収益サービス証明書の発行エラーのために悪意のある手口となった数百万ドルの価値のある機密情報を暗号化するための基礎として、内部収益サービス納税証明書を誰かが使用したとします。内国歳入庁は、このような状況での損害賠償請求から身を守りたいと思うかもしれません。クリティカルフラグの付いた証明書ポリシー拡張機能は、このような状況での証明書発行者へのリスクを軽減することを目的としています。
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 the ACE Corporation establishes an agreement with the ABC Corporation to cross-certify each others' public-key infrastructures for the purposes of mutually protecting electronic data interchange (EDI). 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. 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).
たとえば、ACE CorporationがABC Corporationと、電子データ交換（EDI）を相互に保護する目的で相互の公開鍵インフラストラクチャを相互認証するための合意を確立したとします。さらに、両社がそれぞれace-e-commerceとabc-e-commerceと呼ばれる既存の金融取引保護ポリシーを持っているとします。 2つのドメイン間で相互証明書を生成するだけでは、必要な相互運用性が提供されないことがわかります。これは、2つの企業のアプリケーションが構成され、従業員の証明書にそれぞれの証明書ポリシーが入力されるためです。 1つの可能なソリューションは、いずれかのポリシーを要求するようにすべての金融アプリケーションを再構成し、両方のポリシーですべての証明書を再発行することです。管理が容易な別のソリューションでは、ポリシーマッピングフィールドを使用します。このフィールドがACE Corporation証明機関によって発行されたABC Corporation証明機関の相互認証に含まれている場合、ABCの金融取引保護ポリシー（つまり、abc-e-commerce）は以下と同等と見なすことができるというステートメントを提供できます。 ACE Corporationのそれ（すなわち、ace-e-commerce）。
The Policy Constraints extension supports two optional features. The first is the ability for a certification authority to require that explicit certificate policy indications be present in all subsequent certificates in a certification path. Certificates at the start of a certification path may be considered by a certificate user to be part of a trusted domain, i.e., certification authorities are trusted for all purposes so no particular certificate policy is needed in the Certificate Policies extension. Such certificates need not contain explicit indications of certificate policy. However, when a certification authority in the trusted domain certifies outside the domain, it can activate the requirement for explicit certificate policy in subsequent certificates in the certification path.
ポリシー制約拡張は、2つのオプション機能をサポートしています。 1つ目は、証明機関が、証明書パス内の後続のすべての証明書に明示的な証明書ポリシーの指示が存在することを要求する機能です。証明書パスの開始時の証明書は、証明書ユーザーによって信頼されたドメインの一部であると見なされる場合があります。つまり、証明機関はあらゆる目的で信頼されているため、証明書ポリシー拡張で特定の証明書ポリシーは必要ありません。このような証明書には、証明書ポリシーの明示的な表示が含まれている必要はありません。ただし、信頼されたドメインの証明機関がドメインの外部を証明する場合、証明パスの後続の証明書で明示的な証明書ポリシーの要件をアクティブにすることができます。
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 certificate policy 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.
証明書ポリシー拡張フィールドには、各証明書ポリシー識別子とともに、修飾子フィールドで追加のポリシー依存情報を伝達するための規定があります。 X.509標準は、このフィールドが使用される目的を義務付けておらず、このフィールドの構文も規定していません。ポリシー修飾子タイプは、どの組織でも登録できます。
The following policy qualifier types are defined in PKIX Part I [PKI1]:
以下のポリシー修飾子タイプは、PKIXパートI [PKI1]で定義されています。
(a) The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a uniform resource identifier (URI).
（a）CPSポインター修飾子には、CAによって発行されたCPS（Certification Practice Statement）へのポインターが含まれています。ポインターは、ユニフォームリソース識別子（URI）の形式です。
(b) The User Notice qualifier contains a text string that is to be displayed to a certificate user (including 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 certficate user acknowledge that the applicable terms and conditions have been disclosed or accepted.
（b）ユーザー通知修飾子には、証明書の使用前に証明書ユーザー（サブスクライバーおよび証明書利用者を含む）に表示されるテキスト文字列が含まれています。テキスト文字列は、IA5StringまたはBMPString-ISO 100646-1の複数オクテットコード化文字セットのサブセットです。 CAは、該当する契約条件が開示または受け入れられていることを証明書ユーザーが確認することを要求する手順を呼び出す場合があります。
Policy qualifiers can be used to support the definition of generic, or parameterized, certificate policy definitions. Provided the base certificate policy definition 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.
ポリシー修飾子は、一般的な、またはパラメーター化された証明書ポリシー定義の定義をサポートするために使用できます。基本証明書ポリシー定義が提供されると、ポリシー修飾子タイプを定義して、証明書ごとに、一般的な定義を埋める追加の特定のポリシーの詳細を伝えることができます。
The term certification practice statement (CPS) is defined by the ABA Guidelines as: "A statement of the practices which a certification authority employs in issuing certificates." [ABA1] In the 1995 draft of the ABA guidelines, the ABA expands this definition with the following comments:
認定実践規定（CPS）という用語は、ABAガイドラインで次のように定義されています。「証明機関が証明書を発行する際に採用する規定の記述」。 [ABA1] ABAガイドラインの1995年草案では、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, or it may be a statute or regulation applicable to the certification authority and covering similar subject matter. It may also be part of the contract between the certification authority and the subscriber. A certification practice statement may also be comprised of multiple documents, a combination of public law, private contract, and/or declaration.
認定実務声明は、その信頼できるシステムの詳細と、その運用において、および証明書の発行をサポートするために採用する実務について、証明機関による宣言の形式を取る場合があります。または、それは、証明機関と同様の主題をカバーしています。また、認証局と加入者の間の契約の一部である場合もあります。認定実務声明は、複数の文書、公法、民間契約、および/または宣言の組み合わせで構成される場合もあります。
Certain forms for legally implementing certification practice statements lend themselves to particular relationships. For example, when the legal relationship between a certification authority and subscriber is consensual, a contract would ordinarily be the means of giving effect to a certification practice statement. The certification authority's duties to a relying person are generally based on the certification authority's representations, which may include a certification practice statement.
認定実務声明を法的に実施するための特定のフォームは、特定の関係に役立ちます。たとえば、認証局と加入者の間の法的関係が合意に基づく場合、契約は通常、認証実務声明を有効にする手段となります。証明書利用者の証明書利用者への義務は、一般に、証明機関の表明に基づいており、これには、認証実務声明が含まれる場合があります。
Whether a certification practice statement is binding on a relying person depends on whether the relying person has knowledge or notice of the certification practice statement. A relying person has knowledge or at least notice of the contents of the certificate used by the relying person to verify a digital signature, including documents incorporated into the certificate by reference. It is therefore advisable to incorporate a certification practice statement into a certificate by reference.
認定実務ステートメントが信頼者に拘束力があるかどうかは、信頼者が認定実務ステートメントの知識または通知を持っているかどうかによって異なります。証明書利用者は、デジタル署名を検証するために証明書利用者が使用する証明書の内容（参照により証明書に組み込まれたドキュメントを含む）を知っているか、少なくとも通知します。したがって、参照により証明書に認証実務声明を組み込むことをお勧めします。
As much as possible, a certification practice statement should indicate any of the widely recognized standards to which the certification authority's practices conform. Reference to widely recognized standards may indicate concisely the suitability of the certification authority's practices for another person's purposes, as well as the potential technological compatibility of the certificates issued by the certification authority with repositories and other systems.
可能な限り、認証実務声明は、認証局の実務が準拠している広く認められている基準のいずれかを示す必要があります。広く認められている規格への言及は、認証機関の実践が別の人の目的に適していること、および認証機関が発行した証明書とリポジトリおよびその他のシステムとの潜在的な技術的互換性を簡潔に示している場合があります。
3.6 RELATIONSHIP BETWEEN CERTIFICATE POLICY AND CERTIFICATION PRACTICE STATEMENT
3.6 証明書ポリシーと証明書実務声明の関係
The concepts of certificate policy and CPS come from different sources and were developed for different reasons. However, their interrelationship is important.
証明書ポリシーとCPSの概念はさまざまなソースから来ており、さまざまな理由で開発されました。ただし、それらの相互関係は重要です。
A certification practice statement is a detailed statement by a certification authority as to its practices, that potentially needs to be understood and consulted by subscribers and certificate users (relying parties). Although the level of detail may vary among CPSs, they will generally be more detailed than certificate policy definitions. Indeed, CPSs may be quite comprehensive, robust documents providing a description of the precise service offerings, detailed procedures of the life-cycle management of certificates, and more - a level of detail which weds the CPS to a particular (proprietary) implementation of a service offering.
認定実務声明は、その実務に関する認証局による詳細な声明であり、潜在的にサブスクライバーおよび証明書ユーザー（証明書利用者）が理解して相談する必要があります。詳細レベルはCPSによって異なる場合がありますが、通常は証明書ポリシーの定義よりも詳細です。実際、CPSは、正確なサービス提供の説明、証明書のライフサイクル管理の詳細な手順など、CPSを特定の（独自の）実装に統合する詳細レベルを提供する、非常に包括的で堅牢なドキュメントである場合があります。サービス提供。
Although such detail may be indispensable to adequately disclose, and to make a full assessment of trustworthiness in the absence of accreditation or other recognized quality metrics, a detailed CPS does not form a suitable basis for interoperability between CAs operated by different organizations. Rather, certificate policies best serve as the vehicle on which to base common interoperability standards and common assurance criteria on an industry-wide (or possibly more global) basis. A CA with a single CPS may support multiple certificate policies (used for different application purposes and/or by different certificate user communities). Also, multiple different CAs, with non-identical certification practice statements, may support the same certificate policy.
このような詳細は、適切に開示し、認定やその他の承認された品質指標がない場合の信頼性を完全に評価するために不可欠ですが、詳細なCPSは、異なる組織によって運用されるCA間の相互運用性の適切な基礎を形成しません。むしろ、証明書ポリシーは、共通の相互運用性標準と共通の保証基準を業界全体（またはおそらくグローバルな）に基づいてベースとする手段として最適に機能します。単一のCPSを持つCAは、複数の証明書ポリシーをサポートする場合があります（さまざまなアプリケーションの目的で、またはさまざまな証明書ユーザーコミュニティによって使用されます）。また、複数の異なるCAが、同一でない認証実務ステートメントを使用して、同じ証明書ポリシーをサポートする場合があります。
For example, the Federal Government might define a government-wide certificate policy for handling confidential human resources information. The certificate policy definition will be a broad statement of the general characteristics of that certificate policy, and an indication of the types of applications for which it is suitable for use. Different departments or agencies that operate certification authorities with different certification practice statements might support this certificate policy. At the same time, such certification authorities may support other certificate policies.
たとえば、連邦政府は機密の人事情報を処理するための政府全体の証明書ポリシーを定義する場合があります。証明書ポリシーの定義は、その証明書ポリシーの一般的な特性を幅広く説明し、使用に適したアプリケーションのタイプを示します。異なる認証実務ステートメントで認証局を運営する異なる部門または機関が、この証明書ポリシーをサポートしている場合があります。同時に、そのような証明機関は他の証明書ポリシーをサポートする場合があります。
The main difference between certificate policy and CPS can therefore be summarized as follows:
したがって、証明書ポリシーとCPSの主な違いは、次のように要約できます。
(a) Most organizations that operate public or inter-organizational certification authorities will document their own practices in CPSs or similar statements. The CPS is one of the organization's means of protecting itself and positioning its business relationships with subscribers and other entities.
（a）公的認証機関または組織間認証機関を運営するほとんどの組織は、CPSまたは同様の声明で独自の慣行を文書化します。 CPSは、それ自体を保護し、加入者やその他のエンティティとのビジネス関係を位置付ける組織の手段の1つです。
(b) There is strong incentive, on the other hand, for a certificate policy to apply more broadly than to just a single organization. If a particular certificate policy is widely recognized and imitated, it has great potential as the basis of automated certificate acceptance in many systems, including unmanned systems and systems that are manned by people not independently empowered to determine the acceptability of different presented certificates.
（b）一方、証明書ポリシーは、単一の組織だけに適用されるのではなく、より広範囲に適用されることを強く奨励します。特定の証明書ポリシーが広く認識され模倣されている場合、無人システムや、提示されたさまざまな証明書の受け入れ可能性を個別に判断する権限を与えられていない人が担当するシステムなど、多くのシステムでの自動証明書受け入れの基礎として大きな可能性があります。
In addition to populating the certificate policies field with the certificate policy 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 certificate policy qualifier, is described in Section 3.4.
証明書ポリシーフィールドに証明書ポリシーIDを入力することに加えて、証明機関は、発行する証明書に、その証明実践ステートメントへの参照を含めることができます。証明書ポリシー修飾子を使用してこれを行う標準的な方法は、セクション3.4で説明されています。
A set of provisions is a collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
一連の規定は、このフレームワークで説明されているアプローチを採用した証明書ポリシー定義またはCPSを表現する際に使用するための、一連の標準的なトピックにわたる実践および/またはポリシーステートメントのコレクションです。
A certificate policy can be expressed as a single set of provisions.
証明書ポリシーは、単一のプロビジョニングセットとして表すことができます。
A CPS can be expressed as a single set of provisions with each component addressing the requirements of one or more certificate policies, or, alternatively, as an organized collection of sets of provisions. For example, a CPS could be expressed as a combination of the following:
CPSは、各コンポーネントが1つ以上の証明書ポリシーの要件に対処する単一のプロビジョニングセットとして表現することも、組織化された一連のプロビジョニングの集まりとして表現することもできます。たとえば、CPSは次の組み合わせで表すことができます。
(a) a list of certificate policies supported by the CPS;
（a）CPSがサポートする証明書ポリシーのリスト。
(b) for each certificate policy in (a), a set of provisions which
contains statements that refine that certificate policy by
filling in details not stipulated in that policy or expressly
left to the discretion of the CPS by that certificate policy;
such statements serve to state how this particular CPS
implements the requirements of the particular certificate policy;
(c) a set of provisions that contains statements regarding the certification practices on the CA, regardless of certificate policy.
（c）証明書のポリシーに関係なく、CAでの認証慣行に関する記述を含む一連の規定。
The statements provided in (b) and (c) may augment or refine the stipulations of the applicable certificate policy definition, but must not conflict with any of the stipulations of such certificate policy definition.
（b）および（c）で提供されるステートメントは、該当する証明書ポリシー定義の規定を強化または改善する場合がありますが、そのような証明書ポリシー定義の規定と競合してはなりません。
This framework outlines the contents of a set of provisions, in terms of eight primary components, as follows:
このフレームワークは、次のように、8つの主要コンポーネントの観点から、一連の条項の内容の概要を示しています。
* Introduction;
* 前書き;
* General Provisions;
* 一般規定;
* Identification and Authentication;
* 識別と認証;
* Operational Requirements;
* 運用要件;
* Physical, Procedural, and Personnel Security Controls;
* 物理的、手続き的、および人的セキュリティ管理;
* Technical Security Controls;
* 技術的なセキュリティ管理;
* Certificate and CRL Profile; and
* 証明書とCRLプロファイル。そして
* Specification Administration.
* 仕様管理。
Components 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.
コンポーネントはさらにサブコンポーネントに分割でき、サブコンポーネントは複数の要素で構成されます。セクション4では、上記のコンポーネントとそのサブコンポーネントの内容の詳細を説明します。
This section expands upon the contents of a set of provisions, as introduced in Section 3.7. The topics identified in this section are, consequently, candidate topics for inclusion in a certificate policy definition or CPS.
このセクションでは、セクション3.7で紹介した一連の条項の内容を拡張します。したがって、このセクションで識別されるトピックは、証明書ポリシー定義またはCPSに含める候補トピックです。
While many topics are identified, it is not necessary for a certificate policy or a CPS to include a concrete statement for every such topic. Rather, a particular certificate policy or CPS may state "no stipulation" for a component, subcomponent, or element on which the particular certificate policy or CPS imposes no requirements. In this sense, the list of topics can be considered a checklist of topics for consideration by the certificate policy or CPS writer. It is recommended that each and every component and subcomponent be included in a certificate policy or CPS, even if there is "no stipulation"; this will indicate to the reader that a conscious decision was made to include or exclude that topic. This protects against inadvertent omission of a topic, while facilitating comparison of different certificate policies or CPSs, e.g., when making policy mapping decisions.
多くのトピックが識別されていますが、証明書ポリシーまたはCPSがそのようなトピックごとに具体的なステートメントを含める必要はありません。むしろ、特定の証明書ポリシーまたはCPSは、特定の証明書ポリシーまたはCPSが要件を課さないコンポーネント、サブコンポーネント、または要素について「規定なし」と述べる場合があります。この意味で、トピックのリストは、証明書ポリシーまたはCPSライターが検討するトピックのチェックリストと見なすことができます。 「規定がない」場合でも、すべてのコンポーネントとサブコンポーネントを証明書ポリシーまたはCPSに含めることをお勧めします。これは、そのトピックを含めるか除外するかを意識的に決定したことを読者に示します。これにより、トピックの不注意による脱落を防ぎながら、たとえばポリシーマッピングを決定するときに、さまざまな証明書ポリシーまたはCPSの比較を容易にします。
In a certificate policy definition, 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. Such certificate policy definitions 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.
証明書ポリシー定義では、特定のコンポーネント、サブコンポーネント、および/または要素を指定しないままにして、必要な情報がポリシー修飾子で示されるように規定することが可能です。このような証明書ポリシー定義は、パラメーター化された定義と見なすことができます。一連の規定では、必要なポリシー修飾子タイプを参照または定義し、適用可能なデフォルト値を指定する必要があります。
This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the specification is targeted.
このコンポーネントは、一連の規定を識別および導入し、仕様の対象となるエンティティおよびアプリケーションのタイプを示します。
This component has the following subcomponents:
このコンポーネントには次のサブコンポーネントがあります。
* Overview;
* 概要;
* Identification;
* 識別;
* Community and Applicability; and
* コミュニティと適用性。そして
* Contact Details.
* 連絡先の詳細。
This subcomponent provides a general introduction to the specification.
このサブコンポーネントは、仕様の概要を提供します。
This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the set of provisions.
このサブコンポーネントは、ASN.1オブジェクト識別子を含む、該当する名前またはその他の識別子を提供します。
This subcomponent describes the types of entities that issue certificates or that are certified as subject CAs (2, 3), the types of entities that perform RA functions (4), and the types of entities that are certified as subject end entities or subscribers. (5, 6)
このサブコンポーネントでは、証明書を発行するか、サブジェクトCAとして認定されるエンティティのタイプ（2、3）、RA機能を実行するエンティティのタイプ（4）、およびサブジェクトエンドエンティティまたはサブスクライバーとして認定されるエンティティのタイプについて説明します。 （5、6）
This subcomponent also contains:
このサブコンポーネントには以下も含まれます。
* A list of applications for which the issued certificates are suitable. (Examples of application in this case are: electronic mail, retail transactions, contracts, travel order, etc.)
* 発行された証明書が適しているアプリケーションのリスト。 （この場合の適用例は、電子メール、小売取引、契約、旅行注文などです。）
* A list of applications for which use of the issued certificates is restricted. (This list implicitly prohibits all other uses for the certificates.)
* 発行された証明書の使用が制限されているアプリケーションのリスト。 （このリストは、証明書の他のすべての使用を暗黙的に禁止します。）
* A list of applications for which use of the issued certificates is prohibited.
* 発行された証明書の使用が禁止されているアプリケーションのリスト。
This subcomponent includes the name and mailing address of the authority that is responsible for the registration, maintenance, and interpretation of this certificate policy or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person.
このサブコンポーネントには、この証明書ポリシーまたはCPSの登録、保守、および解釈を担当する機関の名前とメールアドレスが含まれます。また、連絡先の名前、電子メールアドレス、電話番号、およびFAX番号も含まれます。
This component specifies any applicable presumptions on a range of legal and general practices topics.
このコンポーネントは、法的および一般的なプラクティスのトピックに関する適用可能な推定を指定します。
This component contains the following subcomponents:
このコンポーネントには、次のサブコンポーネントが含まれています。
* Obligations;
* 義務;
* Liability;
* 責任;
* Financial Responsibility;
* 経済的責任;
* Interpretation and Enforcement;
* 解釈と執行;
* Fees;
* 料金;
* Publication and Repositories;
* 出版物とリポジトリ;
* Compliance Audit;
* コンプライアンス監査;
* Confidentiality; and
* 守秘義務;そして
* Intellectual Property Rights.
* 知的財産権。
Each subcomponent may need to separately state provisions applying to the entity types: CA, repository, RA, subscriber, and relying party. (Specific provisions regarding subscribers and relying parties are only applicable in the Liability and Obligations subcomponents.)
各サブコンポーネントは、エンティティタイプ（CA、リポジトリ、RA、サブスクライバー、および証明書利用者）に適用される条項を個別に述べる必要がある場合があります。 （加入者および依拠当事者に関する特定の規定は、責任および義務サブコンポーネントにのみ適用されます。）
This subcomponent contains, for each entity type, any applicable provisions regarding the entity's obligations to other entities. Such provisions may include:
このサブコンポーネントには、エンティティタイプごとに、他のエンティティに対するエンティティの義務に関する適用可能な規定が含まれています。そのような規定には以下が含まれます。
* CA and/or RA obligations: * Notification of issuance of a certificate to the subscriber who is the subject of the certificate being issued; * Notification of issuance of a certificate to others than the subject of the certificate; * Notification of revocation or suspension of a certificate to the subscriber whose certificate is being revoked or suspended; and * Notification of revocation or suspension of a certificate to others than the subject whose certificate is being revoked or suspended.
* CAおよび/またはRAの義務：*発行される証明書の対象であるサブスクライバーへの証明書の発行の通知。 *証明書の対象者以外への証明書の発行の通知。 *証明書が失効または一時停止されている加入者への証明書の失効または一時停止の通知。および*証明書の失効または一時停止の対象者以外への証明書の失効または一時停止の通知。
* Subscriber obligations:
* 加入者の義務：
* Accuracy of representations in certificate application; * Protection of the entity's private key; * Restrictions on private key and certificate use; and * Notification upon private key compromise.
* 証明書申請における表明の正確性; *エンティティの秘密鍵の保護。 *秘密鍵と証明書の使用に関する制限。および*秘密鍵の侵害に関する通知。
* Relying party obligations:
* 依拠当事者の義務：
* Purposes for which certificate is used; * Digital signature verification responsibilities; * Revocation and suspension checking responsibilities; and * Acknowledgment of applicable liability caps and warranties.
* 証明書が使用される目的; *デジタル署名検証の責任。 *失効および一時停止チェックの責任。および*適用される責任の上限と保証の承認。
* Repository obligations
* リポジトリの義務
* Timely publication of certificates and revocation information
* 証明書と失効情報のタイムリーな公開
This subcomponent contains, for each entity type, any applicable provisions regarding apportionment of liability, such as:
このサブコンポーネントには、エンティティタイプごとに、次のような責任の割り当てに関する該当する条項が含まれています。
* Warranties and limitations on warranties;
* 保証と保証の制限;
* Kinds of damages covered (e.g., indirect, special, consequential, incidental, punitive, liquidated damages, negligence and fraud) and disclaimers;
* 対象となる損害の種類（間接的、特別、結果的、偶発的、懲罰的、損害賠償、過失、詐欺など）および免責事項。
* Loss limitations (caps) per certificate or per transaction; and
* 証明書またはトランザクションごとの損失制限（上限）。そして
* Other exclusions (e.g., Acts of God, other party responsibilities).
* その他の除外事項（例：神の行為、他の当事者の責任）。
This subcomponent contains, for CAs, repository, and RAs, any applicable provisions regarding financial responsibilities, such as:
このサブコンポーネントには、CA、リポジトリ、およびRAについて、次のような経済的責任に関する適用可能な規定が含まれています。
* Indemnification of CA and/or RA by relying parties;
* 依拠当事者によるCAおよび/またはRAの補償。
* Fiduciary relationships (or lack thereof) between the various entities; and
* さまざまなエンティティ間の受託者関係（またはその欠如）。そして
* Administrative processes (e.g., accounting, audit).
* 管理プロセス（会計、監査など）。
This subcomponent contains any applicable provisions regarding interpretation and enforcement of the certificate policy or CPS, addressing such topics as:
このサブコンポーネントには、証明書ポリシーまたはCPSの解釈および実施に関する適用可能な規定が含まれ、次のようなトピックに対処します。
* Governing law;
* 準拠法;
* Severability of provisions, survival, merger, and notice; and
* 条項の分離可能性、存続、合併、および通知。そして
* Dispute resolution procedures.
* 紛争解決手続き。
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 fee;
* 証明書アクセス料;
* Revocation or status information access fee;
* 失効またはステータス情報アクセス料;
* Fees for other services such as policy information; and
* ポリシー情報などの他のサービスの料金。そして
* Refund policy.
* 返金について。
This subcomponent contains any applicable provisions regarding:
このサブコンポーネントには、以下に関する該当する条項が含まれています。
* A CA's obligations to publish information regarding its practices, its certificates, and the current status of such certificates;
* その慣行、その証明書、およびそのような証明書の現在の状況に関する情報を公開するCAの義務;
* Frequency of publication;
* 出版の頻度;
* Access control on published information objects including certificate policy definitions, CPS, certificates, certificate status, and CRLs; and
* 証明書ポリシー定義、CPS、証明書、証明書ステータス、CRLなど、公開された情報オブジェクトへのアクセス制御。そして
* Requirements pertaining to the use of repositories operated by CAs or by other independent parties.
* CAまたは他の独立した当事者が運営するリポジトリの使用に関する要件。
This subcomponent addresses the following:
このサブコンポーネントは、次のことを扱います。
* Frequency of compliance audit for each entity;
* 各エンティティのコンプライアンス監査の頻度。
* Identity/qualifictions of the auditor;
* 監査人の身元/資格;
* Auditor's relationship to the entity being audited; (30)
* 監査対象のエンティティと監査人の関係。 （30）
* List of topics covered under the compliance audit; (31)
* コンプライアンス監査の対象となるトピックのリスト。 （31）
* Actions taken as a result of a deficiency found during compliance audit; (32)
* コンプライアンス監査中に発見された不備の結果として取られた措置。 （32）
* Compliance audit results: who they are shared with (e.g., subject CA, RA, and/or end entities), who provides them (e.g., entity being audited or auditor), how they are communicated.
* コンプライアンス監査結果：それらが誰と共有されるか（例：対象のCA、RA、および/またはエンドエンティティ）、誰がそれらを提供するか（例：監査対象のエンティティまたは監査人）、それらの伝達方法
This subcomponent addresses the following:
このサブコンポーネントは、次のことを扱います。
* Types of information that must be kept confidential by CA or RA;
* CAまたはRAが機密保持する必要がある情報の種類。
* Types of information that are not considered confidential;
* 機密と見なされない情報の種類。
* Who is entitled to be informed of reasons for revocation and suspension of certificates;
* 証明書の取り消しおよび一時停止の理由について通知を受ける権利を有する者;
* Policy on release of information to law enforcement officials;
* 法執行当局への情報公開に関する方針。
* Information that can be revealed as part of civil discovery;
* 市民の発見の一環として明らかにすることができる情報。
* Conditions upon which CA or RA may disclose upon owner's request; and
* CAまたはRAが所有者の要求に応じて開示できる条件。そして
* Any other circumstances under which confidential information may be disclosed.
* 機密情報が開示される可能性のあるその他の状況。
This subcomponent addresses ownership rights of certificates, practice/policy specifications, names, and keys.
このサブコンポーネントは、証明書の所有権、実践/ポリシーの仕様、名前、および鍵を扱います。
This component describes the procedures used to authenticate a certificate applicant to a CA or RA prior to certificate issuance. It also describes how parties requesting rekey or revocation are authenticated. This component also addresses naming practices, including name ownership recognition and name dispute resolution.
このコンポーネントは、証明書の発行前にCAまたはRAに対して証明書申請者を認証するために使用される手順を記述します。また、鍵の再発行または失効を要求する当事者がどのように認証されるかについても説明します。このコンポーネントは、名前の所有権の認識や名前の紛争の解決など、名前の付け方にも対処します。
This component has the following subcomponents:
このコンポーネントには次のサブコンポーネントがあります。
* Initial Registration;
* 初期登録;
* Routine Rekey;
* 定期的な鍵更新;
* Rekey After Revocation; and
* 失効後の鍵の再生成。そして
* Revocation Request.
* 失効リクエスト。
This subcomponent includes the following elements regarding identification and authentication procedures during entity registration or certificate issuance:
このサブコンポーネントには、エンティティの登録または証明書の発行中の識別および認証手順に関する次の要素が含まれています。
* Types of names assigned to the subject (7);
* サブジェクトに割り当てられた名前のタイプ（7）;
* Whether names have to be meaningful or not (8);
* 名前が意味を持つ必要があるかどうか（8）。
* Rules for interpreting various name forms;
* さまざまな名前の形式を解釈するための規則。
* Whether names have to be unique;
* 名前が一意である必要があるかどうか。
* How name claim disputes are resolved;
* 名義紛争の解決方法;
* Recognition, authentication, and role of trademarks;
* 商標の認識、認証、および役割。
* If and how the subject must prove possession of the companion private key for the public key being registered (9);
* サブジェクトが、登録されている公開鍵のコンパニオン秘密鍵の所有を証明しなければならない場合とその方法（9）。
* Authentication requirements for organizational identity of subject (CA, RA, or end entity) (10);
* サブジェクト（CA、RA、またはエンドエンティティ）の組織IDの認証要件（10）;
* Authentication requirements for a person acting on behalf of a subject (CA, RA, or end entity) (11), including:
* サブジェクト（CA、RA、またはエンドエンティティ）に代わって行動する人物の認証要件（11）。
* Number of pieces of identification required; * How a CA or RA validates the pieces of identification provided; * If the individual must present personally to the authenticating CA or RA; * How an individual as an organizational person is authenticated (12).
* 必要な身分証明書の数。 * CAまたはRAが提供された識別情報を検証する方法。 *個人が認証CAまたはRAに個人的に提示する必要がある場合。 *組織の個人としての個人の認証方法（12）。
This subcomponent describes the identification and authentication procedures for routine rekey for each subject type (CA, RA, and end entity). (13)
このサブコンポーネントは、各サブジェクトタイプ（CA、RA、およびエンドエンティティ）のルーチンキー再生成の識別および認証手順を説明します。 （13）
This subcomponent describes the identification and authentication procedures for rekey for each subject type (CA, RA, and end entity) after the subject certificate has been revoked. (14)
このサブコンポーネントは、サブジェクト証明書が取り消された後の各サブジェクトタイプ（CA、RA、およびエンドエンティティ）のキー再生成の識別および認証手順を説明します。 （14）
This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, and end entity). (16)
このサブコンポーネントは、各サブジェクトタイプ（CA、RA、エンドエンティティ）による失効リクエストの識別と認証の手順を説明します。 （16）
This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, or end entities with respect to various operational activities.
このコンポーネントは、さまざまな運用活動に関してCA、サブジェクトCA、RA、またはエンドエンティティの発行に課される要件を指定するために使用されます。
This component consists of the following subcomponents:
このコンポーネントは、次のサブコンポーネントで構成されています。
* Certificate Application;
* 証明書の申請;
* Certificate Issuance;
* 証明書の発行;
* Certificate Acceptance;
* 証明書の承認;
* Certificate Suspension and Revocation;
* 証明書の一時停止と取り消し;
* Security Audit Procedures;
* セキュリティ監査手順;
* Records Archival;
* レコードのアーカイブ。
* Key Changeover;
* キーの切り替え;
* Compromise and Disaster Recovery; and
* 妥協と災害復旧;そして
* CA Termination.
* CAの終了。
Within each subcomponent, separate consideration may need to be given to issuing CA, repository, subject CAs, RAs, and end entities.
各サブコンポーネント内で、発行元のCA、リポジトリ、サブジェクトCA、RA、およびエンドエンティティについて個別に検討する必要がある場合があります。
This subcomponent is used to state requirements regarding subject enrollment and request for certificate issuance.
このサブコンポーネントは、サブジェクトの登録および証明書発行の要求に関する要件を示すために使用されます。
This subcomponent is used to state requirements regarding issuance of a certificate and notification to the applicant of such issuance.
このサブコンポーネントは、証明書の発行とそのような発行の申請者への通知に関する要件を述べるために使用されます。
This subcomponent is used to state requirements regarding acceptance of an issued certificate and for consequent publication of certificates.
このサブコンポーネントは、発行された証明書の受け入れおよびその後の証明書の公開に関する要件を述べるために使用されます。
This subcomponent addresses the following:
このサブコンポーネントは、次のことを扱います。
* Circumstances under which a certificate may be revoked;
* 証明書が取り消される可能性のある状況。
* Who can request the revocation of the entity certificate;
* エンティティ証明書の失効をリクエストできるのは誰ですか。
* Procedures used for certificate revocation request;
* 証明書失効要求に使用される手順。
* Revocation request grace period available to the subject;
* 対象が利用できる失効リクエストの猶予期間。
* Circumstances under which a certificate may be suspended;
* 証明書が一時停止される可能性のある状況。
* Who can request the suspension of a certificate;
* 誰が証明書の一時停止を要求できるか;
* Procedures to request certificate suspension;
* 証明書の一時停止を要求する手順。
* How long the suspension may last;
* 停止が続く期間。
* If a CRL mechanism is used, the issuance frequency;
* CRLメカニズムが使用されている場合、発行頻度。
* Requirements on relying parties to check CRLs;
* 証明書利用者がCRLをチェックするための要件。
* On-line revocation/status checking availability;
* オンライン失効/ステータスチェックの可用性。
* Requirements on relying parties to perform on-line revocation/status checks;
* オンライン失効/ステータスチェックを実行するための依拠当事者の要件。
* Other forms of revocation advertisements available; and
* 利用可能な失効広告の他の形式。そして
* Requirements on relying parties to check other forms of revocation advertisements.
* 依存パーティが他の形式の失効広告を確認するための要件。
* Any variations on the above stipulations when the suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation).
* 一時停止または取り消しが秘密鍵の侵害の結果である場合の上記の規定のバリエーション（一時停止または取り消しのその他の理由とは対照的）。
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; (28)
* 記録されたイベントのタイプ。 （28）
* Frequency with which audit logs are processed or audited;
* 監査ログが処理または監査される頻度。
* Period for which audit logs are kept;
* 監査ログが保持される期間。
* Protection of audit logs:
* 監査ログの保護：
- Who can view audit logs; - Protection against modification of audit log; and - Protection against deletion of audit log.
- 監査ログを表示できるユーザー。 -監査ログの変更に対する保護。および-監査ログの削除に対する保護。
* 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.
* 脆弱性の評価。
This subcomponent is used to describe general records archival (or records retention) policies, including the following:
このサブコンポーネントは、以下を含む一般的なレコードアーカイブ（またはレコード保持）ポリシーを記述するために使用されます。
* Types of events recorded; (29)
* 記録されたイベントのタイプ。 （29）
* Retention period for archive;
* アーカイブの保存期間。
* Protection of archive:
* アーカイブの保護：
- Who can view the archive; - Protection against modification of archive; and - Protection against deletion of archive.
- 誰がアーカイブを閲覧できるか。 -アーカイブの変更に対する保護。および-アーカイブの削除に対する保護。
* 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.
* アーカイブ情報を取得して確認する手順。
This subcomponent describes the procedures to provide a new public key to a CA's users.
このサブコンポーネントは、CAのユーザーに新しい公開鍵を提供する手順を説明します。
This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following circumstances may need to be addressed separately:
このサブコンポーネントは、侵害または災害が発生した場合の通知および回復手順に関連する要件について説明します。以下の状況はそれぞれ個別に対処する必要がある場合があります。
* 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 reestablished,
* コンピューティングリソース、ソフトウェア、データが破損している、または破損している疑いがある場合に使用される回復手順。これらの手順は、安全な環境がどのように再確立されるかを説明しています。
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 recertified.
取り消される証明書、エンティティキーが取り消されるかどうか、新しいエンティティ公開鍵がユーザーに提供される方法、サブジェクトが再認証される方法。
* The recovery procedures used if the entity public key is revoked. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified.
* エンティティーの公開鍵が取り消された場合に使用されるリカバリー手順。これらの手順では、安全な環境を再確立する方法、新しいエンティティの公開キーをユーザーに提供する方法、およびサブジェクトを再認証する方法について説明します。
* The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is reestablished, how the new entity public key is provided to the users, and how the subjects are recertified.
* エンティティキーが侵害された場合に使用される回復手順。これらの手順では、安全な環境を再確立する方法、新しいエンティティの公開キーをユーザーに提供する方法、およびサブジェクトを再認証する方法について説明します。
* The CA's procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is reestablished either at the original site or a remote hot-site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.
* 自然災害またはその他の災害の後、安全な環境が元のサイトまたはリモートホットサイトで再確立される前の期間に、施設を保護するためのCAの手順。たとえば、地震で被害を受けたサイトからの機密性の高い物質の盗難を防ぐための手順。
This subcomponent describes requirements relating to procedures for termination and for 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 describes non-technical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to perform securely the functions of key generation, subject authentication, certificate issuance, certificate revocation, audit, and archival.
このコンポーネントは、キーの生成、サブジェクト認証、証明書の発行、証明書の取り消し、監査、およびアーカイブの機能を安全に実行するために発行CAによって使用される非技術的なセキュリティ制御（つまり、物理的、手続き的、および人的制御）を記述します。
This component can also be used to define non-technical security controls on repository, subject CAs, RAs, and end entities. The non technical security controls for the subject CAs, RAs, and end entities 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 the compromise of the CA private key.
セキュリティが不足していると、CAの操作が危険にさらされ、誤った情報を含む証明書やCRLが作成されたり、CAの秘密鍵が危険にさらされたりする可能性があるため、これらの非技術的なセキュリティ制御は証明書を信頼するうえで重要です。
This component consists of three subcomponents:
このコンポーネントは、3つのサブコンポーネントで構成されています。
* Physical Security Controls;
* 物理的セキュリティ管理;
* Procedural Controls; and
* 手続き管理;そして
* Personnel Security Controls.
* 人事セキュリティ管理。
Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, issuing CA, repository, subject CAs, RAs, and end entities.
各サブコンポーネント内では、通常、各エンティティタイプ、つまり発行元CA、リポジトリ、サブジェクトCA、RA、およびエンドエンティティに個別の考慮事項を与える必要があります。
In this subcomponent, the physical controls on the facility housing the entity systems are described.(21) Topics addressed may include:
このサブコンポーネントでは、エンティティシステムを収容する施設の物理的な制御について説明します。（21）取り上げるトピックには、次のものがあります。
* Site location and construction;
* サイトの場所と建設。
* Physical access;
* 物理的アクセス;
* Power and air conditioning;
* 電源とエアコン。
* Water exposures;
* 水への暴露;
* Fire prevention and protection;
* 防火と保護;
* Media storage;
* メディアストレージ;
* Waste disposal; and
* 廃棄物処理;そして
* Off-site backup.
* オフサイトバックアップ。
In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role.(22)
このサブコンポーネントでは、信頼された役割を認識するための要件が、各役割の責任とともに説明されています。（22）
For each task identified for each role, it should also be stated how many individuals are required to perform the task (n out m rule). Identification and authentication requirements for each role may also be defined.
各役割について特定された各タスクについて、そのタスクを実行するために必要な個人の数も明記する必要があります（n out mルール）。各ロールの識別と認証の要件も定義できます。
This subcomponent addresses the following:
このサブコンポーネントは、次のことを扱います。
* Background checks and clearance procedures required for the personnel filling the trusted roles; (23)
* 信頼できる役割を担当する担当者に必要なバックグラウンドチェックとクリアランス手順。 （23）
* Background checks and clearance procedures requirements for other personnel, including janitorial staff; (24)
* 用務スタッフを含む他の要員の身元調査および通関手続きの要件。 （24）
* Training requirements and training procedures for each role;
* 各役割のトレーニング要件とトレーニング手順。
* Any retraining period and retraining procedures for each role;
* 各ロールの再トレーニング期間と再トレーニング手順。
* 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; (25)
* 不正行為、権限の不正使用、およびエンティティシステムの不正使用に対する職員に対する制裁。 （25）
* Controls on contracting personnel, including:
* 以下を含む契約社員の管理：
- Bonding requirements on contract personnel; - Contractual requirements including indemnification for damages due to the actions of the contractor personnel; - Audit and monitoring of contractor personnel; and - Other controls on contracting personnel.
- 契約担当者の結合要件; -契約社員の行動による損害の補償を含む契約上の要件。 -請負業者の監査と監視。 -契約社員に関するその他の管理策。
* Documentation to be supplied to personnel.
* 担当者に提供するドキュメント。
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 and end entities to protect their cryptographic 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, audit, and archival. 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, and end entities.
このコンポーネントは、リポジトリ、サブジェクトCA、RA、およびエンドエンティティに関する他の技術的なセキュリティコントロールを定義するためにも使用できます。
This component has the following subcomponents:
このコンポーネントには次のサブコンポーネントがあります。
* Key Pair Generation and Installation;
* 鍵ペアの生成とインストール。
* Private Key Protection;
* 秘密鍵の保護;
* Other Aspects of Key Pair Management;
* 鍵ペア管理のその他の側面;
* Activation Data;
* アクティベーションデータ;
* Computer Security Controls;
* コンピューターのセキュリティ管理;
* Life-Cycle Security Controls;
* ライフサイクルのセキュリティ管理;
* Network Security Controls; and
* ネットワークセキュリティコントロール;そして
* Cryptographic Module Engineering Controls.
* 暗号化モジュールのエンジニアリング管理。
Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. 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?
1. エンティティの公開鍵と秘密鍵のペアを生成するのは誰ですか？
2. How is the private key provided securely to the entity?
2. 秘密鍵はどのようにしてエンティティに安全に提供されますか？
3. How is the entity's public key provided securely to the certificate issuer?
3. エンティティの公開キーはどのようにして証明書発行者に安全に提供されますか？
4. If the entity is a CA (issuing or subject) how is the entity's public key provided securely to the users?
4. エンティティがCA（発行またはサブジェクト）である場合、エンティティの公開鍵はどのように安全にユーザーに提供されますか？
5. What are the key sizes?
5. 鍵のサイズは何ですか？
6. Who generates the public key parameters?
6. 公開鍵パラメーターを生成するのは誰ですか？
7. Is the quality of the parameters checked during key generation?
7. 鍵の生成中にパラメーターの品質がチェックされますか？
8. Is the key generation performed in hardware or software?
8. 鍵の生成はハードウェアまたはソフトウェアで実行されますか？
9. 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 the Version 3, X.509 certificates)?
9. キーを使用する目的、またはキーの使用を制限する目的（X.509証明書の場合、これらの目的は、バージョン3、X.509証明書のキー使用フラグにマップする必要があります）？
Requirements for private key protection need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entity, the following questions potentially need to be answered:
発行CA、リポジトリ、サブジェクトCA、RA、サブジェクトエンドエンティティについて、秘密鍵保護の要件を考慮する必要があります。これらのタイプのエンティティごとに、次の質問に回答する必要がある可能性があります。
1. What standards, if any, are required for the module used to generate the keys? For example, are the keys certified by the infrastructure required to be generated using modules complaint with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module?
1. 鍵を生成するために使用されるモジュールに必要な標準があれば、それは何ですか？たとえば、US FIPS 140-1に準拠したモジュールを使用して生成する必要があるインフラストラクチャによって認証されたキーはありますか？その場合、必要なモジュールのFIPS 140-1レベルは何ですか？
2. Is the private key under n out of m multi-person control?(18) 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人のコントロールの下にありますか？（18）はいの場合、nとmを提供します（2人のコントロールはm人のうちn人の特別なケースで、n = m = 2）
3. Is the private key escrowed? (19) 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. 秘密鍵はエスクローされますか？ （19）その場合、エスクローエージェントは誰か、エスクローされたキーの形式（例：平文、暗号化、分割キー）、およびエスクローシステムのセキュリティコントロールは何ですか？
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. Who enters the private key in the cryptographic module? In what form (i.e., plaintext, encrypted, or split key)? How is the private key stored in the module (i.e., plaintext, encrypted, or split key)?
6. 誰が暗号モジュールに秘密鍵を入力するのですか？どのような形式（つまり、プレーンテキスト、暗号化、または分割キー）ですか？秘密キーはどのようにモジュールに保存されますか（つまり、平文、暗号化、または分割キー）？
7. 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?
7. 誰が秘密鍵をアクティブ化（使用）できますか？秘密キーをアクティブにするために実行する必要があるアクション（ログイン、電源オン、PINの提供、トークン/キーの挿入、自動など）は何ですか？キーがアクティブになると、キーは無期限にアクティブになりますか、1回アクティブになりますか、または定義された期間アクティブになりますか？
8. Who can deactivate the private key and how? Example of how might include, logout, power off, remove token/key, automatic, or time expiration.
8. 秘密鍵を無効にできるのは誰ですか？ログアウト、電源オフ、トークン/キーの削除、自動、時間の有効期限などの例。
9. Who can destroy the private key and how? Examples of how might include token surrender, token destruction, or key overwrite.
9. 誰が秘密鍵を破壊できますか？トークンの降伏、トークンの破棄、キーの上書きなどの例。
Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, and subject end entities. For each of these types of entity, 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? The archival system should provide integrity controls other than digital signatures since: the archival period may be greater than the cryptanalysis period for the key and the archive requires tamper protection, which is not provided by digital signatures.
1. 公開鍵はアーカイブされていますか？もしそうなら、誰がアーカイブエージェントであり、アーカイブシステムのセキュリティ管理は何ですか？アーカイブシステムは、デジタル署名以外の整合性制御を提供する必要があります。アーカイブ期間は、キーの暗号化分析期間よりも長くなる可能性があり、アーカイブには、デジタル署名では提供されない改ざん保護が必要なためです。
2. What are the usage periods, or active lifetimes, for the public and the private key respectively?
2. 公開鍵と秘密鍵の使用期間またはアクティブなライフタイムはそれぞれ何ですか？
Activation data refers to data values other than keys that are required to operate cryptographic modules and that need to be protected. (20) Protection of activation data potentially needs to be considered for the issuing CA, subject CAs, RAs, and end entities. 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, and end entity) 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.
アクティベーションデータとは、暗号モジュールの操作に必要であり、保護する必要のあるキー以外のデータ値を指します。 （20）発行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 reuse, 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. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation related activity undertaken.
コンピューターシステムのコンピューターのセキュリティ評価が必要になる場合があります。評価は、たとえば、信頼できるシステムの評価基準（TCSEC）、カナダの信頼できる製品の評価基準、ヨーロッパの情報技術セキュリティ評価基準（ITSEC）、またはCommon Criteriaに基づく場合があります。このサブコンポーネントは、製品評価分析、テスト、プロファイリング、製品認証、および/または行われる製品認定関連のアクティビティの要件にも対応できます。
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 the following aspects of a cryptographic module: 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. Requirements may be expressed through reference to a standard such as U.S. FIPS 140-1. (27)
このサブコンポーネントは、暗号化モジュールの次の側面に対処します。暗号化モジュールの境界の識別、入力/出力、役割とサービス、有限状態機械、物理的セキュリティ、ソフトウェアセキュリティ、オペレーティングシステムのセキュリティ、アルゴリズムへの準拠、電磁気的互換性、セルフテスト。要件は、U.S。FIPS 140-1などの規格を参照して表すことができます。 （27）
This component is used to specify the certificate format and, if CRLs are used, the CRL format. Assuming use of the X.509 certificate and CRL formats, this includes information on profiles, versions, and extensions used.
このコンポーネントは、証明書の形式、およびCRLが使用されている場合はCRL形式を指定するために使用されます。 X.509証明書とCRL形式の使用を想定すると、使用されるプロファイル、バージョン、および拡張機能に関する情報が含まれます。
This component has two subcomponents:
このコンポーネントには2つのサブコンポーネントがあります。
* Certificate Profile; and
* 証明書プロファイル;そして
* CRL Profile.
* CRLプロファイル。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile):
このサブコンポーネントは、次のようなトピックに対処します（PKIXパートIプロファイルなど、別のプロファイル定義を参照することにより）。
* Version number(s) supported;
* サポートされているバージョン番号。
* Certificate extensions populated and their criticality;
* 設定された証明書の拡張とその重要度。
* Cryptographic algorithm object identifiers;
* 暗号化アルゴリズムのオブジェクト識別子。
* Name forms used for the CA, RA, and end entity names;
* CA、RA、およびエンドエンティティ名に使用される名前形式。
* Name constraints used and the name forms used in the name constraints;
* 使用される名前制約と名前制約で使用される名前形式。
* Applicable certificate policy Object Identifier(s);
* 該当する証明書ポリシーオブジェクト識別子。
* Usage of the policy constraints extension;
* ポリシー制約拡張の使用法。
* Policy qualifiers syntax and semantics; and
* ポリシー修飾子の構文とセマンティクス。そして
* Processing semantics for the critical certificate policy extension.
* 重要な証明書ポリシー拡張のセマンティクスを処理します。
This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the PKIX Part I profile):
このサブコンポーネントは、次のようなトピックに対処します（PKIXパートIプロファイルなど、別のプロファイル定義を参照することにより）。
* Version numbers supported for CRLs; and
* CRLでサポートされるバージョン番号。そして
* CRL and CRL entry extensions populated and their criticality.
* 設定されているCRLおよびCRLエントリ拡張とその重要度。
This component is used to specify how this particular certificate policy definition or CPS will be maintained.
このコンポーネントは、この特定の証明書ポリシー定義またはCPSを維持する方法を指定するために使用されます。
It contains the following subcomponents:
次のサブコンポーネントが含まれています。
* Specification Change Procedures;
* 仕様変更手順;
* Publication and Notification Procedures; and
* 公開および通知手順;そして
* CPS Approval Procedures.
* CPS承認手続き。
It will occasionally be necessary to change certificate policies and Certification Practice Statements. Some of these changes will not materially reduce the assurance that a certificate policy or its implementation provides, and will be judged by the policy administrator as not changing the acceptability of certificates asserting the policy for the purposes for which they have been used. Such changes to certificate policies and Certification Practice Statements need not require a change in the certificate policy Object Identifier or the CPS pointer (URL). Other changes to a specification will change the acceptability of certificates for specific purposes, and these changes will require changes to the certificate policy Object Identifier or CPS pointer (URL).
証明書ポリシーと認証実務声明を変更する必要がある場合があります。これらの変更の一部は、証明書ポリシーまたはその実装が提供する保証を実質的に低下させることはなく、ポリシー管理者によって、ポリシーが使用されている目的のためにポリシーを表明する証明書の許容性を変更しないと判断されます。証明書ポリシーと認証実践ステートメントへのこのような変更では、証明書ポリシーのオブジェクト識別子またはCPSポインター（URL）を変更する必要はありません。仕様に対する他の変更は、特定の目的のための証明書の受け入れ可能性を変更し、これらの変更は証明書ポリシーのオブジェクト識別子またはCPSポインター（URL）の変更を必要とします。
This subcomponent contains the following information:
このサブコンポーネントには、次の情報が含まれています。
* A list of specification components, subcomponents, and/or elements thereof that can be changed without notification and without changes to the certificate policy Object Identifier or CPS pointer (URL).
* 通知なしで、および証明書ポリシーのオブジェクト識別子またはCPSポインター（URL）を変更せずに変更できる仕様コンポーネント、サブコンポーネント、および/またはその要素のリスト。
* A list of specification components, subcomponents, and/or elements thereof that may change following a notification period without changing the certificate policy Object Identifier or CPS pointer (URL). The procedures to be used to notify interested parties (relying parties, certification authorities, etc.) of the certificate policy or CPS changes are described. The description of notification procedures includes the notification mechanism, notification period for comments, mechanism to receive, review and incorporate the comments, mechanism for final changes to the policy, and the period before final changes become effective.
* 証明書ポリシーのオブジェクト識別子またはCPSポインター（URL）を変更せずに、通知期間後に変更される可能性がある仕様コンポーネント、サブコンポーネント、および/またはその要素のリスト。証明書ポリシーまたはCPSの変更を関係者（証明書利用者、証明機関など）に通知するために使用する手順について説明します。通知手順の説明には、通知メカニズム、コメントの通知期間、コメントを受信、確認して組み込むメカニズム、ポリシーの最終変更のメカニズム、および最終変更が有効になるまでの期間が含まれます。
* A list of specification components, subcomponents, and/or elements, changes to which require a change in certificate policy Object Identifier or CPS pointer (URL)..
* 仕様コンポーネント、サブコンポーネント、要素のリスト。証明書ポリシーのオブジェクト識別子またはCPSポインター（URL）を変更する必要がある変更。
This subcomponent contains the following elements:
このサブコンポーネントには、次の要素が含まれています。
* A list of components, subcomponents, and elements thereof that exist but that are not made publicly available; (33)
* コンポーネント、サブコンポーネント、およびそれらの要素のリストですが、公開されていません。 （33）
* Descriptions of mechanisms used to distribute the certificate policy definition or CPS, including access controls on such distribution.
* 証明書ポリシー定義またはCPSの配布に使用されるメカニズムの説明（そのような配布に対するアクセス制御を含む）。
In a certificate policy definition, this subcomponent describes how the compliance of a specific CPS with the certificate policy can be determined.
証明書ポリシー定義では、このサブコンポーネントは、特定のCPSが証明書ポリシーに準拠しているかどうかを判断する方法を説明します。
This section contains a possible outline for a set of provisions, intended to serve as a checklist or (with some further development) a standard template for use by certificate policy or CPS writers. Such a common outline will facilitate:
このセクションには、チェックリストとして、または（さらに開発を進めて）証明書ポリシーまたはCPSライターが使用する標準テンプレートとして機能することを目的とした、一連の規定の可能な概要が含まれています。このような共通のアウトラインにより、以下が容易になります。
(a) Comparison of two certificate policies during cross-certification (for the purpose of equivalency mapping).
（a）相互認証中の2つの証明書ポリシーの比較（同値マッピングのため）。
(b) Comparison of a CPS with a certificate policy definition to ensure that the CPS faithfully implements the policy.
（b）CPSと証明書ポリシー定義の比較。CPSがポリシーを忠実に実装していることを確認します。
(c) Comparison of two CPSs.
（c）2つのCPSの比較。
1. INTRODUCTION
1. 前書き
1.1 Overview
1.1 概観
1.2 Identification
1.2 識別
1.3 Community and Applicability 1.3.1 Certification authorities 1.3.2 Registration authorities 1.3.3 End entities 1.3.4 Applicability
1.3 コミュニティと適用性1.3.1証明機関1.3.2登録機関1.3.3エンドエンティティ1.3.4適用性
1.4 Contact Details 1.4.1 Specification administration organization 1.4.2 Contact person 1.4.3 Person determining CPS suitability for the policy
1.4 連絡先の詳細1.4.1仕様管理組織1.4.2連絡担当者1.4.3ポリシーに対するCPSの適合性を決定する担当者
2. GENERAL PROVISIONS
2. 一般規定
2.1 Obligations
2.1 義務
2.1.1 CA obligations 2.1.2 RA obligations 2.1.3 Subscriber obligations 2.1.4 Relying party obligations 2.1.5 Repository obligations
2.1.1 CAの義務2.1.2 RAの義務2.1.3加入者の義務2.1.4依拠当事者の義務2.1.5リポジトリの義務
2.2 Liability
2.2 責任
2.2.1 CA liability 2.2.2 RA liability
2.2.1 CA責任2.2.2 RA責任
2.3 Financial responsibility
2.3 経済的責任
2.3.1 Indemnification by relying parties 2.3.2 Fiduciary relationships 2.3.3 Administrative processes
2.3.1 依拠当事者による補償2.3.2受託者関係2.3.3管理プロセス
2.4 Interpretation and Enforcement
2.4 解釈と執行
2.4.1 Governing law 2.4.2 Severability, survival, merger, notice 2.4.3 Dispute resolution procedures
2.4.1 準拠法2.4.2分離可能性、存続、合併、通知2.4.3紛争解決手順
2.5 Fees
2.5 料金
2.5.1 Certificate issuance or renewal fees 2.5.2 Certificate access fees 2.5.3 Revocation or status information access fees 2.5.4 Fees for other services such as policy information 2.5.5 Refund policy
2.5.1 証明書の発行または更新料2.5.2証明書のアクセス料2.5.3失効またはステータス情報のアクセス料2.5.4ポリシー情報などの他のサービスの料金2.5.5返金ポリシー
2.6 Publication and Repository
2.6 公開とリポジトリ
2.6.1 Publication of CA information 2.6.2 Frequency of publication 2.6.3 Access controls 2.6.4 Repositories
2.6.1 CA情報の公開2.6.2公開の頻度2.6.3アクセス制御2.6.4リポジトリ
2.7 Compliance audit
2.7 コンプライアンス監査
2.7.1 Frequency of entity compliance audit 2.7.2 Identity/qualifications of auditor 2.7.3 Auditor's relationship to audited party 2.7.4 Topics covered by audit 2.7.5 Actions taken as a result of deficiency 2.7.6 Communication of results
2.7.1 エンティティコンプライアンス監査の頻度2.7.2監査人のアイデンティティ/資格2.7.3監査人と被監査者の関係2.7.4監査の対象となるトピック2.7.5不備の結果として取られた措置2.7.6結果の伝達
2.8 Confidentiality
2.8 守秘義務
2.8.1 Types of information to be kept confidential 2.8.2 Types of information not considered confidential 2.8.3 Disclosure of certificate revocation/suspension information 2.8.4 Release to law enforcement officials 2.8.5 Release as part of civil discovery 2.8.6 Disclosure upon owner's request 2.8.7 Other information release circumstances
2.8.1 秘密にしておくべき情報の種類2.8.2秘密とは見なされない情報の種類2.8.3証明書の取り消し/一時停止情報の開示2.8.4法執行官への公開2.8.5民事発見の一環としての公開2.8.6所有者の要求に応じた公開2.8.7その他の情報公開状況
2.9 Intellectual Property Rights
2.9 知的財産権
3. IDENTIFICATION AND AUTHENTICATION (34)
3. 識別および認証（34）
3.1 Initial Registration 3.1.1 Types of names 3.1.2 Need for names to be meaningful 3.1.3 Rules for interpreting various name forms 3.1.4 Uniqueness of names 3.1.5 Name claim dispute resolution procedure 3.1.6 Recognition, authentication and role of trademarks 3.1.7 Method to prove possession of private key 3.1.8 Authentication of organization identity 3.1.9 Authentication of individual identity
3.1 初期登録3.1.1名前のタイプ3.1.2名前が意味を持つ必要がある3.1.3さまざまな名前の形式を解釈するための規則3.1.4名前の一意性3.1.5名前のクレーム紛争解決手順3.1.6商標の認識、認証、および役割3.1.7秘密鍵の所有を証明する方法3.1.8組織のアイデンティティの認証3.1.9個人のアイデンティティの認証
3.2 Routine Rekey
3.2 定期的な鍵更新
3.3 Rekey after Revocation 3.4 Revocation Request
3.3 失効後の鍵の再生成3.4失効リクエスト
4. OPERATIONAL REQUIREMENTS (34)
4. 動作要件（34）
4.1 Certificate Application
4.1 証明書申請
4.2 Certificate Issuance
4.2 証明書の発行
4.3 Certificate Acceptance
4.3 証明書の承認
4.4 Certificate Suspension and Revocation 4.4.1 Circumstances for revocation 4.4.2 Who can request revocation 4.4.3 Procedure for revocation request 4.4.4 Revocation request grace period 4.4.5 Circumstances for suspension 4.4.6 Who can request suspension 4.4.7 Procedure for suspension request 4.4.8 Limits on suspension period 4.4.9 CRL issuance frequency (if applicable) 4.4.10 CRL checking requirements 4.4.11 On-line revocation/status checking availability 4.4.12 On-line revocation checking requirements 4.4.13 Other forms of revocation advertisements available 4.4.14 Checking requirements for other forms of revocation advertisements 4.4.15 Special requirements re key compromise
4.4 証明書の一時停止と失効4.4.1失効の状況4.4.2失効をリクエストできるユーザー4.4.3失効リクエストの手順4.4.4失効リクエストの猶予期間4.4.5一時停止の状況4.4.6一時停止をリクエストできるユーザー4.4.7一時停止の手順リクエスト4.4.8一時停止期間の制限4.4.9 CRLの発行頻度（該当する場合）4.4.10 CRLチェック要件4.4.11オンライン失効/ステータスチェックの可用性4.4.12オンライン失効チェック要件4.4.13その他の形式利用可能な失効広告4.4.14他の形式の失効広告の要件の確認4.4.15キーの侵害に関する特別な要件
4.5 Security Audit Procedures 4.5.1 Types of event recorded 4.5.2 Frequency of processing log 4.5.3 Retention period for audit log 4.5.4 Protection of audit log 4.5.5 Audit log backup procedures 4.5.6 Audit collection system (internal vs external) 4.5.7 Notification to event-causing subject 4.5.8 Vulnerability assessments
4.5 セキュリティ監査手順4.5.1記録されるイベントの種類4.5.2処理ログの頻度4.5.3監査ログの保存期間4.5.4監査ログの保護4.5.5監査ログのバックアップ手順4.5.6監査収集システム（内部と外部） 4.5.7イベントを引き起こす対象への通知4.5.8脆弱性評価
4.6 Records Archival
4.6 レコードのアーカイブ
4.6.1 Types of event recorded 4.6.2 Retention period for archive 4.6.3 Protection of archive 4.6.4 Archive backup procedures 4.6.5 Requirements for time-stamping of records 4.6.6 Archive collection system (internal or external) 4.6.7 Procedures to obtain and verify archive information
4.6.1 記録されるイベントのタイプ4.6.2アーカイブの保存期間4.6.3アーカイブの保護4.6.4アーカイブバックアップ手順4.6.5レコードのタイムスタンプの要件4.6.6アーカイブコレクションシステム（内部または外部）4.6.7取得手順アーカイブ情報を確認する
4.7 Key changeover
4.7 キーの切り替え
4.8 Compromise and Disaster Recovery 4.8.1 Computing resources, software, and/or data are corrupted 4.8.2 Entity public key is revoked 4.8.3 Entity key is compromised 4.8.4 Secure facility after a natural or other type of disaster
4.8 侵害と災害復旧4.8.1コンピューティングリソース、ソフトウェア、データが破損している4.8.2エンティティの公開鍵が取り消されている4.8.3エンティティの鍵が危険にさらされている4.8.4自然災害または他のタイプの災害後の安全な施設
4.9 CA Termination
4.9 CAの終了
5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS (34)
5. 物理的、手続き的、および人的セキュリティ管理（34）
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.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 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 手続き管理5.2.1信頼できる役割5.2.2タスクごとに必要な人数5.2.3各役割の識別と認証
5.3 Personnel Controls 5.3.1 Background, 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 Contracting personnel requirements 5.3.8 Documentation supplied to personnel
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要員に提供される文書
6. TECHNICAL SECURITY CONTROLS (34)
6. テクニカルセキュリティコントロール（34）
6.1 Key Pair Generation and Installation 6.1.1 Key pair generation 6.1.2 Private key delivery to entity 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to users 6.1.5 Key sizes 6.1.6 Public key parameters generation 6.1.7 Parameter quality checking 6.1.8 Hardware/software key generation 6.1.9 Key usage purposes (as per X.509 v3 key usage field)
6.1 鍵ペアの生成とインストール6.1.1鍵ペアの生成6.1.2エンティティへの秘密鍵の配信6.1.3証明書発行者への公開鍵の配信6.1.4ユーザーへのCA公開鍵の配信6.1.5鍵サイズ6.1.6公開鍵パラメーターの生成6.1 .7パラメータ品質チェック6.1.8ハードウェア/ソフトウェアキーの生成6.1.9キーの使用目的（X.509 v3キー使用フィールドによる）
6.2 Private Key Protection 6.2.1 Standards for cryptographic module 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 entry into cryptographic module 6.2.7 Method of activating private key 6.2.8 Method of deactivating private key 6.2.9 Method of destroying private key
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.3 Other Aspects of Key Pair Management 6.3.1 Public key archival 6.3.2 Usage periods for the public and private keys
6.3 鍵ペア管理のその他の側面6.3.1公開鍵のアーカイブ6.3.2公開鍵と秘密鍵の使用期間
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.4 アクティベーションデータ6.4.1アクティベーションデータの生成とインストール6.4.2アクティベーションデータの保護6.4.3アクティベーションデータのその他の側面
6.5 Computer Security Controls 6.5.1 Specific computer security technical requirements 6.5.2 Computer security rating
6.5 コンピュータセキュリティ管理6.5.1特定のコンピュータセキュリティ技術要件6.5.2コンピュータセキュリティ評価
6.6 Life Cycle Technical Controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security ratings
6.6 ライフサイクル技術管理6.6.1システム開発管理6.6.2セキュリティ管理管理6.6.3ライフサイクルセキュリティ評価
6.7 Network Security Controls
6.7 ネットワークセキュリティコントロール
6.8 Cryptographic Module Engineering Controls
6.8 暗号モジュールエンジニアリングコントロール
7. CERTIFICATE AND CRL PROFILES
7. 証明書とCRLプロファイル
7.1 Certificate Profile
7.1 証明書プロファイル
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 policy extension
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重要な証明書ポリシー拡張のセマンティクスの処理
7.2 CRL Profile
7.2 CRLプロファイル
7.2.1 Version number(s) 7.2.2 CRL and CRL entry extensions
7.2.1 バージョン番号7.2.2 CRLおよびCRLエントリ拡張
8. SPECIFICATION ADMINISTRATION
8. 仕様管理
8.1 Specification change procedures
8.1 仕様変更手順
8.2 Publication and notification policies
8.2 公開および通知ポリシー
8.3 CPS approval procedures
8.3 CPS承認手続き
The development of this document 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 Technical Working Group. Special thanks are due to Dave Fillingham, Jim Brandt, and Edmond Van Hees for their inspiration, support, and valuable inputs.
この文書の作成は、カナダ政府の政策管理局（PMA）委員会、国家安全保障局、国立標準技術研究所（NIST）、および米国弁護士協会情報セキュリティ委員会認定技術ワーキンググループによってサポートされました。 Dave Fillingham、Jim Brandt、Edmond Van Heesのインスピレーション、サポート、貴重な情報提供に特に感謝します。
The following individuals also deserve credit for their review and input:
以下の個人もまた、レビューと入力のための信用に値します：
Teresa Acevedo, A&N Associates;
Michael Baum; VeriSign;
Sharon Boeyen, Entrust;
Bob Burger, McCarter & English;
Bill Burr, NIST;
Patrick Cain, BBN;
Michael Harrop, Government of Canada Treasury Board;
Rick Hornbeck, Digital Commerce Services;
Francois Marinier, Domus Software;
John Morris, CygnaCom Solutions;
Tim Moses, Entrust;
Noel Nazario, NIST;
John Nicolletos, A&N Associates;
Jean Petty, CygnaCom Solutions;
Denis Pinkas, Bull;
J.-F. Sauriol, Domus Software;
Robert Shirey, BBN;
Mark Silvern, VeriSign;
David Simonetti, Booz, Allen and Hamilton; and
Darryl Stal, Entrust.
Johnny Hsiung, and Chris Miller assisted in the preparation of the manuscript.
ジョニー・シウングとクリス・ミラーは原稿の準備を手伝いました。
[ABA1] American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce, 1995.
[ABA1]アメリカ法曹協会、デジタル署名ガイドライン：証明機関と電子商取引のための法的インフラストラクチャ、1995年。
[BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR- 94-654, June 1994.
[BAU1]マイケル。 S. Baum、連邦認証局の責任とポリシー、NIST-GCR- 94-654、1994年6月。
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997 edition. (Pending publication of 1997 edition, use 1993 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1996.)
[ISO1] ISO / IEC 9594-8 / ITU-T勧告X.509、「情報技術-オープンシステム相互接続：ディレクトリ：認証フレームワーク」、1997年版。 （1997年版の公開待ち、次の修正が適用された1993年版を使用：証明書拡張に関するISO / IEC 9594-8に対する修正草案DAM 1の最終テキスト、1996年6月）
[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., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[PKI1] Housley、R.、Ford、W.、Polk、W. and D. Solo、 "Internet X.509 Public Key Infrastructure、Certificate and CRL Profile"、RFC 2459、January 1999。
Santosh Chokhani CygnaCom Solutions, Inc. Suite 100 West 7927 Jones Branch Drive McLean, VA 22102
Santosh Chokhani CygnaCom Solutions、Inc. Suite 100 West 7927 Jones Branch Drive McLean、VA 22102
Phone: (703) 848-0883 Fax: (703) 848-0960 EMail: chokhani@cygnacom.com
電話：（703）848-0883ファックス：（703）848-0960メール：chokhani@cygnacom.com
Warwick Ford VeriSign, Inc. 301 Edgewater Place, Suite 210 Wakefield, MA 01880
Warwick Ford VeriSign、Inc.301 Edgewater Place、Suite 210 Wakefield、MA 01880
Phone: (781) 245-6996 x225 Fax: (781) 245-6006 EMail: wford@verisign.com
電話：（781）245-6996 x225ファックス：（781）245-6006メール：wford@verisign.com
NOTES
ノート
1 The ABA Digital Signature Guidelines can be purchased from the ABA. See http://www.abanet.com for ordering details.
1 ABAデジタル署名ガイドラインは、ABAから購入できます。注文の詳細については、http：//www.abanet.comを参照してください。
2 Examples of types of entity for subject CAs are a subordinate organization (e.g., branch or division), a federal government agency, or a state or provincial government department.
2サブジェクトCAのエンティティのタイプの例は、下位組織（支店や部門など）、連邦政府機関、または州または地方政府の部門です。
3 This statement can have significant implications. For example, suppose a bank claims that it issues CA certificates to its branches only. Now, the user of a CA certificate issued by the bank can assume that the subject CA in the certificate is a branch of the bank
3このステートメントは、重要な意味を持つことがあります。たとえば、銀行がその支店にのみCA証明書を発行すると主張しているとします。これで、銀行が発行したCA証明書のユーザーは、証明書内の対象のCAが銀行の支店であると想定できます。
4 Examples of the types of subject RA entities are branch and division of an organization.
4サブジェクトRAエンティティのタイプの例は、組織の支社と部門です。
5 Examples of types of subject end entities are bank customers, telephone company subscribers, and employees of a government department
5サブジェクトエンドエンティティのタイプの例は、銀行の顧客、電話会社の加入者、および政府部門の従業員です。
6 This statement can have significant implications. For example, suppose Government CA claims that it issues certificates to Government employees only. Now, the user of a certificate issued by the Government CA can assume that the subject of the certificate is a Government employee.
6この声明は重要な意味を持ちます。たとえば、政府CAが政府職員のみに証明書を発行すると主張しているとします。これで、政府CAによって発行された証明書のユーザーは、証明書の件名が政府職員であると想定できます。
7 Examples include X.500 distinguished name, Internet e-mail address, and URL.
7例には、X.500識別名、インターネット電子メールアドレス、およびURLが含まれます。
8 The term "meaningful" means that the name form has commonly understood semantics to determine identity of the person and/or organization. Directory names and RFC 822 names may be more or less meaningful.
8「意味のある」という用語は、名前の形式が、人や組織のアイデンティティを決定するための意味論を一般的に理解していることを意味します。ディレクトリ名とRFC 822名は多かれ少なかれ意味があります。
9 Examples of proof include the issuing CA generating the key, or requiring the subject to send an electronically signed request or to sign a challenge.
9証明の例には、キーを生成する発行CA、または電子的に署名されたリクエストを送信するか、チャレンジに署名することをサブジェクトに要求することが含まれます。
10 Examples of organization identity authentication are: articles of incorporation, duly signed corporate resolutions, company seal, and notarized documents.
10組織のID認証の例は、定款、正式に署名された企業決議、会社の印鑑、公証された文書です。
11 Examples of individual identity authentication are: biometrics (thumb print, ten finger print, face, palm, and retina scan), driver's license, passport, credit card, company badge, and government badge.
11個人の身元認証の例は、バイオメトリクス（サムプリント、10フィンガープリント、顔、手のひら、網膜スキャン）、運転免許証、パスポート、クレジットカード、会社バッジ、政府バッジです。
12 Examples include duly signed authorization papers or corporate ID badge.
12例には、正式に署名された承認書または企業IDバッジが含まれます。
13 The identification policy for routine rekey should be the same as the one for initial registration since the same subject needs rekeying. The rekey authentication may be accomplished using the techniques for initial I&A or using digitally signed requests.
13同じ対象が鍵の再生成を必要とするため、定期的な鍵の再生成の識別ポリシーは、初期登録の場合と同じでなければなりません。キー再生成認証は、初期I＆Aの手法を使用して、またはデジタル署名された要求を使用して実行できます。
14 This identification and authentication policy could be the same as that for initial registration.
14この識別と認証のポリシーは、初期登録の場合と同じにすることができます。
15 This policy could be the same as the one for initial registration.
15このポリシーは、初期登録のポリシーと同じにすることができます。
16 The identification policy for Revocation request could be the same as that for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for Revocation request. Other less stringent authentication policy could be defined.
16失効要求の識別ポリシーは、同じサブジェクト証明書を失効させる必要があるため、初期登録の場合と同じにすることができます。認証ポリシーは、サブジェクトによってデジタル署名された失効リクエストを受け入れることができます。初期登録時に使用される認証情報は、失効リクエストで受け入れられる場合があります。他の厳格でない認証ポリシーを定義できます。
17 The identification policy for key compromise notification could be the same as the one for initial registration since the same subject certificate needs to be revoked. The authentication policy could accept a Revocation request digitally signed by subject. The authentication information used during initial registration could be acceptable for key compromise notification. Other less stringent authentication policy could be defined.
17鍵の侵害通知の識別ポリシーは、同じサブジェクト証明書を取り消す必要があるため、初期登録の場合と同じにすることができます。認証ポリシーは、サブジェクトによってデジタル署名された失効リクエストを受け入れることができます。初期登録時に使用される認証情報は、キーの侵害通知に受け入れられる可能性があります。他の厳格でない認証ポリシーを定義できます。
18 The n out of m rule allows a 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 key, but having any n- 1 parts provides one with no information about the key.
18 mのうちnのルールでは、キーをmの部分に分割できます。 ｍ個の部分は、ｍ人の異なる個人に与えられてもよい。 m個のパーツのうちn個のパーツを使用してキーを完全に再構成できますが、n-1個のパーツがあると、キーに関する情報がありません。
19 A key may be escrowed, backed up or archived. Each of these functions have different purpose. Thus, a 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 legally obtain the key without the cooperation of the subject. The purpose of back up is to allow the subject to reconstitute the key in case of the destruction of the key. The purpose of archive is to provide for reuse of the key in future, e.g., use the private key to decrypt a document.
19キーはエスクロー、バックアップ、またはアーカイブできます。これらの機能にはそれぞれ異なる目的があります。したがって、キーは、要件に応じてこれらの機能のサブセットを通過する場合があります。エスクローの目的は、第三者（組織や政府など）が主体の協力なしに合法的にキーを取得できるようにすることです。バックアップの目的は、キーが破壊された場合に、サブジェクトがキーを再構成できるようにすることです。アーカイブの目的は、将来的にキーの再利用を提供することです。たとえば、秘密キーを使用してドキュメントを復号化します。
20 An example of activation data is a PIN or passphrase.
20アクティベーションデータの例は、PINまたはパスフレーズです。
21 Examples of physical access controls are: monitored facility , guarded facility, locked facility, access controlled using tokens, access controlled using biometrics, and access controlled through an access list.
21物理的アクセス制御の例は、監視対象施設、監視対象施設、ロックされた施設、トークンを使用して制御されるアクセス、生体認証を使用して制御されるアクセス、およびアクセスリストを介して制御されるアクセスです。
22 Examples of the roles include system administrator, system security officer, and system auditor. The duties of the system administrator are to configure, generate, boot, and operate the system. The duties of the system security officer are to assign accounts and privileges. The duties of the system auditor are to set up system audit profile, perform audit file management, and audit review.
22役割の例には、システム管理者、システムセキュリティ担当者、システム監査人が含まれます。システム管理者の役割は、システムの構成、生成、起動、および操作です。システムセキュリティ担当者の役割は、アカウントと特権を割り当てることです。システム監査人の職務は、システム監査プロファイルの設定、監査ファイル管理の実行、および監査レビューです。
23 The background checks may include clearance level (e.g., none, sensitive, confidential, secret, top secret, etc.) and the clearance granting authority name. In lieu of or in addition to a defined clearance, the background checks may include types of background information (e.g., name, place of birth, date of birth, home address, previous residences, previous employment, and any other information that may help determine trustworthiness). The description should also include which information was verified and how.
23バックグラウンドチェックには、認可上限レベル（なし、機密、機密、秘密、最高機密など）と認可認可機関の名前が含まれる場合があります。定義されたクリアランスの代わりに、またはそれに加えて、経歴チェックには、経歴情報のタイプ（たとえば、名前、出生地、生年月日、自宅住所、以前の居住地、以前の雇用、および決定に役立つその他の情報）が含まれる場合があります。信頼性）。説明には、検証された情報とその方法も含める必要があります。
24 For example, the certificate policy may impose personnel security requirements on the network system administrator responsible for a CA's network access.
24たとえば、証明書ポリシーは、CAのネットワークアクセスを担当するネットワークシステム管理者に要員のセキュリティ要件を課す場合があります。
25 Regardless of whether authorized persons are employees, practices should be implemented to ensure that each authorized person is held accountable for his/her actions.
25権限のある人物が従業員であるかどうかに関係なく、各権限のある人物が自分の行動に対して責任を負うようにするための慣行を実施する必要があります。
26 A cryptographic module is hardware, software, or firmware or any combination of them.
26暗号モジュールは、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせです。
27 The compliance description should be specific and detailed. For example, for each FIPS 140-1 requirement, describe the level and whether the level has been certified by an accredited laboratory.
27コンプライアンスの説明は具体的かつ詳細でなければなりません。たとえば、FIPS 140-1の要件ごとに、レベルと、そのレベルが認定ラボによって認定されているかどうかを説明します。
28 Example of audit events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, establishment of trusted roles on the CA, actions of truste personnel, changes to CA keys, etc.
28監査イベントの例は、証明書の作成の要求、証明書の失効の要求、鍵の侵害の通知、証明書の作成、証明書の失効、証明書の発行、CRLの発行、鍵の侵害CRLの発行、確立です。 CAでの信頼された役割、トラスティ担当者のアクション、CAキーの変更など。
29 Example of archive events are: request to create a certificate, request to revoke a certificate, key compromise notification, creation of a certificate, revocation of a certificate, issuance of a certificate, issuance of a CRL, issuance of key compromise CRL, and changes to CA keys.
29アーカイブイベントの例は、証明書の作成の要求、証明書の失効の要求、キーの侵害の通知、証明書の作成、証明書の失効、証明書の発行、CRLの発行、キーの侵害CRLの発行、およびCAキーの変更。
30 A parent CA is an example of audit relationship.
30親CAは監査関係の例です。
31 Example of compliance audit topics: sample check on the various I&A policies, comprehensive checks on key management policies, comprehensive checks on system security controls, comprehensive checks on operations policy, and comprehensive checks on certificate profiles.
31コンプライアンス監査トピックの例：さまざまなI＆Aポリシーのサンプルチェック、キー管理ポリシーの包括的なチェック、システムセキュリティ制御の包括的なチェック、運用ポリシーの包括的なチェック、および証明書プロファイルの包括的なチェック。
32 The examples include, temporary suspension of operations until deficiencies are corrected, revocation of entity certificate, change in personnel, invocation of liability policy, more frequent compliance audit, etc.
32例には、欠陥が修正されるまでの一時的な運用の停止、エンティティ証明書の失効、人事異動、責任ポリシーの呼び出し、より頻繁なコンプライアンス監査などが含まれます。
33 An organization may choose not to make public some of its security controls, clearance procedures, or some others elements due to their sensitivity.
33組織は、その機密性のために、そのセキュリティ制御、クリアランス手順、またはその他の要素の一部を公開しないことを選択する場合があります。
34 All or some of the following items may be different for the various types of entities, i.e., CA, RA, and end entities.
34以下の項目のすべてまたは一部は、さまざまなタイプのエンティティ、つまりCA、RA、およびエンドエンティティによって異なる場合があります。
LIST OF ACRONYMS
頭字語のリスト
ABA - American Bar Association CA - Certification Authority 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-American Bar Association CA-証明機関CPS-認定実務声明CRL-証明書失効リストDAM-修正草案FIPS-連邦情報処理標準I＆A-識別および認証IEC-国際電気標準会議IETF-インターネット技術特別調査委員会IP-インターネットプロトコルISO -国際標準化機構ITU-国際電気通信連合NIST-国立標準技術研究所OID-オブジェクト識別子PIN-個人識別番号PKI-公開鍵インフラストラクチャPKIX-公開鍵インフラストラクチャ（X.509）（IETFワーキンググループ）RA-登録Authority RFC-Request For Comment URL-Uniform Resource Locator US-アメリカ合衆国
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
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 assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。