4. PKI 管理の必須機能 English
第 1 章で概説した PKI 管理機能については、ここで詳細に記述します。
この章では、すべての EE および CA／RA の実装で提供しなければならない機能（恐らく第 5 章で定義した伝送機構のうちのいずれかを用いて）という意味での「必須」機能について論じます。事実上、この部分は PKI 管理の機能上、サポートしなければならないもののプロファイルとなります。
任意のPKI管理機能の結果として必ず PKI メッセージが生成されるとは限らないことに注意してください。
[ 本ドキュメントにおける「ルート CA」についての定義は 1.2.2 節を参照してください]
新しく作られたルート CA は必ず「自己証明書」を生成しなければなりません。「自己証明書」とは、ルート CA 鍵更新に続いて発行された「newWithNew」証明書のプロファイルをもつ証明書構造のことを指します。
自己証明書の取得にあたって「アウトオブバンド」方式を使用しない EE にとって、CA の自己証明書を有用化するには、CA は必ずその公開鍵の拇印（fingerprint）も生成しなければなりません。何らかの「アウトオブバンド」方式で安全にこの拇印を取得した EE はその後、CA の自己証明書およびその中のほかの属性について検証することができます。
拇印を伝送するためのデータ構造体は OOBCertHash です。
CA 鍵（ほかのすべての鍵と同様）は有限な存続期間を持ち、そして周期的に更新されなければなりません。CA が発行した NewWithNew 証明書、NewWithOld 証明書および OldWithNew 証明書は、既存の現行最新自己署名CA証明書（OldWithOld）をもつ EE に新しい自己署名 CA 証明書(NewWithNew)へ安全な移行を手伝い、そして NewWithNew をもつ新しい EE に OldWithOld を安全に取得させ、既存データの検証も手伝います。
本ドキュメントにおける「下位 CA」の定義については、1.2.2 節を参照してください。
PKI 管理プロトコルの観点からみて、下位 CA の初期化は EE の初期化と同じです。唯一の違いは下位 CA が初期の失効リストを生成しなければならないことです。
任意の証明書を発行する前に新しく設立された（CRL を発行する）CA は定期的に生成する CRL ごとに「空（empty）」のバージョンを必ず作成しなければなりません。
PKI エンティティ（CA、RAまたはEE）は、CA の現在状態についての情報を取得しようとするときに、CA に対してその情報の要求を送付することができます。
CA は（最低限に）リクエスタが要求するすべての情報に応答しなければなりません。もしその一部の情報が提供不可能な場合に、必ずエラーでリクエスタに返さなければなりません。
PKIMessages がこのような PKI 情報の要求および応答に遣われる場合に、必ずリクエストに GenMsg メッセージを、レスポンスに GenRep メッセージを、そしてエラーに Error メッセージを使用しなければなりません。これらのメッセージは共有秘密情報に基づいた MAC （すなわち、PasswordBasedMAC）もしくはほかの認証済みの方式（仮に EE が既存の証明書を持つ場合）で保護されています。
リクエスタ CA とは、相互認証証明書の主体者になる CA のことであり、レスポンダ CA は相互認証証明書の発行者になる CA のことを指します。
相互認証業務を開始する前に、リクエスタ CA は、起動して運用（up and running）の状態になっていなければなりません。
4.6.1 一方向「リクエスト―レスポンス」機構 English
相互認証機構は基本的に一方向的な操作です。つまり、成功した場合に、その操作の結果として新しい相互認証証明書が生成されます。もし要件事項として相互認証証明書が「双方向」的に生成されることになれば、それぞれの CA が順番に相互認証の操作（あるいはほかの機構）を始めなければなりません。
この機構の適用対象は、対象となる 2つの CA が既にお互いの署名を検証できる（信頼できる共通点がいくつか持っている）場合と、「アウトオブバンド」方式で認証リクエストの原本性を検証する場合とがあります。
詳細説明：
相互認証はレスポンダと呼ばれる CA から始まります。レスポンダの CA 管理者が相互認証したい相手の CA を識別し、レスポンダ CA 装置から許可コードを発行します。レスポンダ CA 管理者がこの許可コードをアウト・オブ・バンド方式でリクエスタ CA 管理者に渡します。リクエスタ CA 管理者がオンライン交換を開始するためにリクエスタ CA にその許可コードを入力します。
許可コードは認証と完全性という目的に用いられます。それを実現するには、許可コードを元に対称型鍵を生成し、またその対称型鍵を用いてすべての通信メッセージに対してメッセージ許可コード（MAC）を生成します。
リクエスタ CA がある乱数（リクエスタ乱数）を生成し、通信を開始します。次にリクエスタ CA が相互認証リクエスト（ccr）メッセージをレスポンダ CA に送付します。このメッセージのフィールドは許可コードに基づいた MACによって変更から守られています。
ccr メッセージを受信したと同時に、レスポンダ CA がプロトコルのバージョンチェックを行い、リクエスタに乱数を保存し、そして自分自身の乱数を生成し、MAC について検証します。次にレスポンダ CA が、リクエスタ CA 公開鍵を含んだ、レスポンダ CA 署名秘密鍵で署名した新しいリクエスタ証明書を作成（要求に応じて、アーカイブ化も）します。レスポンダ CA が相互認証レスポンス（ccp）メッセージをもって応答します。このメッセージのフィールドは許可コードに基づいた MAC によって変更から守られています。
ccp メッセージを受信したと同時に、リクエスタ CA は自分のシステム時間がレスポンダのシステム時間と近似かどうかを確認し、受信した乱数について、そしてMACについても検証します。その後リクエスタ CA が PKIConfirm メッセージをもって応答します。このメッセージのフィールドは許可コードに基づいた MAC によって変更から守られています。リクエスタ CA がリクエスタ証明書をリポジトリに書き込みます。
PKIConfirm メッセージを受信すると同時に、レスポンダ CA が乱数を確認し、MAC について検証を行います。
注意事項：
- ccr メッセージは必ず「完全な」認証リクエストを包含しなければなりません。つまり、リクエスタ CA がすべてのフィールド（例えば、BasicConstraints 拡張領域などを含む）を明記しなければなりません。
- ccp メッセージにはレスポンダ CA の検証証明書を格納することになります。その証明書が存在する場合、リクエスタ CA は必ずその検証を行わなければなりません。（例えば、「アウト・オブ・バンド」方式経由で）
CA と同様に、 EE も初期化しなければなりません。 EE の初期化は少なくとも 2つのステップで構成されます。：
- PKI情報の取得
- アウト・オブ・バンド方式によるルート CA 公開鍵の 1つを検証
（他に考えられるステップとして、信頼条件について情報の検索および（または）ほかの CA 公開鍵のアウト・オブ・バンド検証があります。）
必要な情報とは以下のように示します。：
- 現在のルート CA 公開鍵
- （もし認証 CA がルート CA ではない場合）ルート CA から認証 CA までの認証パス、および適切な失効リスト
- 認証 CA が各関連用途ごとにサポートしているアルゴリズムおよびアルゴリズムのパラメータ
成功な認証リクエストを生成するには、それ以外付加的な情報が要求されることもあります（例えば、対応する拡張領域や CA ポリシー情報）。しかしながら、簡素性という観点から EE が PKI メッセージ経由によるこれらの情報の取得は強制しません。最終結果として、単に一部の認証リクエストが失敗することがあります。（例えば、 EE が自分の暗号化鍵を生成したいが、CA はそれを許可しない場合）
必要な情報は、4.5 節の説明を参照し、取得することができます。
4.7.2アウト・オブ・バンド方式によるルート CA 鍵の検証 English
EE は自分のルート CA の公開鍵を安全に保持しなければなりません。これを実現するひとつの方法としては、何らかの安全な「アウトオブバンド」方式を通して EE に CA の自己証明書の拇印を提供することです。そうすれば、 EE が CA の自己署名証明書を安全に利用することができます。
さらに詳細な内容については 4.1 節を参照してください。
（更新手続きの一環として、もしくはそれ以外の任意の目的で）初期化された EE は、いつでも証明書を申請することができます。この申請は認証リクエスト（cr）メッセージを通して行われます。もしその EE が既に署名鍵ペア（対応する検証証明書とともに）を所有していれば、典型的な場合にこの cr メッセージがエンティティのディジタル署名によって保護されます。（申請が成功した場合）CA が CertRepMessage のなかに新しい証明書を格納し、応答します。
鍵ペアがこれから期限切れになる場合に、関連 EE が鍵の更新を要求することができます。つまり、CA に対して新しい鍵ペアの新しい証明書の発行を申請することができます。このリクエストに鍵更新（kur）メッセージが用いられます。もしこの EE が既に署名鍵ペア（対応の検証証明書とともに）を所有している場合は、そのメッセージは典型的にエンティティのデジタル署名によって保護されます。CA が鍵更新レスポンス（kup）メッセージに新しい証明書を格納し、返答します。構文上は CertRepMessage と 同じです。