(57)【要約】【目的】オフラインでの高度のセキュリティーやアクセス制御を実現するようなデータ交換システムやデータ交換方法を提供する。【解決手段】公開鍵を基盤とするデータ交換システムにおいて、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データを交換する。データ交換フォーマット内の属性要素によってオフラインでの利用が図れる。【選択図】　図７
2004118455.tif 000002
【特許請求の範囲】
【請求項１】
公開鍵を基盤とするデータ交換システムであって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とするデータ交換システム。
【請求項２】
前記属性認証局から発行された属性証明書が付与された後では、前記電子データのデータ交換フォーマット内の前記属性要素は公開鍵証明書への関連付け情報を有することを特徴とする請求項１記載のデータ交換システム。
【請求項３】
前記属性要素に関連付けられた公開鍵証明書は前記データ交換フォーマット内の署名要素に付与されることを特徴とする請求項２記載のデータ交換システム。
【請求項４】
前記公開鍵証明書は公開鍵証明書発行認証局によって発行され、該公開鍵証明書発行認証局は前記属性認証局とは異なる機関であることを特徴とする請求項２記載のデータ交換システム。
【請求項５】
前記データ交換フォーマットはＸＭＬ文書からなることを特徴とする請求項１記載のデータ交換システム。
【請求項６】
前記アクセス権限情報に含まれるアクセス権限を有する者は複数であることを特徴とする請求項１記載のデータ交換システム。
【請求項７】
前記アクセス権限情報に含まれるアクセス権限を有する者は、複数のカテゴリーに分類されることを特徴とする請求項１記載のデータ交換システム。
【請求項８】
前記複数のカテゴリーは、他のアクセス権限を有する者の署名とは無関係に自己の署名を付与して再配信を行う者からなる第１のカテゴリーと、他のアクセス権限を有する者の署名を条件として自己の署名を付与して再配信を行う者からなる第２のカテゴリーとを含むことを特徴とする請求項６記載のデータ交換システム。
【請求項９】
前記アクセス権限情報に含まれるアクセス権限を有する者を対象としての前記電子データは、アクセス権限を有する者に対して、前記アクセス権限情報に関連して機能するサーバーを介さずに配信されることを特徴とする請求項１記載のデータ交換システム。
【請求項１０】
前記アクセス権限を有する複数の受信者を対象とした電子データの発信は、同報若しくは回覧を選択可能とすることを特徴とする請求項１記載のデータ交換システム。
【請求項１１】
電子データの発信方法として前記回覧を選択した場合、複数の受信者はそのデータの回覧の順番が予め決められていることを特徴とする請求項１０記載のデータ交換システム。
【請求項１２】
電子データの発信方法として前記回覧を選択した場合、複数の受信者はそのデータの回覧の順番が決められていないことを特徴とする請求項１０記載のデータ交換システム。
【請求項１３】
公開鍵を基盤とするデータ交換方法であって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とするデータ交換方法。
【請求項１４】
前記属性認証局から発行された属性証明書が付与された後では、前記電子データのデータ交換フォーマット内の前記属性要素は公開鍵証明書への関連付け情報を有することを特徴とする請求項１３記載のデータ交換方法。
【請求項１５】
前記属性要素に関連付けられた公開鍵証明書は前記データ交換フォーマット内の署名要素に付与されることを特徴とする請求項１４記載のデータ交換方法。
【請求項１６】
前記公開鍵証明書は公開鍵証明書発行認証局によって発行され、該公開鍵証明書発行認証局は前記属性認証局とは異なる機関であることを特徴とする請求項１４記載のデータ交換方法。
【請求項１７】
前記データ交換フォーマットはＸＭＬ文書からなることを特徴とする請求項１３記載のデータ交換方法。
【請求項１８】
前記アクセス権限情報に含まれるアクセス権限を有する者は複数であることを特徴とする請求項１３記載のデータ交換方法。
【請求項１９】
前記アクセス権限情報に含まれるアクセス権限を有する者は、複数のカテゴリーに分類されることを特徴とする請求項１３記載のデータ交換方法。
【請求項２０】
前記複数のカテゴリーは、他のアクセス権限を有する者の署名とは無関係に自己の署名を付与して再配信を行う者からなる第１のカテゴリーと、他のアクセス権限を有する者の署名を条件として自己の署名を付与して再配信を行う者からなる第２のカテゴリーとを含むことを特徴とする請求項１８記載のデータ交換方法。
【請求項２１】
前記アクセス権限情報に含まれるアクセス権限を有する者を対象としての前記電子データは、アクセス権限を有する者に対して、前記アクセス権限情報に関連して機能するサーバーを介さずに配信されることを特徴とする請求項１３記載のデータ交換方法。
【請求項２２】
前記アクセス権限を有する複数の受信者を対象とした電子データの発信は、同報若しくは回覧を選択可能とすることを特徴とする請求項１３記載のデータ交換方法。
【請求項２３】
電子データの発信方法として前記回覧を選択した場合、複数の受信者はそのデータの回覧の順番が予め決められていることを特徴とする請求項２２記載のデータ交換方法。
【請求項２４】
電子データの発信方法として前記回覧を選択した場合、複数の受信者はそのデータの回覧の順番が決められていないことを特徴とする請求項２２記載のデータ交換方法。
【請求項２５】
公開鍵を基盤とするデータ交換のためのプログラムであって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とするデータ交換プログラム。
【請求項２６】
公開鍵を基盤とするデータ交換プログラムが記録された記録媒体であって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とするデータ交換プログラムが記録された記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は公開鍵を基盤とするデータ交換システム、データ交換方法、データ交換プログラム、及びデータ交換プログラムが記録された記録媒体に関し、特にそのアクセス制御を簡単に処理できるデータ交換システム、データ交換方法、データ交換プログラム、及びデータ交換プログラムが記録された記録媒体に関する。
【０００２】
【従来の技術】
オープンなネットワーク環境においてはインターネットの普及によって電子商取引やイントラネット、社内ＬＡＮなどの社内システムに対するセキュリティの関心が高まってきている。その背景として挙げられるのは、ネットワークを利用したビジネスが急速に展開してきており、ＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔ　Ｌａｙｅｒ）などの公開鍵基盤（ＰＫＩ：Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）が広く導入されつつあることが挙げられる。公開鍵基盤は、公開鍵暗号方式に基づくセキュリティシステムであり、インターネットコマースに関する基本技術として各種のプラットフォームへの標準装備も進められている。
【０００３】
また、ウェブ上の新しいＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ　Ｄａｔａ　Ｉｎｔｅｒｃｈａｎｇｅ）サービスを提供するための言語として、Ｗ３Ｃ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ　Ｃｏｎｓｏｒｔｉｕｍ）によって標準化が進められたＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）が急激に普及を遂げている。ＸＭＬは、従来からのウェブページの作成用記述言語として標準的なＨＴＭＬの拡張仕様として開発され、文書構造を記述できるＳＧＭＬ（Ｓｔａｎｄａｒｄ　Ｇｅｎｅｒａｌｉｚｅｄ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）のサブセットとして開発されたデータ交換フォーマットである。このＸＭＬにおいても公開鍵基盤の導入が検討されており、電子署名技術などについてＷ３Ｃによって標準化のための作業が進められており、いくつかの勧告も行われている。
【０００４】
【発明が解決しようとする課題】
現状の公開鍵基盤のシステムは、サーバーを中心とするシステムが多くなっている。そのため、ネットワーク上ではセキュリティーを確保できるものの、オフラインで文書などの電子データを交換する場合では高いセキュリティーを維持しながらサービスを提供することが困難である。その理由の１つとしては、ユーザの権限やデータへのアクセス権などのアクセス制御がシステムの中核をなすサーバーによって処理されていることから、オフラインではアクセス権限の制御が困難となる。
【０００５】
そこで、本発明は、このような技術的な課題に鑑み考案されたものであって、オフラインでの高度のセキュリティーやアクセス制御を実現するようなデータ交換システム、データ交換方法、データ交換プログラム、及びデータ交換プログラムが記録された記録媒体の提供を目的とする。
【０００６】
【課題を解決するための手段】
上述の目的を達成するため、本発明のデータ交換システムは、公開鍵を基盤とするデータ交換システムであって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とする。
【０００７】
本発明のデータ交換システムによれば、電子データのデータ交換フォーマット内の属性要素に属性認証局から発行されたアクセス権限情報を含む属性証明書が含まれることになり、その属性要素の認識は特別なサーバーなどによる必要がなく、各種のパーソナルコンピューターなどの電子情報機器でのアクセス管理が可能となる。
【０００８】
また、同様に、本発明のデータ交換方法は、公開鍵を基盤とするデータ交換方法であって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とする。
【０００９】
本発明のデータ交換方法によれば、電子データのデータ交換フォーマット内の属性要素に属性認証局から発行されたアクセス権限情報を含む属性証明書が含まれることになり、各種のパーソナルコンピューターなどの電子情報機器でのアクセス管理が可能となり、アクセス権限を制御する際にその都度サーバーに接続する必要なく処理が可能となる。
【００１０】
また、本発明のデータ交換プログラムは、公開鍵を基盤とするデータ交換のためのプログラムであって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とする。
【００１１】
本発明のデータ交換プログラムによれば、電子データのデータ交換フォーマット内の属性要素に属性認証局から発行されたアクセス権限情報を含む属性証明書が含まれることになり、その属性要素の認識は特別なサーバーなどによる必要がなく、各種のパーソナルコンピューターなどの電子情報機器でのアクセス管理が可能となる。
【００１２】
更に、上述の目的を達成するための本発明のデータ交換プログラムが記録された記録媒体は、公開鍵を基盤とするデータ交換プログラムが記録された記録媒体であって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されることを特徴とする。
【００１３】
本発明のデータ交換プログラムが記録された記録媒体によれば、電子データのデータ交換フォーマット内の属性要素に属性認証局から発行されたアクセス権限情報を含む属性証明書が含まれることになり、その属性要素の認識は特別なサーバーなどによる必要がなく、各種のパーソナルコンピューターなどの電子情報機器でのアクセス管理が可能となるプログラムを提供できることになる。
【００１４】
【発明の実施の形態】
本実施の形態は、公開鍵を基盤とするデータ交換システムであって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換されるデータ交換システムである。
【００１５】
本実施の形態では、アクセス権限を有する者、申請者、確認者、承認者などの本システムの各ユーザについて説明されるが、本明細書では、これらの者にデータを送信したり、配信したりすることは、これらの者がパスワードや認証その他の手段によって、オンライン、オフラインを問わずにエントリーしている情報機器、情報端末、携帯電話機、ＰＤＡ（Ｐｅｒｓｏｎａｌ　Ｄｉｇｉｔａｌ　Ａｓｓｉｓｔａｎｔ）、その他のエンティティに対してデータを送信することを意味している。
【００１６】
本実施の形態のデータ交換システムは、先ず、電子データのデータ交換フォーマットとして、Ｗ３Ｃ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ　Ｃｏｎｓｏｒｔｉｕｍ）によって標準化が進められたＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）が用いられる。ＸＭＬは、従来からのウェブページの作成用記述言語として標準的なＨＴＭＬの拡張仕様であって、文書構造を記述できるＳＧＭＬ（Ｓｔａｎｄａｒｄ　Ｇｅｎｅｒａｌｉｚｅｄ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）のサブセットとして機能するデータ交換フォーマットである。
【００１７】
また、本実施の形態のデータ交換システムは、公開鍵基盤を導入したシステムとなっている。公開鍵基盤とは、簡単には、後述する公開鍵証明書（Ｐｕｂｌｉｃ　ＫｅｙＣｅｒｔｉｆｉｃａｔｅ；ＰＫＣ）を交換して相手を認証する場合、認証局（Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ；ＣＡ）の署名が正しいか否かを検証することで信頼できるか否かを示すことができるシステムであり、認証局が発行した公開鍵証明書を利用してセキュリティを確保するシステムである。
【００１８】
更に、本実施の形態のデータ交換システムは、先のＸＭＬデータ交換フォーマットにおいて、属性証明書　（Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ；ＡＣ）を付加することでデータに対するアクセス権限情報を参照している。このため公開鍵証明書とは、異なるカテゴリーや異なるグループでのアクセス制御を行うことができ、公開鍵証明書の発行機関である認証局とは異なる属性認証局も独立して設置可能であり、属性認証局は属性証明書発行機関としても機能する。
【００１９】
先ず、本実施の形態のデータ交換システムに先立って、電子証明書である公開鍵証明書（Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅ；ＰＫＣ）及び上述した属性証明書の概略について説明する。
【００２０】
初めに、図１に公開鍵証明書（図１の（ａ））と属性証明書（図１の（ｂ））の概要を対比する形式で示す。公開鍵証明書の内容は、バージョン、シリアル番号、署名アルゴリズム、発行者、有効期間、サブジェクト、サブジェクト公開鍵情報、エクステンションなどに及び、証明書発行認証局（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ；ＣＡ）による署名が付与されている。この公開鍵証明書は、公開鍵がその所有者のものであることを証明するためのものであり、その所有者が保持する個人鍵に対応する公開鍵を含む。また、証明書発行認証局の署名は証明書発行認証局の秘密鍵によるものである。
【００２１】
これに対して属性証明書の内容は、バージョン、ホルダー、発行者、署名アルゴリズム、シリアル番号、有効期間、属性、エクステンションなどに及び、属性認証局（Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ；ＡＡ）による署名が付与される。属性証明書を用いることでアクセス制御情報のような証明書所有者の属性情報と公開鍵証明書を分離することができ、属性証明書には公開鍵が含まれず、公開鍵証明書への関連付け情報（図１において矢印で示す。）がホルダーの部分に含まれる。
【００２２】
次に、公開鍵証明書について詳しく説明する。公開鍵証明書は、いわゆる公開鍵暗号方式における独立した所定の第三者機関である証明書発行認証局（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ；ＣＡ又はＩｓｓｕｅｒ　Ａｕｔｈｏｒｉｔｙ；ＩＡ）によって発行されるものである。
【００２３】
ここで、公開鍵暗号方式について説明する。公開鍵暗号方式は、発信者と受信者との鍵を異なるものとして、一方の鍵を不特定のユーザが使用可能な公開鍵とし、他方の鍵を秘密に保つ秘密鍵とするものである。公開鍵暗号方式は、暗号化及び復号に共通の鍵を用いるいわゆる共通鍵暗号方式と異なり、秘密に保つ必要がある秘密鍵を特定の１人が持てばよいため、共通鍵暗号方式と比較して鍵の管理において有利である。公開鍵暗号方式の代表的なものとしては、いわゆるＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ）暗号がある。このＲＳＡ暗号は、例えば１５０桁程度の非常に大きな２つの素数の積の素因数分解処理の困難性を利用するものである。
【００２４】
公開鍵暗号方式は、不特定多数のユーザに公開鍵を使用可能とするものであり、配布する公開鍵が正当なものであるか否かを証明するために公開鍵証明書を用いる方法が広く用いられている。例えば、公開鍵暗号方式においては、ある特定のユーザＡが対となる公開鍵と秘密鍵とを生成し、生成した公開鍵を証明書発行認証局に対して送付して公開鍵証明書を取得し、この公開鍵証明書を一般に公開する。一方、不特定のユーザは、公開鍵証明書に基づいて所定の手続きを経ることによって公開鍵を取得し、平文たる文書等を暗号化して特定のユーザＡに対して送付する。そして、ユーザＡは、不特定のユーザから送付された暗号化文書を秘密鍵を用いて復号する等の処理を行う。公開鍵暗号方式は、このような暗号方式である。
【００２５】
また、公開鍵暗号方式においては、ユーザＡは、秘密鍵を用いて平文たる文書等に署名を付加し、不特定のユーザが公開鍵証明書に基づいて所定の手続きを経ることによって公開鍵を取得し、その署名の検証を行うことが可能となる。例えば、公開鍵暗号方式においては、証明書発行認証局が公開鍵証明書を参照して公開鍵を判別すると、任意の平文たる文書等をユーザＡに対して送付し、秘密鍵を用いて暗号化させ、再度送り返させる。証明書発行認証局は、ユーザＡから送付された暗号化文書を公開鍵を用いて復号することにより、署名の正当性を検証することができる。
【００２６】
このような公開鍵暗号方式における公開鍵証明書は、管理者たるユーザが自己を識別するための情報や公開鍵等を証明書発行認証局に提出することにより、証明書発行認証局側が当該証明書発行認証局を識別するための情報や有効期限等の情報を付加し、さらに証明書発行認証局による署名を付加して作成される。
【００２７】
具体的には、公開鍵証明書は、図２及び図３に示すようなフォーマットから構成される。なお、同図においては、公開鍵証明書を構成する各フィールド毎の項目と、これらの各項目に対する説明とを記載している。
【００２８】
図２に示すバージョン（ｖｅｒｓｉｏｎ）は、公開鍵証明書のフォーマットのバージョン情報を記述するフィールドであり、例えばフォーマットがバージョン３である場合にはバージョン３を示す”２”が記述される。
【００２９】
シリアルナンバ（ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）は、証明書発行認証局によって設定される公開鍵証明書のシリアルナンバを記述するフィールドであり、例えばシーケンシャルな番号が記述される。
【００３０】
署名アルゴリズム識別子、及びアルゴリズムパラメータ（ｓｉｇｎａｔｕｒｅ　ａｌｇｏｒｉｔｈｍ　Ｉｄｅｎｔｉｆｉｅｒ　ａｌｇｏｒｉｔｈｍ　ｐａｒａｍｅｔｅｒｓ）は、公開鍵証明書の署名アルゴリズムを識別するための情報とそのパラメータとを記述するフィールドである。署名アルゴリズムとしては、例えば楕円曲線暗号又はＲＳＡ暗号があり、署名アルゴリズムとして楕円曲線暗号が適用されている場合には、アルゴリズムパラメータとしてパラメータ及び鍵長が記述され、署名アルゴリズムとしてＲＳＡ暗号が適用されている場合には、アルゴリズムパラメータとして鍵長が記述される。
【００３１】
発行者（ｉｓｓｕｅｒ）は、公開鍵証明書の発行者、すなわち、証明書発行認証局の名称を識別可能とする形式（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ　Ｎａｍｅ）で記述するフィールドである。
【００３２】
有効期限（ｖａｌｉｄｉｔｙ）は、公開鍵証明書の有効期限である開始日時（ｎｏｔ　Ｂｅｆｏｒｅ）及び終了日時（ｎｏｔ　Ａｆｔｅｒ）を記述するフィールドである。
【００３３】
サブジェクト（ｓｕｂｊｅｃｔ）は、ユーザである認証対象者の名前を記述するフィールドであり、例えばユーザ機器の識別子やサービス提供主体の識別子等が記述される。
【００３４】
サブジェクト公開鍵情報（ｓｕｂｊｅｃｔ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｏ　ａｌｇｏｒｉｔｈｍ　ｓｕｂｊｅｃｔ　Ｐｕｂｌｉｃ　ｋｅｙ）は、ユーザの公開鍵情報としての鍵アルゴリズムや鍵情報自体を記述するフィールドであり、鍵アルゴリズムとしては、例えば楕円曲線暗号又はＲＳＡ暗号がある。
【００３５】
これらの各フィールドは、公開鍵証明書のフォーマットがバージョン１以降のバージョンであるものに含まれるフィールドであり、以下に示す各フィールドは、バージョン３であるものに追加されるフィールドである。
【００３６】
証明局鍵識別子（ａｕｔｈｏｒｉｔｙ　Ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ−ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ，　ａｕｔｈｏｒｉｔｙ　Ｃｅｒｔ　Ｉｓｓｕｅｒ，　ａｕｔｈｏｒｉｔｙ　Ｃｅｒｔ　Ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）は、証明書発行認証局の署名確認用の鍵を識別するための情報であり、８進数表記の鍵識別番号、一般名称（Ｇｅｎｅｒａｌ　Ｎａｍｅ）形式の証明書発行認証局の名称、及び認証番号を記述するフィールドである。
【００３７】
サブジェクト鍵識別子（ｓｕｂｊｅｃｔ　ｋｅｙ　Ｉｄｅｎｔｉｆｉｅｒ）は、複数の鍵を公開鍵証明書において証明する場合に各鍵を識別するための識別子を記述するフィールドである。
【００３８】
鍵使用目的（ｋｅｙ　ｕｓａｇｅ）は、鍵の使用目的を指定するフィールドであり、（０）ディジタル署名用（ｄｉｇｉｔａｌ　Ｓｉｇｎａｔｕｒｅ）、（１）否認防止用（ｎｏｎ　Ｒｅｐｕｄｉａｔｉｏｎ）、（２）鍵の暗号化用（ｋｅｙ　Ｅｎｃｉｐｈｅｒｍｅｎｔ）、（３）メッセージの暗号化用（ｄａｔａ　Ｅｎｃｉｐｈｅｒｍｅｎｔ）、（４）共通鍵配送用（ｋｅｙ　Ａｇｒｅｅｍｅｎｔ）、（５）認証の署名確認用（ｋｅｙ　Ｃｅｒｔ　Ｓｉｇｎ）、（６）失効リストの署名確認用（ＣＲＬ　Ｓｉｇｎ）、（７）鍵交換時（ｋｅｙ　Ａｇｒｅｅｍｅｎｔ）データの暗号化にのみ利用（ｅｎｃｉｐｈｅｒ　Ｏｎｌｙ）、及び（８）鍵交換時データの復号にのみ利用（ｄｅｃｉｐｈｅｒ　Ｏｎｌｙ）の各使用目的が設定される。
【００３９】
秘密鍵有効期限（ｐｒｉｖａｔｅ　Ｋｅｙ　Ｕｓａｇｅ　Ｐｅｒｉｏｄ）は、ユーザが有する秘密鍵の有効期限である開始日時（ｎｏｔ　Ｂｅｆｏｒｅ）及び終了日時（ｎｏｔ　Ａｆｔｅｒ）を記述するフィールドであり、デフォルトでは、公開鍵証明書の有効期限と公開鍵の有効期限と秘密鍵の有効期限とは互いに同一とされる。
【００４０】
図３に示す認証局ポリシー（Ｃｅｒｔｉｆｉｃａｔｅ　Ｐｏｌｉｃｙ）は、証明書発行認証局の証明書発行ポリシーを記述するフィールドであり、例えばＩＳＯ／ＩＥＣ　９８３４−１に準拠したポリシーＩＤ（ｐｏｌｉｃｙ　Ｉｄｅｎｔｉｆｉｅｒ）や認証基準（ｐｏｌｉｃｙ　Ｑｕａｌｉｆｉｅｒｓ）が記述される。
【００４１】
ポリシー・マッピング（ｐｏｌｉｃｙ　Ｍａｐｐｉｎｇｓ）は、証明書発行認証局を認証する場合にのみ記述されるフィールドであり、証明書発行を行う証明書発行認証局のポリシー（ｉｓｓｕｅｒ　Ｄｏｍａｉｎ　Ｐｏｌｉｃｙ）と被認証ポリシー（ｓｕｂｊｅｃｔ　Ｄｏｍａｉｎ　Ｐｏｌｉｃｙ）とのマッピングを規定する。
【００４２】
サポート・アルゴリズム（ｓｕｐｐｏｒｔｅｄ　Ａｌｇｏｒｉｔｈｍｓ）は、ディレクトリ（Ｘ．５００）のアトリビュートを定義するフィールドである。サポート・アルゴリズムは、コミュニケーションの相手がディレクトリ情報を利用する場合に、事前にそのアトリビュートを知らせるのに用いる。
【００４３】
サブジェクト別名（ｓｕｂｊｅｃｔ　Ａｌｔ　Ｎａｍｅ）は、ユーザの別名を一般名称（Ｇｅｎｅｒａｌ　Ｎａｍｅ）形式で記述するフィールドである。
【００４４】
発行者別名（ｉｓｓｕｅｒ　Ａｌｔ　Ｎａｍｅ）は、証明書発行者の別名を記述するフィールドである。
【００４５】
サブジェクト・ディレクトリ・アトリビュート（ｓｕｂｊｅｃｔ　Ｄｉｒｅｃｔｏｒｙ　Ａｔｔｒｉｂｕｔｅｓ）は、ユーザの任意の属性を記述するフィールドである。
【００４６】
基本制約（ｂａｓｉｃ　Ｃｏｎｓｔｒａｉｎｔｓ）は、証明対象の公開鍵が証明書発行認証局の署名用であるかユーザのものであるかを区別するためのフィールドである。
【００４７】
許容サブツリー制約名（ｎａｍｅ　Ｃｏｎｓｔｒａｉｎｔｓ　ｐｅｒｍｉｔｔｅｄ　Ｓｕｂｔｒｅｅｓ）は、被認証者が証明書発行認証局である場合にのみ使用される公開鍵証明書の有効領域を示すフィールドである。
【００４８】
制約ポリシー（ｐｏｌｉｃｙ　Ｃｏｎｓｔｒａｉｎｔｓ）は、認証パスの残りに対する明確な認証ポリシーＩＤや禁止ポリシーマップを要求する制限を記述するフィールドである。
【００４９】
ＣＲＬ参照ポイント（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｐｏｉｎｔｓ）は、ユーザが公開鍵証明書を利用する際に、この公開鍵証明書が失効していないかどうかを確認するための失効リストの参照ポイントを記述するフィールドである。
【００５０】
署名は、公開鍵証明書発行者、すなわち、証明書発行認証局の署名フィールドである。電子署名は、公開鍵証明書の全体に対していわゆるハッシュ関数を適用してハッシュ値を生成し、このハッシュ値に対して証明書発行認証局の秘密鍵を用いて暗号化して生成したデータである。
【００５１】
証明書発行認証局は、このようなフォーマットからなる公開鍵証明書を発行するとともに、有効期限が切れた公開鍵証明書を更新し、不正を行ったユーザの排斥を行うための不正者リストの作成、管理、配布、すなわち、リボケーション（ｒｅｖｏｃａｔｉｏｎ）を行う。また、証明書発行認証局は、必要に応じて、公開鍵及び秘密鍵の生成も行う。
【００５２】
一方、この公開鍵証明書を利用するユーザは、自己が有する証明書発行認証局の公開鍵を用いて当該公開鍵証明書の電子署名を検証し、電子署名の検証に成功すると、公開鍵証明書に基づいて公開鍵を取得し、この公開鍵を利用することができる。したがって、公開鍵証明書を利用する全てのユーザは、当該公開鍵証明書を発行した証明書発行認証局の公開鍵を有しているか取得する必要がある。
【００５３】
本実施形態のデータ交換システムにおいては、後述するように、このような公開鍵証明書を各エンティティに保持させる。
【００５４】
次に、属性証明書について詳しく説明する。属性証明書は、証明書発行認証局とは異なるローカルな機関である属性認証局（Ａｔｔｒｉｂｕｔｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ；ＡＡ）によって発行されるものである。
【００５５】
属性証明書は、図４及び図５に示すようなフォーマットから構成される。なお、同図においては、属性証明書を構成する各フィールド毎の項目と、これらの各項目に対する説明とを記載している。
【００５６】
図４に示すバージョン（ｖｅｒｓｉｏｎ）は、属性証明書のフォーマットのバージョン情報を記述するフィールドであり、例えばフォーマットがバージョン２（１）である場合にはバージョン２（１）を示す”１”が記述される。
【００５７】
ホルダー（ｈｏｌｄｅｒ）は、属性証明書が結び付けられた公開鍵証明書の所有者を特定するためのフィールドである。ホルダーには、ベース認証局識別子（ｂａｓｅ　Ｃｅｒｔｉｆｉｃａｔｅ　ＩＤ）として、属性証明書の所有者が有する公開鍵証明書の発行者名（ｉｓｓｕｅｒ）、属性証明書の所有者が有する公開鍵証明書のシリアルナンバ（ｓｅｒｉａｌ）、属性証明書の所有者が有する公開鍵証明書の発行者を識別するための固有の識別子（ｉｓｓｕｅｒ　ＵＩＤ）が記述される。また、ホルダーには、公開鍵証明書におけるサブジェクト（ｓｕｂｊｅｃｔ）又はサブジェクト別名（ｓｕｂｊｅｃｔ　Ａｌｔ　Ｎａｍｅ）と同一とされる属性証明書の所有者の名称（ｅｎｔｉｔｙ　ｎａｍｅ）が記述される。さらに、ホルダーには、将来、属性証明書が識別情報（ｉｄｅｎｔｉｔｙ）や公開鍵証明書にリンクされていない場合を想定して、例えば公開鍵のハッシュが記述されるオブジェクト・ダイジェスト情報（ｏｂｊｅｃｔ　Ｄｉｇｅｓｔ　Ｉｎｆｏ）が記述される。
【００５８】
発行者（ｉｓｓｕｅｒ）は、属性証明書に署名した発行者の情報を指定するフィールドである。
【００５９】
署名（ｓｉｇｎａｔｕｒｅ）は、属性証明書の署名を有効にするために使用するアルゴリズムを識別するための識別子を記述するフィールドである。
【００６０】
シリアルナンバ（ｓｅｒｉａｌ　ｎｕｍｂｅｒ）は、属性認証局が各属性証明書に割り振るシリアルナンバを記述するフィールドである。
【００６１】
属性証明書有効期限（ａｔｔｒ　Ｃｅｒｔ　Ｖａｌｉｄｉｔｙ　Ｐｅｒｉｏｄ）は、属性証明書の有効期限である開始日時（ｎｏｔ　Ｂｅｆｏｒｅ）及び終了日時（ｎｏｔ　Ａｆｔｅｒ）を記述するフィールドである。
【００６２】
図５に示す属性（ａｔｔｒｉｂｕｔｅｓ）は、属性証明書の所有者の特権に関する情報を記述するフィールドであり、例えば、文章でアクセスが許可された対象物を記述してもよく、システム側で用意しておいたアクセスすることができるコードを記述してもよく、ある平文を暗号化する鍵を記述してもよい。例えば、属性には、属性証明書の検証者が当該属性証明書の所有者を認証する場合に利用するサービスに関する認証情報（Ｓｅｒｖｉｃｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ）、属性証明書の検証者が用いる当該属性証明書の所有者のアクセス許可情報（Ａｃｃｅｓｓ　Ｉｄｅｎｔｉｔｙ）、課金のために属性証明書の所有者を特定するための情報（Ｃｈａｒｇｉｎｇ　Ｉｄｅｎｔｉｔｙ）、属性証明書の所有者のグループへの帰属関係を示す情報（Ｇｒｏｕｐ）、属性証明書の所有者に与えられる役割を示す情報（Ｒｏｌｅ）、属性証明書の所有者に対する秘密情報の使用許可に関する情報（Ｃｌｅａｒａｎｃｅ）が記述される。
【００６３】
発行者固有識別子（ｉｓｓｕｅｒ　Ｕｎｉｑｕｅ　ＩＤ）は、属性証明書の発行者の公開鍵証明書で指定されている場合に利用されるフィールドである。
【００６４】
拡張情報（ｅｘｔｅｎｓｉｏｎｓ）は、属性証明書の所有者の情報ではなく属性証明書の情報を記述するフィールドであり、サーバー及び／又はサービス管理者が属性証明書の所有者の監査を行い不正行為の検出、すなわち特定をするために用いる情報（Ａｕｄｉｔ　Ｉｄｅｎｔｉｔｙ）、属性証明書が対象とするサーバー及び／又はサービスを示す情報（ＡＣ　Ｔａｒｇｅｔｉｎｇ）、属性証明書の検証者による当該属性証明書の署名確認の補助情報である属性証明書の発行者の鍵情報（Ａｕｔｈｏｒｉｔｙ　Ｋｅｙ）、属性証明書の検証者による当該属性証明書の失効状態確認の補助情報であるＯＣＳＰレスポンダのＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒｓ）を示す情報（Ａｕｔｈｏｒｉｔｙ　Ｉｎｆｏｒｍａｔｉｏｎ　Ａｃｃｅｓｓ）、属性証明書の検証者による当該属性証明書の失効状態確認の補助情報であるＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｖｏｃａｔｉｏｎ　Ｌｉｓｔ）配布点のＵＲＩを示す情報（ＣＲＬ　Ｄｉｓｔｒｉｂｕｔｉｏｎ）、当該属性証明書に対応する失効情報がないことを示す情報（Ｎｏ　Ｒｅｖｏｃａｔｉｏｎ）、提出者が所有者以外である場合に利用され、属性証明書を提出することができるエンティティを示す情報（Ｐｒｏｘｙ　Ｉｎｆｏ）が記述される。
【００６５】
署名（ｓｉｇｎａｔｕｒｅ　Ｖａｌｕｅ）は、属性認証局によってつけられた署名を記述するフィールドである。
【００６６】
次に、図６を参照して、本実施の形態のデータ交換システムが適用される公開鍵基盤の機関及びエンティティの一例について説明する。本実施の形態のデータ交換システムはワークフロー型の業務形態に好適であり、例えば、後述するように或る会社内の稟議や決裁などのように書類を複数の者が確認するようなシステムに適用できる。
【００６７】
本実施の形態のデータ交換システムが適用される公開鍵基盤の機関及びエンティティの一例は、信頼できる機関として、該信頼機関自身の秘密鍵で署名した公開鍵証明書ＰＫＣを発行する認証局ＣＡが存在しており、これに対して社内の機関として人事システムにおける登録局（Ｒｅｇｉｓｔｒａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）ＲＡ及び人事属性局ＥＡＡ、更に決裁システムにおけるシステム属性局ＳＡＡを有していて、これら人事属性局ＥＡＡとシステム属性局ＳＡＡには認証局ＣＡで発行された公開鍵ＰＫＣが与えられている。
【００６８】
登録局ＲＡは、当該公開鍵基盤のシステムの範囲で、公開鍵証明書を発行する所持者の資格審査などを行い登録を行う機関である。登録局ＲＡは、必要に応じてディレクトリアクセス、鍵生成、ＩＣカード発行などを運用に応じて行うことも可能である。図６の例では、３人の社員Ｅ１、Ｅ２、Ｅ３がおり、それぞれが登録局ＲＡで登録を行うことで、公開鍵ＰＫＣが与えられている。ここで各社員Ｅ１、Ｅ２、Ｅ３に付与される公開鍵ＰＫＣは、それぞれの社員Ｅ１、Ｅ２、Ｅ３で例えば社員証のように独自のものとされる。ここでは社員の数を３としているが、これは例示であり、会社であれば全社員に個別の公開鍵を与えることができることは勿論である。
【００６９】
このような登録局ＲＡでの登録による公開鍵ＰＫＣの付与と平行して、人事属性局ＥＡＡからは属性証明書ＡＣが各社員Ｅ１、Ｅ２、Ｅ３に発行される。人事属性局ＥＡＡは属性証明書発行機関であり、属性証明書ＡＣには人事属性局ＥＡＡの署名が付与される。属性証明書ＡＣには、種々のアクセス制御に関する情報が含まれる。例えば、属性証明書ＡＣには、対象とする社員の所属情報、役職情報、規則情報、役割情報、資格情報、賞罰情報、等級情報などのアクセス制御の基になる情報が属性情報として含まれる。従って、公開鍵ＰＫＣで信頼性を確保しながら同時に属性証明書ＡＣを活用することで、次に例示するような決裁申請ワークフローにおけるアクセス制御を好適に管理できることになる。
【００７０】
図６においては、システム属性局ＳＡＡにも認証局ＣＡから与えられた公開鍵ＰＫＣが存在する。システム属性局ＳＡＡは、次に説明する決裁システムの一部の機関であり、これによって決裁システムには公開鍵基盤における信頼性が確保されていることになる。
【００７１】
次に、図７を参照して、本実施の形態におけるデータ交換システムとしての決裁申請ワークフローについて説明する。特にこの決裁申請ワークフローにおいては、確認者ＥＤ１〜ＤＥ３への送信などにおいてオフラインでの送信が可能であり、書類の送受が円滑に行えるなどの利点がある。決裁申請ワークフローは、例えば電子書類に因らない場合、申請者が書類を作成し、複数の確認者、例えば所属の上司などが確認し、最後に決裁の承認をする者が承認すれば良いように構成されており、本実施の形態では、それが電子書類であるＸＭＬ文書を用いて送受されるように構成される。
【００７２】
先ず、図７に示すように、決裁申請ワークフローの機関及びエンティティの構成について説明すると、申請者ＰＥと、３名の確認者ＥＤ１〜ＥＤ３、決裁承認者ＥＤＳの間で申請書が回覧され、決裁がなされるように構成される。また、サーバーなどからなる決裁システムＤＳが申請者ＰＥや決裁承認者ＥＤＳからアクセス可能とされる。申請者ＰＥは、決裁すべき事項を有する者であって、当該決裁システムにおける決裁対象となる書類を作成する者である。また、確認者ＥＤ１〜ＥＤ３は、例えば同じプロジェクトの管理者などの役職を有する者であって、決裁対象事項を確認する立場にある者である。決裁承認者ＥＤＳは、最終的に承認を行う立場の者であり、プロジェクトリーダーや責任者などの立場の者である。
【００７３】
ここで、本決裁申請ワークフローについて、図８を参照しながら、その手順に従って説明する。
【００７４】
先ず、手順Ｓ１１で申請者ＰＥが電子的な文書からなる申請書を作成する。申請書は例えばＸＭＬ文書からなるが、署名や属性証明書の付加の前の段階では他の電子的な文書であっても良い。申請書には、決裁対象事項が記載され、その申請者ＰＥが署名を行って属性証明書ＡＣを付加する。申請者ＰＥが署名を行う行為は、公開鍵基盤のシステム内で信頼性を付加する意味で行われ、属性証明書ＡＣの付加は当該申請書におけるアクセス情報の付加に該当する。申請者ＰＥによる電子的な文書からなる申請書の作成行為は、通常のパーソナルコンピューターなどの情報機器によって可能とされるが、他のＰＤＡや携帯電話機などの通信機器を用いることも可能である。
【００７５】
申請者ＰＥが署名を行う行為は、ＸＭＬ文書においては後述するように署名要素を付加してその中のＫｅｙＩｎｆｏタグ内に公開鍵情報を付加することになる。また、属性証明書ＡＣの付加は属性タグ（Ａｔｔｒｉｂｕｔｅタグ）内に申請者ＰＥの属性証明書ＡＣを付加することを意味する。また、申請内容について、コンテントタグ（Ｃｏｎｔｅｎｔタグ）内に記載することができるものである。申請者ＰＥの属性証明書ＡＣは、例えば、その申請者ＰＥの所属情報や役職情報などを含む。
【００７６】
次に、手順Ｓ１２で申請者ＰＥが決裁システムＤＳにアクセスし、そのＸＭＬ形式の申請書を決裁システムＤＳに送る。決裁システムＤＳは、まず手順Ｓ１３で、送られてきた申請書が信頼性のあるものか否かを署名に基づいてチェックを行う。そのチェックの結果、決裁システムＤＳが信頼性のあるものと判断される場合、申請書に対して属性証明書ＡＣを付加する。ここで付加される属性証明書ＡＣはアクセス権限に関する情報であり、例えば、図７の確認者ＥＤ１〜ＥＤ３と決裁承認者ＥＤＳがアクセス権限があるなどの情報を含む。この決裁システムＤＳで付加される属性証明書ＡＣは、先に添付された申請者ＰＥの属性証明書ＡＣから導かれるものとすることができ、或いは自動的に或いは申請者の操作によってアクセス権限者が選択されるものとしても良い。
【００７７】
ＸＭＬ形式の申請書に属性証明書ＡＣを付加した後、決裁システムＤＳは署名を行い信頼性を確保して申請者ＰＥに返信する。この返信により、申請者ＰＥは属性証明書ＡＣ付きの申請書を受信することになる（手順Ｓ１４）。
【００７８】
次に、決裁システムＤＳによってアクセス制御情報を属性証明書ＡＣの形式で付与された申請書を確認者ＥＤ１〜ＥＤ３に送信する。この時の送信形態としては、一斉に送る同報形式も可能であるが、例えば１人の確認者が次の確認者に送信する回覧形式も可能である。また、特に本実施の形態では、申請書がＸＭＬ形式であることから、専用サーバーなどを介さずにオフラインでの書類の転送なども可能であって、例えば電子メールに添付して送ることができる。そして、転送先では電子メールから添付書類を取り出したところでＸＭＬのアクセス属性による権限処理が可能となり、専用サーバーにアクセスすることなく、承認や確認などのアクセス権限を有する者の処理が可能となる。特に、通常のオフィスワークにおいて、専用サーバーにログオンする場合には、パスワードＩＤが必要とする場合においては、そのようなパスワードＩＤの入力によらずに、オフラインでの書類の転送ができることになり、事務効率が大幅に向上する。
【００７９】
手順Ｓ１６では、属性証明書ＡＣが付加された申請書を転送された確認者ＥＤ１〜ＥＤ３はその内容をチェックする。本実施形態では、申請書はＸＭＬ形式であることから、後述するようなコンテントタグ内に記載される事項は決裁クライアントプログラムによって適切に表示され、確認者ＥＤ１〜ＥＤ３はそれぞれ自己の属性証明書ＡＣを付加し、署名する。署名する際、申請書に付加されているアクセス権限情報を保有している属性証明書ＡＣにより確認者の権限チェックも行い、権限のない者は署名できない。
【００８０】
この署名を行った時点で、ある確認者は属性証明書付き申請書を他の確認者に送信する（手順Ｓ１７）。この他の確認者への送信も、申請書がＸＭＬ形式であることから、専用サーバーなどを介さずにオフラインで転送可能であり、例えば電子メールに添付して送ることができる。そして、転送先では電子メールから添付書類を取り出したところでＸＭＬのアクセス属性による権限処理が可能となり、専用サーバーにアクセスすることなく、承認や確認などのアクセス権限を有する者の処理が可能となる。特に、通常のオフィスワークにおいてはパスワードＩＤの入力によらずに、オフラインでの書類の転送ができることになり、事務効率が大幅に向上する。
【００８１】
確認者が複数の場合、全ての署名が済んだところで、申請者ＰＥは決裁承認者ＥＤＳに確認者の署名及び属性証明書ＡＣが結合したデータを送信する（手順Ｓ１８）。この結合したデータで全確認者の確認がとれている状態となり、次に手順Ｓ１９で決裁承認者ＥＤＳはその内容をチェックする。決裁承認者ＥＤＳが承認する場合、署名を行って属性証明書ＡＣを付加する。署名の際、認証者も確認者同様申請書に付加されているアクセス権限情報を保有している属性証明書ＡＣにより承認者の権限チェックも行い、権限のない者は署名できない。この作業によって、決裁承認者ＥＤＳが承認することになり、ＸＭＬ形式の申請書は承認済み申請書として決裁システムに送信される（手順Ｓ２０）。決裁システムは送られてきたＸＭＬ形式の申請書を受付け、決裁承認者ＥＤＳの承認を以って決裁システム上で決裁されたことになる（手順Ｓ２１）。
【００８２】
以上の流れのように、本決裁申請ワークフローにおいては、決裁システムＤＳへのアクセスは申請時と承認時の２回だけで良く、申請書がＸＭＬ形式であることから、専用サーバーなどを介さずにオフラインでの転送なども可能である。例えば申請書をＳ／ＭＩＭＥ等の電子メールに添付して或いはＸＭＬ形式の電子メールとして送ることができる。そして、転送先では電子メールから書類を取り出したところでＸＭＬのアクセス属性による権限処理が可能となり、専用サーバーにアクセスすることなく、承認や確認などのアクセス権限を有する者の処理が可能となる。特に、通常のオフィスワークにおいて、専用サーバーにログオンする場合には、パスワードＩＤが必要とする場合においては、そのようなパスワードＩＤの入力によらずに、オフラインでの書類の転送ができることになり、事務効率が大幅に向上する。また、サーバーによらないことから非同期に処理することも可能であり、使い勝手に優れることになる。
【００８３】
次に、図９乃至図１３を参照して、申請書に付加されるデータと共に前述のフローについて詳述する。
【００８４】
図９は申請者ＰＥから決裁システムＤＳに対して申請書を送り、返信されるまでの様子を示す模式図である。この図９は図８の手順Ｓ１１から手順Ｓ１４までのステップに該当する。図９に示すように、申請者ＰＥが送信するのは、ＸＭＬ形式の申請書１１である。申請書１１は署名対象である申請情報を含み、申請情報は決裁対象事項を含んでいる。申請者ＰＥはＸＭＬ署名を付加し、更にＸＭＬ属性を付加する。ＸＭＬ署名は申請者署名と申請者の公開鍵ＰＫＣを含んでおり、ＸＭＬ属性は申請者の属性証明書ＡＣを含む。ここで、申請者の属性証明書ＡＣは、その申請者ＰＥの所属情報や役職情報などであり、アクセス権限情報の１つである。申請者の属性証明書ＡＣは申請者の公開鍵情報への関連付けがなされており、申請者の属性証明書ＡＣ自体は公開鍵情報を有していない。
【００８５】
この申請書１１は決裁システムＤＳで受付されて処理される。その後に、申請者ＰＥに返信されるのは処理された申請書１２である。ＸＭＬ形式の申請書１２はシステムで付加された属性証明書ＡＣを含んでおり、先の申請書１１のデータが全て署名対象とされ、システムＤＳによってＸＭＬ署名が付加され、更にＸＭＬ属性が付加されている。ＸＭＬ署名はシステム署名とシステム公開鍵からなり、ＸＭＬ属性としてデータ属性証明書ＡＣが付与される。データ属性証明書ＡＣにはＸＭＬ署名の中のシステムの公開鍵情報への関連付けがなされており、システムの属性証明書ＡＣ自体は公開鍵情報を有していない。データ属性証明書ＡＣは、当該ワークフローにおけるアクセス制御情報が含まれており、どの所属やプロジェクト、役職などの者がアクセスできるかが参照されることになる。
【００８６】
次に、図１０、図１１、図１２はそれぞれ申請者ＰＥから確認者ＥＤ１、ＥＤ２に対して申請書を配信する場合の模式図であり、図１０の例が回覧の順序がある場合の例であり、図１１の例が回覧の順序がない場合の例であり、図１２の例が同報の場合の例である。
【００８７】
図１０の例では、先ず、申請者ＰＥからシステムによって属性証明書ＡＣが付与された申請書２１が第１の確認者ＥＤ１に送られ、この確認者ＥＤ１の処理によって、属性証明書ＡＣが付与された申請書２２には、申請書２１のコンテンツに加えて、該第１の確認者ＥＤ１の署名・公開鍵ＰＫＣが付与されると共に第１の確認者ＥＤ１の属性証明書ＡＣが付与される。属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、第１の確認者ＥＤ１の署名・公開鍵ＰＫＣに対してリンクが設けられる。この申請書２２における署名範囲は申請書２１のコンテンツである。
【００８８】
このような申請書２２が形成されたところで、申請書２２は第２の確認者ＥＤ２に送られる。第２の確認者ＥＤ２の処理では、第１の確認者ＥＤ１と同様に、第２の確認者ＥＤ２の署名・公開鍵ＰＫＣが付与されると共に第２の確認者ＥＤ２の属性証明書ＡＣが付与される。第２の確認者ＥＤ２の属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、第２の確認者ＥＤ２の署名・公開鍵ＰＫＣに対してリンクが設けられる。また、第２の確認者ＥＤ２の署名は、既に第１の確認者ＥＤ１が処理した申請書２２の全体に対して行われる。すなわち第２の確認者ＥＤ２の署名は第１の確認者ＥＤ１も署名対象としており、確認の順序を設定する場合に機能する。
【００８９】
このような第１の確認者ＥＤ１と第２の確認者ＥＤ２の結合がなされたところで、再び申請者ＰＥに返信される。
【００９０】
図１１の例は回覧の順序がない場合の例であり、先ず、申請者ＰＥからシステムによって属性証明書ＡＣが付与された申請書３１が第１の確認者ＥＤ１に送られ、この確認者ＥＤ１の処理によって、属性証明書ＡＣが付与された申請書３２には、申請書３１のコンテンツに加えて、該第１の確認者ＥＤ１の署名・公開鍵ＰＫＣが付与されると共に第１の確認者ＥＤ１の属性証明書ＡＣが付与される。属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、第１の確認者ＥＤ１の署名・公開鍵ＰＫＣに対してリンクが設けられる。この申請書３２における署名範囲は申請書３１のコンテンツである。
【００９１】
このような申請書３２が形成されたところで、申請書３２は第２の確認者ＥＤ２に送られる。第２の確認者ＥＤ２の処理では、第１の確認者ＥＤ１と同様に、第２の確認者ＥＤ２の署名・公開鍵ＰＫＣが付与されると共に第２の確認者ＥＤ２の属性証明書ＡＣが付与されて申請書３３が構成される。第２の確認者ＥＤ２の属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、第２の確認者ＥＤ２の署名・公開鍵ＰＫＣに対してリンクが設けられる。この図１１の例では、第２の確認者ＥＤ２の署名範囲は、申請書３１のコンテンツであって、第１の確認者ＥＤ１が付加した属性証明書ＡＣや署名などは含まれない。従って第１の確認者ＥＤ１と第２の確認者ＥＤ２の署名範囲は同じであるため、回覧の際の順位が形成されないことになり、回覧による確認も順序を気にせずに送信できることになる。
【００９２】
図１２の例は、同報による確認の例である。申請者ＰＥからシステムによって属性証明書ＡＣが付与された申請書４１が第１の確認者ＥＤ１に送られ、これと同報に属性証明書ＡＣが付与された申請書４１が第２の確認者ＥＤ２に送られる。
【００９３】
第１の確認者ＥＤ１の処理によって、属性証明書ＡＣが付与された申請書４２には、申請書４１のコンテンツに加えて、該第１の確認者ＥＤ１の署名・公開鍵ＰＫＣが付与されると共に第１の確認者ＥＤ１の属性証明書ＡＣが付与される。属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、第１の確認者ＥＤ１の署名・公開鍵ＰＫＣに対してリンクが設けられる。この申請書４２における署名範囲は申請書４１のコンテンツである。
【００９４】
また、第２の確認者ＥＤ２の処理によって、属性証明書ＡＣが付与された申請書４３には、申請書４１のコンテンツに加えて、該第２の確認者ＥＤ２の署名・公開鍵ＰＫＣが付与されると共に第２の確認者ＥＤ２の属性証明書ＡＣが付与される。属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、第２の確認者ＥＤ２の署名・公開鍵ＰＫＣに対してリンクが設けられる。この申請書４３における署名範囲は申請書４１のコンテンツである。
【００９５】
このような第１の確認者ＥＤ１と第２の確認者ＥＤ２からのそれぞれの申請書４２、４３が申請者ＰＥにそれぞれ返信され、申請者ＰＥは申請書４２と申請書４３を合体させて申請書４４を形成する。
【００９６】
図１３は申請者ＰＥから承認者ＤＡに申請書を送り、最終的な承認を得る手順の模式図である。申請者ＰＥは前述のような方法によって確認者から確認者の署名付きであって且つ属性証明書ＡＣが付与された申請書５１を作成する。この申請書５１は承認者ＤＡに送られ、この申請書５１の属性証明書ＡＣを参照して、承認者ＤＡがアクセス権限にある者か否かが判断される。なお、この承認者ＤＡは図７の決裁承認者ＥＤＳと同義である。この承認者ＤＡは、更に申請書５１のコンテンツに加えて、承認者ＤＡの署名・公開鍵ＰＫＣが付与されると共に承認者ＤＡの属性証明書ＡＣが付与される。属性証明書ＡＣの部分には公開鍵が含まれないが、公開鍵情報への関連付けがなされており、承認者ＤＡの署名・公開鍵ＰＫＣに対してリンクが設けられる。この申請書５２における署名範囲は申請書５１のコンテンツである。
【００９７】
ＸＭＬ形式の申請書５２はサーバシステムＤＳ１に送られ、そこで署名のチェックなどが行われて決裁の承認が行われる。
【００９８】
次に図１４を参照して、ＸＭＬ署名フォーマットについて説明する。ＸＭＬ署名フォーマットは、署名要素（Ｓｉｇｎａｔｕｒｅ要素）についてのフォーマットであって、基本的なエレメントとしてＳｉｇｎａｔｕｒｅＩｎｆｏ若しくはＳｉｇｎｅｄＩｎｆｏ要素として、ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ要素、ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ要素、Ｒｅｆｅｒｅｎｃｅ要素を有している。ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ要素は必要な場合に付加される正規化アルゴリズムを設定する領域であり、この正規化アルゴリズムによって表現形式はことなるが、意味的に同一なものとして扱えるように正規化するためのものである。ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ要素は署名アルゴリズムを設定する領域であり、Ｒｅｆｅｒｅｎｃｅ要素は署名対象への関連付けを行うための領域である。
【００９９】
Ｒｅｆｅｒｅｎｃｅ要素は、さらに３つの要素からなり、オプションのＴｒａｎｓｆｏｒｍｓ要素と、ＤｉｇｅｓｔＭｅｔｈｏｄ要素と、ＤｉｇｅｓｔＶａｌｕｅ要素からなる。Ｔｒａｎｓｆｏｒｍｓ要素は変換アルゴリズムを設定する領域であり、ＤｉｇｅｓｔＭｅｔｈｏｄ要素はハッシュアルゴリズムを設定する領域であり、ＤｉｇｅｓｔＶａｌｕｅ要素はハッシュ値を与える領域である。ＤｉｇｅｓｔＭｅｔｈｏｄ要素とＤｉｇｅｓｔＶａｌｕｅ要素は、署名検証処理に用いられ、署名対象に対してＤｉｇｅｓｔＭｅｔｈｏｄ要素のハッシュアルゴリズムからダイジェスト値を計算し、その計算されたダイジェスト値をＤｉｇｅｓｔＶａｌｕｅ要素のダイジェスト値（ハッシュ値）と比較することで検証が進められる。
【０１００】
署名要素（Ｓｉｇｎａｔｕｒｅ要素）については、上述のＳｉｇｎａｔｕｒｅＩｎｆｏ若しくはＳｉｇｎｅｄＩｎｆｏ要素に加えて、ＳｉｇｎａｔｕｒｅＶａｌｕｅ要素と、オプションのＫｅｙＩｎｆｏ要素、Ｏｂｊｅｃｔ要素がある。ＳｉｇｎａｔｕｒｅＶａｌｕｅ要素は署名値を与える領域であり、ＫｅｙＩｎｆｏ要素は署名鍵に対する情報のための領域であって、公開鍵情報も含まれることになる。
【０１０１】
図１５は本実施の形態で使用されるＸＭＬ属性フォーマットを示す図である。これは属性要素（ａｔｔｒｉｂｕｔｅ要素）についてのフォーマットであって、基本的なエレメントとして、ＡｔｔｒｉｂｕｔｅＴｒａｎｓｆｏｒｍ要素、ＡｔｔｒｉｂｕｔｅＣｅｒｔｉｆｉｃａｔｅ要素、ＡｔｔｒｉｂｕｔｅＲｅｆｅｒｅｎｃｅ要素、オプションとしてのＡｔｔｒｉｂｕｔｅＩｓｓｕｅｒ要素からなる。ＡｔｔｒｉｂｕｔｅＴｒａｎｓｆｏｒｍ要素は、変換アルゴリズムを設定するための領域であり、ＡｔｔｒｉｂｕｔｅＣｅｒｔｉｆｉｃａｔｅ要素は属性証明書ＡＣのための領域である。また、ＡｔｔｒｉｂｕｔｅＲｅｆｅｒｅｎｃｅ要素は、属性証明書に対する公開鍵を示すＣｅｒｔｉｆｉｃａｔｅＯｆＡｔｔｒｉｂｕｔｅ要素か属性証明書に対する公開鍵へのリンクを示すＲｅｆｅｒｅｎｃｅＯｆＡｔｔｒｉｂｕｔｅ要素のどちらかを選択するように構成される。また、オプションとしてのＡｔｔｒｉｂｕｔｅＩｓｓｕｅｒ要素は、ＩｓｓｕｅｒＣｅｒｔｉｆｉｃａｔｅ要素をオプションとして有し、属性証明書ＡＣの発行者に対する公開鍵が示される。
【０１０２】
図１６はＸＭＬ署名へのリンクを示す図であり、ＸＭＬのデータの記述の要部を抽出して記載したものである。Ａｔｔｒｉｂｕｔｅタグで示される範囲が属性要素の範囲であり、その中に前述の属性証明書に対する公開鍵を示すＡｔｔｒｉｂｕｔｅＲｅｆｅｒｅｎｃｅ要素がＡｔｔｒｉｂｕｔｅＲｅｆｅｒｅｎｃｅタグ形式で記載されている。この場合のＡｔｔｒｉｂｕｔｅＲｅｆｅｒｅｎｃｅ要素は、ＲｅｆｅｒｅｎｃｅＯｆＡｔｔｒｉｂｕｔｅ要素を選択したものとなっており、ここでは”＃ａｔｔｒｉｂｕｔｅ１”と識別子を付けられた署名ＩＤに対してリンクが張られている。
【０１０３】
識別子”＃ａｔｔｒｉｂｕｔｅ１”は署名要素の１つを識別してリンクするものとなっていて、そこからＸ５０９Ｄａｔａタグ内に記述される公開鍵情報ＰＫＣにリンクされることになる。このようなリンクによって属性証明書ＡＣから公開鍵情報への関連付けが行われる。
【０１０４】
図１７、図１８はＸＭＬ形式の申請書の決裁者までの属性証明書を付与した時点でのＸＭＬ構成例を示している。
【０１０５】
先ず、コンテントで始まるタグに申請内容が記述され、申請者の作成した文書、表、画像、その他の内容がここに記載される。コンテントタグが終了した次のところには、アトリビュートタグが記述されており、このアトリビュートタグ内に申請者の属性証明書ＡＣが記述される。この属性証明書ＡＣからは、前述の図１６に示した方法によって公開鍵情報へのリンクが張られていて、次のシグネチャ−タグにおけるキーインフォタグのさらにＸ５０９Ｄａｔａタグ内に存在するＸ５０９サーティフィケイトタグに申請者の公開鍵情報が置かれる。
【０１０６】
前述のように、アクセス制御はアクセス制御用の属性証明書ＡＣを用いており、ＩＤがＳｙｓｔｅｍとされるボディタグの終り部分にあるアトリビュートタグの中にアクセス制御用の属性証明書ＡＣが記述される。この決裁システムからの属性証明書ＡＣも同様に公開鍵情報へのリンクが張られていて、次のシグネチャ−タグにおけるキーインフォタグのさらにＸ５０９Ｄａｔａタグ内に存在するＸ５０９サーティフィケイトタグに申請者の公開鍵情報が置かれる。
【０１０７】
図１８によれば、２名の確認者の属性証明書ＡＣが同様にアトリビュートタグの中に記述され、そこからそれぞれ同様に公開鍵情報へのリンクが張られていて、次のシグネチャ−タグにおけるキーインフォタグのさらにＸ５０９Ｄａｔａタグ内に存在するＸ５０９サーティフィケイトタグに申請者の公開鍵情報が置かれる。
【０１０８】
また、最後に決裁承認者の属性証明書ＡＣについても同様の構造となっており、決裁承認者の属性証明書ＡＣが同様にアトリビュートタグの中に記述され、そこから同様に公開鍵情報へのリンクが張られていて、次のシグネチャ−タグにおけるキーインフォタグのさらにＸ５０９Ｄａｔａタグ内に存在するＸ５０９サーティフィケイトタグに申請者の公開鍵情報が置かれる。
【０１０９】
このようなＸＭＬフォーマットを利用することで、属性証明書ＡＣの添付やリンク付けを円滑且つ簡単に行うことができ、決裁や稟議などの複数の者が見る必要のある書類については、事務効率の高い処理が実現されることになる。
【０１１０】
なお、上述の実施の形態では、主に決裁システムについて説明したが、本発明のデータ交換システムは種々の電子的な書類を転送する状況に対して適用可能である。さらにまた、このデータ交換システムを実行するためのプログラムは、例えばいわゆるコンパクトディスク（Ｃｏｍｐａｃｔ　Ｄｉｓｃ）等の所定の記録媒体やインターネット等の伝送媒体によって提供することができる。
【０１１１】
【発明の効果】
本発明のデータ交換システムによれば、公開鍵を基盤とするデータ交換システムであって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換される。
【０１１２】
よって、本発明のデータ交換システムを用いることで専用サーバーなどを介さずにオフラインでの転送なども可能であり、電子データである例えば申請書をＳ／ＭＩＭＥ等の電子メールに添付して或いはＸＭＬ形式の電子メールとして送ることも可能である。そして、転送先では電子メールから書類を取り出したところでアクセス属性による権限処理が可能となり、専用サーバーにアクセスすることなく、承認や確認などのアクセス権限を有する者の処理が可能となる。特に、通常のオフィスワークにおいて、専用サーバーにログオンする場合には、パスワードＩＤが必要とする場合においては、そのようなパスワードＩＤの入力によらずに、オフラインでの書類の転送ができることになり、事務効率が大幅に向上する。また、サーバーによらないことから非同期に処理することも可能であり、使い勝手に優れることになる。
【０１１３】
特に、電子データのデータ交換フォーマットとしては例えばＸＭＬフォーマットを利用することができ、属性証明書ＡＣの添付やリンク付けを円滑且つ簡単に行うことができ、決裁や稟議などの複数の者が見る必要のある書類については、事務効率の高い処理が実現されることになる。
【０１１４】
また、本発明のデータ交換方法によれば、公開鍵を基盤とするデータ交換方法であって、属性認証局から発行されたアクセス権限情報を含む属性証明書を電子データのデータ交換フォーマット内の属性要素に付加させた後、前記アクセス権限情報に含まれるアクセス権限を有する者を対象として該電子データを発信し、前記アクセス権限を有する者には前記属性証明書の前記アクセス権限情報によって権限が与えられた上で前記電子データが交換される。
【０１１５】
よって、本発明のデータ交換方法を用いることで専用サーバーなどを介さずにオフラインでの転送なども可能であり、電子データである例えば申請書をＳ／ＭＩＭＥ等の電子メールに添付して或いはＸＭＬ形式の電子メールとして送ることも可能である。そして、転送先では電子メールから書類を取り出したところでアクセス属性による権限処理が可能となり、専用サーバーにアクセスすることなく、承認や確認などのアクセス権限を有する者の処理が可能となる。特に、通常のオフィスワークにおいて、専用サーバーにログオンする場合には、パスワードＩＤが必要とする場合においては、そのようなパスワードＩＤの入力によらずに、オフラインでの書類の転送ができることになり、事務効率が大幅に向上する。また、サーバーによらないことから非同期に処理することも可能であり、使い勝手に優れることになる。
【０１１６】
また、同様に、電子データのデータ交換フォーマットとしては例えばＸＭＬフォーマットを利用することができ、属性証明書ＡＣの添付やリンク付けを円滑且つ簡単に行うことができ、決裁や稟議などの複数の者が見る必要のある書類については、事務効率の高い処理が実現されることになる。
【図面の簡単な説明】
【図１】公開鍵証明書と属性証明書の概要を示す図である。
【図２】公開鍵証明書のフォーマットを説明する図である。
【図３】公開鍵証明書のフォーマットを説明する図であって、図１に示す項目に続く残りの項目を説明する図である。
【図４】属性証明書のフォーマットを説明する図である。
【図５】属性証明書のフォーマットを説明する図であって、図３に示す項目に続く残りの項目を説明する図である。
【図６】本発明の実施の形態のデータ交換システムが適用される公開鍵基盤の機関及びエンティティの一例を示す図である。
【図７】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローを示す模式図である。
【図８】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローの手順を示す流れ図ある。
【図９】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローにおける申請者から決裁システムに対して申請書を送り返信されるまでの様子を示す模式図である。
【図１０】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローにおける回覧の順序がある場合の申請者から確認者に対して申請書を配信する場合の模式図である。
【図１１】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローにおける回覧の順序がない場合の申請者から確認者に対して申請書を配信する場合の模式図である。
【図１２】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローにおける同報の場合の申請者から確認者に対して申請書を配信する場合の模式図である。
【図１３】本発明の実施の形態のデータ交換システムが適用される決裁申請ワークフローにおける申請者から承認者に申請書を送り最終的な承認を得る手順の模式図である。
【図１４】本発明の実施の形態のデータ交換システムで用いられるＸＭＬ署名フォーマットの一例を示す図である。
【図１５】本発明の実施の形態のデータ交換システムで用いられるＸＭＬ属性フォーマットの一例を示す図である。
【図１６】本発明の実施の形態のデータ交換システムで用いられるＸＭＬによる記述であって、ＸＭＬ署名からの公開鍵情報への関連付けを示す図である。
【図１７】本発明の実施の形態のデータ交換システムで用いられるＸＭＬ構造を示す図である。
【図１８】図１７の続き部分のＸＭＬ構造を示す図である。
【符号の説明】
ＣＡ　認証局
ＡＣ　属性証明書
ＰＫＣ　公開鍵
ＲＡ　登録局
ＰＥ　申請者
ＥＤ１〜ＥＤ３　確認者
ＤＳ　決裁システム
ＤＳ１　サーバーシステム
ＤＡ　承認者
Ｅ１〜Ｅ３　社員
【図１】
2004118455.tif 000003
【図２】
2004118455.tif 000004
【図３】
2004118455.tif 000005
【図４】
2004118455.tif 000006
【図５】
2004118455.tif 000007
【図６】
2004118455.tif 000008
【図７】
2004118455.tif 000009
【図８】
2004118455.tif 000010
【図９】
2004118455.tif 000011
【図１０】
2004118455.tif 000012
【図１１】
2004118455.tif 000013
【図１２】
2004118455.tif 000014
【図１３】
2004118455.tif 000015
【図１４】
2004118455.tif 000016
【図１５】
2004118455.tif 000017
【図１６】
2004118455.tif 000018
【図１７】
2004118455.tif 000019
【図１８】
2004118455.tif 000020