ネットワーク WG
Request for Comments: 3647
廃止: 2527
分類: 情報提供
 

S. Chokhani
Orion Security Solutions, Inc.
W. Ford
VeriSign, Inc.
R. Sabett
Cooley Godward LLP
C. Merrill
McCarter & English, LLP
S. Wu
Infoliance, Inc.
2003年11月

English

インターネット 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 は、廃止されます。

目次

1. はじめに

1.1. 背景
1.2. 目的
1.3. 範囲

2. 定義

3. 概念

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. 規定集の内容

4.1. はじめに
4.1.1. 概要
4.1.2. 文書名と識別
4.1.3. PKI の関係者
4.1.4. 証明書の用途
4.1.5. ポリシー運用管理
4.1.6. 定義と頭字語

4.2. 発行とリポジトリの責任

4.3. I&A(身元確認と認証)
4.3.1. 命名
4.3.2. 初期身元検証
4.3.3. 鍵の再生成リクエストについての I&A
4.3.4. 失効リクエストについての I&A

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. 証明書の失効と一時保留
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.8. 準拠性監査や他の評価

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. 他の条項

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

6. 規定集の概要

7. RFC 2527 との比較

8. 謝辞

9. 参考文献

10. 注記事項

11. 頭字語一覧

12. 著者のアドレス

13. 著作権表記全文

 

1. はじめに  English

1.1. 背景 English

一般に、公開鍵証明書(以降、「証明書」)は、「(個人、組織、アカウント、デバイスもしくはサイトのような)主体によって保持される公開鍵」を、「対応するプライベート鍵を利用する主体を識別する一式の情報」に結合します。身元確認用の証明書に関する多くの場合、この主体は、証明書の「サブジェクト(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 が純粋に情報提供としての文書、あるいは開示文書となるように努める可能性があります。

1.2. 目的 English

本書の目的は、2 つあります。まず、本書は、CP と CPS の概念を説明し、これら 2 つの概念の差異を記述し、これらの加入者や信頼者との合意に対する関係を記述することを目的とします。次に、本書は、CP または CPS の執筆者もしくはユーザが、これらの文書を執筆したり、理解する際に支援するためにフレームワークを提供することを目的としています。特に、このフレームワークは、CP もしくは CPS を定式化する際に考慮される必要がある可能性がある要素を識別します。これ自体の目的は、特定の CP もしくは CPS を規定することにありません。さらに、本書は、 CP もしくは CPS 中に含められる必要がある、特定の要件もしくは実践に関する法的な助言もしくは推奨事項を提供することを目的としていません。(しかし、このような推奨事項は、[ABA2] にあります。)

1.3. 範囲 English

本書の範囲は、CP(X.509 において規定されている。)もしくは CPS(DSG と PAGにおいて規定されている。)において扱われうる論点の検討にとどまります。特に、本書は、CP もしくは CPS に含めることについて考慮されるべき情報の種類を記述します。提供したフレームワークは、一般に、身元確認目的については X.509 v3 証明書フォーマットの利用を想定していますが、「題材が、その証明書フォーマットもしくは身元証明書の利用に制限されること」は意図されていません。むしろ、「このフレームワークが、他の証明書フォーマットや、将来、身元確認以外の保証目的に使われることになる可能性がある証明書に採用可能なものであること」が意図されています。

扱う範囲は、(組織体のセキュリティポリシー、システムのセキュリティポリシーもしくはデータラベル付けポリシーのような)セキュリティポリシー一般を規定することにはおよびません。さらに、本書は、特定の CP もしくは CPS を規定するものではありません。さらに、フレームワークを提供する際に、本書は、CP もしくは CPS を策定するための厳密なひな形としてではなく、CP または CPS と特定の関係があると考慮される必要がある論点を提供している柔軟性あるツールと見なされて、使われる必要があります。

本書は、「読者は、X.509、DSG および PAG に使われているような、デジタル処刑、証明書および公開鍵インフラストラクチャ(PKI)の一般的な概念になじみがある」と想定します。

2. 定義 English

本書は、下記に定義された用語を使います。:

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 ((十分性)検証)
 証明書申請の身元確認の手順。検証は、身元確認の一部であり、証明書申請の身元を確立するための身元確認を言う。

 

3. 概念 English

この章は、CP と CPS の概念を説明し、「加入者との合意」や「信頼者との合意」のような他の PKI 文書との関係を記述ます。他の関連する概念も、記述されます。この章と、他の章のいずれかで扱われる題材には、X.509 v3 に規定された証明書ポリシー拡張に特有なものがあります。これらの章を除いて、このフレームワークは、将来、使われる可能性がある他の証明書フォーマットに適用可能であることを意図しています。

3.1. 証明書ポリシー(CP) English

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 表示を採用します。

3.2. 証明書ポリシー(CP)の例 English

例示のために、「国際航空運送協会(IATA: International Air Transport Association)」が、個々の航空会社によって運用されている PKI の組み合わせによる IATA によって運用されている PKI における航空業界による利用のために、いくつかの CP の定義を行っている」と想定します。2 つの CP が規定される可能性があります。(IATA 一般目的 CP と IATA 商業用 CP。)

国際航空運送協会(IATA)の一般用 CP は、定常的な情報(例: 普段の電子メール)を防護するためや、WWW ブラウザーから一般的な情報取得目的のサーバー宛の接続を認証するために業界人によって使われる可能性があります。その鍵ペアは、商用のブラウザーのような廉価なソフトウェアに基づくシステムを使って生成・保存・管理される可能性があります。このポリシーのもとで、証明書は、IATA の協会内ディレクトリ、もしくは、会員航空会社内のディレクトリ中に従業員として掲載されていて、組織体内のネットワーク管理者宛に署名された証明書リクエストフォームを送信するあらゆる者に対して自動的に発行される可能性があります。

国際航空運送協会(IATA)の商業用 CP は、財務取引、もしくは、航空会社間の契約に基づく交換を防護するために使われる可能性があります。このポリシーのもとで、IATA は、「認定された鍵ペアが承認された暗号技術的なハードウェアトークンによって生成され、保存されること」を要求する可能性があります。証明書やトークンは、航空会社の従業員宛に支払い権限と共に提供される可能性があります。そして、これらの認可された個人には、トークンと証明書が発行される条件として、協会のセキュリティオフィスに出頭し、正統な身分証明バッジを見せ、当該トークンを防護し認可された目的にのみ使うことを要求する「加入者との合意」に署名することが要求される可能性があります。

3.3. X.509 証明書の各フィールド English

X.509 証明書中の下記の拡張フィールドが、CP をサポートするために使われます。:

3.3.1. 証明書ポリシー拡張 English

証明書ポリシーフィールドは、当該 CA が適用可能であると宣言する CP を掲げます。3.2 節において定義された IATA 一般目的ポリシーと商業用ポリシーの例を使うと、通常の航空会社従業員宛に発行された証明書は、一般目的ポリシーのオブジェクト識別子を含みます。支払い権限をもつ従業員宛に発行された証明書は、一般目的ポリシーと、商業用ポリシーの両方のオブジェクト識別子を含みます。両オブジェクト識別子を証明書に含めることは、「それらが、一般目的ポリシーか、商業用ポリシーのいずれかについて適切であること」を意味します。また、この CP フィールドは、オプションとして、各識別されたポリシーについての修飾子の値も運ぶ可能性があります。(修飾子の利用法は、3.4節において検討されています。)

認証パスを処理するとき、信頼者のアプリケーションに受容可能な CP が、パス中のすべての証明書中に、(すなわち、エンド主体証明書と同様に CA 証明書中に)存在しなければなりません。

証明書ポリシーフィールドのクリティカルフラグが立っている場合、これは、上述と同じ目的のためですが、追加的な役割も果たすものです。具体的には、これは、「当該証明書の利用法が、識別されるポリシーのひとつに制限されること」、すなわち、「その CA は、『当該証明書は、少なくとも、掲載されている CP のひとつの規定集に準拠してのみ使われなければならない』と宣言していること」を示します。このフィールドは、「当該適用可能な CP に明示されているように、当該証明書を不適切な目的に、あるいは、不適切な作法で使った信頼者によって申し立てられた被害の請求から CA を保護すること」を意図したものです。

例えば、米国内国歳入庁(Internal Revenue Service)は、納税者宛に、納税申告を保護する目的で 証明書を発行する可能性があります。内国歳入庁は、誤って悪い証明書を発行することのリスクを理解し、対応することができます。(例: なりすます者に対して発行する。)しかし、「誰かが内国歳入庁の納税申告証明書を数百万ドルの価値の営業秘密を暗号化するための基礎として使い、後にこれが、メッセージを復号できる攻撃者による暗号技術的攻撃によって、悪人の手に渡ってしまった」と想定してください。内国歳入庁は、「当該加入者と信頼者が当該証明書を濫用したこと」を示すために、当該証明書ポリシー拡張の重要度を指し示すことによって、このような状況における損害賠償請求から自身を護ることを望む可能性があります。クリティカルフラグが立てられた証明書ポリシー拡張は、そのような状況において、その CA についてのリスクを低減することが意図されたものです。

3.3.2. ポリシーマッピング拡張 English

ポリシーマッピング拡張は、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 についてのオブジェクト識別子を含む証明書を受容・処理・信頼することができます。

3.3.3. ポリシー制約拡張 English

ポリシー制約拡張は、2 つのオプションとしての機能をサポートします。第1 の機能は、CA が「明確な CP の表示が認証パス中のすべての後続の証明書の中にあること」を要求できる機能です。認証パスの起点にある証明書は、信頼者によって信用されたドメインの一部となり、すなわち、CA は、すべての目的について信用されており、証明書ポリシー拡張中に特定の CP は不要と見なされる可能性があります。このような証明書は、CP の明示をもつ必要がありません。しかし、信用されたドメイン中の CA が、そのドメインの外部を認証するとき、これは、「特定の CP のオブジェクト識別子が当該認証パス中の後続の証明書中にあること」という要件を課すことができます。

ポリシー制約フィールド中の他のオプションとしての機能には、CA が認証パスにおける後続の CA によるポリシーマッピングを不能にする機能があります。ポリシーマッピングを不能にすることは、ドメイン外の者を認証するとき、賢明である可能性があります。これは、連鎖的な信用に起因するリスクをコントロールする際に支援できます。(例: ドメイン A は、ドメイン B を信用し、ドメイン B は、ドメイン C を信用するが、ドメイン A は、ドメイン C を信用することを強制されることを望まない。)

3.3.4. ポリシー修飾子 English

証明書ポリシー拡張フィールドは、各 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 が、そのように提供する場合、ポリシー修飾子種別は、一般的なポリシーを補完するために追記される具体的なポリシーの詳細を運ぶために、証明書ごとに定義される可能性があります。

3.4. 認証実施規定(CPS) English

認証実施規定(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 は、下記のものを含む他の文書における参照によって、組み合わされる可能性があります。:

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 において参照する可能性がある文書には、以下のものがあります。:

 

3.7. 規定集 English

規定集は、下記の 第 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 つの主要コンポーネントに分けて概説します。:

  1. はじめに
  2. 発行とリポジトリ
  3. I&A(身元確認と認証)
  4. 証明書のライフサイクル運用的要件
  5. 設備、管理および運用的コントロール
  6. 技術的セキュリティコントロール
  7. 証明書、CRL および OCSP のプロファイル
  8. 準拠性監査
  9. 他の案件と法的事項

 

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章中に述べられた項目の下に、追加的な項目を追加することが許されています。

 

4. 規定集の内容 English

この章は、(3.7 節において紹介した)シンプルな規定のフレームワークの内容に基づいて発展させます。この章において識別された論点は、必然的に、詳細な CP もしくは CPS に含められる論点の候補となります。

多くの論点が識別されていますが、CP もしくは CPS が、このような各論点について具体的な言明を含むことは、不可欠ではありません。むしろ、特定の CP もしくは CPS は、「特定の CP もしくは CPS imposes no 要件を定めないコンポーネント・項目・要素」あるいは「開示しないコンポーネント・項目・要素」について、「規定しない」と記述することができます。この意味において、論点の一覧は、CP もしくは CPS の執筆者によって考慮される論点のチェックリストと見なすことができます。

「たとえ『規定しない』とする場合でも、各すべてのコンポーネントおよび項目を CP もしくは CPS に含めておくこと」が推奨されます。このことは、読者に、「その論点に関する規定を「含むこと」あるいは「含まないこと」について、意図的な意思決定がなされたこと」を示します。この執筆スタイルは、不注意による論点の見落しを防ぐとともに、異なる CP・CPS の比較を容易にします。(例: ポリシーマッピング判定を行うとき)

CP において、特定のコンポーネント、項目、および/または、要素を規定しないままとし、「要求される情報は、ポリシー修飾子中に示されること、あるいは、 ポリシー修飾子が指す文書中に示されること」を規定することが可能です。このような CP は、修飾された定義であると見なすことができます。規定集は、要求されたポリシー修飾子種別を参照するか、定義する必要があり、あらゆる受容可能なデフォルト値を規定する必要があります。

4.1. はじめに English

このコンポーネントは、規定集を識別・紹介し、当該文書(執筆される CP か CPS のいずれか)の対象となる主体とアプリケーションの種類を示します。

4.1.1. 概要 English

この項目は、書かれる文書についての一般的な導入を提供します。この項目は、当該 CP もしくは CPS が適用される PKI の概要情報を提供するためにも使うことができます。例えば、これは、当該 PKI において、証明書によって提供される異なるレベルの保証を設定する可能性があります。当該特定の PKI の複雑性と範囲によっては、PKI についての概略的な表現が、ここで有用である可能性がります。

4.1.2. 文書名と識別 English

この項目は、当該文書について適用可能なあらゆる名前、もしくは、他の識別子(ASN.1 オブジェクト識別子を含む)を提供します。このような文書名の例として、「セキュアな電子メールについての米国連邦政府ポリシー」が挙げられます。

4.1.3. PKI の関係者(PKI Participants) English

この項目は、PKI において一定の役割を果たす主体の身元もしくは種別を記述します。:

4.1.4. 証明書の用途(Certificate Usage) English

この項目は、下記の事項を含みます。:

かつ/または、

CP もしくは CPS が異なるレベルの保証を記述している場合、この項目は、異なる保証のレベルについて適する/適さない、アプリケーション(そのもの)あるいはアプリケーションの種類を記述することができます。

4.1.5. ポリシー運用管理(Policy Administration) English

この項目は、この CP もしくは CPSの執筆、登録、維持管理および更新に責任を負う組織体の名前と郵便先住所を含みます。これは、また、連絡先担当者の名前、電子メールアドレス、電話番号、ファックス番号も含みます。実際の人間を命名する代わりに、その文書は、肩書きもしくは役職、電子メールのエイリアスおよび他の一般化された連絡先情報を指名する可能性があります。場合によっては、その組織体は、「その連絡先担当者が、(独り、もしくは、他者との組で)当該文書についての質問に回答できること」を述べることができます。

さらに、公式/非公式のポリシー決定機関が「CA は、ある PKI 中において運用すること、あるいは、他の PKI と相互運用することを許可される必要があるか否かを判断すること」について責任を負うとき、これは、当該 CA の CPS を、そのポリシー決定機関の CP に照らして適切であるとして承認することを望む可能性があります。その場合、この項目は、そのような意思決定を行う者の名前もしくは肩書き、電子メールアドレス(もしくはエイリアス)、電話番号、ファックス番号、および他の一般情報を含む可能性があります。最後に、この場合、この項目は、この意思決定を行う手順も含みます。

4.1.6. 定義と頭字語 English

この項目は、文書中の頭字語の一覧と、それらの意味とともに、その文書中で使われている定義された用語についての定義の一覧を含みます。

4.2. 発行とリポジトリの責任 English

このコンポーネントは、以下の事項に関して適用されるあらゆる条項を含みます。:

4.3. I&A(識別と認証) English

このコンポーネントは、証明書の発行に先立って、「CA もしくは RA に申請する者の身元、および/または、エンドユーザ証明書の他の属性を認証するために使われる手続」を記述します。さらに、このコンポーネントは、「その身元を認証することについての手続」および「CA や RA になることを希望している申請者や、PKI を運用していたり、PKI と相互運用していたりする他の主体を受容することについての基準を規定します。これは、また、「どのように鍵の再生成あるいは、失効をリクエストしている主体が認証されるか」も記述します。このコンポーネントは、特定の名前における登録商標権の認識を含む命名実践にも対応します。

4.3.1. 命名 English

この項目は、加入者の命名と身元確認に関する下記の要素を含みます。:

4.3.2. 初回身元検証 English

この項目は、各サブジェクト種別(CA、RA、加入者、または、他の関係者)のついて、初回登録のため I&A 手順のために下記の要素を含みます。:

4.3.3. 鍵の再生成リクエストについての I&A English

この項目は、各サブジェクト種別(CA、RA、加入者、および他の関係者)のための鍵の再生成についての I&A 手順のための下記の要素に対応します。:

4.3.4. 失効リクエストについての I&A English

この項目は、サブジェクト種別(CA、RA、加入者、および他の関係者)ごとに失効リクエストについての I&A 手順を記述します。例示には、対となる公開鍵が失効される必要があるプライベート鍵でデジタル的に署名された失効リクエストと、デジタル的に署名された RA によるリクエストが含まれます。

4.4. 証明書のライフサイクル運用的要件 English

このコンポーネントは、 証明書のライフサイクルに関して、証明書発行 CA、サブジェクト CA、RA、加入者もしくは他の関係者について提起される要件を規定するために充てられます。

各項目において、サブジェクト CA、RA、加入者および他の関係者について、別個の考慮がなされる必要がある可能性があります。

4.4.1. 証明書申請 English

この項目は、証明書申請に関する下記の要件に対応するために充てられます。:

4.4.2. 証明書申請の処理 English

この項目は、証明書申請処理についての手順を記述するために充てられます。例えば、証明書発行 CA と RA は、当該証明書申請の妥当性を検証するために I&A 手順を行う可能性があります。このような手順に従って、当該 CA もしくは RA は、おそらく何らかの枠組みに基づいて、その証明書申請を承認することもあれば、却下することもあります。最後に、この項目は、CA および/または RA が証明書申請を受理し、処理しなければならない期限を設定します。

4.4.3. 証明書の発行 English

この項目は、証明書の発行に関する下記の項目を記述するために充てられます。:

4.4.4. 証明書の受領 English

この項目は、以下の事項に対応します。:

4.4.5. 鍵ペアと証明書の利用法 English

この項目は、以下の事項を含めて、鍵と証明書の利用に関する責任を記述するために充てられます。:

4.4.6. 証明書の更新(Renewal) English

この項目は、証明書の更新に関する下記の事項を記述するために充てられます。証明書の更新は、「加入者宛に、加入者または他の関係者の公開鍵、あるいは、証明書中の他のあらゆる情報を変更することなく、新しい証明書を発行すること」を意味します。:

4.4.7. 証明書の鍵の再生成 English

この項目は、新しい鍵ペアを生成して、(新しい公開鍵を認定する)新しい証明書が発行されることについて適用する、加入者もしくは他の関係者に関する下記の要素を記述するために充てられます。:

4.4.8. 証明書の変更 English

この項目は、加入者の公開鍵以外の証明書の中にある情報の変更に起因する新しい証明書(注 6)の発行に関する下記の要素を記述するために充てられます。:

4.4.9. 証明書の失効と一時保留 English

この項目は、下記の事項に対応します。:

4.4.10. 証明書状態サービス English

この項目は、依存者が利用可能な証明書状態確認サービスに対応し、下記サービスを含みます。:

4.4.11. 登録の終了 English

この項目は、加入者によって CA サービスへの登録を終了するために行われる手順に対応し、下記手順を含みます。:

4.4.12. 鍵寄託と復旧 English

この項目は、寄託、かつ/または、(CA もしくは他の信用できる第三者を通じて)プライベート鍵寄託サービスが利用可能な場合に、プライベート鍵の復旧に関するポリシーと実践を識別するために、下記の要素を含みます。:

4.5. マネジメントコントロール、運用的コントロールおよび物理的コントロール English

このコンポーネントは、鍵生成、サブジェクトの認証、証明書発行、証明書失効、監査およびアーカイブ化の機能をセキュアに行うために、証明書発行 CA によって使われる非技術的なセキュリティコントロール(すなわち、物理的、手続的および要員的なコントロール)について記述します。

このコンポーネントは、リポジトリ、証明書発行 CA、RA、加入者および他の関係者のついての非技術的なセキュリティコントロールを規定するためにも充てられます。サブジェクト CA、RA、加入者および他の関係者について、非技術的セキュリティコントロールは、同様である/類似する/全く異なる可能性があります。

これらの非技術的なセキュリティコントロールは、証明書を信用するために、極めて重要です。なぜならば、セキュリティの欠如は、CA の運用を侵害し、例えば、証明書の誤作成、もしくは、間違った情報をもつ CRL、もしくは、CA のプライベート鍵の危殆化をもたらす可能性があるからです。

各項目中において、一般に、各主体の種別(すなわち、発行 CA、リポジトリ、被発行 CA、RA、加入者および他の関係者)について、別個の考慮がなされる必要があります。

 

4.5.1. 物理的セキュリティコントロール English

この項目において、当該主体のシステムを格納する施設についての物理的コントロールが記述されます。対応される論点には、下記事項が含まれる可能性があります。:

4.5.2. 手続的コントロール English

この項目において、信頼できる役割と認識されるための要件が、各役割についての責任と共に記述されます。信頼できる役割の例には、システム運用管理者、セキュリティ責任者およびシステム監査人が含まれます。

識別された各タスク(課業)については、そのタスクを遂行するために要求される数多くの個人(n out m ルール)が、各役割について記述される必要があります。各役割についての身元確認と本人認証の(I&A 要件も規定される可能性があります。

このコンポーネントは、同一人物によっては遂行できない役割に関する職務分轄についても含みます。

4.5.3. 要員的セキュリティコントロール English

この項目は、下記の事項に対応します。:

4.5.4. 監査ログ記録手順 English

この項目は、セキュアな環境を維持管理するために実装されるイベントログ記録と監査のシステムについて記述するために充てられます。要素には、下記の事項が含まれます。:

 

4.5.5. 記録のアーカイブ化 English

この項目は、一般的な記録アーカイブ化ポリシー(もしくは、記録の保存ポリシー)を記述するために充てられ、下記事項を含みます。:

4.5.6. 鍵 Changeover English

この項目は、新しい公開鍵を CA による re-key に伴う CA のユーザ宛に提供する手順を記述します。これらの手順は、現行の鍵を提供する手順と同様である可能性があります。また、その新しい鍵は、古い鍵を使って署名された証明書において認定される可能性があります。

4.5.7. 侵害および災害からの復旧 English

この項目は、侵害もしくは災害の時における通知と復旧の手順に関する要件を記述します。下記事項の各々は、別々に対応される必要がある可能性があります。:

4.5.8. CA もしくは RA の廃業 English

この項目は、廃業と、CA もしくは RA の廃業通知についての手順に関する要件を記述し、CA と RA のアーカイブの記録のカストディアンの身元を含みます。

 

4.6. 技術的セキュリティコントロール English

このコンポーネントは、発行 CA によって、その暗号技術的鍵とアクティべーションデータを防護するために行われるセキュリティ手段(例: PIN、パスワード、あるいは、マニュアル的に保持されている共有鍵)を規定するために充てられます。このコンポーネントは、リポジトリ、サブジェクト CA、加入者や他の関係者が、そのプライベート鍵や重要なセキュリティパラメータについてのアクティべーションデータを防護ために制約を課すためにも使われる可能性があります。セキュアな鍵管理は、「すべての秘密鍵(プライベート鍵)および活性化(activation)データが防護され、認可された者によってのみ使われること」を確保するために極めて重要です。

このコンポーネントは、証明書発行 CA によって、鍵生成、ユーザ認証、証明書の登録、証明書の失効、監査およびアーカイブ化の機能をセキュアに行うために使われる他の技術的セキュリティコントロールについても記述します。技術的なコントロールは、ライフサイクルセキュリティコントロール(ソフトウェア開発環境のセキュリティ、信用できるソフトウェア開発手法を含む。)と運用的なセキュリティコントロールを含みます。

このコンポーネントは、リポジトリ、サブジェクト CA、RA、加入者および他の関係者についての他の技術的なセキュリティコントロールを定義するのに充てることもできます。

4.6.1. 鍵ペアの生成と導入 English

鍵ペアの生成と導入は、証明書発行 CA、リポジトリ、サブジェクト CA、RA および加入者について考慮される必要があります。これらの主体の種別ごとに、下記の問いが、潜在的に答えられる必要があります。:

  1. 「誰がその主体の公開鍵・プライベート鍵の鍵ペアを生成するのか?(可能性としては加入者、RA もしくは CA が考えれれる。)」、また、「どのように鍵生成が行われたか?」、「鍵生成は、ハードウェアによって行われるのか?あるいは or ソフトウェアによって行われるのか?」
  2. どのようにプライベート鍵は、主体宛にセキュアに提供されるのか?(可能性としては、 「主体がプライベート鍵を生成し、それゆえ既にプライベート鍵をもっている場合、プライベート鍵を主体に物理的に手渡す状況」、「プライベート鍵をトークンに含めてセキュアに郵送する状況」あるいは「SSLセッションを使ってプライベート鍵を引き渡す状況」がある。)
  3. どのように主体の公開鍵が CA へセキュアに提供されるか?(可能性として、オンライン SSL セッションまたは RA の署名付きメッセージを利用することが挙げられる。)
  4. 発行 CA に関して、RA の公開鍵がどのように潜在的信頼者へセキュアに提供されるか?(可能性として、「公開鍵を信頼者本人へ直に手渡す方法」、「信頼者へコピーを物理的にセキュアに郵送する方法」あるいは「SSL セッションを使って公開鍵を引き渡す方法」が考えられる。)
  5. その鍵長は?(例:1,024 bit の RSA モジュールおよび 1,024 bit の DSA 素数等)
  6. 「誰が公開鍵のパラメータを生成するのか?」そして、「鍵生成において、パラメータの品質は、チェックされるか?」
  7. 「何の目的で、その鍵は使われる可能性があるのか?」あるいは「どのような目的で鍵用途は制限される必要があるのか?」(X.509 証明書について、これらの目的は、X.509 v3 証明書中の鍵用途フラグに対応させる必要がある。)
 

4.6.2. プライベート鍵の防護と暗号モジュールエンジニアリングコントロール English

プライベート鍵防護と暗号モジュールについての要件が、証明書発行 CA、リポジトリ、サブジェクト CA、RA および加入者について、考慮される必要があります。これらの主体のそれぞれについて、下記の問いが、潜在的に答えられる必要があります。:

  1. どのような標準が、鍵を生成するために使われる暗号モジュールに要求されるか?(そのような標準が、ある場合。)暗号モジュールは、ハードウェア、ソフトウェア、ファームウェア又はそれらの組み合わせから構成することができます。(例:「基盤によって認証された鍵は、米国FIPS 140-1に準じたモジュールを使って生成しなければならないの?。」その場合、「モジュールの要求されたFIPS 140-1のレベルは何か?」、「(暗号モジュールの境界、インプット/アウトプット、役割およびサービス、有限状態機械、物理的セキュリティ、ソフトウェアセキュリティ、OS セキュリティ、アルゴリズムの準拠性、電磁的互換性、自己テスト等の)暗号のモジュールに関連する他のエンジニアリング(あるいは他の)コントロールは、存在するか否か? 」)
  2. 「プライベート鍵は、『m 人中の n 人("n out of m")』による複数人の管理下におかれるのか?」yes である場合、n および m を規定します。(2人による管理は、n=m=2 となり、"n out of m"の特別な場合です。) (注 7
  3. 当該プライベート鍵は、寄託されているか?(注 8)その場合、「寄託機関となるのは何者か?」、「どのような形式(例:平文、暗号化されたもの、分割鍵)で鍵は寄託されるか?」 、「エスクローシステムにおけるセキュリティ管理は、どのようなものか?」
  4. 「当該プライベート鍵は、バックアップされているか?」その場合、「誰がバックアップエージェントであるのか?」、「どのような形式(例:平文、暗号化されたもの、分割鍵)を用いて鍵のバックアップは、行われるか?」、「バックアップシステムのセキュリティコントロールは、どのようなものか?」
  5. 「当該プライベート鍵は、アーカイブされるのか?」、その場合「アーカイブ機関となるのは、何者か?」、「どのような形式(例:平文、暗号化されたもの、分割鍵)で鍵はアーカイブされるのか?」、「アーカイブシステムのセキュリティコントロールは、どのようなものか?」
  6. 「どのような場合に、プライベート鍵を暗号モジュールの中へ又は暗号モジュールから転送することができるか?」、「このような運送作業を行うことが許可されているのは誰か?」、「 その移行中に、プライベート鍵はどのような形式(例:平文、暗号化されたもの、分割鍵)の中におかれるか?」
  7. どのようにプライベート鍵は、モジュール中に保管されるか?(すなわち、平文、暗号化されたもの、分割鍵)
  8. 「誰がプライベート鍵をアクティベート(利用)できるか?」、「プライベート鍵を活性化させるためにどのような行為が行われなければならないか?」(例:ログイン、電源を入れる、PINを入力する、トークン/鍵を差し込む、自動的に等)、「一旦、鍵がアクティベートされたら、永久に鍵を使えるのか?」、「一度きりしか使えないのか?」あるいは「定義された期間のみ使えるのか?」
  9. 誰が、どのようにプライベート鍵を非活性化しうるのか?(プライベート鍵を非活性化する方法の例:ログアウト、「電源を切る」、「トークン/鍵を取り外す」、「自動的に非活性化する」および「時間切れ」)
  10. 誰が、どのようにプライベート鍵を破棄することができるか?(プライベート鍵の破壊方法の例:トークンの解約、トークンの破棄および鍵の上書き)
  11. 暗号モジュールの能力を下記の領域の中に定める。: 「暗号モジュールの境界」、「インプット/アウトプット」、「役割およびサービス」、「有限状態機械」、「物理的セキュリティ」、「ソフトウェアセキュリティ」、「OS セキュリティ」、「アルゴリズムの準拠性」、「電磁気の互換性」および「自己検証の認識」。能力については、米国 FIPS 140-1、関連レベルおよび格付け評価等の標準への準拠性を参照することによって記述される可能性がある。
 

4.6.3. 鍵ペア管理の他の観点 English

鍵管理の他の観点が証明書発行 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、信用されたパス、セキュリティ検査および侵入検査。 製品保証も対応される可能性があります。

コンピュータ システムについて、コンピュータセキュリティの格付けが要求される可能性があります。その格付けは、例えば、

 

に基づくことができます。この項目は、製品評価分析、製品試験、プロファイリング、製品認定、および/または、行われている活動に関する 製品の運用承認(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

この項目は、ファイアウォール等、ネットワークセキュリティ関連コントロールに対応します。

4.6.8. タイムスタンプ English

この項目は、様々なデータについてのタイムスタンプの利用に関する要件または実践に対応します。これは、「タイムスタンプを付すアプリケーションが信用できる時刻の源泉を使わなければならないか否か」も検討することができます。

4.7. 証明書と CRL のプロファイル English

このコンポーネントは、証明書フォーマットを、CRL および/または OCSP が使われている場合は、当該 CRL および/または OCSP フォーマットを規定するために充てられます。これは、使われているプロファイル、バージョンおよび拡張についての情報を含みます。

4.7.1. 証明書プロファイル English

この項目は、(潜在的に、IETF PKIX RFC 3280 において定義されているもののような独立したプロファイル定義に対する参照によって)下記のような論点に対応します。:

4.7.2. CRL プロファイル English

この項目は、(IETF PKIX RFC 3280 中で規定されたもののように、別のプロファイル定義を場合によっては参照することによって)、
潜在的には、下記のような論点に対応します。:

4.7.3. OCSP プロファイル English

この項目は、(潜在的に、IETF RFC 2560 プロファイルのような別のプロファイル定義への参照によって)下記のような論点に対応します。:

 

4.8. 準拠性監査と他の評価 English

このコンポーネントは、下記事項に対応します。:

 

4.9. 他の業務事項と法的事項 English

このコンポーネントは、一般的な業務事項と法的事項を扱います。このフレームワークの 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 が、責任を制限するための特定の規定を適用することに関連した「加入者との合意」または「信頼者との合意」を使うことについて述べることもできます。

4.9.1. 料金 English

この項目は、CA、リポジトリもしくは RA によって課せられる料金に関する、下記のような、あらゆる適用可能な規定を含みます。:

4.9.2. 財務的責任 English

この項目には、「PKI の運用上の責任を遂行するため」および「そのような運用から生じる請求に関する判決又は和解の支払いを行う責任がある場合の支払能力を維持し、損害を支払うため」に、CA、RA または認証サービスを提供している他の関係者が利用可能な財源に関する要件もしくは情報開示について記述されます。このような規定には、下記のものが含まれます。:

 

4.9.3. ビジネス情報の秘匿性 English

この項目は、関係者がお互いに交換することができる秘密のビジネス情報の取り扱いに関する規定が含まれます。例えば、事業計画書、売上高情報、企業秘密および秘密保持契約のもとにおいて第三者から受領した情報が挙げられます。具体的には、この項目は、下記事項に対応します。:

4.9.4. 個人情報のプライバシーEnglish

この項目は、関係者(特に、CA、RA、リポジトリー)が、個人的に証明書申請者、加入者および他の関係者の身元確認が可能な個人情報を提供するように要求される可能性に関連します。具体的には、この項目は、適用法に準じて適切な範囲内で下記事項に対応します。:

関係者が、民間、または公的な司法手続、行政手続その他の法的手続について、裁判的行政措置に従って個人情報を開示する権限を有する(または要求される)あらゆる状況

4.9.5. 知的財産権 English

この項目は、特定の関係者が CP、CPS、証明書、名前および鍵の中に有したり、あるいは、有すると主張することができるような著作権、特許、登録商標、もしくは営業秘密のような知的財産権、あるいは、又は関係者に対するライセンス若しくは関係者からのライセンスの対象となるようなものに対応します。

 

4.9.6. 表現および保証 English

この項目には、当該 CP もしくは CPS に従って作成された様々な主体の表現と保証を含めることができます。例えば、契約として扱われる CPS は、「当該証明書中にある情報は、正確である」という CA の保証を含む可能性があります。これに対して、CPS は、「証明書中の情報は、正当な注意を払って一定の身元認証手続を行った後には、CA が最大限知る限り真実である」という限定的な保証しか与えません。この項目は、「表明保証を『加入者との合意』または『信頼者との合意』のような特定の合意の中に示す」という要件も、含む可能性があります。例えば、CP は、「すべての CA が『加入者との合意』を援用すること」および「『加入者協定』の中には証明書中の情報が正確であることについて、CA の保証を含まなければならない」という要件が含まれる可能性がある。表明や保証を行う可能性がある加入者には、CA、RA、加入者、信頼者および他の関係者が含まれます。

4.9.7. 保証の免責事項 English

この項目には、「この項目が無ければ合意中に存在すると見なされる明示の保証を行わないこと」および「この項目が無ければ適用法によって課される黙示の保証を行わないこと」(例:特定の目的に対する商品性または適合性の保証)を含めることができます。その CP もしくは CPS は、このような免責事項を直接提起する可能性があり、あるいは、当該 CP もしくは CPS は、「免責事項が、加入者との合意、もしくは、信頼者との合意のような関連文書に記述される」という要件を含む可能性があります。

4.9.8. 責任の制限 English

この項目は、「CP・CPSにおける責任の制限」あるいは、「『加入者との合意』または『信頼者との合意』のような CP・CPS に関連した協定の中に示す(あるいは、示さなければならない)制限を含むことができます。これらの制限は、下記の 2つの分類のうち、いずれかに分けることができます。(ひとつは、回復可能な損害の要件についての制限。もうひとつは、責任の上限としても認識される回復可能な損害額の制限。)しばしば、契約は、付随的かつ必然的な損害、時には懲罰的損害といった損害要素の回復を禁止する条項を含みます。頻繁に契約は、一当事者(または他の当事者)に対して可能な回復額を、売主が契約に基づき支払いを受けた額のような一定の額(もしくは基準に準じた額)に限定する条項を含みます。

4.9.9. 補償(Indemnities) English

この項目は、「典型的には一方当事者の行為から発生するが、他方当事者が生じさせた損失または損害すべてを一方当事者が他方当事者に対して賠償する旨」の規定を含みます。それらは、CP、CPS もしくは合意にある可能性があります。例えば、CP は、CA が加入者に不正確な証明書を発行した場合、それが、証明書の申請書上の加入者による不正な誤表明から生じたものであれば、CA が被った損失に対して、加入者が CA へ賠償を行う義務がある旨の条項を「加入者との合意」におくよう要求することができます。同様に、CPS は、信頼者が適切に失効情報を調べずに行った証明書の使用、又は CA の許可の範囲外の目的での証明書の使用によって、CA が被った損失について信頼者が CA に対し賠償する義務があることを定める「信頼者との合意」を CA が使用する旨定めることができます。

4.9.10. 期間と廃業 English

この項目は、CP・CPS が有効とされる期間および文書、文書の一部、その文書の特定の関係者に対する有効性が終了する期間を含む可能性があります。これに加えて、あるいは、これに代えて、その CP もしくは CPS は、特定の有効期間と終了条項を「加入者との合意」もしくは「信頼者との合意」のような協定の中に示すことを要件を含む可能性があります。特に、このような条件は、下記の事項を含む可能性があります。:

4.9.11. 関係者間の個別通知と伝達 English

この項目は、ある関係者が他の関係者との伝達を法的に有効とするために行われる他の関係者と個別に連絡しあうことができる(あるいは、連絡しあわなければならない)方法を検討します。例えば、RA は、CA との協定を終了したい旨を CA に対して知らせることを望む可能性があります。この項目は、発行機能やリポジトリ機能とは別のものです。なぜならば、公開およびリポジトリーへの送信は、この項目中で述べる個別の連絡とは異なって、(すべての信頼者宛のように)不特定多数の読者への伝達を目的としているからです。この項目は、伝達のための仕組みを作り、そしてそのような伝達の経路に使われるべき連絡先情報を示すことができます。(例:特定の連絡先へのデジタル署名付き電子メールでの通知、それを受領したことを伝える署名付き電子メールの承認)

4.9.12. 改訂 English

ときとして、CP もしくは CPS を改訂することが必要不可欠であることがあります。これらの変更には、認証ポリシー、または、その履行による保証を著しく減じるものではなく、証明書の受領可能性に重大な影響を与えないため、ポリシー管理者によって判断されます。このような CP もしくは CPS に対する変更は、CP OID もしくは、その CPS ポインタ(URL)について、変更を要求しません。他方、仕様に対する変更には、特定の目的についての証明書の受領可能性を著しく変えるものがあり、これらの変更は、対応するCPオブジェクト識別子、または、CPSポインター修飾子(URL)の変更を要する可能性があります。

この項目は、下記の情報も含む可能性があります。:

4.9.13. 紛争解決手続 English

この項目は、CP、CPS、かつ/または、合意から提起される争議を解決するために援用される手順を検討します。このような手順の例には、紛争がある特定の会議体において、または、代替的紛争解決手段(ADR)によって解決されるものとする
要件が含まれます。

4.9.14. 準拠法 English

この項目は、「一定の司法権に属する法が、解釈に適用される」 という言明と、「対象となる CP、CPS もしくは協定の適用」を規定します。

 

4.9.15. 適用可能な法への準拠性 English

この項目は、「関係者は、適用法を遵守する」(例: 特定の司法権における輸出規制法の適用を受ける暗号技術的なハードウェアやソフトウェアに関する法律)という要件に関するものです。当該 CP もしくは CPS は、このような要件を課すことを表明する可能性があり、あるいは、「他の合意中に、このような規定をおくこと」を要求する可能性があります。

4.9.16. 雑則 English

この項目は、(しばしば、契約において「ボイラープレート条項(boilerplate provisions)」と呼ばれる)雑則を含みます。この項目で扱われる条項は、CP、CPS もしくは合意にある可能性があり、下記事項を含む可能性があります。:

4.9.17. 他の条項 English

この項目は、「このフレームワークの他の章および節にうまく当てはまらない追加的な責任および条項を PKI 関係者に課すことができる」という、いわゆるキャッチオール条項のための箇所である。CP や CPS の執筆者は、この項目の中に、別の項目によって扱われていないあらゆる項目を置くことができます。

 

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

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、リポジトリ、加入者システムおよび信頼者システムのような)のセキュアな運用を確保することを指向しています。

 

6. 規定集の概要 English

この章は、CP もしくは CPS の執筆者によって使われるチェックリスト、もしくは、(さらに発展可能な)標準テンプレートの役割を果たすことが意図された規定集について推奨される章立てを含みます。このような共通概要は、下記事項を容易にします。:

(a) 横断認証、あるいは、(同等性マッピング目的の)他の形態の相互運用の際に、2 つの証明書ポリシーの比較。

(b) 「CPS が誠実にポリシーを実施していること」を確認するための当該 CPS の CP との比較。

(c) 2 つの CPS の比較。

RFC に準拠するために、準拠する CP もしくは CPS の執筆者には、この構成に従うことが強く推奨されます。代替的な構成の利用は止めていただきたいですが、逸脱について適切な正当化が示され、かつ、「この構成において記述された各要素がどこに書かれているか」を見分けられるための対応表が示される場合、許容される可能性があります。

 

7. RFC 2527 との比較 English

このフレームワークは、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

(作業中)

 

8. 謝辞 English

以前の版である文書(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 も、貢献してくださいました。

 

9. 参考文献

[ABA1] American Bar Association,
Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Secure Electronic Commerce,
1996年.
 
[ABA2] American Bar Association, PKI Assessment Guidelines, v0.30, Public Draft For Comment,
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月.

10. 注記事項 English

  1. ABA DSG(デジタル署名 Guidelines)のコピーは、ABA から購入することができます。詳細については、http://www.abanet.com 参照。DSG は、下記の ABA の web サイトからも無償でダウンロードできます。
    http://www.abanet.org/scitech/ec/isc/digital_signature.html

  2. "the PKI Assessment Guidelines" のドラフトは、ABA の Web サイト(http://www.abanet.org/scitech/ec/isc/pag/pag.html)から無償でダウンロードできます。
  3. 「有意(meaningful)」という用語は、「名前の形式は、個人、かつ/または、組織体の身元を判定するために、広く理解される意味論をもつこと」を意味します。ディレクトリ名と RFC 822 名は、多かれ少なかれ有意でしょう。
  4. CA がサブジェクトに代わってサブジェクトの鍵ペアを生成する場合、サブジェクトは、CA に対しては登録されている公開鍵に対応するプライベート鍵を保有しているということを証明する必要はありません。
  5. 個人を識別し認証する手段の例は、(拇印、10本の指紋、および顔、手のひら、又は 網膜のスキャン等の)バイオメトリックな手段、運転免許証、クレジットカード、社章、および政府職員証明書等を含みます。
  6. 証明書の「変更(modification)」は、既存の証明書に変更を行うことを指すわけではありません。なぜならば、この行為が証明書に対してのすべてのデジタル署名検証を妨げ、証明書が無効となることを引き起こすからです。むしろ、「変更」の概念は、証明書内に参照された情報が変更された、又は変更されるべき状況を指し、それに伴って CA は、変更された情報を含む新しい証明書を発行します。一例として、「彼(もしくは彼女)の名前を変更する加入者」が挙げられます。これは、新しい氏名を含む新証明書の発行を必要不可欠とします。
  7. 「n out of mルール」は、プライベート鍵を m 個の部分に分けるものです。 m 個の部分は、異なる m 人へ与えることができます。
    すべての m 部分中の n  部分は、プライベート鍵を完全に再構成するために使えますが、n-1 部分ではプライベート鍵についての情報を全く提供しません。
  8. プライベート鍵は、寄託(エスクロー)、バックアップもしくはアーカイブされる可能性があります。これらの機能の各々は、異なる目的をもっています。それゆえ、プライベート鍵には、要件に応じて、これらの機能のどれでも、適用できます。寄託の目的は、「(組織体もしくは政府のような)第三者が加入者の協力無しに、そのプライベート鍵を入手できるようにすること」にあります。バックアップの目的は、「鍵の破壊もしくは頽廃が起きた場合、加入者にビジネスの継続を目的としての鍵の再構成を行えるようにすること」にあります。アーカイブの目的は、「将来におけるプライベート鍵の再利用のために提供すること」にあります。(例: 文書を複合するために利用)
  9. "WebTrust" とは、アメリカ公認会計士協会とカナダ勅許会計士協会から発行されている「CA のための Web トラストプログラム」のことを言います。
  10. <http://www.aicpa.org> を参照。
  11. この章に挙げる要素の全部または一部は、様々な主体の種類(すなわち、CA、RA およびエンドエンティティ)ごとに異なる可能性があります。

 

11. 頭字語一覧

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

 

12. 著者のアドレス

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

電話: (703) 237-4621
Fax: (703) 237-4920
EMail: chokhani@orionsec.com

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

電話: (617) 642-0139
EMail: wford@verisign.com

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

電話: (703) 456-8137
Fax: (703) 456-8100
EMail: rsabett@cooley.com

Charles (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.com

Stephen 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

 

13. 著作権表記全文

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.