|
ネットワーク 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月 |
このメモは、インターネットコミュニティに情報提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2003). All Rights Reserved.
本書は、CA(認証局)、ポリシー機関、および、 証明書に依存しようとしている利害関係者のように、 PKIにおける関係者のために証明書ポリシーもしくは認証実施フレームワークを書く人を支援するためのフレームワークを提供します。 特に、このフレームワークは、 証明書ポリシーもしくは認証実施フレームワークにおいて、 潜在的に網羅される必要のある諸論点について、 わかりやすい一覧を提供します。 本書によって、RFC 2527 は、 廃止されます。
一般に、公開鍵証明書(以降、「証明書」)は、「(個人、組織、アカウント、 デバイスもしくはサイトのような)主体によって保持される公開鍵」を、 「対応するプライベート鍵を利用する主体を識別する一式の情報」に結合します。 身元確認用の証明書に関する多くの場合、この主体は、 証明書の「サブジェクト(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)の一般的な概念になじみがある」と想定します。
本書は、下記に定義された用語を使います。：
この章は、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] に規定されています。：
ポリシー修飾子は、一般的な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を参照によって組み込み、それによって、 このような合意に各主体を拘束する条項を設けるものがある可能性があります。
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間の主な相違点は、 下記のように要約することができます。：
証明書ポリシー拡張を適用可能なCPオブジェクト識別子とともに配置することに加えて、 CAは、発行する証明書中に、そのCPSへの参照を含む可能性があります。 CP修飾子を使ってこれを行う標準的なやり方は、 3.4節に記述されています。
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において参照する可能性がある文書には、 以下のものがあります。：
規定集は、 下記の第5章にある論点を網羅することによって、 このフレームワークに記述されたアプローチを採用したCPもしくはCPSの表現時における利用についての標準的な論点にわたる実践、 かつ／または、ポリシー宣言の集大成となります。 これらは、 下記の第4章においても詳細に記述されています。
CPは、単一の規定集として表現できます。
CPSは、各コンポーネントが、ひとつ、もしくは、 複数の証明書ポリシーの要件に対応する単一の規定集として、あるいは、 代わりに、編成された規定集として表現することができます。 例えば、CPSは、下記事項の組み合わせとして表現できます。：
b. とc. において提供される言明は、適用可能なCPの規定を強化したり、 あるいは、洗練する可能性がありますが、一般に、 そのようなCPのいかなる規定とも矛盾してはなりません。 しかし、場合によっては、ポリシー機関は、 CP中の要件の例外を許容する可能性があります。 なぜなら、特定のCAの補償(compensating)コントロールが、 CAに「当該CPに完全準拠したCAによって提供される保証と同等の保証を提供すること」を認めているCPS中に開示されているからです。
このフレームワークは、下記のように、 規定集の内容を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章中に述べられた項目の下に、 追加的な項目を追加することが許されています。
この章は、 (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オブジェクト識別子を含む)を提供します。 このような文書名の例として、 「セキュアな電子メールについての米国連邦政府ポリシー」が挙げられます。
この項目は、 PKIにおいて一定の役割を果たす主体の身元もしくは種別を記述します。：
この項目は、下記の事項を含みます。：
かつ／または、
CPもしくはCPSが異なるレベルの保証を記述している場合、この項目は、 異なる保証のレベルについて適する／適さない、 アプリケーション(そのもの)あるいはアプリケーションの種類を記述することができます。
この項目は、このCPもしくはCPSの執筆、登録、 維持管理および更新に責任を負う組織体の名前と郵便先住所を含みます。 これは、また、連絡先担当者の名前、電子メールアドレス、電話番号、 ファックス番号も含みます。 実際の人間を命名する代わりに、その文書は、肩書きもしくは役職、 電子メールのエイリアスおよび他の一般化された連絡先情報を指名する可能性があります。 場合によっては、その組織体は、「その連絡先担当者が、(独り、もしくは、 他者との組で)当該文書についての質問に回答できること」を述べることができます。
さらに、公式／非公式のポリシー決定機関が「CAは、 あるPKI中において運用すること、あるいは、 他のPKIと相互運用することを許可される必要があるか否かを判断すること」について責任を負うとき、これは、 当該CAのCPSを、 そのポリシー決定機関のCPに照らして適切であるとして承認することを望む可能性があります。 その場合、この項目は、そのような意思決定を行う者の名前もしくは肩書き、 電子メールアドレス(もしくはエイリアス)、電話番号、ファックス番号、 および他の一般情報を含む可能性があります。 最後に、この場合、この項目は、この意思決定を行う手順も含みます。
この項目は、文書中の頭字語の一覧と、それらの意味とともに、 その文書中で使われている定義された用語についての定義の一覧を含みます。
このコンポーネントは、 以下の事項に関して適用されるあらゆる条項を含みます。：
このコンポーネントは、証明書の発行に先立って、 「CAもしくはRAに申請する者の身元、および／または、 エンドユーザ証明書の他の属性を認証するために使われる手続」を記述します。 さらに、このコンポーネントは、 「その身元を認証することについての手続」および「CAやRAになることを希望している申請者や、 PKIを運用していたり、 PKIと相互運用していたりする他の主体を受容することについての基準を規定します。 これは、また、「どのように鍵の再生成あるいは、 失効をリクエストしている主体が認証されるか」も記述します。 このコンポーネントは、 特定の名前における登録商標権の認識を含む命名実践にも対応します。
この項目は、加入者の命名と身元確認に関する下記の要素を含みます。：
この項目は、各サブジェクト種別(CA、RA、加入者、または、 他の関係者)のついて、初回登録のためI&A手順のために下記の要素を含みます。：
この項目は、各サブジェクト種別(CA、RA、加入者、 および他の関係者)のための鍵の再生成についてのI&A手順のための下記の要素に対応します。：
この項目は、サブジェクト種別(CA、RA、加入者、 および他の関係者)ごとに失効リクエストについてのI&A手順を記述します。 例示には、対となる公開鍵が失効される必要があるプライベート鍵でデジタル的に署名された失効リクエストと、 デジタル的に署名されたRAによるリクエストが含まれます。
このコンポーネントは、 証明書のライフサイクルに関して、証明書発行CA、 サブジェクトCA、RA、 加入者もしくは他の関係者について提起される要件を規定するために充てられます。
各項目において、サブジェクトCA、RA、加入者および他の関係者について、 別個の考慮がなされる必要がある可能性があります。
この項目は、証明書申請に関する下記の要件に対応するために充てられます。：
この項目は、証明書申請処理についての手順を記述するために充てられます。 例えば、証明書発行CAとRAは、 当該証明書申請の妥当性を検証するためにI&A手順を行う可能性があります。 このような手順に従って、当該CAもしくはRAは、 おそらく何らかの枠組みに基づいて、 その証明書申請を承認することもあれば、却下することもあります。 最後に、この項目は、CAおよび／またはRAが証明書申請を受理し、 処理しなければならない期限を設定します。
この項目は、証明書の発行に関する下記の項目を記述するために充てられます。：
この項目は、以下の事項に対応します。：
この項目は、以下の事項を含めて、 鍵と証明書の利用に関する責任を記述するために充てられます。：
この項目は、 証明書の更新に関する下記の事項を記述するために充てられます。 証明書の更新は、「加入者宛に、加入者または他の関係者の公開鍵、 あるいは、証明書中の他のあらゆる情報を変更することなく、 新しい証明書を発行すること」を意味します。：
この項目は、新しい鍵ペアを生成して、 (新しい公開鍵を認定する)新しい証明書が発行されることについて適用する、 加入者もしくは他の関係者に関する下記の要素を記述するために充てられます。：
この項目は、 加入者の公開鍵以外の証明書の中にある情報の変更に起因する新しい証明書 (注6)の発行に関する下記の要素を記述するために充てられます。：
この項目は、下記の事項に対応します。：
この項目は、依存者が利用可能な証明書状態確認サービスに対応し、 下記サービスを含みます。：
この項目は、 加入者によってCAサービスへの登録を終了するために行われる手順に対応し、 下記手順を含みます。：
この項目は、寄託、かつ／または、 (CAもしくは他の信用できる第三者を通じて) プライベート鍵寄託サービスが利用可能な場合に、 プライベート鍵の復旧に関するポリシーと実践を識別するために、 下記の要素を含みます。：
このコンポーネントは、鍵生成、サブジェクトの認証、証明書発行、 証明書失効、監査およびアーカイブ化の機能をセキュアに行うために、 証明書発行CAによって使われる非技術的なセキュリティコントロール(すなわち、 物理的、手続的および要員的なコントロール)について記述します。
このコンポーネントは、リポジトリ、証明書発行CA、RA、 加入者および他の関係者のついての非技術的なセキュリティコントロールを規定するためにも充てられます。 サブジェクトCA、RA、加入者および他の関係者について、 非技術的セキュリティコントロールは、 同様である／類似する／全く異なる可能性があります。
これらの非技術的なセキュリティコントロールは、 証明書を信用するために、極めて重要です。 なぜならば、セキュリティの欠如は、CAの運用を侵害し、例えば、 証明書の誤作成、もしくは、間違った情報をもつCRL、もしくは、 CAのプライベート鍵の危殆化をもたらす可能性があるからです。
各項目中において、一般に、各主体の種別(すなわち、発行CA、リポジトリ、 被発行CA、RA、加入者および他の関係者)について、 別個の考慮がなされる必要があります。
この項目において、 当該主体のシステムを格納する施設についての物理的コントロールが記述されます。 対応される論点には、下記事項が含まれる可能性があります。：
この項目において、信頼できる役割と認識されるための要件が、 各役割についての責任と共に記述されます。 信頼できる役割の例には、システム運用管理者、 セキュリティ責任者およびシステム監査人が含まれます。
識別された各タスク(課業)については、 そのタスクを遂行するために要求される数多くの個人(n out mルール)が、 各役割について記述される必要があります。 各役割についての身元確認と本人認証の (I&A要件も規定される可能性があります。
このコンポーネントは、 同一人物によっては遂行できない役割に関する職務分轄についても含みます。
この項目は、下記の事項に対応します。：
この項目は、 セキュアな環境を維持管理するために実装されるイベントログ記録と監査のシステムについて記述するために充てられます。 要素には、下記の事項が含まれます。：
この項目は、一般的な記録アーカイブ化ポリシー(もしくは、 記録の保存ポリシー)を記述するために充てられ、下記事項を含みます。：
この項目は、 新しい公開鍵をCAによるre-keyに伴うCAのユーザ宛に提供する手順を記述します。 これらの手順は、現行の鍵を提供する手順と同様である可能性があります。 また、その新しい鍵は、 古い鍵を使って署名された証明書において認定される可能性があります。
この項目は、 侵害もしくは災害の時における通知と復旧の手順に関する要件を記述します。 下記事項の各々は、別々に対応される必要がある可能性があります。：
この項目は、廃業と、 CAもしくはRAの廃業通知についての手順に関する要件を記述し、 CAとRAのアーカイブの記録のカストディアンの身元を含みます。
このコンポーネントは、発行CAによって、 その暗号技術的鍵とアクティべーションデータを防護するために行われるセキュリティ手段(例：PIN、 パスワード、あるいは、 マニュアル的に保持されている共有鍵)を規定するために充てられます。 このコンポーネントは、リポジトリ、サブジェクト CA、 加入者や他の関係者が、 そのプライベート鍵や重要なセキュリティパラメータについてのアクティべーションデータを防護するために制約を課すためにも使われる可能性があります。 セキュアな鍵管理は、 「すべての秘密鍵(プライベート鍵)および活性化(activation)データが防護され、 認可された者によってのみ使われること」を確保するために極めて重要です。
このコンポーネントは、証明書発行CAによって、鍵生成、ユーザ認証、 証明書の登録、証明書の失効、 監査およびアーカイブ化の機能をセキュアに行うために使われる他の技術的セキュリティコントロールについても記述します。 技術的なコントロールは、 ライフサイクルセキュリティコントロール (ソフトウェア開発環境のセキュリティ、信用できるソフトウェア開発手法を含む。) と運用的なセキュリティコントロールを含みます。
このコンポーネントは、リポジトリ、サブジェクトCA、RA、 加入者および他の関係者についての他の技術的なセキュリティコントロールを定義するのに充てることもできます。
鍵ペアの生成と導入は、証明書発行CA、リポジトリ、サブジェクトCA、 RAおよび加入者について考慮される必要があります。 これらの主体の種別ごとに、下記の問いが、 潜在的に答えられる必要があります。：
プライベート鍵防護と暗号モジュールについての要件が、 証明書発行CA、リポジトリ、サブジェクトCA、RAおよび加入者について、 考慮される必要があります。 これらの主体のそれぞれについて、下記の問いが、 潜在的に答えられる必要があります。：
鍵管理の他の観点が証明書発行CA、リポジトリ、サブジェクトCA、RA、 加入者、および他の関係者について考慮される必要があります。 これらの主体の各々について、下記の問いが、 潜在的に答えられる必要があります。：
アクティべーションデータとは、 「プライベート鍵又はプライベート鍵を含んでいる暗号モジュールを運用するために必要とされる、 すべてのプライベート鍵以外のデータ値(例：PIN、パスフレーズ、または、 鍵分割スキームの中で使用されたプライベート鍵の一部)」を言います。 アクティべーションデータの防護は、 プライベート鍵の認可されていない利用を予防し、潜在的に、発行CA、 サブジェクトCA、RAおよび加入者においては考慮される必要があります。 このような考慮は、潜在的に、 生成からアーカイブおよび破棄に至るまでのアクティべーションデータの全ライフサイクルに対応する必要があります。 エンティティの種類(証明書発行CA、リポジトリー、証明書被発行CA、RA、 加入者その他の関係者)ごとに、 4.6.1節から4.6.3節までに挙げた質問のすべてについて、 (鍵に関してというよりも、むしろ)アクティべーションデータに関して、 潜在的には回答される必要があります。
この項目は、
下記のようなコンピュータセキュリティコントロールを記述するために充てられます。：
TCB (Trusted Computing Base)の概念の利用concept,
DAC(自由裁量的アクセスコントロール)、ラベル、
MAC(強制的アクセスコントロール)、オブジェクトの再利用、監査、I&A、
信用されたパス、セキュリティ検査および侵入検査。
製品保証も対応される可能性があります。
コンピュータ システムについて、 コンピュータセキュリティの格付けが要求される可能性があります。 その格付けは、例えば、
に基づくことができます。 この項目は、製品評価分析、製品試験、プロファイリング、製品認定、 および／または、行われている活動に関する製品の運用承認(accreditation)についての要件にも対応できます。
この項目は、 システム開発コントロールとセキュリティ管理的コントロールに対応します。
システム開発コントロールは、開発環境セキュリティ、 開発要員のセキュリティ、製品保守期間中の設定管理セキュリティ、 ソフトウェアエンジニアリング実践、ソフトウェア開発手法、モジュール化、 階層化、フェイルセーフな設計と実装テクニック(例：defensive programming)の利用、および、開発施設のセキュリティを含みます。
セキュリティ管理コントロールは、 「運用システムやネットワークが設定されたセキュリティを固守していること」を検証するためのツールと手順の実行を含みます。 これらのツールや手順は、正しい運用を確保するために、 セキュリティソフトウェア、 ファームウェアおよびハードウェアのインテグリティをチェックすることを含みます。
この項目は、例えば、TSDM (Trusted Software Development Methodology)レベルIVおよびV、 独立したライフサイクルのセキュリティコントロール監査や、 SEI-CMM (Software Engineering Institute's Capability Maturity Model)に基づくセキュリティレイティングにも対応することができます。
この項目は、ファイアウォール等、 ネットワークセキュリティ関連コントロールに対応します。
この項目は、 様々なデータについてのタイムスタンプの利用に関する要件または実践に対応します。 これは、 「タイムスタンプを付すアプリケーションが信用できる時刻の源泉を使わなければならないか否か」も検討することができます。
このコンポーネントは、証明書フォーマットを、 CRLおよび／またはOCSPが使われている場合は、 当該CRLおよび／またはOCSPフォーマットを規定するために充てられます。 これは、使われているプロファイル、 バージョンおよび拡張についての情報を含みます。
この項目は、(潜在的に、IETF PKIX RFC 3280において定義されているもののような独立したプロファイル定義に対する参照によって)下記のような論点に対応します。：
この項目は、(IETF PKIX RFC 3280中で規定されたもののように、 別のプロファイル定義を場合によっては参照することによって)、 潜在的には、下記のような論点に対応します。：
この項目は、(潜在的に、IETF RFC 2560プロファイルのような別のプロファイル定義への参照によって) 下記のような論点に対応します。：
このコンポーネントは、下記事項に対応します。：
このコンポーネントは、一般的な業務事項と法的事項を扱います。 このフレームワークの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によって課せられる料金に関する、 下記のような、あらゆる適用可能な規定を含みます。：
この項目には、 「PKIの運用上の責任を遂行するため」および「そのような運用から生じる請求に関する判決又は和解の支払いを行う責任がある場合の支払能力を維持し、 損害を支払うため」に、CA、 RAまたは認証サービスを提供している他の関係者が利用可能な財源に関する要件もしくは情報開示について記述されます。 このような規定には、下記のものが含まれます。：
この項目は、 関係者がお互いに交換することができる秘密のビジネス情報の取り扱いに関する規定が含まれます。 例えば、事業計画書、売上高情報、 企業秘密および秘密保持契約のもとにおいて第三者から受領した情報が挙げられます。 具体的には、この項目は、下記事項に対応します。：
この項目は、関係者(特に、CA、RA、リポジトリー)が、 個人的に証明書申請者、 加入者および他の関係者の身元確認が可能な個人情報を提供するように要求される可能性に関連します。 具体的には、この項目は、 適用法に準じて適切な範囲内で下記事項に対応します。：
この項目は、特定の関係者がCP、CPS、証明書、 名前および鍵の中に有したり、あるいは、 有すると主張することができるような著作権、特許、登録商標、 もしくは営業秘密のような知的財産権、あるいは、 又は関係者に対するライセンス若しくは関係者からのライセンスの対象となるようなものに対応します。
この項目には、 当該CPもしくはCPSに従って作成された様々な主体の表現と保証を含めることができます。 例えば、契約として扱われるCPSは、 「当該証明書中にある情報は、 正確である」というCAの保証を含む可能性があります。 これに対して、CPSは、「証明書中の情報は、 正当な注意を払って一定の身元認証手続を行った後には、 CAが最大限知る限り真実である」という限定的な保証しか与えません。 この項目は、 「表明保証を『加入者との合意』または『信頼者との合意』のような特定の合意の中に示す」という要件も、 含む可能性があります。 例えば、CPは、「すべてのCAが『加入者との合意』を援用すること」および「『加入者協定』の中には証明書中の情報が正確であることについて、 CAの保証を含まなければならない」という要件が含まれる可能性がある。 表明や保証を行う可能性がある加入者には、CA、RA、加入者、 信頼者および他の関係者が含まれます。
この項目には、 「この項目が無ければ合意中に存在すると見なされる明示の保証を行わないこと」および「この項目が無ければ適用法によって課される黙示の保証を行わないこと」 (例：特定の目的に対する商品性または適合性の保証)を含めることができます。 そのCPもしくはCPSは、このような免責事項を直接提起する可能性があり、 あるいは、当該CPもしくはCPSは、「免責事項が、加入者との合意、 もしくは、信頼者との合意のような関連文書に記述される」という要件を含む可能性があります。
この項目は、「CP・CPSにおける責任の制限」あるいは、 「『加入者との合意』または『信頼者との合意』のようなCP・CPSに関連した協定の中に示す (あるいは、示さなければならない)制限を含むことができます。 これらの制限は、下記の2つの分類のうち、いずれかに分けることができます。 (ひとつは、回復可能な損害の要件についての制限。 もうひとつは、責任の上限としても認識される回復可能な損害額の制限。) しばしば、契約は、付随的かつ必然的な損害、 時には懲罰的損害といった損害要素の回復を禁止する条項を含みます。 頻繁に契約は、一当事者(または他の当事者)に対して可能な回復額を、 売主が契約に基づき支払いを受けた額のような一定の額(もしくは基準に準じた額)に限定する条項を含みます。
この項目は、「典型的には一方当事者の行為から発生するが、 他方当事者が生じさせた損失または損害すべてを一方当事者が他方当事者に対して賠償する旨」の規定を含みます。 それらは、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、かつ／または、 合意から提起される争議を解決するために援用される手順を検討します。 このような手順の例には、紛争がある特定の会議体において、または、 代替的紛争解決手段(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の執筆者によって使われるチェックリスト、 もしくは、(さらに発展可能な)標準テンプレートの役割を果たすことが意図された規定集について推奨される章立てを含みます。 このような共通概要は、下記事項を容易にします。：
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 - 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.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
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.