2．仮定と制約条件 English
PKI 管理エンティティを扱うときに、EE に対する最初のステップとしては、サポートしている PKI 機能についての情報を要求し、適切なルート CAの公開鍵のコピーを安全に取得することです。
EE の初期登録および認証はいろんな仕組みで実現することができます。CA 実装環境におけるポリシー規定範囲の相違や、 EE の種類の多様性により、1つの方法ですべての状況に適応させることは不可能です。
しかしながら、この仕様が対応する初期登録／認証の仕組みについてはここで分類化することができます。「初期」という言葉に重要な意味があることに注意してください。すなわち、対象の EE が今まで一度もPKIと関わりがなかったような状況を想定しています。EE が、既に認証済みの鍵を所有している場合には、単純化/ 交換で処理可能です。
本仕様に対応した仕組みで分類化できた後、また必須項目とオプション項目を指定することができます。最終目標として、必須項目の機構が実際使用中に起こりうるケースを十分にカバーし、そしてオプション項目の機構があまり頻繁に発生しない特殊なケースにも対応できるようにすることです。このように、柔軟性と実装の容易性の間でバランスを保つことができます。
ここで、初期登録/認証機構の分類について述べます。
2.2.1 適用基準 English
2.2.1.1 登録／認証の開始 English
作成された PKI メッセージについて、EE に関連する最初の PKI メッセージが生成された時点を初期登録／認証やり取りの開始と見なすことができます。登録／認証手順の開始は、現実世界では別のところで起こりえることに注意してください。(例えば、人事部が RA 運用者に電話する場合など)
EE 、RA または CA のある所が、その作業（初期登録／認証）の可能な場所です。
2.2.1.2 EE ・メッセージの原本認証 English
証明書を申請する EE のオンライン・メッセージは、認証される場合と却下される場合があります。ここで、 EE から PKI( CA/RA )に送られるすべてのメッセージの原本性を認証することを必要条件とします。
本仕様において、このような認証は、PKI ( CA/RA )から EE に対して、何らかのアウトオブバンド方式で秘密値（初期証明鍵）と参照値（トランザクション識別用）を発行することを意味します。初期証明鍵は、その後関連する PKI メッセージの保護にも使用されます。
オンラインの EE であるかどうかや PKI メッセージが証明されたかどうかを基準に、初期登録/認証機構を分類することができます。
注意事項 1： 「PKI-> EE 」のメッセージに対する認証は常に必須であるため、ここで論じません。どんな場合でも、ルート CA の公開鍵が一度 EE の設備にインストールされているか、または初期認証鍵を基にすれば、簡単に実現することができます。
注意事項 2： EE からのメッセージが何らかのアウトオブバンド方式（例えば、後続のビジット（visit））で認証される場合、初期登録／認証手順は安全確実だと考えられます。
本仕様において、「鍵生成」は、PKIMessage に鍵ペアの公開鍵か秘密鍵が初めて作成されたときに起きると見なされています。これは鍵一括生成サービスを排除する意味ではないことに注意してください。実際の鍵ペアは既に別の場所で生成され、（専有のまたは標準化された）鍵生成要求／応答プロトコル（本仕様の規定範囲外）を経由して EE 、RA もしくは CA まで伝送されることもあります。
このように「鍵生成」の可能な場所は 3つあります。： EE（ EE ）、RA または CA。
2.2.1.4 認証成功の確認 English
EE（ EE ）の最初の証明書を生成した後に、その証明書を含んだメッセージを無事に受信できたことを EE が明示的に確認し、それによってもうひとつの確証を取れることになります。通常、この確認メッセージは、 (初期認証鍵または他の方法に基づいて)保護されなければなりません。
それに伴い、新たに 2つの可能性が生じます:確認済みと未確認
2.2.2 必須機構 English
上記の基準について、多数の初期登録/認証機構を考慮にいれています。本仕様は、準拠の CA 装置、RA 装置および EE 装置に下記 2 番目の機構へのサポートを強制します。任意のエンティティは必要に応じて、ほかの機構にも対応することが可能です。
2.2.2.1 集中型機構 English
上記の分類から見ると、以下のこの機構はある意味で、最もシンプルであるかもしれません。：
- 認証された（ルート）CA から開始する。；
- オンライン・メッセージ認証を必要としない。；
- 「鍵生成」は認証CA で実施する。( 2.2.1.3 節を参照 ) ；
- 確認メッセージを必要としない。
メッセージ・フローに関して、この機構に唯一必要なメッセージは、CA から EE に伝送されるメッセージです。そのメッセージは、必ず EE の PSE を完全に含まなければならなりません。 EE が受け取ったメッセージを認証し、暗号化された値を復号できるように、何らかのアウトオブバンド方式を提供しなければなりません。
2.2.2.2 基本認証機構 English
上記の分類から、この機構は以下の通りとなります。
- EE から開始する。；
- メッセージの認証を必要とする。；
- 「鍵生成」は EE で実施する。 (2.2.1.3 節を参照 ) ；
- 確認メッセージを必要とする。
メッセージ・フローの観点から、基本認証機構は、次のとおりです。 ：
End entity RA/CA ========== ============= out-of-band distribution of Initial Authentication Key (IAK) and reference value (RA/CA -> EE) Key generation Creation of certification request Protect request with IAK -->>--certification request--<<-- verify request process request create response -->>--certification response-->>-- handle response create confirmation<<--confirmation message--<<-- verify confirmation( 確認メッセージの検証が失敗した場合には、RA または CA は必ずその新しく発行され、既に公開済みまたは別の方法で利用可能になっている証明書を失効させねばなりません)
2.3 秘密鍵保持の証明（Proof of Possession、POP） English
ここに規定してある PKI 管理操作によって、 EE が証明書に必要な公開鍵とそれに対応する秘密鍵を所有していることを証明可能にし、そして一定の攻撃から防御し、 EE と鍵ペアとの結合の有効性についても CA／RAが適切に確認できるようにしています。所定の CA/RA は、証明書交換の際にいかに POP を強化するのかは(例えば、アウトオブバンド手順型方法 vs. PKIX-CMP インバンドメッセージ )自由に選択可能です（すなわち、これはポリシーの問題であるかもしれません）。しかしながら、現行の非 PKIX 操作プロトコルの多く（多様な電子メールプロトコルはその一例）は明示的に EE と秘密鍵との結合性について確認を行わないため、CA/RA は必ず何らかの方法で POP を強化しなければなりません。操作プロトコルがこの結合（署名鍵ペア、暗号化鍵ペア、鍵合意鍵ペア）の存在を検証し、かつ遍在的になるまでは、この結合はあくまでも CA/RA によって証明されたという推測にしかすぎません。
POP は、証明書を申請する鍵のタイプに応じて、実現方法が異なります。もし当該鍵が複数の目的 ( 例えば、 RSA鍵) に使用されることとなれば、任意の適切な方法を適用してもよいです。 ( 例えば、署名用の鍵が、別の目的でも使用できるが、その所有を証明するために CA/RA に送ることはしないことになります) 。
本仕様は、 EE が関連証明を RA に送り、続いてその RA が必要な証明は既に受領済み（かつ有効である）であることを CA に証明するようなケースも認めています。例えば、ある EE が署名鍵を認証してもらうために適切な署名を RA に送り、後は EE が既に要求された証明を提示したことを関連 CA に 通告するだけです。もちろん、このような状況は、ポリシーによって却下されることもありえます( 例えば、認証過程において CA は POP を検証できる許可をもつ唯一のエンティティであるかもしれない)
署名鍵というものは、EE がある値に対して署名し、秘密鍵の所有を証明できるものをいいます。
暗号化鍵というものは、 EE が、CA/RA に秘密鍵を提供することや、もしくはある値を復号することによって、秘密鍵の所有を証明することができるものをいいます( 3.2.8節を参照) 。値の復号は直接にあるいは間接的に実現することができます。
直接的な方法として、RA/CA がランダムのチャレンジ（challenge）を発行し、EE にそのチャレンジに対する即座の応答を要求する方法です。
間接的方法として、 EE のために暗号化された証明書を発行することです ( そして、その EE に確認メッセージに含まれている証明書を復号できる能力を証明させる) 。これで、CA が対象 EE にしか使用できない形式の証明書を発行することが可能となります。
本仕様は、間接的な方法の使用を推奨します。なぜなら、余分のメッセージを送ることなくて済むからです。(例えば、「要求、応答、確認」の三つメッセージを使って、その証明を立証できます。）
鍵合意鍵について、 EE と PKI 管理エンティティ（すなわち、CA または RA）の間に共有の機密鍵（secret key）を確立し、 EE の秘密鍵（private key）の所有を証明します。
これは、所定のCAに認証が可能な鍵に対して何らかの制約を課すものではないことに注意してください。特に、デフィー・ヘルマン鍵（Diffie-Hellman key）の場合は、 EE はアルゴリズムのパラメータを自由に選択することができます。-そのとき、 CA は必要に応じて適切なパラメータをもった短期（もしくは一回切りの）鍵ペアを生成できます。
以下の内容は、一部の EE のルート CA にのみ適用できます。
ここで述べられている手順の基本として、CA が古い秘密鍵で新しい公開鍵を保護します。逆の場合も同様です。CA がその鍵ペアを更新する際に、もし証明書(合計4枚: OldWithOld 、 OldWithNew、 NewWithOld 及びNewWithNew）が X.500 ディレクトリで提供されていれば、 2つ余分の cACertificate 属性値を生成しなければなりません。
CA が自分の鍵ペアを変更するときは、アウト・オブ・バンド方式（ out-of-band ）で古い CA 公開鍵を取得した EE が最も影響を受けます。これらの EE は古い CA 秘密鍵で保護された新しいCA公開鍵へのアクセスを必要とします。しかしながら、それらの EE は、一定の期間内にしかこれを必要としません アウト・オブ・バンド（out-of-band）機構で新しい CA 公開鍵を獲得するまで )。 EE の証明書が期限切れた場合は、一般的に容易に実現できます。
新しい CA 公開鍵と古い CA 公開鍵を保護するデータ構造は標準の証明書となっています (拡張領域を含めることもできる) 。新しいデータ構造を必要としません。
注意事項 1. この機構はバージョン 1 証明書の動作に対応するために、X.509 v3 の拡張領域を一切利用していません。KeyIdentifier 拡張領域が存在すれば、効率の改善に役に立ちます。
注意事項 2. この体系について、CA がそのエンド・エンティティのある証明書の有効期間中、一回以上 CA の鍵ペアを更新する場合にも対応できるように汎用化することができるが、その意義ははっきりしないものだと思われます。この汎用化がなければ、単純に CA 鍵ペアの有効期間は必ずその鍵ベアによって発行されたすべての証明書の有効期間よりも長く設定しなければならないことを意味します。
注意事項 3. 本機構において、 EE が所有の古い CA 秘密鍵で署名された最後の証明書の期限切れ日に（アウト・オブ・バンド（ out-of-band）方式で）新しい CA 公開鍵を取得するよう強制します。ほかの時期に発生する証明書と（または）鍵更新の操作はこれを必要としません。（ EE の設備に依存）
2.4.1 CA 運用者操作 English
CA 鍵を交換するために、CA 運用者は下記の操作を実施します :
- 新しい鍵ペアを生成します。；
- 新しい秘密鍵で署名した古い CA 公開鍵を格納した証明書を作成します。( 「 old with new 」証明書 ) ；
- 古い秘密鍵で署名した新しい CA 公開鍵を格納した証明書を作成します。( 「 new with old 」証明書 ) ；
- 新しい秘密鍵で署名した新しい CA 公開鍵を格納した証明書を作成します( 「 new with new 」証明書 ) ；
- これらの新しい証明書をディレクトリ、または他の方法で公開します。 (恐らく CAKeyUpdAnn メッセージを使用) ；
- EE が(必要に応じて)「アウト・オブ・バンド」（out-of-band）機構で取得できるように新しいCA公開鍵をエクスポートします。
古いCA秘密鍵はその時もはや必要でなくなりますが、しばらくの間まだ使用し続けます。古いCA公開鍵が必要とされなくなった (事後否認防止を除外) 時点というのは、この CAのすべての EE が新しい CA 公開鍵を完全に取得完了した時点となります。
「 old with new 」証明書の有効期間は、古い鍵ペアの生成日時を開始時間とし、古い公開鍵の期限切れ日を終了時間と設定しなければなりません。
「 new with old 」証明書の有効期間は、新しい鍵ペアの生成日時を開始時間とし、この CA のすべての EE が確実に新しい公開鍵を取得する日時を終了時間と設定しなければなりません。（遅くても、古い公開鍵の期限切れ日）
「 new with new 」証明書の有効期間は、新しい鍵ペアの生成時点を開始時間とし、次回 CA がその鍵ペアを更新する日時を終了時間とします。
2.4.2 証明書の検証 English
一般的に署名を検証する際に、検証者は（ほかのものの中から）証明書のなかに署名者の公開鍵を含んでいることを検証します。しかしながら、一旦 CA がその鍵を更新することを許されれば、新しい可能性が広がります。以下の表に示す通りです。
新しい公開鍵と古い公開鍵を格納するリポジトリ
古い公開鍵しか格納しないリポジトリ （公開の遅延などの原因のため） 新しい公開鍵を格納する PSE
古い公開鍵を格納する PSE
新しい公開鍵を格納する PSE
古い公開鍵を格納する PSE
署名者の証明書は新しい公開鍵によって保護されている ケース 1： これは標準的なケースであり、ディレクトリを使用することなく検証者が直接に証明書を検証する場合
ケース 3： この場合は検証者は必ずディレクトリにアクセスし、新しい公開鍵の値を取得する ケース 5： CA 運用者がディレクトリを更新していなくても、検証者が証明書を直接に検証できる −ケース1と同様
ケース 7： この場合は CA 運用者がディレクトリを更新していないため、検証作業が失敗になる
署名者の証明書は古い公開鍵によって保護されている ケース 2： この場合は検証者は必ずディレクトリにアクセスし、古い公開鍵の値を取得しなければならない ケース 4： この場合はディレクトリへアクセスすることなく検証者が直接に証明書を検証する ケース 6： CA 運用者がこれをケース 2 と同様な状況と考え、ディレクトリにアクセスするが、失敗となる ケース 8： CA 運用者がディレクトリを更新していないにも関わらず、検証者が証明書を直接に検証できる ケース 4 の場合と同様
2.4.2.1 ケース 1、4、5 及び 8 における検証 English
これらの場合は、検証者が CA 公開鍵のローカル・コピーを持ち、証明書を直接に検証することができます。これは、鍵変更が発生しなかった状況と同じです。
CA 運用者が新しい鍵ペアを生成した時点と、CA 運用者が更新した属性をディレクトリに格納する時点との間にケース 8 が起こりうることに注目してください。CA 運用者がこの「隙間（gap）」( 下記の故障ケースに結びつくため、CA 運用者がこの状況を回避すべきこととします)の間に、署名者の証明書および検証者の証明書の両方を発行した場合に限って、ケース 5 は起こりえます。
2.4.2.2 ケース 2 における検証 English
ケース 2 において検証者は CA の古い公開鍵にアクセスをしなければなりません。検証者は以下の作業を行います。：
- ディレクトリから caCertificate 属性を検索し、OldWithNew 証明書（有効期間に基づいて定める）を探し出します。
- 新しい CA 鍵（検証者がローカルに持っている）でその正当性を検証します。
- 正当であれば、古い CA 鍵で署名者の証明書を検証します。
CA 運用者が署名者の証明書を発行し、次に鍵を変更し、そして検証者の証明書を発行した場合に、ケース 2 が起こります。したがって、非常に典型的なケースと言えます。
2.4.2.3 ケース 3 における検証 English
ケース 3 の場合は、検証者は必ず CA の新しい公開鍵にアクセスしなければなりません。検証者は以下の操作を行います。
- ディレクトリの中から CACertificate 属性を検索し、そして NewWithOld 証明書（有効期間に基づいて決まる）を選び出します。
- 当該証明書の正当性を古い CA 鍵（検証者のローカルに格納されている）で検証します。
- 正当であれば、新しい CA 鍵で署名者の証明書を確認します。
ケース3はCA運用者が検証者の証明書を発行し、次に鍵を変更し、そして署名者の証明書を発行する場合で起こります。これも非常に典型的なケースです。
2.4.2.4 ケース 6 における検証の失敗 English
この場合、ディレクトリ属性を更新することなく、CA が新しい鍵の入った検証者の PSE を発行します。つまり、検証者が古い CA 鍵の信頼できるバージョンを取得する手段がなく、検証が失敗に終わります。
これはCA運用者の過失による失敗であることに注意してください。
2.4.2.5 ケース 7 における検証の失敗 English
この場合、ディレクトリを更新することなく、CA が新しい鍵で保護される署名者の証明書を発行します。つまり、検証者が新しい CA 鍵の信頼できるバージョンを取得する手段がなく、検証が失敗に終わります。
これも CA 運用者の過失による失敗であることに注意してください。
2.4.3 失効 - CA 鍵の取替え English
上記の内容から一旦 CA にその鍵の変更を許可すると、証明書の検証がより複雑なものになります。また失効確認にも同様なことが言えます。CA が CRL の署名に使用する秘密鍵はユーザの PSE のなかの秘密鍵より新しい可能性があるからです。
代替方法についての分析は証明書検証に関するものです。