2 <- index -> 4


3.  アプローチの概観 English

下記が、PKIX(Public-Key Infrastructure using X.509)仕様によって想定されているアーキテクチャのモデルについての単純化した見方である。

このモデル中のコンポーネントは、下記のとおり。:

エンドエンティティ(終端主体): 証明書の「サブジェクト」となる PKI 証明書、かつ/または、エンドユーザシステムのユーザ。

CA: Certification Authority。

RA: Registration Authority。すなわち、CA が特定の管理機能を委任する運用システム。

CRL 発行者: CRL を生成し、署名するシステム。

リポジトリ: 証明書および CRL を保管し、これらの証明書および CRL をエンドエンティティ宛に配布する手段としての役割を果たすシステム、もしくは、分散システムの総体。

CA は、彼らが発行する証明書の失効状態を示すことに責任を負う。失効状態情報は、OCSP(Online Certificate Status Protocol)[RFC2560]、CRL(Certificate Revocation List)、あるいは、何らかの他のメカニズムを使って提供される可能性がある。一般に、失効状態情報が CRL を使って提供されるとき、その CA は、CRL 発行者でもある。しかし、CA は、CRL を発行することについての責任を、異なる主体に委任する可能性がある。

AA(Attribute Authority)は、CRL 発行者の CRL の発行を代理することを選択する可能性もあることに注意。

  
   +---+
   | C |                       +------------+
   | e | <-------------------->| End entity |
   | r |       Operational     +------------+
   | t |       transactions          ^
   | i |      and management         |  Management
   | f |       transactions          |  transactions        PKI
   | i |                             |                     users
   | c |                             v
   | a | =======================  +--+------------+  ==============
   | t |                          ^               ^
   | e |                          |               |         PKI
   |   |                          v               |      management
   | & |                       +------+           |       entities
   |   | <---------------------|  RA  |<----+     |
   | C |  Publish certificate  +------+     |     |
   | R |                                    |     |
   | L |                                    |     |
   |   |                                    v     v
   | R |                                +------------+
   | e | <------------------------------|     CA     |
   | p |   Publish certificate          +------------+
   | o |   Publish CRL                     ^      ^
   | s |                                   |      |  Management
   | i |                +------------+     |      |  transactions
   | t | <--------------| CRL Issuer |<----+      |
   | o |   Publish CRL  +------------+            v
   | r |                                      +------+
   | y |                                      |  CA  |
   +---+                                      +------+

  

図 1. PKI 関連主体

3.1. X.509 v3 証明書 English

公開鍵の利用は、「関連するプライベート鍵は、これで暗号化メカニズムもしくはディジタル署名メカニズムを使う、遠隔にいる正しいサブジェクト(人間 もしくはシステム)によって所有される」という確証を要する。この確証は、公開鍵証明書の利用を通じて得られる。公開鍵証明書は、公開鍵の値を サブジェクトに結合するデータ構造体である。その結合は、信頼される(trusted)CA が各証明書に署名するようにすることによって言明される。その CA は、技術的な手段に基づく、この言明(チャレンジレスポンスプロトコルを通じての所持の証明として知られている)、そのプライベート鍵の表現、あるいは、その サブジェクト による言明に基づく可能性がある。証明書は、限られた有効期間(lifetime)をもつ。これは、その署名された コンテンツ中に示される。証明書の署名および適時性(timeliness)は、証明書を使うクライアントによって独立してチェックされる可能性があるので、証明書は、信頼されない通信やサーバーシステム経由で配布される可能性があり、証明書を使っているシステム中にセキュア化されていないストレージにキャッシュされる可能性がある。

ITU-T X.509 (formerly CCITT X.509) もしくは ISO/IEC 9594-8 は、標準証明書フォーマット [X.509] を規定している。(これは、当初、1988 年に X.500 directory recommendations の一部として発行された。)1988 年の標準中の証明書 フォーマットは、バージョン 1(v1)フォーマットと呼ばれる。X.500 が 1993年に改訂されたとき、ふたつのフィールドが追加され、バージョン 2(v2)フォーマットとなった。

1993年に発行された PEM(Privacy Enhanced Mail)の RFC は、X.509 v1 証明書に基づく PKI についての仕様を含む [RFC1422]。RFC 1422 を配備する試みにおいて得られた教訓は、「v1 および v2 の証明書 フォーマットは、いくつかの観点から不十分であったこと」を明確にした。最も重要なのは、他のフィールドも、PEM が設計した情報を運ぶことが必要とされ、実装実験が不可欠と立証された。これらの新しい要件に対応して、 ISO/IEC, ITU-T および ANSI X9 は、X.509 version 3 (v3) 証明書フォーマットを策定した。v3 フォーマットは、追加的な拡張フィールドについての規定を追加することによって v2 フォーマットを拡張する。特定に拡張 フィールドの種別は、標準において規定される可能性、あるいは、あらゆる組織もしくはコミュニティによっても規定され、登録される可能性がある。1996年 6月に、basic v3 フォーマットの標準化は、完了した [X.509]。

ISO/IEC, ITU-T および ANSI X9 も、v3 拡張フィールド [X.509][X9.55] における利用について標準拡張を策定した。これらの拡張は、追加的な サブジェクト 識別情報、鍵の属性情報、ポリシー情報および証明書パス制約のようなデータを運ぶことができる。

しかし、ISO/IEC, ITU-T および ANSI X9 の標準拡張は、それらの適用可能性において、非常に広範である。インターネットで利用する X.509 v3 システムの相互運用可能な実装を開発するためには、インターネットに合わせた X.509 v3 拡張の利用のためのプロファイルを規定することが不可欠である。Internet WWW, 電子メールおよび IPsec アプリケーションについてのプロファイルを規定することは、本書の目的のひとつである。追加的な要件をもつ環境が、このプロファイルに基づいて構築される可能性、あるいは、これを置き換える可能性がある。

3.2. 証明書パスとトラスト English

公開鍵の知識を要するセキュリティ サービス のユーザは、一般に、要求される公開鍵を含む証明書を取得し、検証する必要がある。その公開鍵ユーザが、まだ、その証明書、その CA の名前および(有効期間もしくは名前制約のような)関連情報に署名した CA の公開鍵の assured copy を保持していない場合、その公開鍵を入手するために追加的な証明書が必要となる可能性がある。一般に、複数の証明書の連鎖が必要とされ、ある CA によって署名される公開鍵の所有者(end entity)の証明書や、他の CA によって署名された CA のゼロ以上の追加的な証明書を包含する可能性がある。このような証明書パスと呼ばれる連鎖が要求される。なぜならば、公開鍵 ユーザは、限られた数の assured CA 公開鍵でのみ初期化されるからである。

CA が公開鍵 ユーザ用に証明書パスを発見できるようにするために設定される可能性がある異なる方法がある。PEM について、RFC 1422 は、CA の rigid 階層的構造を規定した。3 種の PEM CA がある。:

(a) IPRA(Internet Policy Registration Authority): the Internet Society の auspices のもとで運用され、この authority は、PEM 認証(certification)階層の level 1 に位置する root の役割を果たす。これは、証明書を次のレベルの authorities(PCA)宛にのみ発行する。すべての証明書パスは、その IPRA で始まる。

(b) PCA(Policy Certification Authorities): PCA は、階層の level 2 にあり、各 PCA は、IPRA によって認定される。PCA は、認定するユーザ、もしくは、subordinate CA に関するポリシーの言明を確立し、公表するものとする。Distinct PCA は、異なるユーザのニーズを満たすことを目的とする。例えば、ある PCA (an organizational PCA) は、営利組織の一般的な電子メールのニーズをサポートする可能性があり、別の PCA (a high-assurance PCA) は、法的にディジタル署名要件を結合することを満たすために制定された、より stringent なポリシーをもつ可能性がある。

(c) CA(Certification Authority): CA は、階層のレベル 3 にあり、より下位にある可能性もある。レベル 3 にあるものは、PCA によって認証される。CA は、例えば、特定の組織、特定の組織内の単位(例: 部門、グループ、セクション)もしくは特定の地理学的な地域を表現する。

RFC 1422 は、さらに、名前に関して下位に位置づけるルールをもつ。これは、「CA は、その名前が(その X.500 命名ツリー中で)その CA 自体の名前の下位に位置づけられる主体用の証明書のみを発行できること」を要求する。PEM 証明書パスに関連する信頼(trust)は、その PCA 名によって意味される。この名前を下位に位置づけるルールは、「PCA 配下の CA は、彼らが認定する(certify)可能性がある subordinate 主体の集合に関して、合理的に見なされること(例: ある組織について、CA は、その組織の名前 tree 中の主体のみを認定できる)」を確保する。証明書ユーザのシステムは、「その名前の subordination ルールが遵守されていること」を機械的にチェックできる。

RFC 1422 は、X.509 v1 証明書フォーマットを使う。X.509 v1 の制限は、関連するポリシー情報を明確にするため、あるいは、証明書の用途を制限するために、いくつかの構造的制限を無理に要求した。これらの制限は、下記の事項を含む。:

(a) すべての証明書パスが IPRA から始まることを伴う純粋なトップダウン階層。

(b) CA の サブジェクトの名前を制限して下位に位置づける命名ルール。

(c) PCA 概念(concept)の利用。これは、証明書チェーン検証ロジック中に組み込まれるようにするために、個々の PCA の知識を要求する。個々の PCA の知識は、「チェーンは、許容される可能性があるか否か」を判定するために要求された。

X.509 v3 と共に、RFC 1422 によって対応された大部分の要件は、使われている CA 構造を制限することを必要とせずに証明書拡張を使うことによって対応されうる。特に、証明書ポリシーに関する証明書拡張は、PCA についての必要性を不要にし、制約拡張は、名前 subordination ルールについての必要性を不要にする。結果として、本書は、下記事項を含むより柔軟なアーキテクチャをサポートする。:

(a) 証明書パスは、ユーザ自身のドメイン中の CA の公開鍵から、あるいは、階層の頂点の公開鍵から始まる。ユーザ自身のドメイン中の CA の公開鍵から始めることには、一定の優位性がある。環境によっては、そのローカルドメインが最も信頼される。

(b) 名前制約は、証明書中に名前制約拡張を明示的に含めることを通じて提起されるが、要求されない可能性がある。

(c) ポリシー拡張およびポリシーマッピングは、より高度に自動化することを許容する PCA concept に置き換える。そのアプリケーションは、「その証明書パスが PCA についての先験的な知識の代わりに、その証明書の制約に基づいて、受容可能か否か?」を判定できる。これは、証明書パス処理の自動化を許容する。

また、X.509 v3 は、CA か、あるいは、エンドエンティティのいずれかとして、PEM において要求されていたオフライン(out-of-band)情報への依存を低減する証明書の サブジェクト を識別する拡張を含む。

この仕様は、ふたつのクラスの証明書を扱う。(CA 証明書および主体(entity)証明書)CA 証明書は、さらに 3 つのクラスに分けられる可能性がある。(横断証明書、自発行証明書および自己署名証明書)横断証明書は、CA 証明書であり、この中で、その発行者と サブジェクト は、異なる主体である。横断証明書は、ふたつの CA 間の信頼関係を記述する。自発行証明書は、CA 証明書であり、ここでは、その発行者と サブジェクトは、同一の主体である。自発行証明書は、ポリシーもしくは運用における変更をサポートするために生成される。自己署名証明書は、そのディジタル署名が、その証明書に制限される公開鍵によって検証される可能性がある場合の自発行証明書である。自己署名証明書は、証明書パスの始点とする用途のために公開鍵を運ぶために使われる。エンドエンティティ証明書は、証明書を発行することを認可されていないサブジェクト宛に発行される。

3.3. 失効 English

証明書が発行されるとき、その有効期間の全期間に渡って使われることが期待される。しかし、様々な状況が、「証明書が有効期間の期限切れの前に不正となること」をもたらす可能性がある。このような状況は、名前の変更、サブジェクトと CA の関係の変更(例: 従業員が組織との雇用契約を終了する)や、対応するプライベート鍵の侵害もしくは侵害の疑念を含む。このような状況のもとで、その CA は、その証明書を失効させる必要がある。

X.509 は、ひとつの証明書失効の手法を規定する。この手法は、CRL(証明書失効リスト)と呼ばれる署名されたデータ構造体を定期的に発行する各 CA を巻き込む。CRL は、CA もしくは CRL の発行者によって署名され、公衆のリポジトリにおいて自由に入手可能にされた失効された証明書を識別する、タイムスタンプされたリストである。失効された各証明書は、CRL において、その証明書シリアル番号によって識別される。証明書を使うシステムが証明書を使うとき(例: 遠隔ユーザのディジタル署名を検証するため)、そのシステムは、その証明書の署名と妥当性をチェックするのみならず、"suitably recent" な CRL を得て、「その証明書のシリアル番号は、その CRL 上に無いこと」をチェックする。"suitably recent" の意味は、ローカルポリシーによって多様である可能性があるが、これは、通常、最近、発行された CRL を意味する。新しい CRL は、定期的に(例: 毎時、毎日もしくは毎週)発行される。ある主体は、その CRL に、失効の通知に従う next update の一部として加えられる。主体は、それが失効された証明書の有効期間を越えて発行された、通常(regularly)スケジュールされていないひとつの CRL 上に現れるまでに、その CRL から消去されなければならない(MUST NOT)

この失効手法の優位性は、「CRL は、証明書自体 (まさに、信頼されていない(untrusted)サーバ、かつ、信頼されていない通信経由)として、まさに同一の手段によって配布される可能性があること」にある。

その CRL 失効手法のひとつの制限として、信頼されていない通信やサーバの利用は、「失効の時刻の精度(granularity)は、その CRL 発行周期に制限されること」である。例えば、失効が今、報告された場合、その失効は、現在発行されている、すべての CRL が更新されるようにスケジュールされるまで、証明書を使うシステム宛てに、信頼性を確保して通知されるわけではない。 -- これは、CRL が発行される頻度に拠って 1 時間、1 日、もしくは 1 週間までの幅がある可能性がある。

X.509 v3 証明書 フォーマットについてと同様に、複数のベンダーからの相互運用可能な実装を容易にするために、X.509 v2 CRL フォーマットは、インターネットにおける利用のためにプロファイル化されることを要する。そのプロファイルを規定することは、本書の目標のひとつである。しかし、このプロファイルは、CRL の発行を要しない。オンライン失効通知をサポートするメッセージフォーマットおよびプロトコルは、他の PKIX 仕様に規定されている。失効通知のオンライン手法は、X.509 CRL の代替手段として、環境によっては適用可能である可能性がある。オンライン失効のチェックを行うことは、失効報告と、relying 主体宛の情報配信の間の待ち時間(latency)を著しく低減する可能性がある。ひとたび、その CA が失効報告を正統(authentic)かつ妥当として受容すると、そのオンラインサービスへの、あらゆる問い合わせは、その失効の証明書検証への影響を正しく反映する。しかし、これらの手法は、新しいセキュリティ要件を提起する。: そのリポジトリは、信頼される必要はないが、その証明書検証器は、そのオンライン検証サービスを信頼する必要がある。

3.4. 運用プロトコル English

運用プロトコルは、証明書および CRL(もしくは状態情報)を証明書を使うクライアントシステム宛に配布することを要する。証明書および CRL を配布する多様な異なる手段について、(LDAP、HTTP、FTP および X.500 に基づく配布手順を含めて)規定が必要とされる。これらの機能をサポートする運用プロトコルは、他の PKIX 仕様において規定されている。これらの仕様は、上記のすべての運用環境をサポートするためのメッセージフォーマットおよび手順(適切な MIME content type の定義、もしくは、MIME content type への参照を含む)の定義を含む可能性がある。

3.5. 管理プロトコル English

管理プロトコルは、PKI ユーザと管理主体の間のオンラインの相互作用をサポートすることを要する。例えば、管理プロトコルは、CA と、鍵ペアが関連づけられるクライアントシステムの間、あるいは、相互に横断認証しているふたつの CA 間で使われる可能性がある。潜在的に管理プロトコルによってサポートされる必要がある機能の集合は、下記の機能を含む。:

(a) 登録(registration):
これは、プロセスであり、これによって、ユーザは、まず、その CA がそのユーザ用の証明書(単数もしくは複数)を発行する前に CA(直接、もしくは、RA を通じて)宛に自身を知らせる。

(b) 初期化(initialization):
クライアントシステムがセキュアに運用できる前に、そのインフラストラクチャ中のどこかに保管される鍵と共に、適切な関係をもつ「鍵とする素材」をインストールすることが不可欠である。例えば、そのクライアントは、その trusted CA の公開鍵および他の言明された情報をもつ証明書パスを検証する際に使われるように、セキュアに初期化される必要がある。

さらに、クライアントは、典型的には、自体の鍵ペアで初期化される必要がある。

(c) 認定(certification):
これは、CA が証明書をユーザ の公開鍵について発行するプロセスであり、その証明書をそのユーザのクライアントシステム返す。かつ/または、その証明書をリポジトリに投函する。

(d) 鍵ペアの回復:
オプションとして、ユーザクライアントの鍵とする素材(例: 暗号化の目的のために使われるユーザのプライベート鍵)は、CA もしくは鍵のバックアップシステムによってバックアップされる可能性がある。ユーザが、これらのバックアップ鍵とする素材を復旧することを必要とする場合(例: 失念したパスワード、もしくは、喪失した鍵チェーンファイルの結果として)、オンラインプロトコル交換(exchange)は、このような復旧をサポートする必要とされる可能性がある。

(e) 鍵ペアの更新(update):
すべての鍵ペアは、定期的に更新される(すなわち、新しい鍵ペアで置き換えられ、新しい証明書が発行される)必要がある。

(f) 失効要求(request):
認可された人物は、証明書失効を要する異常な状況にある CA を助言する。

(g) 横断認証(cross-certification):
ふたつの CA は、横断証明書を確立する際に使われる情報を交換する。横断証明書は、一方の CA によって、証明書を発行するために使われる CA 署名鍵を含む他方の CA 宛に発行される証明書である。

オンラインプロトコルは、上記の機能を実装する唯一の方法ではないことに注意。すべての機能について、同じ結果を達成するオフラインの手法があり、この仕様は、オンラインプロトコルの利用を強制しない。例えば、ハードウェアトークンが使われるとき、その機能の多くは、物理的トークンの配布の一部として達成される可能性がある。さらに、上記の機能には、ひとつのプロトコル交換中に組み合わされるものがある可能性がある。特に、複数の登録機能、初期化機能および 認定(certification)機能がは、ひとつのプロトコル交換に組み合わされる可能性がある。

PKIX シリーズの仕様は、上記の機能をサポートする標準メッセージフォーマットの集合を規定する。これらのメッセージを異なる環境(例: 電子メール、ファイル 転送および WWW)において運ぶためのプロトコルは、それらの仕様中に記述されている。


2 <- index -> 4