最終更新日：2005年 4月22日
本章では、PKI の信用モデルとして、「単独 CA モデル」、「階層型モデル」、「Web モデル」、「メッシュモデル」、「ブリッジ CA モデル」について解説します。また、信用点 （トラストアンカー） の考え方と、それぞれの信用モデルにおける有効性検証について解説します。
現実世界では様々な組織が様々なポリシーで運営されています。PKI においても同様に、様々な CA が様々なポリシーのもとで運営されています [58]。本書においては、CA が影響を与える信用の範囲を「CA ドメイン」と呼びます。
現実の組織がそれぞれ連携して機能するように、PKI においても、それぞれの CA が連携する場合があります（図 5-1）。CA 同士の連携は、相手の CA に証明書（CA 証明書や相互認証証明書）を発行することによって行われます。CA が連携するということは、その CA が相手の CA を信用していることを意味します。このような信用関係のモデルを「信用モデル」といいます。
図 5-1 様々な CA
上図では、CA1 と CA2 および CA2 と CA3 はそれぞれがお互いを信用しています [59]。また、CA4 は、信用関係を結んでおらず、単独で存在しています。
信用モデルの種類を以下に示します（表 5-1）。
表 5-1 信用モデルの種類
|
種類 |
説明 |
|
単独 CA モデル |
1つの CA が全てのユーザに証明書を発行する方式です。 |
|
階層型モデル |
複数の CA を階層型（ツリー構造）に構成する方式です。 |
|
Web モデル |
あらかじめクライアントのアプリケーションにルート CA の一覧を埋め込む方式です。Web ブラウザで用いられています。 |
|
メッシュモデル |
複数の CA を相互認証により接続する方式です。 |
|
ブリッジ CA モデル |
複数の CA がブリッジ CA を介して接続する方式です。 |
実際には、これら複数の信用モデルを組み合わせて運用する場合があります。これをハイブリッド型といいます。それぞれのモデルの詳細は、5.2節以降で解説します。
証明書利用者 (Relying Party) は、証明書を利用する前にその証明書が信用できることを確認しなければなりません（図 5-2）。
図 5-2 証明書の検証
証明書の有効性検証は、「認証パスの構築 (Certification Path Construction)」と「認証パスの検証 (Certification Paths Validation)」の手順で行います [60]。認証パスとは、検証したい証明書から出発して信用関係を順にたどり、自分が信用している CA まで結ぶものです。認証パス上において、信用の基点となる CA を 「信用点(トラストアンカー： Trust Anchor)」といいます（図 5-3）。
図 5-3 認証パスの構築と検証
上図において、CA1 を信用する証明書利用者が、User1 の証明書を検証する場合を考えます。
証明書利用者は、User1証明書の発行者(issuer)フィールドから CA2 の名前を得ます。CA2 の証明書を所有していない場合、リポジトリ等から入手します [61]。
次に CA2 の証明書の発行者フィールドから、CA1 の名前を得ます。証明書利用者は、CA1 は信用する CA として登録しているので、認証パスの構築はここで終了します。構築された認証パスは、「CA1→CA2→User1」となり、信用点(Trust Anchor)は CA1 となります。
次に、構築した認証パスに対して、信用点 (CA1) から順に証明書の検証を行います。全ての証明書の検証が終わると、証明書の信用性が確認できます。
階層型モデル、メッシュモデル等においては、複数の CA が信用関係で結ばれます。このとき、完全に相手の CA を信用するのではなく、条件を限定して信用したい場合があります。相手の CA に発行する証明書（CA 証明書や相互認証証明書）に制限を記載することで、限定した条件で信用関係を構築できます（図 5-4）。
図 5-4 信用の制限
証明書の拡張領域に記載できる制限の種別を以下に示します（表 5-2）。
表 5-2 証明書に記載する制限
|
種別 |
解説 |
|
基本制約 (basicConstraints) |
その証明書が CA 証明書か否かを示します。また、下位 CA の階層の数を制限します。ユーザ用に発行した証明書が、不正に下位 CA として使われることを防ぎます。 |
|
名前制約 (nameConstraints) |
その CA が発行する証明書について、主体者 (subject) と主体者別名 (subjectAltName) に記載できる名前を制限します。許可する名前と禁止する名前を指定できます。 |
|
ポリシーマッピング (policyMappings) |
2つの証明書ポリシー (CP) が等価であることを表明します。後述する相互認証証明書に使用します。発行者のポリシー ID と主体者のポリシー ID を指定します。 |
|
ポリシー制約 (policyConstraints) |
CP を省略可能な CA の階層数を指定します。また、ポリシーマッピングが有効となる CA のパス数を指定します。 |
|
AnyPolicyの禁止 (inhibitAnyPolicy) |
CP に AnyPolicy（ポリシーを限定しない）を記載することができる CA の階層数を指定します。 |
図 5-4 においては、CA1 が CA2 に発行した証明書において、CA1 で使用する SomeCP1 という証明書ポリシー (CP) と CA2 で使用する SomeCP2 という証明書ポリシーは等価であることを表明しています。CA1 をトラストアンカーとするユーザは、CA2 が発行する証明書のうち、証明書ポリシーが SomeCP2 である証明書 (User1) のみを信用できます。SomeCP2 以外の証明書ポリシーを持つ証明書 (User2) は、このユーザから信用されません。
前のページ 目次 次のページ Copyright © 2005 Information-technology Promotion Agency, Japan. All rights reserved.