1 PKI 管理の概要 English
PKI（システム）は、それを管理する個人の役割と一致するように構築されなければなりません。仮に選択余地が無限な管理者がいるとしたら、必要なソフトを煩雑化するばかりでなく、管理者またはソフトウェア開発者による微かな誤りによって広範囲の信用喪失の結果になってしまう危険性が増えます。同じように、扱いにくい仕組みを使って管理者を制限するとしたら、管理者が PKI の 利用を放棄してしまう恐れがあります。
管理プロトコルは、 公開鍵基盤( PKI ) コンポーネント間のオンラインイントラクションをサポートする必要があります。例えば、認証局( CA )と鍵ペアで結び付けられているクライアントシステムとの間に、もしくは、相互認証証明書（cross-certificate）を相互に発行する 2つの認証局間に管理プロトコルが使われることがあります。
個々のメッセージ形式と手続きを詳細に説明する前に、まず PKI 管理に関わるエンティティ、およびエンティティ間の(必要な PKI 管理機能の見地から)相互作用（interaction）について定義します。次に、識別可能な異なるタイプの EE（エンドエンティティ）を適応させるために、これらの機能をグループ化します。
PKI 管理に関わるエンティティは、EE（エンドエンティティ： すなわち、証明書の主体者フィールドに記載されているエンティティ) と認証局(つまり、証明書の発行者フィールドに記載されているエンティティ) を包含しています。場合によって、登録局（RA： Registration Authority）も PKI 管理に関係します。
1.2.1 主体者とエンドエンティティ English
ここで「主体者（subject）」という言葉は、証明書の主体者フィールド（subject field）に指定されるエンティティのことを表します。； 主体者が使用するツールと（または）ソフトウェア( 例えば、ローカル証明書管理モジュール )を見分けたい時に、「主体者装置（subject equipment）」という 用語を使用します。概して、フィールド名による混乱を回避するために、「主体者」よりも「EE（エンドエンティティ）」という用語を使用することが望まれます。
ここでいう EE は、アプリケーションを使用する人間のユーザばかりでなく、アプリケーション自身（例えば、IP セキュリティ）も含まれることを認識することは重要です。このことは、PKI 管理操作時に使うプロトコルに影響を及ぼします 。； 例えば、アプリケーション・ソフトウェアは、どの証明書拡張領域が必要なのかについて人間のユーザーよりもはるかに正確に知ります。PKI 管理エンティティは、時折証明書または相互認証証明書（cross-certificate）の主体者フィールドで指定することもあるため、ある意味では EE でもあります。また場所によって、EE という用語は、 PKI 管理エンティティ以外の EE を指すこともあります。
全ての EE は、一部の情報に対してローカルにおける安全なアクセスを必要とします。（その一部の情報というのは、最低限 EE 自身の名前、秘密鍵、そのエンティティに直接信頼される認証局（CA）名、および当該認証局の公開鍵（あるいは、自己認証バージョンが別の場所で提供可能となっている場合に公開鍵の拇印）が含まれます。 ）実装する際に、最小限以上の情報（例えば、EE 自身の証明書またはアプリケーション固有情報 )を格納するために安全なローカル記憶機構を使用することができます。記憶機構の形式もそれぞれ異なります。 （単なるファイルから耐タンパー性の暗号トークンまで。）このような信頼されたローカル記憶機構は、ここで EE の「PSE（個人セキュリティ環境」と呼びます。
PSE の形式については、本ドキュメントの定義範囲外ですが( それらは装置などに大きく依存しています) 、ここに PSE のための汎用交換フォーマットを1つ定義してあります- 認証応答メッセージが使われることがあります。
EE から見て、認証局( CA )は真の「第三者（Third Party）」であったり、あるいは必ずしもそうではないかもしれません。CA は、実際に、しばしば自分がサポートする EE と同じ組織に属します。
また、「CA」という用語は、証明書の発行者フィールドに指定されたエンティティのことを表すために使われます。； CA が使用するソフトウェアまたはハードウェアツールと区別する必要がある場合、「CA 装置（CA equipment）」という 用語を使います。
通常 CA 装置は、「オフライン」構成要素と「オンライン」構成要素の両方を含んでおり、CA の秘密鍵は「オフライン」構成要素にしか利用できません。しかしながら、これは実装者にとっての問題です。( ポリシー問題にも関係しているけれども ) 。
ここで EE が直接に信用する CA のことを「ルート CA」と呼びます; すなわち、ルート CA 公開鍵の値を安全に取得するには、いくつかのアウト・オブ・バンド方式の手順が必要です。この表現は、何もルート CA が必ずあらゆる階層の最上位にあると意味するものではなく、単に当該 CA が直接信用されていることを表すのみです。
「下位 CA」は、当該 EE のルート CA 以外の CA を指します。通常、下位 CA は任意のエンティティのルート CA になることはないが、強制的なものではありません。
1.2.3 登録局 English
EE と CA に加え、多くの環境では、認証局から分離した RA (登録局 ) の存在を必要とします。RA が実現する機能はケースによって異なりますが、個人認証、トークン配布、失効情報報告、名称付与、鍵生成、鍵ペアのアーカイブなどが考えられます。
本ドキュメントにおいて、RA をオプションの構成要素として位置づけます。 RA が存在しない場合、CA が RA の機能を実行できると考えられるため、EE からみて PKI 管理プロトコルは変わりません。
また、必要に応じて、RA そのものと RA が使用するツール（「RA 設備」）を区別します。
RA 自体が 1つの EE であることに注意してください。更に、全ての RA が実際認証済みの EE であり、かつ署名用秘密鍵を持っていることを仮定します。特定の CA 装置がいかにいくつかの EE から RA を判別するのかは、実装の問題です。( すなわち、本 書は、RA認証の運用方法については専門的に明記しません) 。RA が当面の間、相互に作用しあう CA の認証を取得することを強制はしません。(従って、1つの RAは、一回の認証のみで 1つ以上の CA と連動できます)
状況によって、RA が存在していても、エンドエンティティが直接に CA と通信することもあります。例えば、最初の登録と（または）認証の際に、主体者はその RA も使うが、証明書更新のためには直接 CA と通信もします。
ここに提示しているプロトコルは下記の PKI 管理の要件を満たしています。
- PKI 管理は、ISO 9594-8 標準およびそれに関連する修正（証明書拡張領域）に準拠しなければならない。
- PKI 管理は、このシリーズの他の部分にも準拠しなければならない。
- 他の鍵ペアに何も影響を与えず、任意の鍵ペアの定期的な更新を可能にしなければならない。
- PKI 管理プロトコルにおける秘密性の使用は、規制問題を緩和するため最小限に留められばならない。
- PKI 管理プロトコルは様々な業界標準暗号アルゴリズム(特に RSA、DSA、MD5、 SHA-1 を含む)を使用できるようにしなければなりません。 -- すなわち、任意の CA、RA または EE（エンドエンティティ）は、原則として、自分の鍵ペアに適するようなアルゴリズムを何でも使用できることです。
- PKI 管理プロトコルは対象エンドエンディティ、RA、もしくは CA による鍵ペアの生成を排除してはいけません。鍵生成は他のところで行うこともありますが、PKI管理という目的においては、鍵がエンドエンティティ、RA、または CA のいずれかで最初に現れたときに鍵生成と見なすことができます。
- PKI 管理プロトコルは対象となるエンド・エンティティや、RA もしくは CA による証明書の公開に対応しなければなりません。実装方式および環境の違いによって、上記のアプローチのいずれかが選択されることがあります。
- PKI 管理プロトコルは認証済みのエンドエンティティによる証明書の失効要求に応え、証明書失効リスト (CRL) の生成に対応しなければなりません。実施するにあたって、Dos 攻撃 （サービス妨害攻撃）を容易化しないような方式で行わなければなりません。
- PKI 管理プロトコルは、mail、http、TCP/IP、および ftp を含めた様々な伝送方式が使用できるようにしなければなりません。
- 認証（証明書）作成の最終権限は、 CA にあります; RA またはエンドエンティティ装置は、CA 発行の証明書に要求されたものが含まれているかどうかを推測できません。 CA は、運営ポリシーに従って、証明書フィールドの値を変更したり、もしくは拡張領域を追加、削除、変更したりすることができます。すなわち、たとえ実際に発行される証明書と申請の証明書と異なっても、全ての PKI エンティティ( エンドエンティティ、RA 及び CA ) は、その申請に対する応答が可能でなければなりません (例えば、CA は有効期間を申請よりも短くすることもあります)。ポリシーの規定に従い、申請元のエンティティが新規生成された証明書を確認し、かつ（典型的な場合は、PKIConfirm メッセージを使用して）受け入れるまでは、CA が証明書の公開もしくは配布を実施してはいけないことに注意してください。
- 危殆化していない CA 鍵ペアから次の CA 鍵ペアへの切換（CA 鍵更新）を巧みに、計画的に対応しなければなりません。（CA 鍵が失効した場合は、当該CAドメイン内にあるすべてのエンティティに対して再初期化（全ての証明書の再発行）を実施しなければならないことに注意してください) 。(CA鍵更新の結果として)新しい CA 公開鍵を含んだ PSE をもったエンドエンティティは、古い公開鍵で証明書を検証できなければなりません。また、古い CA 鍵ペアを直接に信頼するエンドエンティティは新しい CA 秘密鍵で署名した証明書も検証できなければなりません。( 古い CA 公開鍵がエンドエンティティの暗号装置に「ハードウェア的に組み込まれている」状況を想定した場合 )
- 実装方式や環境によって、RA の機能は CA 自身で実現することもあります。通信先が RA なのか CA なのかを問わず、EE が同一のプロトコル（ただし、勿論、同じ鍵ではない！）を使用するように、プロトコルを設計しなければなりません。
- EE が指定の公開鍵の値を含んだ証明書を申請する場合に、当該 EE が相応の秘密鍵の所有を示す用意が必要です。認証要求の種別によって、実現方法もいろいろあります。PKIX-CMP (すなわち、証明書管理プロトコル) メッセージを対象に定義したイン・バンド方式の詳細については、2.3 節の「秘密鍵所持の証明（Proof of Possession of Private Key）」を参照してください。
PKI 管理操作
次の図に、PKI 管理の操作について前に定義したエンティティ間の関係を示しています。この図形にある文字は「プロトコル」を表し、各文字列に沿って定義済みのPKI 管理メッセージのセットを送信できることを意味します。
+----+ 証明書公開 +-------------------+ j | | <--------------------- | エンドエンティティ| <------- | 証 | g +-------------------+ 「アウト・オブ・バンド」 | | | ^ ロード中 | 明 | | | 初期 | | a | | b 登録/ | 書 | | | 認証 | | | | 鍵ペア回復 | / | | | 鍵ペア更新 | | | | 証明書更新 | C | PKI 「ユーザ」 V | 失効要求 | R |-------------------+-+-----+-+------+-+------------------- | L | PKI 管理 | ^ | ^ | | エンティティ a | | b a | | b | | V | | | | リ | g +------+ d | | | ポ | <------------ | RA | <-----+ | | | ジ | 証明書公開 | | ----+ | | | | ト | +------+ c | | | | | リ | | | | | | | V | V | | | g +------------+ i | | <------------------------| CA |-------> | | h +------------+ 「アウト・オブ・バンド」 | | 証明書公開 | ^ 公開 | | ＣＲＬ公開 | | +----+ | | 相互認証 e | | f 相互認証証明書 | | 更新 | | V | +------+ | CA-2 | +------+図1 - PKI エンティティ
高いレベルにおいて、管理メッセージによって定義されたいくつかの操作は、次のようにグループ分けすることができます。
1 CA 構築： 新しい CA を構築する際に、一定のステップを必要とします。（例えば、 CRL の作成、CA 公開鍵のエクスポート）
2 エンドエンティティの初期化： ルート CA の公開鍵をインポートすることと、PKI 管理エンティティが対応するオプションの情報を取得することが含まれます。
3 認証 :様々な操作の結果として、新規の証明書が生成されます。：
3.1 初期登録/認証： CA が EE の証明書を発行する前に、当該エンドエンティティはまず自分のことを CA または RA に知ってもらうプロセスがあります。このプロセスの(成功した場合の)最終結果として、CA がエンドエンティティ公開鍵に対して証明書を発行し、そしてその証明書をエンドエンティティに返送し、同時に（または）公開リポジトリに送付します。このプロセスは、特に典型的な場合は、複数の「ステップ」が伴い、そのなかにエンドエンティティ装置の初期化が含まれることがあります。例えば、エンドエンティティ装置を証明書パスの有効化に適用するために、必ず CA 公開鍵によって安全に初期化されなければなりません。更に、EE は自分の鍵ペアで初期化する必要があることも典型的です。
3.2 鍵ペア更新： 全ての鍵ペアは、定期的に更新されなければなりません(すなわち、新しい鍵ペアと交換すること)。そして、新しい証明書の発行が必要となります。
3.3 証明書更新： 証明書の有効期限が切れた場合、もし環境的な関連項目に何も変更がなければ、延長（refresh）することができます。
3.4 CA 鍵ペア更新： エンドエンティティと同様に、CA の鍵ペアにも定期的な更新を必要とします; しかしながら、必要な機構（Mechanism）が異なります。
3.5 相互認証要求： ある CA から別の CA に対して相互認証証明書の発行を要求します。この標準のために次の用語が定義されています。「相互認証証明書」において、主体者 CA（subject CA）と発行者CA（Issuer CA）が区別され、そして SubjectPublicKeyInfo のなかに検証用鍵(つまり、その証明書は主体者CAの署名用鍵ペアのために発行されます) が含まれます。そして更なる細かい区別が必要となる場合は、次の「用語」（term）を使用することがあります 。： 主体者 CA と発行者 CA が異なる管理ドメインに属する場合はその相互認証証明書のことを「ドメイン間相互認証証明書」と呼ばれます。それ以外の場合は「ドメイン内相互認証証明書」と呼ばれます。
注意事項：
事項1. 上記の「相互認証証明書」の定義は、 X.509 で定義されている「CA‐証明書」と同じものになります。X.500 の「 cACertificate 」属性タイプとは無関係なので、両者を混同しないように注意してください。
事項2. 多く場合において、特別な限定がない限り、「相互認証証明書」という言葉は、上記の「ドメイン間相互認証証明書」と同義であると解釈します。
事項3. これに限ることではありませんが、相互認証証明書は通常相互に発行されます; すなわち、2つの CA はお互いに相手に対して相互認証証明書を発行し合います。
3.6 相互認証証明書の更新: 相互認証証明書であるという違い以外は、通常の証明書更新と類似します。
4 証明書/CRL検知操作:証明書またはCRLの公開（publication）を行うためのPKI管理操作の一部です。：
4.1 証明書公開: 証明書の生成に支障が発生した場合、それを公開するいくつかの方法が必要となります。PKIXのなかで定義された「方法（means）」は、3.3.13節 - 3.3.16 節 で述べたメッセージと関係したり、PKIX シリーズ仕様準拠の「操作プロトコル」ドキュメントに記述されたその他の方法 (例えば、LDAP)を含んだりすることがあります。
4.2 CRL公開: 証明書の公開と同じ
5 回復操作： EE（エンドエンティティ）が PSE を「失った」時に使用する一部のPKI管理操作です:
5.1 鍵ペア回復 : オプションとして、ユーザ・クライアントの鍵そのもの(例えば、暗号を復号するためのユーザ秘密鍵)は、CA、RAまたはCA/RAと関係づけられた鍵バックアップシステムによってバックアップすることができます。エンティティがこのバックアップされた鍵の回復が必要な場合（一例として、パスワードを忘れたり、鍵チェンファイルを紛失したりする場合）、その（鍵）回復のためのプロトコル交換が必要になります。
6 失効操作： 新たに CRL にエントリを作ったり、新しい CRL を生成する PKI 操作の一部です。：
6.1 失効要求： 権限が授与された人は、異常状況にあるCAに対して証明書失効の要求を勧めます。
7 PSE 操作： PSE 操作（例えば、PSEの移動、PIN の変更など）の定義は本仕様の規定範囲外となるが、この操作の基本を形成できるPKIMessage ( CertRepMessage ) についてはここに定義します。
オンライン・プロトコルは上記の操作の実装に必要な唯一の手段ではないことに注意してください。全ての操作について、オフラインの方法でも同じ結果をもたらすことができ、本仕様は特にオンライン・プロトコルの使用を強制するものではありません。例えば、ハードウェア・トークンを利用する場合、多くの操作は物理的なトークンの引き渡しなどとして実現されます。
後節では、上記の操作に対応する標準のメッセージセットを定義します。異なる環境 ( ファイル・ベース、オンライン、電子メール、及び WWW ) において、これらのやり取り（exchange）を伝達するためのプロトコルについても規定しています。