属性認証局の運用手順概略

属性認証の利用要求が生じた場合、AC 保有者は当該属性を証明する AC の発行依頼を行う。ま た、企業内の利用における新入社員への属性付与のように、AC 保有者の申請なしに企業側が一律 に発行することもある。 

(1) AC 保有者の申請に基づいて、AC を作成、及び発行 

オンライン or オフライン

①PKC+申請書(署名含む)

③属性確認

⑤AC発行処理 オンライン or オフライン

⑥AC

AC保有者 管理主体

オンライン or オフライン

オンライン or オフライン

④確認結果

②PKCおよび署名の 有効性検証 運用主体(AA)

図 3-4 AC 保有者の申請に基づく属性証明書の発行フロー 

① AC 保有者は、AA に対して、PKC と、その PKC に対応した秘密鍵による署名が付与された 申請書を AA に送付する。 

② AA は、PKC および申請書に対する署名の検証を行う。 

③ AA は、②が OK の場合、属性の管理主体に申請された属性の確認を行う。 

④ 属性の管理主体は、確認結果を AA に返す。 

⑤ AA は、④が OK の場合、AC 発行処理を行う。 

⑥ AA は、AC 保有者に AC を送付する。 

(2) 管理主体の申請に基づいて、一律に AC を作成、及び発行 

②AC一括発行処理

オンラインorオフライン

③AC

AC保有者 管理主体

オフライン

① PKC＋属性情報

運用主体(AA)

図 3-5 管理主体の申請に基づく属性証明書の発行フロー 

① 管理主体は、AA に対し、AC 発行対象者の PKC および属性情報を送付する。 

② AA は、AC 一括発行処理を行う。 

③ AA は、状況に応じて AC を AC 保有者に提供する。 

(3) AC の利用 

本節では、AC の発行を受けた AC 保有者が AC を利用して自身の資格や権限を証明するため の手順について述べる。AC の利用方法には push 型と pull 型のモデルがあり、一般的には push 型モデルが主流である。例外的な利用方法として、本人の関知しないところで AC がサ ーバで集中管理されており、AC 検証者はそのサーバにアクセス可能であるという利用モデル も考えられ、そのような場合には pull 型モデルが適する。 

push 型とは、AC 保有者が、AC 検証者に対して AC を送り付けることにより、AC 保有者の 資格や権限を確認するモデルである。従って、AA によって発行された AC は、AC 保有者自身 が保持(管理)していることが、push 型モデルの前提となる。 

pull 型とは、AC 検証者が、資格・権限の確認に必要な AC をリポジトリ等から取り寄せる ことにより、AC 保有者の資格や権限を確認するモデルである。従って、AA によって発行さ れた AC は、AC 検証者がアクセス可能なリポジトリによって保持(管理)されていることが、

pull 型モデルの前提となる。 

属性証明書利用フローを図に示す。 

属性認証局  (AA)

AC保有者 AC検証者

ACの発行  push 型モデルの場合 

① 署名データの生成  ③ 署名データの検証 

(ACの検証含む)  認証局 

(CA)

(③-3 ACの有効性確認)  (③-2 PKCの有効性確認) 

② 資格・権限の提示  (署名データの送付) 

AC の送付: 

push 型モデルの場合 

③-1 ACの取得  pull 型モデルの場合  リポジトリ

④ 属性の認証  (資格・権限のチェック)  ACの発行 

pull 型モデルの場合 

図 3-6 属性証明書利用フロー 

①  AC 保有者は、資格・権限を提示するために必要な署名データを生成する。すなわち、AC 保有者は、AC 保有者の資格・権限を記載した AC(pull 型の場合 AC 自体は含まず、AC を 保持するリポジトリの所在を示す情報)、および、AC 保有者の PKC を含む形で署名デー タを生成する。当該署名データの生成には、AC 保有者の秘密鍵を使用する。 

②  AC保有者は、資格・権限をAC検証者に提示する。すなわち、①で生成した署名付きデータを AC検証者に送信する。 

③  AC検証者は、AC保有者から受信した署名データを検証する。署名データの検証には、AC 保 有者の AC の検証も含まれる。pull 型の場合は AC 保有者の AC を取得するために、署名 データに含まれる AC の所在を示す情報を元に、AC の取得を行う(③-1)。次に AC 保有者 の PKC や、AA の PKC の検証が行うが、必要に応じて CAに対して有効性確認を行う(③-2)。

その後ACの検証を行うが、ACが失効することがある場合には、AAに対してACの有効性確認 を 行 う 。 具 体 的 に は 、ACRL(Attribute  Certificate  Revocation  List)の 取 得 や OCSP(Online Certificate Status Protocol)による有効性確認を行う。 

④  AC検証者は、ACに記載されている属性(資格・権限等)と、AC検証者で管理しているルールや アクセス制御ポリシーとを比較し、当該ACを提示したAC保有者がサービスを受ける資格・権限 があるかどうかを判断する。 

(4) 属性証明書の失効 

AC 保有者の秘密鍵の危殆化、属性の変更などが生じた場合、AC 保有者の安全性確保、サ ービス品質の維持のため、その AA が発行した AC の失効を要することも想定される。また、

AC は、その失効理由、AC 有効期間など個々の要素およびそれらの組み合わせにより失効を 要しない場合も存在する。たとえば、AC の有効期間をごく短くし、有効期限を迎えるたびに

自動的に AC の更新を行うことによって、時間的にあまり変化しない属性を AC によって証明 するようなシステムの場合、属性の変更などが発生した場合には、単に AC の自動更新を停 止すればよいからである。