| ネットワーク WG Request for Comments： 3647 廃止： 2527 分類： 情報提供 |
S. Chokhani |
インターネット X.509 PKI： 証明書ポリシーと認証実施フレームワーク
(Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework)
このメモの位置づけ
このメモは、インターネットコミュニティに情報提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布に制限はありません。
著作権表記
Copyright (C) The Internet Society (2003). All Rights Reserved.
要旨
本書は、CA（認証局）、ポリシー機関、および、証明書に依存しようとしている利害関係者のように、PKI における関係者のために証明書ポリシーもしくは認証実施フレームワークを書く人を支援するためのフレームワークを提供します。特に、このフレームワークは、証明書ポリシーもしくは認証実施フレームワークにおいて、潜在的に網羅される必要のある諸論点について、わかりやすい一覧を提供します。本書によって、RFC 2527 は、廃止されます。
目次
3.1. 証明書ポリシー（CP）
3.2. 証明書ポリシー（CP）の例
3.3. X.509 証明書の各フィールド
3.3.1. 証明書ポリシー拡張
3.3.2. ポリシーマッピング拡張
3.3.3. ポリシー制約拡張
3.3.4. ポリシー修飾子
3.4. 認証実施規定（CPS）
3.5. 証明書ポリシー（CP）と認証実施規定（CPS）の関係
3.6. 証明書ポリシー（CP）、認証実施規定（CPS）、合意、他の文書の関係
3.7. 規定集4.1. はじめに
4.1.1. 概要
4.1.2. 文書名と識別
4.1.3. PKI の関係者
4.1.4. 証明書の用途
4.1.5. ポリシー運用管理
4.1.6. 定義と頭字語4.3. I&A（身元確認と認証）
4.3.1. 命名
4.3.2. 初期身元検証
4.3.3. 鍵の再生成リクエストについての I&A
4.3.4. 失効リクエストについての I&A4.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. 証明書の失効と一時保留
4.4.10. 証明書状態サービス
4.4.11. 登録の終了
4.4.12. 鍵寄託と復旧4.5. マネジメントコントロール、管理的コントールおよび運用的コントロール
4.5.1. 物理的セキュリティコントロール
4.5.2. 手続的コントロール
4.5.3. 要員的コントロール
4.5.4. 監査ログ記録手順
4.5.5. 記録のアーカイブ化
4.5.6. 鍵 Changeover
4.5.7. 侵害と災害復旧
4.5.8. CA もしくは RA の廃業4.6. 技術的セキュリティコントロール
4.6.1. 鍵ペアの生成と導入
4.6.2. プライベート鍵の防護と暗号モジュールエンジニアリングのコントロール
4.6.3. 鍵ペア管理の他の局面
4.6.4. アクティべーションデータ
4.6.5. コンピュータセキュリティコントロール
4.6.6. ライフサイクルにわたるセキュリティコントロール
4.6.7. ネットワークセキュリティコントロール
4.6.8. タイムスタンプ4.7. 証明書、CRL および OCSP のプロファイル
4.7.1. 証明書のプロファイル
4.7.2. CRL のプロファイル
4.7.3. OCSP のプロファイル4.9. 他の業務事項と法的事項
4.9.1. 料金
4.9.2. 財務的責任
4.9.3. ビジネス情報の秘匿性
4.9.4. 個人情報のプライバシー
4.9.5. 知的財産権
4.9.6. 表現と保証
4.9.7. 保証の免責事項
4.9.8. 責任の制限
4.9.9. 補償
4.9.10. 期間と廃業
4.9.11. 関係者との個別通知と伝達
4.9.12. 改訂
4.9.13. 紛争解決手順
4.9.14. 準拠法
4.9.15. 適用可能な法への準拠性
4.9.16. 雑則
4.9.17. 他の条項
一般に、公開鍵証明書（以降、「証明書」）は、「（個人、組織、アカウント、デバイスもしくはサイトのような）主体によって保持される公開鍵」を、「対応するプライベート鍵を利用する主体を識別する一式の情報」に結合します。身元確認用の証明書に関する多くの場合、この主体は、証明書の「サブジェクト（subject）」もしくは「加入者（subscriber）」として知られています。しかし、2 つの例外があり、それは、デバイス（これについての加入者は、通常、そのデバイスをコントロールする個人もしくは組織体。）と匿名署名書（これについては、個人もしくは組織体の身元は、その証明書からは得られない。）です。他にも、公開鍵を（役割、肩書き、信用情報のような）主体の身元以外の主体の属性に結合する種類の証明書があります。
証明書は、証明書によって配布されるサブジェクト公開鍵と、その身元、かつ／または、その証明書中のサブジェクトの他の属性間の結合を使う必要があり、かつ、その正確性に依存する「証明書のユーザ」もしくは「信頼者」によって使われます。しばしば、信頼者は、証明書のサブジェクトからのデジタル署名を検証する主体であり、このデジタル署名というのは、電子メール、web フォーム、電子文書あるいは他のデータに関連づけられたものです。信頼者の他の例には、
が含まれる可能性があります。要するに、信頼者は、（署名検証、および／あるいは、暗号化のために）証明書中の公開鍵を使う主体です。信頼者が証明書中にあるその結合を信用できる程度は、いくつかの要因に依存します。これらの要素は、
を含む可能性があります。
X.509 v3 証明書は、「その証明書に適用される特定の（ひとつもしくは複数の）証明書ポリシー（CP）」を宣言するフィールドを含む可能性があります。[ISO1] X.509 によれば、CP は、「特定のコミュニティ、および／あるいは、共通のセキュリティ要件を有するアプリケーションのクラスへの証明書の適用可能性を示す命名された規定の集合」です。CP は、「証明書（およびその中の項目）が十分に信用に応えられるか否か」と、さもなければ、「特定のアプリケーションについて適切であるか否か」の判断を支援するために、信頼者によって使われる可能性があります。その CP 概念は、PEM（Privacy Enhanced Mail）[PEM1] のために開発され、[BAU1] において拡張されたポリシー宣言概念から発展したものです。4.9節に示された法的観点および責任の観点は、IETF PKIX WG と、デジタル署名の法的な受容性と、その受容における PKI の役割について取り組んできた ABA（American Bar Association）会員の間の協働の成果です。
CA によって、証明書を発行する際や、他に管理する際に遵守される実践についてのより詳細な記述は、当該 CA によって発行もしくは参照される CPS に含められる可能性があります。ABA（American Bar Association）の情報セキュリティ委員会（Information Security Committee）の DSG（Digital Signature Guidelines）（注 1）および情報セキュリティ委員会（Information Security Committee）の PAG（PKI Assessment Guidelines）（注 2）によれば、「CPS は、CA が証明書を発行する際に採用する実践についての宣言です。」[ABA1, ABA2] 一般に、CPS は、また、すべての証明書ライフサイクルにわたるサービス（例： 発行、管理、失効、更新または鍵の再生成）に関する実践を記述し、CPS は、他の事業、法務、技術的事項に関する詳細を提供します。CP もしくは CPS 中の条項は、契約として、PKI の関係者を拘束することも、しないこともできます。CP もしくは CPS は、それ自体が契約であるとすることができます。しかし、より卑近なことに、合意は、参照することによって、CP もしくは CPS を取り込むことができ、それゆえ、条項の一部もしくはすべてについて、合意の当事者を拘束することを試みることができます。例えば、PKI には、加入者と CA もしくは RA間の合意（「加入者の合意（subscriber agreement）と呼ばれる。）、もしくは、信頼者と CA間の合意（「信頼者との合意（relying party agreement）もしくは "RPA" と呼ばれる。）における参照によって取り込まれた CP、もしくは、（より卑近には）CPS を援用するものがある可能性があります。しかし、場合によっては、CP もしくは CPS が契約的な意義を一切もたないこともあります。PKI は、これらの CP や CPS が純粋に情報提供としての文書、あるいは開示文書となるように努める可能性があります。
本書の目的は、2 つあります。まず、本書は、CP と CPS の概念を説明し、これら 2 つの概念の差異を記述し、これらの加入者や信頼者との合意に対する関係を記述することを目的とします。次に、本書は、CP または CPS の執筆者もしくはユーザが、これらの文書を執筆したり、理解する際に支援するためにフレームワークを提供することを目的としています。特に、このフレームワークは、CP もしくは CPS を定式化する際に考慮される必要がある可能性がある要素を識別します。これ自体の目的は、特定の CP もしくは CPS を規定することにありません。さらに、本書は、 CP もしくは CPS 中に含められる必要がある、特定の要件もしくは実践に関する法的な助言もしくは推奨事項を提供することを目的としていません。（しかし、このような推奨事項は、[ABA2] にあります。）
本書の範囲は、CP（X.509 において規定されている。）もしくは CPS（DSG と PAGにおいて規定されている。）において扱われうる論点の検討にとどまります。特に、本書は、CP もしくは CPS に含めることについて考慮されるべき情報の種類を記述します。提供したフレームワークは、一般に、身元確認目的については X.509 v3 証明書フォーマットの利用を想定していますが、「題材が、その証明書フォーマットもしくは身元証明書の利用に制限されること」は意図されていません。むしろ、「このフレームワークが、他の証明書フォーマットや、将来、身元確認以外の保証目的に使われることになる可能性がある証明書に採用可能なものであること」が意図されています。
扱う範囲は、（組織体のセキュリティポリシー、システムのセキュリティポリシーもしくはデータラベル付けポリシーのような）セキュリティポリシー一般を規定することにはおよびません。さらに、本書は、特定の CP もしくは CPS を規定するものではありません。さらに、フレームワークを提供する際に、本書は、CP もしくは CPS を策定するための厳密なひな形としてではなく、CP または CPS と特定の関係があると考慮される必要がある論点を提供している柔軟性あるツールと見なされて、使われる必要があります。
本書は、「読者は、X.509、DSG および PAG に使われているような、デジタル処刑、証明書および公開鍵インフラストラクチャ（PKI）の一般的な概念になじみがある」と想定します。
本書は、下記に定義された用語を使います。：
Activation data （アクティベーションデータ）
鍵以外で、暗号モジュールを操作するために要求され、かつ、保護される必要のあるデータ値。（例： PIN、パスフレーズ、保持された分割鍵）Authentication （認証）
「個人／組織体／物が、それらが主張している存在であること」を確立する過程。PKI において、認証は、「特定の名前のもとで何かを申請したり、何かにアクセスしようとしたりする個人もしくは組織体が、実際に正当な個人もしくは組織体であること」を確立する過程である可能性がある。下記「身元確認（identification）」の定義に示されているように、この過程は、身元確認における 2 番目の過程に対応する。認証は、「個人／組織体／物が、それらが主張している存在であること」、もしくは、「メッセージもしくは他のデータが、特定の個人／組織体／デバイスから発信されたこと」を保証するセキュリティサービスを言う可能性もある。それゆえ、「メッセージのデジタル署名は、メッセージの送信者を認証する」と言われる。CA-Certificate（CA 証明書）
別の CA（認証局）によって行された CA の公開鍵についての証明書。Certificate policy (CP) （証明書ポリシー）
特定のコミュニティ、および／あるいは、共通のセキュリティ要件を有するアプリケーションのクラスへの証明書の利用可能性を示す命名されたルールの集合。例えば、特定の CP が、一定金額内の財／役務の通商の企業間取引（B to B）に携わる主体の認証への、ある種類の証明書の利用可能性を示す可能性がある。Certification path （認証パス）
（パス中の最初のオブジェクトの公開鍵と併せて、）パス中の最後のオブジェクトの公開鍵を取得する処理が可能な証明書の連鎖。Certification Practice Statement (CPS) （認証実施規定）
証明書の発行・管理・失効・更新、あるいは、鍵の再生成の際に CA が 採用している実施についての言明。CPS Summary (or CPS Abstract) （認証実施規定の要約／認証実施規定の要旨）
CA によって公表されている完全な CPS 規定の部分。Identification （身元確認／識別）
「個人もしくは組織体が本人であること」を確立する過程、すなわち、「個人もしくは組織体が、特定の個人もしくは組織体であること」を示す過程。PKI において、身元確認は、下記の 2 つの過程を言う。：
(1)
「提示された個人もしくは組織体の名前が、現実世界における個人もしくは組織体の身元に対応すること」を確立する。
(2) 「当該名前で、何かに申請したり、あるいは、何かにアクセスしようとしている個人もしくは組織体が、実際にその名前の個人もしくは組織体であること」を確立する。身元確認を求めている人物は、証明書の申請者、PKI 関係者の中で信用される役職の採用についての応募者、あるいは、CA システムへのアクセスを求める CA 運用管理者のように、ネットワークもしくはソフトウェアアプリケーションへのアクセスを求める人物である可能性がある。 Issuing certification authority (issuing CA) （（証明書）発行認証局／発行 CA）
特定の証明書において、issuing CA は、当該証明書を発行した CA である。（Subject CA も参照。）Participant （参画者／関係者）
加入者、信頼者、CA、RA、証明書一括発行機関、リポジトリサービスの提供者、もしくは、同様の主体として、PKI において役割を演じる個人または組織体。PKI Disclosure Statement (PDS) （PKI 開示規定）
CA／PKI のポリシーや規定についての重要な情報を開示することによって、CP もしくは CPS を補足する手段。PDS は、通常、関連する CP かつ／または CPS 文書によって詳細が記述される情報の開示と強調のための媒介手段である。したがって、PDS は、CP もしくは CPS を置き換えることを意図したものではない。Policy qualifier（ポリシー修飾子）
X.509 証明書内の CP 識別子を伴う可能性があるポリシーに従属する情報。このような情報は、適用可能な CPS もしくは信頼者との合意の URL を指すポインタを含むことができる。これは、また、証明書の利用条件あるいは他の法的情報を含む文言（もしくは、文言を指す番号）も含むことができる。Registration authority (RA) （登録局）
下記の機能のひとつ以上に責任を負う主体。：
- 証明書申請者の身元確認と認証
- 証明書申請の承認もしくは却下
- 特定の状況における証明書の失効もしくは一時保留の開始
- 加入者からの証明書失効あるいは一時保留のリクエストの処理
- 加入者による証明書更新あるいは鍵の再生成のためのリクエストの承認あるいは却下
しかし、RA は、証明書に署名したり、証明書を発行しない。（すなわち、RA は、CA の代理として特定の業務を代行する。）
[注意： しばしば、LSA（Local Registration Authority）という用語が、他の文書において同じ概念について使われる。]Relying party （信頼者）
「証明書、および／または、その証明書を使って検証されるあらゆるデジタル署名」に依存して行為する証明書の受領者。本書において、「証明書ユーザ」と「信頼者（relying party）」という用語は、相互に置き換え可能な用語として使われる。Relying party agreement (RPA) （信頼者との合意）
典型的には、デジタル署名の検証、もしくは、証明書の他の利用法に関する CA と信頼者間の権利・義務を確立する CA と信頼者間における合意。Set of provisions （規定集）
このフレームワーク中に記述されたアプローチを採用して、CP もしくは CPS を表現する際に使うための標準的な論点にわたる実践、および／または、ポリシーの言明の集大成。Subject certification authority (subject CA) （サブジェクト認証局／サブジェクト CA）
特定の CA 証明書として、サブジェクト CA は、自身の公開鍵がその証明書において証明されている CA である。（Issuing certification authority（証明書発行認証局）も参照。）Subscriber （加入者）
証明書が発行される者である証明書のサブジェクト。Subscriber Agreement （加入者契約）
証明書の発行と管理に関する主体の権利と義務を確立する認証局と加入者間の合意。Validation （（十分性）検証）
証明書申請の身元確認の手順。検証は、身元確認の一部であり、証明書申請の身元を確立するための身元確認を言う。
この章は、CP と CPS の概念を説明し、「加入者との合意」や「信頼者との合意」のような他の PKI 文書との関係を記述ます。他の関連する概念も、記述されます。この章と、他の章のいずれかで扱われる題材には、X.509 v3 に規定された証明書ポリシー拡張に特有なものがあります。これらの章を除いて、このフレームワークは、将来、使われる可能性がある他の証明書フォーマットに適用可能であることを意図しています。
CA が証明書を発行するとき、CA は、証明書ユーザ（すなわち、信頼者）宛に、「特定の公開鍵が特定の主体（通常は加入者でもある当該証明書のサブジェクト）の身元もしくは他の属性と結合されている」という言明を提供します。しかし、信頼者が CA による言明を信頼する程度は、信頼者、もしくは、信頼者や信頼者のアプリケーションが証明書を使う方法をコントロールもしくは調整する主体によって評価される必要があります。異なる証明書は、異なるポリシーや手順に従って発行され、それぞれのアプリケーションもしくは目的に適合するようになります。
X.509 標準は、CP を「特定のコミュニティ、かつ／または、共通のセキュリティ要件をもつアプリケーションのクラスへの証明書の適用可能性を示すルールの命名された集合」と定義しています。[ISO1] X.509 v3 証明書は、特定の適用可能な CP を示すことができ、これは、信頼者が「証明書、関連する公開鍵、もしくは、当該公開鍵を特定の目的のために使っているあらゆる検証されたデジタル署名を信用するか否か」を判断するために使われる可能性があります。
CP は、典型的には、2 つの主要な分類に分けられます。第 1 に、CP には、「特定のコミュニティにおける証明書の受容可能性を示す」ISO1] ものがあります。これらの CP は、証明書の利用法についての要件と、コミュニティのメンバーについての要件を規定します。例えば、クォリファイド証明書を発行する CA のための ETSI ポリシー要件 [ETS] のように、CP は、地理的なコミュニティのニーズに焦点を当てる可能性があります。また、この種の CP は、金融サービス [IDT] のように、特定業種のコミュニティのニーズに照準を合わせる可能性もあります。
典型的な CP の第 2 の類型は、「共通セキュリティ要件をもつアプリケーションのクラスへの証明書の適用可能性を示します」。これらの CP は、証明書についてのアプリケーションもしくは利用法の集合を識別し、「これらのアプリケーションや利用法は、一定のレベルのセキュリティを要求する」と述べます。CP は、次に、これらのアプリケーションや利用法について適切な PKI 要件を規定します。この分類に属する CP は、しばしば、関連する CP に準拠して発行される証明書に比して、証明書によって提示される一定の「保証のレベル」が適切となるように、要件を設定します。これらの保証レベルは、証明書の「クラス」もしくは「種別」に対応する可能性があります。
例えば、カナダ政府（GOC）の PMA（PKI Plicy Management Authority）は、単一文書中に 8 つの証明書ポリシーを確立しました。（4 つのポリシーが、 デジタル署名に使われる証明書についてのものであり、4 つのポリシーが、守秘性確保のための暗号化に使われる証明書についてのものです。）[GOC] これらのアプリケーションの各々について、この文書は、4 つのレベルの保証（初歩・基本・中・高）を確立します。カナダ政府（GOC）の PMA は、この文書において、一定種類のデジタル署名と暗号化の利用法を、各々、一定のセキュリティ要件と共に記述し、それらを 8 つの類型に分類しました。そして、カナダ政府（GOC）の PMA は、これらの類型ごとに PKI 要件を確立しました。これによって、各々、初歩・基本・中・高のレベルの保証を提供する 8 種類の証明書が作られました。「初歩」レベルから「高」レベルへの昇級は、セキュリティ要件の高度化と、対応する保証レベルの高度化に対応します。
CP は、「オブジェクト識別子（OID）」と呼ばれる一意の番号によって、証明書中に表現されます。その OID（もしくは、少なくとも「アーク」）を登録することができます。「アーク」は、OID の数字の初めの部分であり、特定の組織体に割り当てられたものです。その登録過程は、ISO/IEC と ITU の標準に規定された手順に従います。OID もしくは「アーク」を登録する者は、信頼者による試験のために、CP の文章を発行することもできます。あらゆる証明書は、典型的には、単一の CP を宣言するか、あるいは、おそらく少数の異なる CP が整合性をもって発行されます。このような宣言は、X.509 バージョン 3 証明書の証明書ポリシー拡張中にあります。CA が複数の CP を証明書の証明書ポリシー拡張内に記述するとき、その CA は、「当該証明書は、掲載された、いかなる CP に準拠した利用についても適切である」を宣言しています 。
また、CP は、監査、認定、もしくは、これ以外の CA の評価のための基礎を築きます。各 CA は、実施されていると認識されている、ひとつ、もしくは、複数の CP もしくは CPS に照らして監査される可能性があります。ある CA が CA 証明書を別の CA 宛に発行するとき、証明書発行 CA は、当該サブジェクト CA を信頼する根拠となる CP の集合を評価しなければなりません。（このような評価は、関連する CP に関する評価に基づく可能性があります。）そして、当該評価された CP の集合は、証明書発行 CA によって、CA 証明書中に示されます。その X.509 認証パス処理ロジックは、そのよく定義されている信頼モデルにいて、これらの CP 表示を採用します。
例示のために、「国際航空運送協会（IATA： International Air Transport Association）」が、個々の航空会社によって運用されている PKI の組み合わせによる IATA によって運用されている PKI における航空業界による利用のために、いくつかの CP の定義を行っている」と想定します。2 つの CP が規定される可能性があります。（IATA 一般目的 CP と IATA 商業用 CP。）
国際航空運送協会（IATA）の一般用 CP は、定常的な情報（例： 普段の電子メール）を防護するためや、WWW ブラウザーから一般的な情報取得目的のサーバー宛の接続を認証するために業界人によって使われる可能性があります。その鍵ペアは、商用のブラウザーのような廉価なソフトウェアに基づくシステムを使って生成・保存・管理される可能性があります。このポリシーのもとで、証明書は、IATA の協会内ディレクトリ、もしくは、会員航空会社内のディレクトリ中に従業員として掲載されていて、組織体内のネットワーク管理者宛に署名された証明書リクエストフォームを送信するあらゆる者に対して自動的に発行される可能性があります。
国際航空運送協会（IATA）の商業用 CP は、財務取引、もしくは、航空会社間の契約に基づく交換を防護するために使われる可能性があります。このポリシーのもとで、IATA は、「認定された鍵ペアが承認された暗号技術的なハードウェアトークンによって生成され、保存されること」を要求する可能性があります。証明書やトークンは、航空会社の従業員宛に支払い権限と共に提供される可能性があります。そして、これらの認可された個人には、トークンと証明書が発行される条件として、協会のセキュリティオフィスに出頭し、正統な身分証明バッジを見せ、当該トークンを防護し認可された目的にのみ使うことを要求する「加入者との合意」に署名することが要求される可能性があります。
X.509 証明書中の下記の拡張フィールドが、CP をサポートするために使われます。：
証明書ポリシーフィールドは、当該 CA が適用可能であると宣言する CP を掲げます。3.2 節において定義された IATA 一般目的ポリシーと商業用ポリシーの例を使うと、通常の航空会社従業員宛に発行された証明書は、一般目的ポリシーのオブジェクト識別子を含みます。支払い権限をもつ従業員宛に発行された証明書は、一般目的ポリシーと、商業用ポリシーの両方のオブジェクト識別子を含みます。両オブジェクト識別子を証明書に含めることは、「それらが、一般目的ポリシーか、商業用ポリシーのいずれかについて適切であること」を意味します。また、この CP フィールドは、オプションとして、各識別されたポリシーについての修飾子の値も運ぶ可能性があります。（修飾子の利用法は、3.4節において検討されています。）
認証パスを処理するとき、信頼者のアプリケーションに受容可能な CP が、パス中のすべての証明書中に、（すなわち、エンド主体証明書と同様に CA 証明書中に）存在しなければなりません。
証明書ポリシーフィールドのクリティカルフラグが立っている場合、これは、上述と同じ目的のためですが、追加的な役割も果たすものです。具体的には、これは、「当該証明書の利用法が、識別されるポリシーのひとつに制限されること」、すなわち、「その CA は、『当該証明書は、少なくとも、掲載されている CP のひとつの規定集に準拠してのみ使われなければならない』と宣言していること」を示します。このフィールドは、「当該適用可能な CP に明示されているように、当該証明書を不適切な目的に、あるいは、不適切な作法で使った信頼者によって申し立てられた被害の請求から CA を保護すること」を意図したものです。
例えば、米国内国歳入庁（Internal Revenue Service）は、納税者宛に、納税申告を保護する目的で 証明書を発行する可能性があります。内国歳入庁は、誤って悪い証明書を発行することのリスクを理解し、対応することができます。（例： なりすます者に対して発行する。）しかし、「誰かが内国歳入庁の納税申告証明書を数百万ドルの価値の営業秘密を暗号化するための基礎として使い、後にこれが、メッセージを復号できる攻撃者による暗号技術的攻撃によって、悪人の手に渡ってしまった」と想定してください。内国歳入庁は、「当該加入者と信頼者が当該証明書を濫用したこと」を示すために、当該証明書ポリシー拡張の重要度を指し示すことによって、このような状況における損害賠償請求から自身を護ることを望む可能性があります。クリティカルフラグが立てられた証明書ポリシー拡張は、そのような状況において、その CA についてのリスクを低減することが意図されたものです。
ポリシーマッピング拡張は、CA 証明書においてのみ使われる可能性があります。このフィールドは、CA が「自身のドメイン中の特定のポリシーが、当該サブジェクト CA のドメインにおいて、特定の他のポリシーと同等であると見なすことができること」を示すことができるようにします。
例えば、「相互運用可能性を確保するために、ACE 社は、相互の「ビジネス to ビジネス」の取引をセキュアにするために、相互の CA の公開鍵を横断認証することを ABC 社と合意を確立する」と想定します。さらに、「両者は、それぞれに ace-e-commerce と abc-e-commerce と呼ばれる既存の財務取引保護ポリシーをもつ」と想定します。人は、「単に 2 つのドメイン間の横断証明書を生成するだけは、必要不可欠な相互運用可能性を提供しないこと」に気付くでしょう。なぜなら、2社のアプリケーションには、それぞれの CP が設定されており、従業員証明書には、それぞれの CP があるからです。ひとつの現実的な解は、いずれかのポリシーを要求するように、すべての財務アプリケーションを再設定し、両方のポリシーをその証明書ポリシー拡張にもつように、すべての証明書を再発行することです。別の解として（これの方が運用管理者にとって容易ですが）、ポリシーマッピングフィールドを使います。このフィールドが ABC 社 CA 宛に ACE 社 CA によって発行された横断証明書に含まれている場合、これは、「ABC の財務取引保護ポリシー（すなわち、abc-e-commerce）は、ACE 社（すなわち、ace-e-commerce）のものと同等である」と見なすことができるという言明を提供できます。ABC 社宛に発行された横断証明書中のこのような言明によって、ace-e-commerce CP についてのオブジェクト識別子の存在を要求する ACE ドメイン中の信頼者のアプリケーションは、ABC ドメイン内で発行された abc-e-commerce CP についてのオブジェクト識別子を含む証明書を受容・処理・信頼することができます。
ポリシー制約拡張は、2 つのオプションとしての機能をサポートします。第1 の機能は、CA が「明確な CP の表示が認証パス中のすべての後続の証明書の中にあること」を要求できる機能です。認証パスの起点にある証明書は、信頼者によって信用されたドメインの一部となり、すなわち、CA は、すべての目的について信用されており、証明書ポリシー拡張中に特定の CP は不要と見なされる可能性があります。このような証明書は、CP の明示をもつ必要がありません。しかし、信用されたドメイン中の CA が、そのドメインの外部を認証するとき、これは、「特定の CP のオブジェクト識別子が当該認証パス中の後続の証明書中にあること」という要件を課すことができます。
ポリシー制約フィールド中の他のオプションとしての機能には、CA が認証パスにおける後続の CA によるポリシーマッピングを不能にする機能があります。ポリシーマッピングを不能にすることは、ドメイン外の者を認証するとき、賢明である可能性があります。これは、連鎖的な信用に起因するリスクをコントロールする際に支援できます。（例： ドメイン A は、ドメイン B を信用し、ドメイン B は、ドメイン C を信用するが、ドメイン A は、ドメイン C を信用することを強制されることを望まない。）
証明書ポリシー拡張フィールドは、各 CP 識別子とともに、修飾子フィールド中の追加的なポリシー従属情報を運ぶための規定をもちます。X.509 標準は、このフィールドが使われるべき目的を強制していませんし、このフィールドについての構文も規定していません。ポリシー修飾子の種別は、いかなる組織体でも登録できます。
下記のポリシー修飾子種別は、PKIX RFC 3280 [PKI1] に規定されています。：
(a) CPS ポインター修飾子は、CA によって発行された CPS、CPS の要約、RPA もしくは PDS を指すポインターを含みます。そのポインターは、URI（Uniform Resource Identifier）の形態をとります。
(b) User Notice 修飾子は、証明書の利用前に加入者と信頼者に表示されるべき文字列を含みます。その文字列は、IA5String もしくは BMPString（ISO 100646-1： 複数オクテットのキャラクタセットのサブセット）である可能性があります。CA は、当該信頼者が「適用可能な条件が開示されていること、かつ／または、受容されていること」を知らせることを要求する手順を働きかける可能性があります。 ポリシー修飾子は、一般的な CP、もしくは、修飾された CP の定義をサポートするために使われる可能性があります。基となる CP が、そのように提供する場合、ポリシー修飾子種別は、一般的なポリシーを補完するために追記される具体的なポリシーの詳細を運ぶために、証明書ごとに定義される可能性があります。
認証実施規定（CPS）という用語は、DSG と PAG によって、次のように定義されています。：
「証明書の発行の際に CA が 採用している実施についての言明。」[ABA1, ABA2]。
上記のように、CPS は、発行以外にも、証明書管理（発行とアーカイブ化を含む。）、失効、および更新もしくは鍵の再生成のようなライフサイクルにわたるサービスに関する実践を確立します。DSG において、ABA は、この定義を下記のコメントによって拡大している。：「CPS は、CA による、その信用に値するシステムの詳細と、その運用と証明書の発行のサポートにおいて、それが行う実践の宣言の形態をとることができます。・・・」この形式の CPS は、最も卑近な種類であり、長さと詳細さの程度について多様である可能性がある。
PKI によっては、徹底した詳細な実施の宣言を作成する必要がない可能性があるものがあります。例えば、当該 CA 自体が信頼者であり、既にそのサービスの性格と信用に値する程度を認識している可能性があります。セキュア化されたアプリケーションによって、侵害された場合においてもわずかのリスクしかもたらさないであろうとされる別の場合において、PKI は、大変低いレベルの保証のみを提供する証明書を提供する可能性があります。これらの場合、PKI を確立する組織体は、「加入者との合意」、「信頼者との合意」、もしくは、PKI 関係者ごとの役割に応じて、加入者の条件と信頼者の条件を組み合わせる協定を書きたい、あるいは、CA に使わせたいだけである可能性があります。このような PKI においては、その合意は、PKI 内の、ひとつ、もしくは、複数の CA によって使われる「唯一の実施の宣言」の役割を果たす可能性があります。したがって、その合意は、CPS と見なされ、そのように題名もしくは副題がつけられる可能性もあります。
同様に、詳細な CPS は、取り扱いに注意を要する、そのシステムについての詳細を含む可能性があるので、CA は、その CPS 全体は発行しないことを選ぶことができます。その代わりに、CA は、「CPS の要約（もしくは、CPS の要旨）」を発行することを選ぶことができます。その CPS の要約は、CPS から「（主体の責任、あるいは、証明書のライフサイクルの段階のように）当該 CA が PKI 内の関係者に関連すると考える規定」のみを抜粋します。しかし、CPS の要約は、攻撃者に当該 CA の運用についての有用な情報を提供してしまう可能性がある完全版 CPS のこれらの慎重を要する規定は含みません。本書を通じて、"CPS" という用語は、（指定しない限り）詳細な CPS と、CPS の要約の両方を含みます。
CPS は、自動的には契約を構成せず、自動的には PKI 関係者を契約の世界に結びつけません。ある文書が「加入者との合意」もしくは「信頼者との合意」かつ CPS であるという二重目的の役割を果たす場合、当該文書は、契約書であることが意図されており、「『加入者との合意』もしくは『信頼者との合意』は、通常、そうであると見なされる」という程度の拘束力をもつ契約を構成します。しかし、大部分の CPS は、そのような二重目的をもちません。それゆえ、大部分の場合、CPS の条項は、別個の文書が主体間の契約関係を作りだしている場合と、その文書が参照によって CPS の部分または全体を組み込んでいる場合のみ、契約条項としての拘束力をもちます。さらに、特定の PKI が（CPS 全体ではなく）CPS の要約を採用する場合、その CPS の要約は、あらゆる適切な「加入者との合意」もしくは「信頼者との合意」に入れ込まれる可能性があります。
将来、裁判所、もしくは、適用可能な制定法もしくは規定法が、「証明書自体が『（証明書ポリシー拡張や、その修飾子のような）参照によって組み込む設計がなされたメカニズムが特定の文書中にある利用条件を示す』 という程度の契約関係を発生させる能力をもつ文書であること」 を宣言する可能性があります。しかし、当面、「加入者との合意」や「信頼者との合意」には、CPS を参照によって組み込み、それによって、このような合意に各主体を拘束する条項を設けるものがある可能性があります。
3.5. 証明書ポリシー（CP）と認証実施規定（CPS）の関係 English
CP と CPS は、「公開鍵証明書が信頼されるべき程度、および、公開鍵証明書が信頼されるべき目的」の観点から信頼者が関心をもつ同じ論点に対応します。これらの主要な相違は、それらの規定の焦点の当て方にあります。CP は、様々な論点を考慮して、当該 PKI によって提起される要件および標準を規定します。換言すれば、CP の目的は、「何を関係者がしなければならないか」を確立することにあります。CPS は、対照的に、「CA および他の関係者が、一定のドメインにおいて、CP において言明されている要件に適合させるために、どのように手順やコントロールを実装するか」を言明します。換言すれば、CPS の目的は、「どのように関係者が各々の役割を果たし、コントロールを実施するか」を開示することです。
CP と CPS 間のさらなる相違点は、これら 2 つの文書が扱う範囲に関係します。CP は要件の宣言であるので、PKI の相互運用が適合しなければならない最小限の運用ガイドラインについて意思疎通するための手段として最も良く機能します。それゆえ、CP は、一般に、複数の CA、複数の組織体、あるいは、複数のドメインに適用されます。対照的に、CPS は、単一の CA もしくは単一の組織体にのみ適用され、一般的には、相互運用を容易にするための手段ではありません。
ひとつの CPS をもつ CA は、複数の CP（異なるアプリケーションの目的、かつ／または、異なる信頼者のコミュニティによって使われるもの）をサポートすることができます。また、異なる CPS をもつ複数の CA が、同一の CP をサポートする可能性があります。
例えば、連邦政府は、守秘すべき人事情報を扱うために、政府全体の CP を規定する可能性があります。その CP は、政府の PKI 中の関係者についての一般的な要件の広範な表明と、利用に適するアプリケーションの種類の表示となります。この PKI において CA を運用することを望む各省庁は、「どのように、これが当該 CP の要件に適合するか」を説明することによって、この CP をサポートする自身の CPS を書くことが要求される可能性があります。同時に、省庁の CPS は、他の証明書ポリシーをサポートする可能性があります。
CP と CPS 間のさらなる相違点は、各規定の詳細さの程度に関わります。詳細さのレベルは、CPS によって様々でしょうが、CPS は、一般に、CP よりも詳細になります。CPS は、CP 要件に適合するようにされている手順とコントロールの詳細な記述を提供する一方、CP は、より一般的です。
それゆえ、CP と CPS 間の主な相違点は、下記のように要約することができます。：
(a) PKI は、CP を「関係者が何をしなければならないか」を宣言する要件を確立するために使います。単一の CA もしくは組織体は、「どのように CP の要件に適合しているか」あるいは「どのように実践やコントロールを実施しているか」を開示するために CPS を使うことができます。
(b) CP は、横断認証、単方向認証、あるいは他の手段を通じて、相互運用を容易にします。それゆえ、これは、複数の CA を扱うことを意図されています。対照的に、CPS は、単独の CA もしくは 組織体の宣言です。その目的は、相互運用を容易にすることではありません。（なぜなら、そのようにすることは、CP の機能であるからです。）
(c) 一般に、CPS は、CP よりも詳細であり、「どのように当該 CA が、証明書を発行する際に基づく、ひとつ、もしくは、複数の CP に規定された要件に適合するか」を規定します。
証明書ポリシー拡張を適用可能な CP オブジェクト識別子とともに配置することに加えて、CA は、発行する証明書中に、その CPS への参照を含む可能性があります。CP 修飾子を使ってこれを行う標準的なやり方は、3.4 節に記述されています。
3.6. 証明書ポリシー（CP）、認証実施規定（CPS）、合意、他の文書の関係 English
CP や CPS は、PKI の要件と実施の文書化において、中心的な役割を果たします。それにもかかわらず、PKI に関する唯一の文書ではありません。例えば、「加入者との合意」と「信頼者との合意」は、証明書と鍵ペアの利用に関する加入者と信頼者の責任配分において極めて重要な役割を果たします。これらは、証明書が発行・管理・利用される条件を確立します。「加入者との合意」という用語は、PAG によって、下記のように定義されています。： 「証明書の発行と管理に関する当事者間の権利義務を確立する CA と、加入者間の合意。」[ABA2] PAG は、「信頼者との合意」を下記のように定義しています。： 「典型的には、証明書のデジタル署名、あるいは他の利用法の検証に関する当事者間の権利義務を確立する CA と信頼者間の合意。」[ABA2]
3.5 節において述べたように、「加入者との合意」、「信頼者との合意」、もしくは、加入者の条件と信頼者の条件を組み合わせた合意は、CPS としての役割も果たす可能性があります。しかし、別の PKI において、「加入者との合意」もしくは「信頼者との合意」は、参照によって、 CP もしくは CPS の条件の部分またはすべてを入れ込む可能性があります。さらに別の PKI は、CP もしくは CPS を参照によって取り込むことをせずに、CP および／または CPS から加入者が受容可能な条件を抽出し、そのような条件を自己完結した加入者との合意の中におく可能性があります。それらは、信頼者の条件を CP および／または CPS から抽出し、そのような条件を自己完結した信頼者との合意中におくために、同じ手法を使う可能性があります。このような自己完結した合意を作成することは、「消費者にとって見直しやすい文書を作成する」という優位性があります。場合によっては、加入者もしくは信頼者は、適用法のもとで、一定の法的もしくは行政的保護の対象となる「顧客」であると見なす可能性があります。民法をもつ国の法的システムのもとで、CP もしくは CPS を参照によって組み込むことは、組み込まれた CP もしくは CPS の条件に拘束するためには有効でない可能性があります。
CP や CPS は、下記のものを含む他の文書における参照によって、組み合わされる可能性があります。：
- 相互運用可能性についての合意（横断認証、単方向認証、あるいは、他の形態の相互運用のための CA の間の合意を含む。）
- ベンダーとの合意（このもとで、PKI ベンダーが CP もしくは CPS の中に規定された標準に適合させることに合意するもの。）
- PDS （[ABA2] 参照。）
PDS は、CPS の要約と同様の機能を果たします。これは、PKI もしくは CA についての重要な詳細のサブセットのみを含む比較的短い文書です。しかし、これは、単なる CPS の濃縮版とは対称的に、その目的は、PKI 全般にわたる性格について、情報の要約としての役割をはたすことにあるという点において、CPS の要約とは異なる可能性があります。
さらに、PDS の目的は、（PDS も、その役割を果たすことはできますが…）非公開の CPS 中に含まれる「セキュリティの観点から取扱いに注意を要する情報」を防護することとは対称的に、その PKI についての情報を抽出することです。
ちょうど、執筆者が、「CP もしくは CPS を参照したい」あるいは「それ（CP もしくは CPS）を契約もしくは PDS における参照によって組み込みたい」と望む可能性があるのと同様に、CP もしくは CPS は、要件を確立したり、開示するとき、他の文書を参照する可能性があります。例えば、CP は、標準的な証明書プロファイルを規定する外部文書を参照することによって、証明書の内容について、要件を設定する可能性があります。外部文書を参照することによって、CP もしくは CPS が他の文書から長文の条項を再引用する必要無しに、詳細な要件を課したり、あるいは、詳細な情報公開ができるようにします。さらに、CP もしくは CPS 中の文書を参照することは、（CPS の要約を公開することの代わりに、あるいは、それに加えて）公開情報と、セキュリティの観点から取扱いに注意を要する機密情報の開示を区別するのに有用な別の方法であるといえます。例えば、PKI は、CP もしくは CPS を発行することを望みながら、CA の高セキュリティゾーンについてのサイト構成要素（parameters）を、機密情報として維持管理することを望む可能性があります。この場合、当該 CP もしくは CPS は、詳細なサイト構成要素（についての情報）を含む外部のマニュアルもしくは文書を参照することができます。
PKI が CP もしくは CPS において参照する可能性がある文書には、以下のものがあります。：
- セキュリティポリシー
- 研修文書、運用的文書、導入文書およびユーザマニュアル類（これらは、運用的要件を含む可能性があります。）
- PKI の特性に適用される標準文書（例： PKI の中で使用されるすべてのハードウェアトークンによってなされる保護のレベルを規定する標準、あるいは、サイト構成に適用可能な標準）
- 鍵管理計画
- 人的資源ガイドと採用マニュアル（これは、要員的セキュリティ実践についての何らかの局面を記述する可能性があります。）
- 電子メールポリシー（適用可能な場合、この項目は、鍵管理についての考察のみならず、加入者と信頼者の責任についても検討できます。）[ABA2] 参照。
規定集は、下記の 第 5 章 にある論点を網羅することによって、このフレームワークに記述されたアプローチを採用した CP もしくは CPS の表現時における利用についての標準的な論点にわたる実践、かつ／または、ポリシー宣言の集大成となります。これらは、下記の第4章においても詳細に記述されています。
CP は、単一の規定集として表現できます。
CPS は、各コンポーネントが、ひとつ、もしくは、複数の証明書ポリシーの要件に対応する単一の規定集として、あるいは、代わりに、編成された規定集として表現することができます。例えば、CPS は、下記事項の組み合わせとして表現できます。：
(a) CPS によってサポートされている証明書ポリシーの一覧
(b) (a) 中の各 CP について、
ポリシー中に明記されていない事項、あるいは、明示的に（その CPS において）当該 CA の自由裁量として残されている事項を詳細を補うことによって、その CP に対応する言明を含む規定集。； このような言明は、「どのように、この特定の CPS が特定の CP の要件を実装するか」を表明する役割を果たします。(c) CP とは関係なく、当該 CA についての認証の実施に関する言明を含む規定集
(b) と (c) において提供される言明は、適用可能な CP の規定を強化したり、あるいは、洗練する可能性がありますが、一般に、そのような CP のいかなる規定とも矛盾してはなりません。しかし、場合によっては、ポリシー機関は、CP 中の要件の例外を許容する可能性があります。なぜなら、特定の CA の補償（compensating）コントロールが、CA に「当該 CP に完全準拠した CAによって提供される保証と同等の保証を提供すること」を認めている CPS 中に開示されているからです。
このフレームワークは、下記のように、規定集の内容を 9 つの主要コンポーネントに分けて概説します。：
- はじめに
- 発行とリポジトリ
- I&A（身元確認と認証）
- 証明書のライフサイクル運用的要件
- 設備、管理および運用的コントロール
- 技術的セキュリティコントロール
- 証明書、CRL および OCSP のプロファイル
- 準拠性監査
- 他の案件と法的事項
PKI は、シンプルな CP もしくは CPS を書くために、9 つの主要コンポーネントから成る、このシンプルなフレームワークを使うことができます。さらに、CA は、「加入者との合意」、「信頼者との合意」、もしくは、加入者の条件と信頼者の条件を含む合意を書くために、この同じフレームワークを使うことができます。CA は、合意を形成するために、このシンプルなフレームワークを使う場合、項目 1 を序章もしくは詳説として使うことができ、また、2 から 8 までの項目において各主体の責任を明示することができ、さらに、（下記の 4.9節 の順序に従って）ビジネスや法的な論点をより詳細に記述するために、第9章を使うことができます。（例：表明保証、無保証、および責任限定等） この単純なフレームワーク、および 4.9節 の業務および法的問題の中での事項の順序は、典型的なソフトウェアもしくは他の技術合意における論点の順序と同一（もしくは同様）です。それゆえ、PKI は、核となる文書集を（CP、CPS、「加入者との合意」および「信頼者との合意」によって） 確立することができます。これらは、すべて、同じ構成および論点の順序をもち、それによって、これらの文書間および他の PKI 関連文書間における比較および対応づけを容易にするものとなります。
このシンプルなフレームワークは、加入者契約や信頼者契約以外の契約のためにも有用である可能性があります。例えば、RA もしくは CMA（証明書 manufacturing 機関）宛に一定業務をアウトソーシングすることを望んでいる CA は、このフレームワークを RA との合意、もしくは、アウトソーシングについての合意を書くためのチェックリストとして使うことが有用であると気付く可能性があります。同様に、2 つの CA は、相互認証、単方向認証、又は他の相互運用協定を執筆するという目的に、この単純なフレームワークを使用することを望む可能性があります。
端的には、（上記の）シンプルなフレームワークの主要コンポーネントは、短い CP、CPS、加入者との合意および信頼者との合意の執筆者のニーズに適合する可能性があります。それにもかかわらず、このフレームワークは、拡張可能であり、その 9 つのコンポーネントの範囲は、総合的な CP や CPS の執筆者の要求に適合する十分な柔軟性をもつものです。具体的には、上記のコンポーネントは、項目に分割される可能性があり、項目は、複数の要素から成る可能性があります。4 章は、上記コンポーネントとその項目の内容についてのより詳細な記述を提供します。CP および CPS の執筆者には、執筆者の特定の PKI の必要性に適合させるために、4章中に述べられた項目の下に、追加的な項目を追加することが許されています。
この章は、（3.7 節において紹介した）シンプルな規定のフレームワークの内容に基づいて発展させます。この章において識別された論点は、必然的に、詳細な CP もしくは CPS に含められる論点の候補となります。
多くの論点が識別されていますが、CP もしくは CPS が、このような各論点について具体的な言明を含むことは、不可欠ではありません。むしろ、特定の CP もしくは CPS は、「特定の CP もしくは CPS imposes no 要件を定めないコンポーネント・項目・要素」あるいは「開示しないコンポーネント・項目・要素」について、「規定しない」と記述することができます。この意味において、論点の一覧は、CP もしくは CPS の執筆者によって考慮される論点のチェックリストと見なすことができます。
「たとえ『規定しない』とする場合でも、各すべてのコンポーネントおよび項目を CP もしくは CPS に含めておくこと」が推奨されます。このことは、読者に、「その論点に関する規定を「含むこと」あるいは「含まないこと」について、意図的な意思決定がなされたこと」を示します。この執筆スタイルは、不注意による論点の見落しを防ぐとともに、異なる CP・CPS の比較を容易にします。（例： ポリシーマッピング判定を行うとき）
CP において、特定のコンポーネント、項目、および／または、要素を規定しないままとし、「要求される情報は、ポリシー修飾子中に示されること、あるいは、 ポリシー修飾子が指す文書中に示されること」を規定することが可能です。このような CP は、修飾された定義であると見なすことができます。規定集は、要求されたポリシー修飾子種別を参照するか、定義する必要があり、あらゆる受容可能なデフォルト値を規定する必要があります。
このコンポーネントは、規定集を識別・紹介し、当該文書（執筆される CP か CPS のいずれか）の対象となる主体とアプリケーションの種類を示します。
この項目は、書かれる文書についての一般的な導入を提供します。この項目は、当該 CP もしくは CPS が適用される PKI の概要情報を提供するためにも使うことができます。例えば、これは、当該 PKI において、証明書によって提供される異なるレベルの保証を設定する可能性があります。当該特定の PKI の複雑性と範囲によっては、PKI についての概略的な表現が、ここで有用である可能性がります。
この項目は、当該文書について適用可能なあらゆる名前、もしくは、他の識別子（ASN.1 オブジェクト識別子を含む）を提供します。このような文書名の例として、「セキュアな電子メールについての米国連邦政府ポリシー」が挙げられます。
4.1.3. PKI の関係者（PKI Participants） English
この項目は、PKI において一定の役割を果たす主体の身元もしくは種別を記述します。：
- CA（認証局）： 証明書を発行する主体。CA に関して、証明書を発行する者は発行 CA となり、その CA 証明書を発行される者は、サブジェクト CA となる。CA は、ある組織体の CA が従属する組織内で運用される認証局に対して証明書を発行する等の階層構造を用いて組織化することができる。（例：より大きな組織体中の支店、部もしくは課等）
- RA（登録局）： エンドユーザーによる証明書申請に対して、登録・発行手続を設定し、証明書申請者の本人性確認および認証を行い、証明書に対する失効要求を開始又は処理し、さらに CA に代わって証明書の更新又は鍵更新に関する申請書を受領する主体。大きな組織体中の下位の（Subordinate）組織体は、組織全体で利用している CA に対して RA としての役割を果たす可能性があるが、RA は CA の外部者（第三者）である可能性もある。
- 加入者： CA から証明書を受領する加入者の例には、自身の CA を持つ組織の被雇用者、銀行業務又は仲買業の顧客、電子商取引を運営している組織体、企業間取引に参加している組織体および一般に対して幅広く証明書を発行している CA から証明書を受領する一般会員が含まれる。
- 信頼者： 信頼者の例には、自身の CA を有する組織の従業員で、デジタル署名付電子メールを他の被雇用者から受領する者、電子商取引サイトから品物およびサービスを購入する者、他の参加組織からの入札又は注文を受領する企業間取引を行う組織体、および、証明書を一般会員に対して発行する CA から、証明書を受領した加入者と取引を行う個人および組織体が含まれます。信頼者は、所与の PKI 中の加入者である可能性もあれば、そうではない可能性もあります。
- 証明書一括発行機関、リポジトリサービスの提供者、および、PKI 関連サービスを提供する他の主体のような他の関係者。
4.1.4. 証明書の用途（Certificate Usage） English
この項目は、下記の事項を含みます。：
- 証明書が適するアプリケーションの一覧もしくは種類（例： 電子メール、リテール取引、契約、旅行の申し込み）
かつ／または、
- 発行された証明書の利用が禁じられているアプリケーションの一覧もしくは種類。
CP もしくは CPS が異なるレベルの保証を記述している場合、この項目は、異なる保証のレベルについて適する／適さない、アプリケーション（そのもの）あるいはアプリケーションの種類を記述することができます。
4.1.5. ポリシー運用管理（Policy Administration） English
この項目は、この CP もしくは CPSの執筆、登録、維持管理および更新に責任を負う組織体の名前と郵便先住所を含みます。これは、また、連絡先担当者の名前、電子メールアドレス、電話番号、ファックス番号も含みます。実際の人間を命名する代わりに、その文書は、肩書きもしくは役職、電子メールのエイリアスおよび他の一般化された連絡先情報を指名する可能性があります。場合によっては、その組織体は、「その連絡先担当者が、（独り、もしくは、他者との組で）当該文書についての質問に回答できること」を述べることができます。
さらに、公式／非公式のポリシー決定機関が「CA は、ある PKI 中において運用すること、あるいは、他の PKI と相互運用することを許可される必要があるか否かを判断すること」について責任を負うとき、これは、当該 CA の CPS を、そのポリシー決定機関の CP に照らして適切であるとして承認することを望む可能性があります。その場合、この項目は、そのような意思決定を行う者の名前もしくは肩書き、電子メールアドレス（もしくはエイリアス）、電話番号、ファックス番号、および他の一般情報を含む可能性があります。最後に、この場合、この項目は、この意思決定を行う手順も含みます。
この項目は、文書中の頭字語の一覧と、それらの意味とともに、その文書中で使われている定義された用語についての定義の一覧を含みます。
このコンポーネントは、以下の事項に関して適用されるあらゆる条項を含みます。：
- CA、証明書一括発行機関あるいは独立したリポジトリーサービスの提供者のように PKI においてリポジトリーを運用する主体（単一もしくは複数）の身元確認
- PKI の運用、証明書、および、そのような証明書の現在の状態に関する情報を公開する PKI 関係者の責任（これは、様々な仕組みを用いて CP・CPS を公に利用できるようにする責任、および（例えばセキュリティ管理、身元証明手続又は企業秘密情報のように）その情報の取り扱いに注意を要するために、存在はするものの公に利用できない文書の章、節、項を明示する責任を含む可能性がある。）
- 情報が公表されなければならない時期、および、その発効頻度
- 公開されている情報オブジェクトについてのアクセスコントロール（CP、CPS、証明書、証明書の状態および CRL を含む。）
このコンポーネントは、証明書の発行に先立って、「CA もしくは RA に申請する者の身元、および／または、エンドユーザ証明書の他の属性を認証するために使われる手続」を記述します。さらに、このコンポーネントは、「その身元を認証することについての手続」および「CA や RA になることを希望している申請者や、PKI を運用していたり、PKI と相互運用していたりする他の主体を受容することについての基準を規定します。これは、また、「どのように鍵の再生成あるいは、失効をリクエストしている主体が認証されるか」も記述します。このコンポーネントは、特定の名前における登録商標権の認識を含む命名実践にも対応します。
この項目は、加入者の命名と身元確認に関する下記の要素を含みます。：
- X.500 の DN、RFC-822 による名前や、X.400 による名前のような、サブジェクトに割り当てられた名前の種類
- 名前は、意味を持つものにするべきか否か？（注 3）
- 「加入者は匿名又は仮名を用いることができるかどうか？」および、もしできる場合、「いかなる名前が匿名希望の加入者に割り当てられ、使用されうるのか？」
- （X.500 標準および RFC-822 のような）種々の名前形式を解釈するための規則
- 名前は、一意であるべきか否か？
- 認識、識別および商標の役割
この項目は、各サブジェクト種別（CA、RA、加入者、または、他の関係者）のついて、初回登録のため I&A 手順のために下記の要素を含みます。：
- サブジェクトが登録された公開鍵に対応するプライベート鍵を所持していることを証明しなければならない場合と、その方法
（例： 証明書要求メッセージにデジタル署名をつけること等）
- 加入者又は関係者（CA、RA、（組織体に対して発行された証明書若しくは組織体によって管理された機構を使うという意味での）加入者又は他の関係者）の組織的本人性に関する本人性確認および認証の要件（例：組織体を識別するデータベースサービスを利用すること、あるいは、組織体の定款を検証すること）
- 個人加入者について、(CA、RA、組織体に対して発行された証明書、もしくは、組織体によって管理された機構を使うという意味における加入者や他の関係者等の)組織的加入者、もしくは、その代理についての下記の事項を含む I&A 要件。 ：
- 文書類の種類、および／または、要求される身元を保証する書類の数
- どのように CA もしくは RA が、提供された書類又は保証書に基づいて、組織体または個人を本人認証するか？
- 個人が認証行為を行う CA または RA に出頭しなければならないか？
- 法人組織に属する者として個人を認証する方法（例： 適式に署名された許可書または法人組織のIDバッヂ）
- 初回登録の際に検証しない加入者情報のリスト（これは、 ｢検証しない加入者についての情報｣と呼ばれる。）
- 権限の正当性確認は、「（『ある組織体に代わって証明書を取得するための行為を行うことに対する許可』を含む）特定の権利、資格あるいは許可を有しているか否か？」の判断を含む。
- 「ある PKI において運用すること」あるいは「ある PKI と相互運用すること」を望んでいる CA からの申請の場合、この項目は、「その運用もしくは相互運用のために当該 CA が適合しているか否か？」について、PKI、CA またはポリシー決定機関が判断する基準を含む。このような相互運用は、相互認証／単方向認証／相互運用の他の形態を含む可能性がある。
4.3.3. 鍵の再生成リクエストについての I&A English
この項目は、各サブジェクト種別（CA、RA、加入者、および他の関係者）のための鍵の再生成についての I&A 手順のための下記の要素に対応します。：
- （新しい鍵を含み、現行の有効な鍵を使って署名されている鍵の再生性リクエストのような）鍵の再生成についての I&A 要件。
- 証明書の失効後の鍵の再生成についての I&A 要件。一例として、初回の本人性検証と同じ手続を行うことが挙げられます。
4.3.4. 失効リクエストについての I&A English
この項目は、サブジェクト種別（CA、RA、加入者、および他の関係者）ごとに失効リクエストについての I&A 手順を記述します。例示には、対となる公開鍵が失効される必要があるプライベート鍵でデジタル的に署名された失効リクエストと、デジタル的に署名された RA によるリクエストが含まれます。
このコンポーネントは、 証明書のライフサイクルに関して、証明書発行 CA、サブジェクト CA、RA、加入者もしくは他の関係者について提起される要件を規定するために充てられます。
各項目において、サブジェクト CA、RA、加入者および他の関係者について、別個の考慮がなされる必要がある可能性があります。
この項目は、証明書申請に関する下記の要件に対応するために充てられます。：
- 証明書のサブジェクトもしくは RA のように、証明書申請できる者
- 証明書申請書を提出するためサブジェクトによって行われる登録・発行手続、および、この手続に関する責任。この過程の一例として、対象者が鍵ペアを生成し、RA 宛に証明書要求（certificate request）を送ることが挙げられる。その RA は、そのリクエストを検証して署名し、それを CA 宛に送ります。CA もしくは RA は、CA または RA は、証明書申請書を受け取るため、登録・発行手続を確立する責任を負う可能性があります。同様に、証明書申請は、その証明書申請書上に正確な情報を提供する責任を負う可能性があります。
この項目は、証明書申請処理についての手順を記述するために充てられます。例えば、証明書発行 CA と RA は、当該証明書申請の妥当性を検証するために I&A 手順を行う可能性があります。このような手順に従って、当該 CA もしくは RA は、おそらく何らかの枠組みに基づいて、その証明書申請を承認することもあれば、却下することもあります。最後に、この項目は、CA および／または RA が証明書申請を受理し、処理しなければならない期限を設定します。
この項目は、証明書の発行に関する下記の項目を記述するために充てられます。：
- 証明書の発行中に、CA が行う行為。（例： CA が RA の署名および登録局の権限を検証し証明書を発行する手続等）
- 証明書の発行を加入者に知らせるために CA によって使われる通知メカニズムがあれば、記述する。（例： CA が加入者もしくは RA 宛に証明書を電子メールで送る方法、あるいは、加入者に Web サイトから証明書をダウンロードすることが許可されたという情報を電子メールで送る方法）
この項目は、以下の事項に対応します。：
- 証明書の受領が成立したと見なされる申請者の行為。このような行為は、「受領を明示する肯定的な処置」、「受領確認を暗示する行動」もしくは「証明書（もしくはその内容）に異議を唱えないこと」を含む可能性があります。（例： 「CA がある一定の期間内に加入者から何ら通知を受け取らない場合、受領確認が生じたとみなすことができること」、「加入者が証明書を受領確認する旨の署名付メッセージを送ることができること」または「加入者は、証明書を拒否する理由を含み、証明書内の不正確もしくは不完全な箇所を特定するような当該証明書を拒否する旨の署名付メッセージを送ることもできること」等）
- 当該 CA による当該証明書の公開（例：その CA は、当該証明書を X.500 もしくは LDAP のリポジトリに登録する可能性がある。）
- 当該 CA による他の主体宛の証明書発行の通知。（例： その CA は、証明書を RA 宛に送付する可能性がある。）
この項目は、以下の事項を含めて、鍵と証明書の利用に関する責任を記述するために充てられます。：
- 加入者のプライベート鍵と証明書の使用に関する加入者の責任。（例： 「CPに示され、適用すべき証明書の内容（鍵用途fフィールド）と一致するような適切なアプリケーションに対してのみプライベート鍵と証明書を使用することを加入者に対し要求できること」、「プライベート鍵と証明書の使用が加入者協定の条件を遵守していること、加入者が対応する証明書を受領確認した後のみプライベート鍵の使用が許可されること」または「加入者が証明書の終了又は失効に従ってプライベート鍵の使用を中止しなければならないこと」）
- 加入者の公開鍵と証明書の利用に関する信頼者の責任。（例：信頼者には、「CPに定められ、適用すべき証明書の内容（鍵用途フィールド）と一致するような適切なアプリケーションについてのみ証明書を信頼すること」、 「CP・CPSに示され、要求又は許可された方法のひとつを使用して証明書のステイタスを確認する責任(下記4.4.9を参照)を証明書を信頼することの条件として、公開鍵運用を適切に行うこと」および「適用すべき信頼者協定の条件に同意することを義務づけられる可能性がある。
4.4.6. 証明書の更新（Renewal） English
この項目は、証明書の更新に関する下記の事項を記述するために充てられます。証明書の更新は、「加入者宛に、加入者または他の関係者の公開鍵、あるいは、証明書中の他のあらゆる情報を変更することなく、新しい証明書を発行すること」を意味します。：
- 証明書の更新が発生する状況において（例： 証明書の期限は終了したが、同じ鍵ペアの再使用をポリシーが認めるような場合）
- 「誰が証明書の更新を要求する可能性があるか？」（例： 加入者、RA。あるいは、CA は、エンドユーザーたる加入者の証明書を自動的に更新する可能性がある。）
- 新しい証明書を発行する更新要求（renewal requests ）を処理する CA もしくは RA の手順（例：「加入者を再認証するためにトークン（パスワード等）を利用する」あるいは「初回の証明書発行と同じ手続をとる」）
- 加入者宛の新しい証明書の通知
- 証明書の受領を構成する行為
- CA による証明書の発行
- CA による他の主体宛の証明書発行の通知
この項目は、新しい鍵ペアを生成して、（新しい公開鍵を認定する）新しい証明書が発行されることについて適用する、加入者もしくは他の関係者に関する下記の要素を記述するために充てられます。：
- 鍵更新を行いうる又は行わなければならない場合（例： 「鍵の危殆化や証明書の期限切れによって証明書が失効された後」または「鍵ペアの使用期間も満了した後」）
- 誰が証明書の鍵の再生成を要求できるか？（例： 加入者）
- 新しい証明書を発行するための鍵更新申請を処理する CA もしくは RA の手続（例：初回の証明書発行と同じ手続）
- 新しい証明書の加入者宛の通知
- 証明書の受領に関する行為
- CA による証明書の公表
- 他の主体宛の CA による証明書発行の通知
この項目は、加入者の公開鍵以外の証明書の中にある情報の変更に起因する新しい証明書（注 6）の発行に関する下記の要素を記述するために充てられます。：
- 証明書の変更が行われうる状況について（例：名前の変更、役職の変更、DN の変更となる組織の再編）
- 誰が、証明書の変更を申請することができるか？（例：加入者、人事部または RA）
- 新しい証明書を発行するための変更申請を処理する CA または RA の手続（例：初回の証明書発行と同じ手続をとる）
- 加入者に対する新しい証明書の通知
- 証明書の受領を成立させる行為
- CA による証明書の公開
- CA による他の主体宛の証明書発行の通知
この項目は、下記の事項に対応します。：
- 「証明書を保留される可能性がある状況」および「証明書を失効させなければならない状況」（例：「加入者の雇用期間の終了」、「暗号技術的なトークンの紛失」またはプ「ライベート鍵危殆化の懸念」）
- 誰が関係者の証明書失効を要求できるか？（例： エンドユーザーたる加入者の証明書の場合、加入者、RA または CA）
- 証明書の失効要求に使用される手続（例： 「RAからのデジタル署名付メッセージ」、「加入者からのデジタル署名付メッセージ」あるいは「RA からの電話」）
- 加入者が失効要求を行わなければならない猶予期間
- CA が失効要求を処理しなければならない期間
- 信頼者が信頼しようとする証明書の状態をチェックするため使用することができる（または、使用しなければならない）メカニズムがあれば、そのメカニズム。
- CRL メカニズムが使われている場合、その発行頻度
- CRL メカニズムが使われている場合、CRL の生成とその CRL がリポジトリーへ届く間の発行サイクルの最長周期（すなわち、CRL が生成された後、CRL がリポジトリーで公開されるまでの最大限の処理遅延および通信遅延）
- オンラインで失効状態をチェックすることができる可能性（例：状態についての問い合わせることができる OCSP や Web サイト）
- 信頼者が失効状態チェックを行うことについての要件
- 利用可能な失効公告の他の形態
- 一時保留または失効がプライベート鍵の危殆化の結果であることについて、上記の規定に関するあらゆる変更（一時保留又は失効が他の理由で生じた場合と対比して）
- 証明書が一時保留にされる可能性がある状況
- 誰が、証明書の一時保留を要求することができるか？（例： 加入者、人事部、加入者の管理者、あるいは(エンドユーザーたる加入者の証明書の場合には)RA）
- 証明書の一時保留を要求する手続（例： 加入者もしくは RA からの電子的署名付メッセージ、または RA からの電話）
- 一時保留とし続けることができる期間
この項目は、依存者が利用可能な証明書状態確認サービスに対応し、下記サービスを含みます。：
- 証明書の状態確認サービスの運用上の特徴
- このようなサービスの利用可能性、および、利用不能状態において適用される可能性のあるあらゆるポリシー
- このようなサービスの、あらゆるオプションとしての機能
この項目は、加入者によって CA サービスへの登録を終了するために行われる手順に対応し、下記手順を含みます。：
- 登録の終了時における証明書の失効。（これは、「その登録の終了が、当該証明書の期限切れによるものであるか、あるいは、サービスの打ち切りによるものであるか」によって異なる可能性があります。）
この項目は、寄託、かつ／または、（CA もしくは他の信用できる第三者を通じて）プライベート鍵寄託サービスが利用可能な場合に、プライベート鍵の復旧に関するポリシーと実践を識別するために、下記の要素を含みます。：
- プライベート鍵の寄託と復旧のポリシーと実践、もしくは、このようなポリシーや実践のリストを含む文書を識別すること
- セッション鍵のカプセル化および復旧のポリシーと実践（あるいは、このようなポリシーと実践の一覧）を含む文書の識別
4.5. マネジメントコントロール、運用的コントロールおよび物理的コントロール English
このコンポーネントは、鍵生成、サブジェクトの認証、証明書発行、証明書失効、監査およびアーカイブ化の機能をセキュアに行うために、証明書発行 CA によって使われる非技術的なセキュリティコントロール（すなわち、物理的、手続的および要員的なコントロール）について記述します。
このコンポーネントは、リポジトリ、証明書発行 CA、RA、加入者および他の関係者のついての非技術的なセキュリティコントロールを規定するためにも充てられます。サブジェクト CA、RA、加入者および他の関係者について、非技術的セキュリティコントロールは、同様である／類似する／全く異なる可能性があります。
これらの非技術的なセキュリティコントロールは、証明書を信用するために、極めて重要です。なぜならば、セキュリティの欠如は、CA の運用を侵害し、例えば、証明書の誤作成、もしくは、間違った情報をもつ CRL、もしくは、CA のプライベート鍵の危殆化をもたらす可能性があるからです。
各項目中において、一般に、各主体の種別（すなわち、発行 CA、リポジトリ、被発行 CA、RA、加入者および他の関係者）について、別個の考慮がなされる必要があります。
4.5.1. 物理的セキュリティコントロール English
この項目において、当該主体のシステムを格納する施設についての物理的コントロールが記述されます。対応される論点には、下記事項が含まれる可能性があります。：
- 立地場所および構造（例：ハイセキュリティゾーンに要求される構造、ならびに、施錠された部屋、檻、金庫および仕切りの使用等）
- 物理的アクセス（すなわち、施設のある箇所から他の箇所へのアクセス、または、ハイセキュリティゾーンへのアクセスを制御する機構）。（例： 「警備員またはセキュリティ対策警報機によって監視された安全なコンピュータールームの中に CA の運用施設が置かれること」、「トークン、バイオメトリック読取装置、および／または、アクセス管理一覧表を使用して区画から区画への移動を完了させることを要求すること」）
- 電源および空調
- 浸水
- 火災予防および防火
- メディアの保管場所（例： 物理的にセキュアであり、火災や水害から防護された別の場所に、バックアップ用のメディアの保管場所を要求すること。）
- ごみの廃棄
- 施設外のバックアップ
この項目において、信頼できる役割と認識されるための要件が、各役割についての責任と共に記述されます。信頼できる役割の例には、システム運用管理者、セキュリティ責任者およびシステム監査人が含まれます。
識別された各タスク（課業）については、そのタスクを遂行するために要求される数多くの個人（n out m ルール）が、各役割について記述される必要があります。各役割についての身元確認と本人認証の（I&A 要件も規定される可能性があります。
このコンポーネントは、同一人物によっては遂行できない役割に関する職務分轄についても含みます。
4.5.3. 要員的セキュリティコントロール English
この項目は、下記の事項に対応します。：
- 人員が信頼される役割又は他の重要な役割を果たす条件として有すべき資格、経験および資格証明。（例：これらの役割の志願者を雇用する前に有すべき推薦状、職務経歴および公式の政府による身分証明）
「信頼されるべき役割（ trusted roles）」や（おそらくは）他の重要な役割を補充する人員を雇用することに関して必要とされる経歴の調査および身分証明手続（例：特定の者の雇用を決定した後に関係者が行う犯罪記録、推薦状および追加の身分証明について信頼される人員が受ける調査を行うという要件）
- 人員の雇用に伴う役割ごとの研修要件および研修手順
- 初期研修終了後の役割ごとのあらゆる再研修期間および再研修手順
- 様々な役割間における仕事のローテーションの頻度および順序
- *「関係者に説明責任を課すために認められていない行動」、「CA の濫用」および「主体のシステムを認可されていないのに利用した者に対する制裁」
当該主体の被雇用者以外の独立した契約者の人員についての統制（例：下記）
- 契約要員ついての保証要件
- 契約要員の行為による損害に対する補償を含む契約要件
- 契約要員の監査および監視
- 契約要員についての他の管理
- 初期研修、再研修、または、その他の研修期間における人員への資料の提供
この項目は、セキュアな環境を維持管理するために実装されるイベントログ記録と監査のシステムについて記述するために充てられます。要素には、下記の事項が含まれます。：
- 記録されるイベントの種類。（例：証明書ライフサイクルの運用、システムへアクセスしようとする試みおよびシステムになされた要求等）
- 監査ログが処理又は保管される頻度（例：毎週、「アラームもしくは異常な事件が起きた後」あるいは「監査ログが n% 蓄積されたとき」）
- 監査ログが保管される期間
- 監査ログの保護：
- 誰が、監査ログ見ることができるか？（例： 監査管理者のみ）
- 監査ログの改変に対する防護（例： 「誰も監査ログを変更若しくは削除することができない」あるいは「監査ログ管理者のみが、監査ファイルを交換する作業の一部として監査ファイルを削除することができる」とする要件）
- 監査ログの削除防止策
- 監査ログのバックアップ手順
- 監査ログ累積システムは、主体に対して内部的なものか、あるいは、外部的なものか？
- 監査が必要となるイベントを引き起こしたサブジェクトへ監査活動について通告されるか否か？
- 脆弱性評価（例： システムのセキュリティを侵害する試みを識別するツールを監査データに適用する。）
この項目は、一般的な記録アーカイブ化ポリシー（もしくは、記録の保存ポリシー）を記述するために充てられ、下記事項を含みます。：
- アーカイブ化される記録の種類（例： すべての監査データ、証明書申請情報および証明書申請をサポートする文書類）
- アーカイブについての保存期間
- アーカイブの防護：
- 誰がアーカイブを見ることができるか？（例： 「監査責任者のみが、アーカイブを見ることができる」という要件）
- アーカイブの変更に対する防止策（例： 一度しか書くことができないメディアにデータをセキュアに保存すること）
- アーカイブの削除に対する防止策
- アーカイブが保存されるメディアの品質低下に対する防止策（例：新しい媒体へと定期的に移行すべきデータについての要件）
- ハードウェア、オペレーティングシステムその他のソフトウェアの陳腐化に対する防止策（例：長期間にわたって保存された記録へのアクセスを認めて利用を許可するために、アーカイブの一部としてハードウェア、オペレーティングシステム、その他のソフトウェアの一部を保存することによる。）
- アーカイブバックアップ手順
- 記録のタイムスタンピングについての要件
- アーカイブ集積システムは、内部的／外部的のいずれか？
- アーカイブの情報を入手し、検証する手続（例： 「アーカイブの 2つの別々のコピーは、2人の別々の人の管理下で保管されるという要件」および「アーカイブの情報が正確であるとの確証を得るために 2つのコピーを比較するという要件」）
この項目は、新しい公開鍵を CA による re-key に伴う CA のユーザ宛に提供する手順を記述します。これらの手順は、現行の鍵を提供する手順と同様である可能性があります。また、その新しい鍵は、古い鍵を使って署名された証明書において認定される可能性があります。
この項目は、侵害もしくは災害の時における通知と復旧の手順に関する要件を記述します。下記事項の各々は、別々に対応される必要がある可能性があります。：
- 適用可能な事故および危殆化の報告手続および取扱手続についての識別または一覧化
- コンピューターの資源、ソフトウェア、かつ／又は、データが破損した（あるいは破損のおそれがある）場合に用いられる復旧手続。これらの手順は、
「セキュアな環境がどのように再構築されるか？」、「どの証明書が失効しているか？」、「主体の鍵は、失効されているか否か？」、「主体の新しい公開鍵は、どのように利用者へ提供されるのか？」および「サブジェクトがどのように再認証されるのか？」ということについて述べる。
- 主体の鍵が危殆化された場合に用いられる復旧手続。これらの手続は、「セキュアな環境が、どのように再構築されるのか？」、「主体の新しい公開鍵は、どのように利用者へ提供されるのか？」および「サブジェクトはどのように再認証されるのか？」ということについて記述する。
- 自然災害又（あるいは、他の災害）の後、事業継続を保証する主体の能力。
このような能力は、運用を復旧させることができる遠隔ホットサイトの利用を含む可能性がある。その能力は、また、自然災害（あるいは他の災害）に続く間でセキュアな環境が元の場所（あるいは遠隔地）に再構築される前に、その施設を安全に保護しておく手続
も含む可能性があります。（例： 地震被災地から取り扱いに注意を要する材の盗難に対して防護する手順）
この項目は、廃業と、CA もしくは RA の廃業通知についての手順に関する要件を記述し、CA と RA のアーカイブの記録のカストディアンの身元を含みます。
このコンポーネントは、発行 CA によって、その暗号技術的鍵とアクティべーションデータを防護するために行われるセキュリティ手段（例： PIN、パスワード、あるいは、マニュアル的に保持されている共有鍵）を規定するために充てられます。このコンポーネントは、リポジトリ、サブジェクト CA、加入者や他の関係者が、そのプライベート鍵や重要なセキュリティパラメータについてのアクティべーションデータを防護ために制約を課すためにも使われる可能性があります。セキュアな鍵管理は、「すべての秘密鍵（プライベート鍵）および活性化（activation）データが防護され、認可された者によってのみ使われること」を確保するために極めて重要です。
このコンポーネントは、証明書発行 CA によって、鍵生成、ユーザ認証、証明書の登録、証明書の失効、監査およびアーカイブ化の機能をセキュアに行うために使われる他の技術的セキュリティコントロールについても記述します。技術的なコントロールは、ライフサイクルセキュリティコントロール（ソフトウェア開発環境のセキュリティ、信用できるソフトウェア開発手法を含む。）と運用的なセキュリティコントロールを含みます。
このコンポーネントは、リポジトリ、サブジェクト CA、RA、加入者および他の関係者についての他の技術的なセキュリティコントロールを定義するのに充てることもできます。
鍵ペアの生成と導入は、証明書発行 CA、リポジトリ、サブジェクト CA、RA および加入者について考慮される必要があります。これらの主体の種別ごとに、下記の問いが、潜在的に答えられる必要があります。：
- 「誰がその主体の公開鍵・プライベート鍵の鍵ペアを生成するのか？（可能性としては加入者、RA もしくは CA が考えれれる。）」、また、「どのように鍵生成が行われたか？」、「鍵生成は、ハードウェアによって行われるのか？あるいは or ソフトウェアによって行われるのか？」
- どのようにプライベート鍵は、主体宛にセキュアに提供されるのか？（可能性としては、 「主体がプライベート鍵を生成し、それゆえ既にプライベート鍵をもっている場合、プライベート鍵を主体に物理的に手渡す状況」、「プライベート鍵をトークンに含めてセキュアに郵送する状況」あるいは「SSLセッションを使ってプライベート鍵を引き渡す状況」がある。）
- どのように主体の公開鍵が CA へセキュアに提供されるか？（可能性として、オンライン SSL セッションまたは RA の署名付きメッセージを利用することが挙げられる。）
- 発行 CA に関して、RA の公開鍵がどのように潜在的信頼者へセキュアに提供されるか？（可能性として、「公開鍵を信頼者本人へ直に手渡す方法」、「信頼者へコピーを物理的にセキュアに郵送する方法」あるいは「SSL セッションを使って公開鍵を引き渡す方法」が考えられる。）
- その鍵長は？（例：1,024 bit の RSA モジュールおよび 1,024 bit の DSA 素数等）
- 「誰が公開鍵のパラメータを生成するのか？」そして、「鍵生成において、パラメータの品質は、チェックされるか？」
- 「何の目的で、その鍵は使われる可能性があるのか？」あるいは「どのような目的で鍵用途は制限される必要があるのか？」（X.509 証明書について、これらの目的は、X.509 v3 証明書中の鍵用途フラグに対応させる必要がある。）
4.6.2. プライベート鍵の防護と暗号モジュールエンジニアリングコントロール English
プライベート鍵防護と暗号モジュールについての要件が、証明書発行 CA、リポジトリ、サブジェクト CA、RA および加入者について、考慮される必要があります。これらの主体のそれぞれについて、下記の問いが、潜在的に答えられる必要があります。：
- どのような標準が、鍵を生成するために使われる暗号モジュールに要求されるか？（そのような標準が、ある場合。）暗号モジュールは、ハードウェア、ソフトウェア、ファームウェア又はそれらの組み合わせから構成することができます。（例：「基盤によって認証された鍵は、米国FIPS 140-1に準じたモジュールを使って生成しなければならないの？。」その場合、「モジュールの要求されたFIPS 140-1のレベルは何か？」、「（暗号モジュールの境界、インプット/アウトプット、役割およびサービス、有限状態機械、物理的セキュリティ、ソフトウェアセキュリティ、OS セキュリティ、アルゴリズムの準拠性、電磁的互換性、自己テスト等の）暗号のモジュールに関連する他のエンジニアリング（あるいは他の）コントロールは、存在するか否か？ 」）
- 「プライベート鍵は、『ｍ 人中の ｎ 人（"n out of m"）』による複数人の管理下におかれるのか？」yes である場合、n および m を規定します。（2人による管理は、n=m=2 となり、"n out of m"の特別な場合です。） （注 7）
- 当該プライベート鍵は、寄託されているか？（注 8）その場合、「寄託機関となるのは何者か？」、「どのような形式(例：平文、暗号化されたもの、分割鍵)で鍵は寄託されるか？」 、「エスクローシステムにおけるセキュリティ管理は、どのようなものか？」
- 「当該プライベート鍵は、バックアップされているか？」その場合、「誰がバックアップエージェントであるのか？」、「どのような形式(例：平文、暗号化されたもの、分割鍵)を用いて鍵のバックアップは、行われるか？」、「バックアップシステムのセキュリティコントロールは、どのようなものか？」
- 「当該プライベート鍵は、アーカイブされるのか？」、その場合「アーカイブ機関となるのは、何者か？」、「どのような形式(例：平文、暗号化されたもの、分割鍵)で鍵はアーカイブされるのか？」、「アーカイブシステムのセキュリティコントロールは、どのようなものか？」
- 「どのような場合に、プライベート鍵を暗号モジュールの中へ又は暗号モジュールから転送することができるか？」、「このような運送作業を行うことが許可されているのは誰か？」、「 その移行中に、プライベート鍵はどのような形式(例：平文、暗号化されたもの、分割鍵)の中におかれるか？」
- どのようにプライベート鍵は、モジュール中に保管されるか？(すなわち、平文、暗号化されたもの、分割鍵)
- 「誰がプライベート鍵をアクティベート（利用）できるか？」、「プライベート鍵を活性化させるためにどのような行為が行われなければならないか？」（例：ログイン、電源を入れる、ＰＩＮを入力する、トークン／鍵を差し込む、自動的に等）、「一旦、鍵がアクティベートされたら、永久に鍵を使えるのか？」、「一度きりしか使えないのか？」あるいは「定義された期間のみ使えるのか？」
- 誰が、どのようにプライベート鍵を非活性化しうるのか？（プライベート鍵を非活性化する方法の例：ログアウト、「電源を切る」、「トークン／鍵を取り外す」、「自動的に非活性化する」および「時間切れ」）
- 誰が、どのようにプライベート鍵を破棄することができるか？（プライベート鍵の破壊方法の例：トークンの解約、トークンの破棄および鍵の上書き）
- 暗号モジュールの能力を下記の領域の中に定める。： 「暗号モジュールの境界」、「インプット／アウトプット」、「役割およびサービス」、「有限状態機械」、「物理的セキュリティ」、「ソフトウェアセキュリティ」、「OS セキュリティ」、「アルゴリズムの準拠性」、「電磁気の互換性」および「自己検証の認識」。能力については、米国 FIPS 140-1、関連レベルおよび格付け評価等の標準への準拠性を参照することによって記述される可能性がある。
鍵管理の他の観点が証明書発行 CA、リポジトリ、サブジェクト CA、RA、加入者、および他の関係者について考慮される必要があります。これらの主体の各々について、下記の問いが、潜在的に答えられる必要があります。：
1. 当該公開鍵は、アーカイブ化されているか？その場合、誰がアーカイブ化する者であり、そのアーカイブ化システムについてのセキュリティコントロールは、どのようなものか？また、有効期限切れの公開鍵の使用を認めるためには、どのソフトウェアやハードウェアがそのアーカイブの一部として保管される必要があるのか？
注： この項目は、デジタル署名のアーカイブデータへの利用を要求したり、記述することに限られず、むしろ、アーカイブが改ざんを防止する必要がある場合のデジタル署名以外のインテグリティ コントロールにも対応することができます。デジタル署名は、デジタル署名は、改ざんを防止することにはならないし、データのインテグリティを保護するわけでもありません。デジタル署名は、単にデータのインテグリティを検証するのみです。さらに、アーカイブ期間は、アーカイブデータに適用されるあらゆる署名を検証するのに必要となる公開鍵についての暗号解析期間よりも長い可能性があります。
2. 加入者宛に発行された証明書の運用期間は？加入者の鍵ペアの使用期間または有効期間は？
4.6.4. アクティべーションデータ（Activation Data） English
アクティべーションデータとは、「プライベート鍵又はプライベート鍵を含んでいる暗号モジュールを運用するために必要とされる、すべてのプライベート鍵以外のデータ値（例： PIN、パスフレーズ、または、鍵分割スキームの中で使用されたプライベート鍵の一部）」を言います。アクティべーションデータの防護は、プライベート鍵の認可されていない利用を予防し、潜在的に、発行 CA、サブジェクト CA、RA および加入者においては考慮される必要があります。このような考慮は、潜在的に、生成からアーカイブおよび破棄に至るまでのアクティべーションデータの全ライフサイクルに対応する必要があります。エンティティの種類（証明書発行 CA、リポジトリー、証明書被発行 CA、RA、加入者その他の関係者）ごとに、4.6.1節から 4.6.3節までに挙げた質問のすべてについて、（鍵に関してというよりも、むしろ）アクティべーションデータに関して、潜在的には回答される必要があります。
4.6.5. コンピュータセキュリティコントロール English
この項目は、下記のようなコンピュータセキュリティコントロールを記述するために充てられます。：
TCB（Trusted Computing Base）の概念の利用 concept, DAC（自由裁量的アクセスコントロール）、ラベル、MAC（強制的アクセスコントロール）、オブジェクトの再利用、監査、I&A、信用されたパス、セキュリティ検査および侵入検査。 製品保証も対応される可能性があります。コンピュータ システムについて、コンピュータセキュリティの格付けが要求される可能性があります。その格付けは、例えば、
- TCSEC（Trusted System Evaluation Criteria）
- カナダの Trusted Products Evaluation Criteria
- ヨーロッパの ITSEC（Information Technology Security Evaluation Criteria）
- CC（Common Criteria）for Information Technology Security Evaluation, ISO/IEC 15408:1999
に基づくことができます。この項目は、製品評価分析、製品試験、プロファイリング、製品認定、および／または、行われている活動に関する 製品の運用承認（accreditation）についての要件にも対応できます。
4.6.6. ライフサイクルにわたるセキュリティコントロール English
この項目は、システム開発コントロールとセキュリティ管理的コントロールに対応します。
システム開発コントロールは、開発環境セキュリティ、開発要員のセキュリティ、製品保守期間中の設定管理セキュリティ、ソフトウェアエンジニアリング実践、ソフトウェア開発手法、モジュール化、階層化、フェイルセーフな設計と実装テクニック（例： defensive programming）の利用、および、開発施設のセキュリティを含みます。
セキュリティ管理コントロールは、「運用システムやネットワークが設定されたセキュリティを固守していること」を検証するためのツールと手順の実行を含みます。これらのツールや手順は、正しい運用を確保するために、セキュリティソフトウェア、ファームウェアおよびハードウェアのインテグリティをチェックすることを含みます。
この項目は、例えば、TSDM（Trusted Software Development Methodology）レベル IV および V、独立したライフサイクルのセキュリティコントロール監査や、SEI-CMM（Software Engineering Institute's Capability Maturity Model）に基づくセキュリティレイティングにも対応することができます。
4.6.7. ネットワークセキュリティコントロール English
この項目は、ファイアウォール等、ネットワークセキュリティ関連コントロールに対応します。
この項目は、様々なデータについてのタイムスタンプの利用に関する要件または実践に対応します。これは、「タイムスタンプを付すアプリケーションが信用できる時刻の源泉を使わなければならないか否か」も検討することができます。
このコンポーネントは、証明書フォーマットを、CRL および／または OCSP が使われている場合は、当該 CRL および／または OCSP フォーマットを規定するために充てられます。これは、使われているプロファイル、バージョンおよび拡張についての情報を含みます。
この項目は、（潜在的に、IETF PKIX RFC 3280 において定義されているもののような独立したプロファイル定義に対する参照によって）下記のような論点に対応します。：
- サポートされるバージョン番号
- 示された証明書拡張およびそれらの重要度
- 暗号アルゴリズムのオブジェクト識別子
- CA、RA および加入者の名前について使われる名前の形式
- 「使われている名前の制約」および「名前制約に使われている名前の形態」
- 利用可能な CP のオブジェクト識別子
- ポリシー制約拡張の用途
- ポリシー修飾子の構文と意味
- 重要な CP 拡張についての処理方法
この項目は、（IETF PKIX RFC 3280 中で規定されたもののように、別のプロファイル定義を場合によっては参照することによって）、
潜在的には、下記のような論点に対応します。：
- CRL についてサポートされているバージョン番号
- CRL、配置された CRL エントリ拡張および、そのクリティカルフラグ
この項目は、（潜在的に、IETF RFC 2560 プロファイルのような別のプロファイル定義への参照によって）下記のような論点に対応します。：
- OCSP システムを構築するための基礎として使われている OCSP のバージョン
- 配置された OCSP 拡張、および、その重要性
このコンポーネントは、下記事項に対応します。：
- 評価、かつ／または、その評価を行うために使われる評価手法によって扱われる論点の一覧。例には、CA についての WebTrust（注 9）や、SAS 70（注 10）が含まれる。
- CP もしくは CPS に基づいて、評価されるべき個々の主体ィに対する準拠性監査又は他の評価が行う頻度、または、評価を行うきっかけとなる状況。（可能性として、「年次監査」、「主体の運用を認める運用前に行う評価」あるいは「実際のセキュリティの危殆化あるいはその可能性に伴う調査」が考えられる。）
- 監査もしくは他の評価を行う人事担当者の身元、かつ／または、資格
- 評価人と評価される主体との関係（評価人の独立性の程度を含む。）
- 評価において発見された不備の結果として、とるべき処置（例： 「不備が改められるまでの運用の一時的な停止」、「評価されたエンティティへ発行された証明書の失効」、「人事の変更」、「特別な調査を発生させること」、「より頻繁に準拠性監査を実施する」、「評価された主体に対する損害賠償請求」等が挙げられる。）
- 「誰が評価結果を見る権能をもつか？」（例： 評価された主体、他の関係者、一般大衆）、「誰が、それらを提供するか？」（評価人または評価された主体）および両者が情報交換をする方法。）
このコンポーネントは、一般的な業務事項と法的事項を扱います。このフレームワークの 9.1節と 9.2節は、「様々なサービスに対して課される料金の業務上の問題」および「継続中の事業（および、それらに対する請求の判決または和解の支払い）に関する財源を維持するための関係者の財務的責任」を検討します。残りの節は、一般に、法的論点に関するものです。
このフレームワークの 9.3節から始めると、この論点の様式は、典型的なソフトウェアのライセンス契約（あるいは、他の技術契約とまったく同じ（あるいは類似の）ものである。したがって、このフレームワークは、CP や CPS についてのみ使われるわけではなく、PKI 関連契約
（特に、「加入者との合意」と「信頼者との合意」）にも使われる可能性があります。こ様式（ordering）は、法律家が、CP、CPSおよび、このフレームワークに伴うその他の文書を精査するのを助けることを意図しています。このコンポーネント中にある多くの法的な項目に関して、CP もしくは CPS にお草稿者は、加入者または信頼者に直接適用できる条項を、この文書に含めることができます。例えば、CP・CPSは、加入者および信頼者に適用される責任の制限を定めることができます。契約条項を含めることは、CP・CPS 自体が契約（または契約の一部）となる場合、適切である可能性が高いです。
しかし、他の場合において、CP・CPS は、契約（もしくは契約の一部）ではありません。それらの条件は、「加入者との合意」または「信頼者との合意」のような、関連する協定を含む別の文書によって、関係者に対して適用されるという形式をとります。そのような場合、CPの執筆者は、一定の法的な条項をそのような関連協定に示す（あるいは、示さない）という要件を課して CP を執筆することができます。例えば、CP は、責任条件の一定制限が CA の「加入者との合意」および「信頼者との合意」の中に示さなければならない事を記述する節を含むこともできます。その他の例としては、CPの規定と矛盾する CA の責任についての制限を含んでいる「加入者との合意」または「信頼者との合意」の使用を禁止する節を含む CP が挙げられます。一定の条項が、CA によって使用している関連した「加入者との合意」、「信頼者との合意」あるいは他の協定で示すことを明らかにするために、CPS の執筆者は、法的な項目を使うことができます。例えば、CPS は、それを執筆している CA が、責任を制限するための特定の規定を適用することに関連した「加入者との合意」または「信頼者との合意」を使うことについて述べることもできます。
この項目は、CA、リポジトリもしくは RA によって課せられる料金に関する、下記のような、あらゆる適用可能な規定を含みます。：
- 証明書の発行料もしくは更新料
- 証明書へのアクセス料金
- 失効情報もしくは状態（status）情報へのアクセス料
- 関連する CP もしくは CPS へのアクセスを提供する等、その他のサービスに対する料金
- 払い戻しについてのポリシー
この項目には、「PKI の運用上の責任を遂行するため」および「そのような運用から生じる請求に関する判決又は和解の支払いを行う責任がある場合の支払能力を維持し、損害を支払うため」に、CA、RA または認証サービスを提供している他の関係者が利用可能な財源に関する要件もしくは情報開示について記述されます。このような規定には、下記のものが含まれます。：
- 「関係者は、他の関係者に対する自分自身の責任を補償できる一定の額の保険に入る」という言明
- 「運用を支援し、責任を負う可能性のある損害に対する支払いをするために、関係者が他の財源を利用することができる」旨の言明。これは、PKI において、発生するであろう偶発債務を、処理・補償するのに必要な最低限度の資産に関して示すことができる。例には、「組織の貸借対照表における資産」、「保証債券」、「信用状」および「一定の状況下における損害賠償に対する協定に基づく権利」が含まれる。
- 「関係者は、PKI の使用に関して、他の関係者に対し損害保険または保証による保護の提供を予定する」という言明
この項目は、関係者がお互いに交換することができる秘密のビジネス情報の取り扱いに関する規定が含まれます。例えば、事業計画書、売上高情報、企業秘密および秘密保持契約のもとにおいて第三者から受領した情報が挙げられます。具体的には、この項目は、下記事項に対応します。：
- 秘密情報と見なされるものの範囲
- 秘密情報の範囲外と見なされる情報の種類
- 秘密情報を受領した関係者が、その情報の侵害から守り、またその情報を使用すること又は第三者に公開することを回避する責任
この項目は、関係者（特に、CA、RA、リポジトリー）が、個人的に証明書申請者、加入者および他の関係者の身元確認が可能な個人情報を提供するように要求される可能性に関連します。具体的には、この項目は、適用法に準じて適切な範囲内で下記事項に対応します。：
- 適用法または適用ポリシーによって要求された場合の「関係者の活動に適用されるプライバシー計画」の明示と開示
- PKI の中で「プライバシーであると見なされる情報」又は「プライバシーではないと見なされる情報」
- 個人情報を受領する関係者の、その情報を守って第三者に対する開示を回避する関係者のあらゆる責任
- 個人情報の使用または開示に関する個人への通知または個人からの承諾に関するあらゆる要件
関係者が、民間、または公的な司法手続、行政手続その他の法的手続について、裁判的行政措置に従って個人情報を開示する権限を有する（または要求される）あらゆる状況
この項目は、特定の関係者が CP、CPS、証明書、名前および鍵の中に有したり、あるいは、有すると主張することができるような著作権、特許、登録商標、もしくは営業秘密のような知的財産権、あるいは、又は関係者に対するライセンス若しくは関係者からのライセンスの対象となるようなものに対応します。
この項目には、当該 CP もしくは CPS に従って作成された様々な主体の表現と保証を含めることができます。例えば、契約として扱われる CPS は、「当該証明書中にある情報は、正確である」という CA の保証を含む可能性があります。これに対して、CPS は、「証明書中の情報は、正当な注意を払って一定の身元認証手続を行った後には、CA が最大限知る限り真実である」という限定的な保証しか与えません。この項目は、「表明保証を『加入者との合意』または『信頼者との合意』のような特定の合意の中に示す」という要件も、含む可能性があります。例えば、CP は、「すべての CA が『加入者との合意』を援用すること」および「『加入者協定』の中には証明書中の情報が正確であることについて、CA の保証を含まなければならない」という要件が含まれる可能性がある。表明や保証を行う可能性がある加入者には、CA、RA、加入者、信頼者および他の関係者が含まれます。
この項目には、「この項目が無ければ合意中に存在すると見なされる明示の保証を行わないこと」および「この項目が無ければ適用法によって課される黙示の保証を行わないこと」（例：特定の目的に対する商品性または適合性の保証）を含めることができます。その CP もしくは CPS は、このような免責事項を直接提起する可能性があり、あるいは、当該 CP もしくは CPS は、「免責事項が、加入者との合意、もしくは、信頼者との合意のような関連文書に記述される」という要件を含む可能性があります。
この項目は、「CP・CPSにおける責任の制限」あるいは、「『加入者との合意』または『信頼者との合意』のような CP・CPS に関連した協定の中に示す（あるいは、示さなければならない）制限を含むことができます。これらの制限は、下記の 2つの分類のうち、いずれかに分けることができます。（ひとつは、回復可能な損害の要件についての制限。もうひとつは、責任の上限としても認識される回復可能な損害額の制限。）しばしば、契約は、付随的かつ必然的な損害、時には懲罰的損害といった損害要素の回復を禁止する条項を含みます。頻繁に契約は、一当事者（または他の当事者）に対して可能な回復額を、売主が契約に基づき支払いを受けた額のような一定の額（もしくは基準に準じた額）に限定する条項を含みます。
4.9.9. 補償（Indemnities） English
この項目は、「典型的には一方当事者の行為から発生するが、他方当事者が生じさせた損失または損害すべてを一方当事者が他方当事者に対して賠償する旨」の規定を含みます。それらは、CP、CPS もしくは合意にある可能性があります。例えば、CP は、CA が加入者に不正確な証明書を発行した場合、それが、証明書の申請書上の加入者による不正な誤表明から生じたものであれば、CA が被った損失に対して、加入者が CA へ賠償を行う義務がある旨の条項を「加入者との合意」におくよう要求することができます。同様に、CPS は、信頼者が適切に失効情報を調べずに行った証明書の使用、又は CA の許可の範囲外の目的での証明書の使用によって、CA が被った損失について信頼者が CA に対し賠償する義務があることを定める「信頼者との合意」を CA が使用する旨定めることができます。
この項目は、CP・CPS が有効とされる期間および文書、文書の一部、その文書の特定の関係者に対する有効性が終了する期間を含む可能性があります。これに加えて、あるいは、これに代えて、その CP もしくは CPS は、特定の有効期間と終了条項を「加入者との合意」もしくは「信頼者との合意」のような協定の中に示すことを要件を含む可能性があります。特に、このような条件は、下記の事項を含む可能性があります。：
- 文書もしくは合意の有効期間（すなわち、「当該文書が有効となる日付」および、「文書が有効期間満了前に終了されない場合、有効期間が切れる日付」）
- 「文書、文書の一部あるいは特定の関係者に対する適用が、有効でなくなる状況」を定める終了についての規定
- 文書（の有効期間の）終了のあらゆる効果（例： 合意内のある規定を終了後も有効なままとすることができる。）例としては、知的財産権の同意および秘密規定などが挙げられます。また、廃業は、秘密情報を開示した個人へこれを返還する責任を発生させる可能性があります。
この項目は、ある関係者が他の関係者との伝達を法的に有効とするために行われる他の関係者と個別に連絡しあうことができる（あるいは、連絡しあわなければならない）方法を検討します。例えば、RA は、CA との協定を終了したい旨を CA に対して知らせることを望む可能性があります。この項目は、発行機能やリポジトリ機能とは別のものです。なぜならば、公開およびリポジトリーへの送信は、この項目中で述べる個別の連絡とは異なって、（すべての信頼者宛のように）不特定多数の読者への伝達を目的としているからです。この項目は、伝達のための仕組みを作り、そしてそのような伝達の経路に使われるべき連絡先情報を示すことができます。（例：特定の連絡先へのデジタル署名付き電子メールでの通知、それを受領したことを伝える署名付き電子メールの承認）
ときとして、CP もしくは CPS を改訂することが必要不可欠であることがあります。これらの変更には、認証ポリシー、または、その履行による保証を著しく減じるものではなく、証明書の受領可能性に重大な影響を与えないため、ポリシー管理者によって判断されます。このような CP もしくは CPS に対する変更は、CP OID もしくは、その CPS ポインタ（URL）について、変更を要求しません。他方、仕様に対する変更には、特定の目的についての証明書の受領可能性を著しく変えるものがあり、これらの変更は、対応するCPオブジェクト識別子、または、CPSポインター修飾子（URL）の変更を要する可能性があります。
この項目は、下記の情報も含む可能性があります。：
- CP・CPS,、および／または、他の文書を改訂しなければならない場合、改訂することができる場合、または改訂された場合の手順。CP もしくは CPS が改訂される場合、変更手順は、
- 「加入者および信頼者等の関係者に対する改訂案を通知する方法」、「コメントの期間」、「コメントが受領され、見直され、そして文書の中へと組み込まれていく方法「および「改訂が最終版となり有効にさせる方法」が含む可能性がある。
- CP もしくは CPS の改訂が、CP OID もしくは CPS ポインタ（URL）における変更を要求する場合。
この項目は、CP、CPS、かつ／または、合意から提起される争議を解決するために援用される手順を検討します。このような手順の例には、紛争がある特定の会議体において、または、代替的紛争解決手段（ADR）によって解決されるものとする
要件が含まれます。
この項目は、「一定の司法権に属する法が、解釈に適用される」 という言明と、「対象となる CP、CPS もしくは協定の適用」を規定します。
この項目は、「関係者は、適用法を遵守する」（例： 特定の司法権における輸出規制法の適用を受ける暗号技術的なハードウェアやソフトウェアに関する法律）という要件に関するものです。当該 CP もしくは CPS は、このような要件を課すことを表明する可能性があり、あるいは、「他の合意中に、このような規定をおくこと」を要求する可能性があります。
この項目は、（しばしば、契約において「ボイラープレート条項（boilerplate provisions）」と呼ばれる）雑則を含みます。この項目で扱われる条項は、CP、CPS もしくは合意にある可能性があり、下記事項を含む可能性があります。：
- 完全合意条項：
これは、典型的には、文書または関係者間における合意全体を構成する文書を識別し、「そのような合意が同一事項に関連する、これより早い時期および同時期の書面または口頭の合意のすべてに優先すること」を言明する。
- 権利譲渡条項：
これは、「他方当事者との間の協定に基づいて、『契約上の自己の権利（将来的に賠償金を受け取る権利のような）を譲渡すること』または『契約上の自己の義務の履行を委任すること』を制限する効果」をも持つ可能性がある。
- 分離条項：
これは、裁判所（または他の評決機関）が、協定内の条項は何らかの理由によって、無効である（または執行できない）旨を決定する場合の当事者の意図を明示する。そして、その目的は、しばしば、ひとつの条項が執行不能であるが故に協定全体が執行できなくなることを防ぐことにある。
- 強制執行条項：
これは、「協定から生じたすべての紛争の勝者は、損害回復の一環として弁護士費用を請求することができる旨」を言明する可能性があり、また、「ある契約違反に対する当事者の請求権放棄が、無期限的な放棄若しくは他の契約違反に対する将来的な放棄とはならない旨」を言明する可能性がある。
- 不可抗力条項：
これは、普通、ある事象の影響を受けたひとり（もしくは複数）の当事者の合理的な支配が及ばない外部の事象が生じたことによって、当該当事者の協定上の債務の履行を免除するために用いられます。典型的には、債務の履行を免除する期間は、事象によって引き起こされた遅延期間と釣り合います。この条項は、さらに特定された状況および要件の下での協定の終了を規定することもできます。「不可抗力」を構成すると考えられる事象とは、いわゆる「神のなせる業」、戦争、テロリズム、ストライキ、自然災害、実施にあたるサプライヤー若しくはベンダーの事業停止又はインターネット（もしくは他のインフラストラクチュア）の停止を含む可能性があります。不可抗力条項は、基本となる協定および適用可能なサービスレベルに関する協定の他の部分と整合するように執筆されるべきです。（例：業務の連続性および災害回復に係る責任・資格条項が、停電に直面した際のバックアップ電力を維持する義務のように、当事者の合理的な支配下にあるいくつかの事象を規定することができる。）
この項目は、「このフレームワークの他の章および節にうまく当てはまらない追加的な責任および条項を PKI 関係者に課すことができる」という、いわゆるキャッチオール条項のための箇所である。CP や CPS の執筆者は、この項目の中に、別の項目によって扱われていないあらゆる項目を置くことができます。
X.509 によれば、証明書ポリシー（CP）は、「共通のセキュリティ要件をもつ特定のコミュニティ、および／または、アプリケーションのクラスへの証明書の適用可能性を示すルールの命名された集合」です。CP は、証明書およびその中に結合されている事項が十分に信頼できるか否か、あるいは、特定のアプリケーションに適合するか否かの判断材料として、信頼者によって使われる可能性があります。
信頼者が証明書に体現されている結合関係を信用できる程度は、いくつかの要素によります。これらの要素は、サブジェクトの本人認証を行う際に CA によって行われる実践を含むことができます。（例えば、当該 CA の運用ポリシー、手順および技術的なセキュリティコントロール（加入者の責任(例えばプライベート鍵の保護)の範囲を含む）や、認証局の運用ポリシー、手続および技術的なセキュリティ管理(加入者の責任の範囲、および、当該 CA の責任条項（例えば、保証、保証の免責、および、責任の制限）等が、挙げられます。
本書は、「当該証明書の生成、発行、更新、鍵の再生性、利用および失効がセキュアな作法で行われること」を確保するために、CA、RA、リポジトリ、加入者および信頼者の暗号モジュールについての（技術的・手続的・要因管理的・物理的な）セキュリティの観点からのフレームワークを提供します。具体的には、「4.3 節 I&A（身元確認と認証）」、「4.4 節 証明書ライフサイクルの運用的要件」、「4.5節 設備的管理および運用的コントロール」、「4.6 節 技術的なセキュリティコントロール」、「4.7 節 証明書、CRL および OCSP プロファイル」および「4.8 節 準拠性監査や他の評価」は、PKI 関連主体（CA、RA、リポジトリ、加入者システムおよび信頼者システムのような）のセキュアな運用を確保することを指向しています。
この章は、CP もしくは CPS の執筆者によって使われるチェックリスト、もしくは、（さらに発展可能な）標準テンプレートの役割を果たすことが意図された規定集について推奨される章立てを含みます。このような共通概要は、下記事項を容易にします。：
(a) 横断認証、あるいは、（同等性マッピング目的の）他の形態の相互運用の際に、2 つの証明書ポリシーの比較。
(b) 「CPS が誠実にポリシーを実施していること」を確認するための当該 CPS の CP との比較。
(c) 2 つの CPS の比較。
RFC に準拠するために、準拠する CP もしくは CPS の執筆者には、この構成に従うことが強く推奨されます。代替的な構成の利用は止めていただきたいですが、逸脱について適切な正当化が示され、かつ、「この構成において記述された各要素がどこに書かれているか」を見分けられるための対応表が示される場合、許容される可能性があります。
このフレームワークは、RFC 2527 を改善したものです。この新しいフレームワークは、RFC 2527 のもとでの CP 文書と CPS 文書を採用してきた過程で得られた経験から恩恵を受けています。さらに、この新しいフレームワークは、ABA（American Bar Association）の技術法制部会（Section of Science and Technology Law）中の ISC（Information Security Committee）との調整に基づいています。ISC は、「PKI 評価ガイドライン（The PKI Assessment Guidelines）」[ABA2] を執筆しました。これは、PKI 運用における技術的・事業的・法的な豊富な経験を具体化したものです。特に、ISC の代表者は、このフレームワークに対して、より法的環境に適合するように、また、弁護士にとって利用しやすくするために、変更を行いました。
技術的な観点からは、RFC 2527 フレームワークへの変更は、革命的なものではなく、むしろ最小限の改善でした。第 3 章から第 7 章までは、適度な再編成が行われ、新たな論点が加えられましたが、概ね従前どおりです。例えば、この新しいフレームワークは、証明書のライフサイクル全体を扱うようにすること、鍵寄託の追記、鍵のカプセル化、 鍵回復ポリシーと実践、および OCSP を含めるようにするフレームワークの第 4 章の見直し を含みます。第 2 章の監査機能は、今般、第 8 章中に単独であり、第 2 章は、専ら、リポジトリ機能について焦点を当てています。RFC 2527 の第2章中の業務的な事項や法的事項は、現在、新第 9 章にあります。
法的な観点からは、新しい第 9 章は、有用です。なぜならば、この章は、フレームワーク中の論点をソフトウェアライセンスや他の技術合意と同じ順に載せてており、それゆえ、技術を扱う弁護士にとって読みやすいからです。さらに、このフレームワーク全体として、加入者との合意、信頼者との合意、あるいは他の PKI 関連の合意のためのフレームワークを兼ねることができます。この変更は、CP 文書や CPS 文書のレビュー（および、これらへの入力）をより効率的にすることを意識したものです。第 9 章は、また、個人情報のプライバシー、責任条項および当該文書の有効期間のような、新しい法的論点を追加しています。
新フレームワークの第 1 章は、信頼者から加入者を切り分け、他の関係者についての節を追加することによって、PKI 関係者の範囲を広げましたが、概ね RFC 2527 と同様です。第 1 章は、「適用可能性」の節を証明書の適切な利用法と禁止される利用法を扱うものに変更しています。また、これは、CPS 承認手続を RFC 2527 の 8.3 節からポリシー運用管理の節に集めるように移動しました。最後に、1.6 節には、定義と頭字語を掲載するところを加えました。
新フレームワークの第 2 章は、旧フレームワークの 2.6 節を再編成したものです。新フレームワークの第 3 章は、旧 3.1 節を「命名」と「I&A」の論点についての 2 つの部分に分割することに基づいています。第 3 章は、仮名および匿名性の許容可能性のような新しい論点を加えました。 監査ログ記録、記録アーカイブ化、鍵の変更、危殆化や災害からの復旧、および、CA の廃業についての旧第 4 章の論点は、第5章に移動されました。第 4 章の残りの論点は、証明書 ライフサイクル全体を扱うように範囲を広げ、再編集されました。新しい論点には、証明書申請処理、証明書修正、および、加入者契約の修了のように、RFC 2527 第 4 章においては黙示的であった要素が、今回、明記されたものがあります。
新しい 5.1 節から 5.3 節までは、RFC 2527 中の対応する節と概ね同じです。新第5章の残りの節は、RFC 2527 の第 4 章にあった順のまま移された論点です。新しいフレームワークの第6章は、旧 6.8節（暗号モジュールエンジニアリングコントロール）の 6.2.1節（現「暗号モジュールの標準とコントロール」） への統合や、新 6.8 節への「タイムスタンプ」の追加のようないくつかの例外を除いて、旧第 6 章と概ね同じです。第7章は、旧第7章と概ね同じであり、主要な変更点は、OCSP プロファイルを扱っている節の追加です。第 8 章は、RFC 2527 の 2.7 節と概ね同じです。
新第 9 章は、RFC 2527 の第 2 章において扱われていた業務的論点と法的論点を含んでおり、これには、料金、財務的責任、守秘義務および知的財産権を含まれます。第 9 章は、今日、重要な政策的論点となっている個人情報のプライバシーについての節を加えました。RFC 2527 中の 2.2 「責任」の節は、現在、9.6 節から 9.9 節までにあり、責任と保証、免責事項、責任制限および補償を扱っています。9.10 節は、文書の有効期間に関する節を加えたものです。9.12 節は、以前は 8.1 節にあった文書類（CP、CPS、合意もしくは他の文書）が改訂される方法に関する条項を集約しています。第9章は、「法的ボイラープレート（legal boilerplate）」論点を含み、この中には、旧第 2 章にあったものがあります。最後に、9.17 節は、フレームワークのどの他の節にも馴染まない情報を執筆者がおくことができる、すべてを受け入れる「その他の条項」の節です。
下表は、旧 RFC 2527 フレームワーク中の節と、それらの後継となる新しいフレームワーク中の節を示します。
ORIGINAL RFC 2527 NEW RFC SECTION SECTION
（作業中）
以前の版である文書（RFC 2527）の開発は、カナダ政府の PMA（Policy Management Authority）委員会、NSA(National Security Agency）、NIST（National Institute of Standards and Technology）および ABA（American Bar Association）の Information Security Committee（情報セキュリティ委員会）Accreditation Working Group によってサポートされていました。
この改訂作業は、概ね、Michael Baum からの着実な示唆の成果です。Michael Power, Mike Jenkins および Alice Sturgeon も、貢献してくださいました。
[ABA1] American Bar Association,
Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce,
1996年.
[ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, Public Draft For Comment,
2001年 6月.
[BAU1] Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR-94-654,
1994年 6月, 下記 URL より入手可能
http://www.verisign.com/repository/pubs/index.html.
[ETS] European Telecommunications Standards Institute,
"Policy Requirements for Certification Authorities Issuing Qualified Certificates,"
ETSI TS 101 456, Version 1.1.1,
2000年12月.
[GOC] Government of Canada PKI Policy Management Authority,
"Digital Signature and Confidentiality Certificate Policies for the Government of Canada Public Key Infrastructure," v.3.02,
1999年 4月.
[IDT] Identrus, LLC,
"Identrus Identity Certificate Policy" IP-IPC Version 1.7,
2001年 3月.
[ISO1] ISO/IEC 9594-8/ITU-T Recommendation X.509,
"Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997年版.
（2000年版の発行は、未決定。1997年版を利用せよ。）
[PEM1] Kent, S.,
"Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management",
RFC 1422,
1993年 2月.
[PKI1] Housley, R., Polk, W. Ford, W. and D. Solo,
「インターネットX.509 PKI： 証明書と CRL のプロファイル
(Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL) Profile)」,
RFC 3280(English),
2002年 4月.
[CPF] Chokhani, S. and W. Ford,
「インターネット X.509 PKI 証明書ポリシーと認証実施フレームワーク
(Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework )」,
RFC 2527,
1999年 3月.
- ABA DSG（デジタル署名 Guidelines）のコピーは、ABA から購入することができます。詳細については、http://www.abanet.com 参照。DSG は、下記の ABA の web サイトからも無償でダウンロードできます。
http://www.abanet.org/scitech/ec/isc/digital_signature.html
- "the PKI Assessment Guidelines" のドラフトは、ABA の Web サイト（http://www.abanet.org/scitech/ec/isc/pag/pag.html）から無償でダウンロードできます。
- 「有意（meaningful）」という用語は、「名前の形式は、個人、かつ／または、組織体の身元を判定するために、広く理解される意味論をもつこと」を意味します。ディレクトリ名と RFC 822 名は、多かれ少なかれ有意でしょう。
- CA がサブジェクトに代わってサブジェクトの鍵ペアを生成する場合、サブジェクトは、CA に対しては登録されている公開鍵に対応するプライベート鍵を保有しているということを証明する必要はありません。
- 個人を識別し認証する手段の例は、（拇印、10本の指紋、および顔、手のひら、又は 網膜のスキャン等の）バイオメトリックな手段、運転免許証、クレジットカード、社章、および政府職員証明書等を含みます。
- 証明書の「変更（modification）」は、既存の証明書に変更を行うことを指すわけではありません。なぜならば、この行為が証明書に対してのすべてのデジタル署名検証を妨げ、証明書が無効となることを引き起こすからです。むしろ、「変更」の概念は、証明書内に参照された情報が変更された、又は変更されるべき状況を指し、それに伴って CA は、変更された情報を含む新しい証明書を発行します。一例として、「彼（もしくは彼女）の名前を変更する加入者」が挙げられます。これは、新しい氏名を含む新証明書の発行を必要不可欠とします。
- 「n out of mルール」は、プライベート鍵を m 個の部分に分けるものです。 m 個の部分は、異なる m 人へ与えることができます。
すべての m 部分中の n 部分は、プライベート鍵を完全に再構成するために使えますが、n-1 部分ではプライベート鍵についての情報を全く提供しません。
- プライベート鍵は、寄託（エスクロー）、バックアップもしくはアーカイブされる可能性があります。これらの機能の各々は、異なる目的をもっています。それゆえ、プライベート鍵には、要件に応じて、これらの機能のどれでも、適用できます。寄託の目的は、「（組織体もしくは政府のような）第三者が加入者の協力無しに、そのプライベート鍵を入手できるようにすること」にあります。バックアップの目的は、「鍵の破壊もしくは頽廃が起きた場合、加入者にビジネスの継続を目的としての鍵の再構成を行えるようにすること」にあります。アーカイブの目的は、「将来におけるプライベート鍵の再利用のために提供すること」にあります。（例： 文書を複合するために利用）
- "WebTrust" とは、アメリカ公認会計士協会とカナダ勅許会計士協会から発行されている「CA のための Web トラストプログラム」のことを言います。
- <http://www.aicpa.org> を参照。
- この章に挙げる要素の全部または一部は、様々な主体の種類（すなわち、CA、RA およびエンドエンティティ）ごとに異なる可能性があります。
ABA - American Bar Association
CA - Certification Authority
CP - Certificate Policy
CPS - Certification Practice Statement
CRL - Certificate Revocation List
DAM - Draft Amendment
FIPS - Federal Information Processing Standard
I&A - Identification and Authentication
IEC - International Electrotechnical Commission
IETF - Internet Engineering Task Force
IP - Internet Protocol
ISO - International Organization for Standardization
ITU - International Telecommunications Union
NIST - National Institute of Standards and Technology
OID - Object Identifier
PIN - Personal Identification Number
PKI - Public Key Infrastructure
PKIX - Public Key Infrastructure（X.509)（IETF Working Group)
RA - Registration Authority
RFC - Request For Comment
URL - Uniform Resource Locator
US - United States
Santosh Chokhani
Orion Security Solutions, Inc.
3410 N. Buchanan Street
Arlington, VA 22207電話： (703) 237-4621
Fax： (703) 237-4920
EMail： chokhani＠orionsec.comWarwick Ford
VeriSign, Inc.
6 Ellery Square
Cambridge, MA 02138電話： (617) 642-0139
EMail： wford＠verisign.comRandy V. Sabett, J.D., CISSP
Cooley Godward LLP
One Freedom Square, Reston Town Center
11951 Freedom Drive
Reston, VA 20190-5656電話： (703) 456-8137
Fax： (703) 456-8100
EMail： rsabett＠cooley.comCharles (Chas) R. Merrill
McCarter & English, LLP
Four Gateway Center
100 Mulberry Street
Newark, New Jersey 07101-0652電話： (973) 622-4444
Fax： (973) 624-7070
EMail： cmerrill＠mccarter.comStephen S. Wu
Infoliance, Inc.
800 West El Camino Real
Suite 180
Mountain View, CA 94040電話： (650) 917-8045
Fax： (650) 618-1454
EMail： swu＠infoliance.com
翻訳者のアドレス
鈴木 優一
セコム株式会社
IS 研究所
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.