XKMS(XML Key Management Specification)は公開鍵基盤(PKI)を利用するためのメッセージとプロトコルを定義するXML規格です｡現在､W3Cの作業部会において検討中で､最新の仕様書はXKMS 2.0 Working Draft 18 March 2002になります｡（URIは５ 項を参照ください。）

XKMSは二つの基本仕様から構成されます｡一つ目は､公開鍵関連情報の問合せを行うX-KISS(Key Information Service Specification)です｡二つ目は､公開鍵関連情報の管理を行うX-KRSS(Key Registration Service Specification)です｡

XKMSの仕様を説明する前に､前提となる公開鍵基盤(PKI: Public Key Infrastructure)の技術を説明します｡

PKIは､電子署名､公開鍵暗号を実現するために必須となるインフラストラクチャです｡電子署名において､検証者(受信側)による付与者(送信側)の正当性の確認は､電子署名に添付される公開鍵の正当性を確認することで行われます｡一般的に、公開鍵の正当性は第三者機関が発行する公開鍵証明書の検証により行われます。この公開鍵を流通させる基盤がPKIになります｡

PKIは公開鍵の管理･登録を行う第三者機関(登録局･認証局)と送信側･受信側から構成されます｡以下､PKIを使用した電子署名付与・検証の最も一般的な手順を説明します｡

1. 電子署名付与に使用する私有鍵と公開鍵のセット(鍵ペア)を生成します｡
2. 公開鍵を第三者機関(登録局)に登録要求します｡
3. 公開鍵証明書を受け取ります｡（一度登録した公開鍵は継続して使用します。）
4. 送信文書と公開鍵証明書に対して私有鍵を使用して署名を付与します｡
5. 署名付き送信文書を受信者に送信します｡

1. 登録要求のあった公開鍵に対して付加情報(発行者､発行者ｼﾘｱﾙ番号､有効期限等)を追加します｡
2. 前記の情報に対して､第三者機関自身の署名を付与します｡(これが公開鍵証明書になります｡)
3. 登録要求元に公開鍵証明書を送付します｡合わせて､認証局において公開鍵証明書を公開します｡

1. 公開鍵証明書に対する第三者機関の署名を検証します｡(注:第三者機関自体の証明書は予め手元にあることが前提です｡)
2. 認証局で公開されるCRLを取得し､検証する公開鍵証明書が掲載されていないかを確認します｡
3. 公開鍵証明書内の公開鍵を使用して､文書に付与される電子署名を検証します｡

公開鍵暗号の場合も､送信側と受信側の処理が逆になりますが､ほぼ同様の処理が行われます｡

以上、説明しましたＰＫＩですが、以下の問題点が指摘されています。

1. 公開鍵証明書の検証は、自身の複雑な構造（証明書チェーン等）の解析、失効リストの検証が必要であり、利用者（クライアントプログラム）の大きな負担になります｡
2. 第三者機関のインタフェースが標準化されていないため、自動化システムの構築が困難です｡

XKMSは前項で説明したPKIにおいて､利用者(送信側､受信側)と第三者機関(XKMS サーバ)との間のメッセージとプロトコルを定義するXML規格です｡メッセージはXML文書(スキーマ)で定義されます｡メッセージは利用者からXKMSサーバへ送られる要求メッセージとXKMSサーバから利用者へ返される応答メッセージがあり､それぞれ一対一で対応します｡XKMSサーバをWebサービスで構成するとき､メッセージはSOAPでラッピングされそれぞれSOAPリクエスト､SOAPレスポンスになります｡XKMSのメッセージとプロトコルの概要を図 2に示します｡

また、XKMSで規定されるのはメッセージとプロトコルのみです。登録局・認証局のサーバ構成等は規定されません。従って、XKMSサーバは既存の登録局・認証局の一部サービスとなる、若しくは、既存の登録局・認証局のフロントエンドサーバとなることが想定されています。想定されるシステム構成例を図 3に示します。

XKMSで規定される機能は大きく二つあります。一つ目は､公開鍵関連情報の問合せを行うX-KISS(Key Information Service Specification)です｡二つ目は､公開鍵関連情報の管理を行うX-KRSS(Key Registration Service Specification)です｡

要求メッセージのトップエレメントがXKMSサーバに対する要求内容となります｡(*1)　現在､X-KRSSで一種類(<Register>:登録)､X-KISSで三種類(<RetrievalMethod>：取得、<Locate>:発見､<Validate>:検証)のエレメントが規定されています｡応答メッセージは“要求メッセージ+Result“のエレメントとなります｡例えば､<Register>要求の応答メッセージは<RegisterResult>になります｡

(*1)SOAPメッセージの時は、<soap:body>内部に現れます。

X-KRSS(Key Registration Service Specification)は､公開鍵関連情報の管理に関するサービス仕様です｡登録､失効､回復の三つのサービスから構成されます｡要求メッセージは、生成する鍵の元情報<Prototype>と鍵保持者の情報<AuthInfo>から構成されます。応答メッセージは登録した鍵の情報<KeyBinding>から構成されます。鍵生成は二種類の方式から選択できます。一方は、クライアントサイドで生成した公開鍵関連情報の登録で、他方はサーバサイドで生成した公開鍵関連情報（この場合、私有鍵も含まれます）の取得です。指定は鍵保持者の情報<AuthInfo>の構成によります。<Register>の主要なエレメントを表 1に、<RegisterResult>の主要なエレメントを表 2に示します。

表 1 Registerの主要エレメント

エレメント	説明
<Prototype>	要求の分類と登録する公開鍵関連情報 <Status>:要求内容の指定。Validate：登録、Invalid：失効、Indeterminate：回復 <KeyInfo>:登録する鍵の情報
<AuthInfo>	要求者の情報 <AuthUserInfo>：クライアントサイド生成時の鍵保有者情報 <AuthServerInfo>：サーバサイド生成時の鍵保有者情報
<Respond>	応答メッセージに含める問合せ情報

表 2 RegisterResultの主要エレメント

エレメント	説明
<Result>	要求自体の成功・不成功
<Answer>	<Status>：要求内容の結果 <KeyInfo>：登録された公開鍵関連情報

X-KISS（Key Information Service Specification）は､公開鍵関連情報の問合せに関するサービス仕様です｡層０から層２までの三階層が定義され、上位層は下位層の機能を包含します。層０は公開鍵関連情報への到達情報から公開鍵関連情報を取得する<RetrievalMethod>サービスです。単純に公開鍵関連情報を取得するのみで、サービスでの特別な処理は行われません。層１は不完全な公開鍵関連情報から完全な公開鍵関連情報を取得する<Locate>サービスです。不完全な公開鍵関連情報とは、公開鍵を特定する曖昧な情報を指します。例えば、鍵名<KeyName>から公開鍵関連情報を取得します。層２は公開鍵関連情報を検証する<Validate>サービスです。<Locate>サービスの機能に加え、問合せされた公開鍵関連情報に対して、失効状態の確認、有効期限の確認等の検証を行います。

X-KISSの要求メッセージは、不完全な（若しくは、完全な）公開鍵関連情報の情報<Query >と問合せ内容<Respond>から構成されます。応答メッセージは、公開鍵関連情報の取得結果<Result>、取得した公開鍵関連情報<KeyInfo>から構成されます。また、<Validate>では<Locate>サービスの結果に加え、公開鍵の検証結果<KeyBinding>が含まれます。

<Locate><Validate>の主要なエレメントを表 3に、<LocateResult><ValidateResult>の主要なエレメントを表 4に示します。<RetrievalMethod>は３-６ 項に示すXML Signatureの定義が使用されます。

表 3 Locate/Validateの主要エレメント

エレメント	説明
<Query>	<KeyInfo>：問合せする不完全な公開鍵関連情報
<Respond>	応答メッセージに含める問合せ情報

表 4 LocateResult/ValidateResultの主要エレメント

エレメント	説明
<Result>	要求自体の成功・不成功
<Answer>	<Status>：要求内容結果 <KeyInfo>：取得した公開鍵関連情報（<Locate>サービス） <KeyBinding>：検証した公開鍵関連情報（<Validate>サービス）

XML Signatureは電子署名を定義するXML規格です。

XKMSのメッセージ中に現れる<KeyInfo>はXML Signatureで規定される公開鍵関連情報<KeyInfo>がそのまま使用されます。<KeyInfo>は、鍵名<KeyName>、鍵の値<KeyValue>、公開鍵証明書<X509Certificate>等から構成されます。従いまして、XKMSはXML Signatureでの署名処理と高い親和性を持っています。例えば、XML Signatureで取得した公開鍵をそのままXKMSのValidateサービスに渡して検証することができます。同様に、XML Encryption（XML 暗号）も、鍵情報として<KeyInfo>を使用していますので、同様の高い親和性を持っています。

一方、XKMSのメッセージ内部にもXML Signatureが使用されています。例えば、サービスへの認証情報、鍵保有者情報はXML Signatureで表現され、完全性の保証のためにメッセージをXML Signatureで署名することが推奨されています。

以上説明しました通り、XKMSはPKIを容易に利用するためには必須な規格です。しかしながら、Working DraftはW3Cでの検討が始まったばかりで（*2）、タグの定義が曖昧であるなど、仕様はまだまだ未熟です。大いに議論され成熟した規格として早期に勧告されることが望まれます。

また、VeriSign社、WebMethod社において、XKMS 1.1に準拠したテストサイトが公開されています。

(*2)XKMSはVeriSign社、Microsoft社、WebMethod社等にて策定され、2001-3-30にW3Cに提案されましたが、作業部会は作成されませんでした。作業部会が発足し検討が始まったのはXKMS 2.0からになります。

XML Key Management Specification (XKMS 2.0)： http://www.w3.org/TR/xkms2/

XML-Signature Syntax and Processing：http://www.w3.org/TR/xmldsig-core/

XML Trust Center：http://www.verisign.com/xml/