(57)【特許請求の範囲】
【請求項１】
リッチ・コンテンツ文書に対するデジタル署名を生成するためのコンピュータ実施方法であって、
クライアントによる、電子文書のインスタンス化を求める要求を受信するステップと、
ｗｅｂアプリケーション・サーバと前記クライアントの間の相互認証の正常完了に応答して、前記電子文書を前記クライアントに提供するステップと、
修正文書を形成するための、前記電子文書に関連する１組の変更を受信するステップと、
前記クライアントから、前記修正文書のためのデジタル署名を生成するよう求める要求を受信したことに応答して、前記ｗｅｂアプリケーション・サーバの私有鍵と前記クライアントに関連するエンドユーザの識別情報とを使用して、前記デジタル署名を生成するステップと、
前記デジタル署名を用いて、前記修正文書に署名を行うステップと、
を含み、
前記電子文書を前記クライアントに提供するステップが、
複数の保護リソース用の保存ハッシュ値を取得するステップと、
デジタル署名生成中に前記ｗｅｂアプリケーション・サーバの前記私有鍵を用いて暗号化されたすべての保存ハッシュ値を、前記ｗｅｂアプリケーション・サーバの公開鍵を用いて暗号解除するステップと、
前記複数の保護リソース用の暗号ハッシュ値を再計算するステップと、
前記暗号ハッシュ値を前記保存ハッシュ値と比較するステップと、
をさらに含む、コンピュータ実施方法。
【請求項２】
前記ｗｅｂアプリケーション・サーバが、ゼロ・フットプリント・サーバである、請求項１に記載のコンピュータ実施方法。
【請求項３】
前記修正文書用の前記デジタル署名を生成するよう求める前記要求を受信したことに応答して、前記デジタル署名を形成するために、メタデータとリファレンスとをデジタル署名プロパティに追加するステップであって、前記リファレンスは、前記デジタル署名プロパティに追加される前記メタデータを詳しく述べるものである、ステップ
をさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項４】
前記メタデータが、前記クライアントに関連する公開鍵証明書または公開識別情報を含む、請求項３に記載のコンピュータ実施方法。
【請求項５】
前記暗号ハッシュ値と前記保存ハッシュ値との比較から、前記暗号ハッシュ値と前記保存ハッシュ値とは等しいという結果が得られたことに応答して、コア妥当性検証成功を指示するステップと、
前記暗号ハッシュ値と前記保存ハッシュ値との比較から、前記暗号ハッシュ値と前記保存ハッシュ値とは等しくないという結果が得られたことに応答して、コア妥当性検証失敗を指示するステップと、
をさらに含む、請求項４に記載のコンピュータ実施方法。
【請求項６】
前記コア妥当性検証成功に応答して、前記デジタル署名内の前記ｗｅｂアプリケーション・サーバの公開鍵証明書を、無効性、満了、および取消の少なくとも１つに関してチェックするステップと、
前記ｗｅｂアプリケーション・サーバの前記公開鍵証明書が無効であること、満了していること、または取り消されていることに応答して、サーバ証明書妥当性検証失敗を指示するステップと、
前記ｗｅｂアプリケーション・サーバの前記公開鍵証明書が有効であり、満了しておらず、取り消されていないとの判定に応答して、サーバ証明書妥当性検証成功を指示するステップと、
をさらに含む、請求項５に記載のコンピュータ実施方法。
【請求項７】
前記サーバ証明書妥当性検証成功に応答して、署名者の公開鍵証明書を取得するステップであって、前記署名者は、前記クライアントに関連する前記エンドユーザである、ステップと、
前記署名者の前記公開鍵証明書を、無効性、満了、および取消の少なくとも１つに関してチェックするステップと、
前記署名者の前記公開鍵証明書が無効であること、満了していること、または取り消されていることに応答して、署名者識別情報妥当性検証失敗を指示するステップと、
前記署名者の前記公開鍵証明書が有効であり、満了しておらず、取り消されていないとの判定に応答して、署名者識別情報妥当性検証成功を指示するステップと、
をさらに含む、請求項６に記載のコンピュータ実施方法。
【請求項８】
前記サーバ証明書妥当性検証成功に応答して、署名者の公開識別情報を取得するステップであって、前記署名者は、前記クライアントに関連する前記エンドユーザである、ステップと、
前記署名者の前記公開識別情報を、無効性、満了、および取消の少なくとも１つに関してチェックするステップと、
前記署名者の前記公開識別情報が無効であること、満了していること、または取り消されていることに応答して、署名者識別情報妥当性検証失敗を指示するステップと、
前記署名者の前記公開識別情報が有効であり、満了しておらず、取り消されていないとの判定に応答して、署名者識別情報妥当性検証成功を指示するステップと、
をさらに含む、請求項６に記載のコンピュータ実施方法。
【請求項９】
署名者識別情報妥当性検証成功に応答して、デジタル署名メタデータによって含意される妥当性チェックを実行するステップと、
前記デジタル署名メタデータによって含意された前記妥当性チェックの少なくとも１つの失敗に応答して、メタデータ妥当性検証失敗を指示するステップと、
前記デジタル署名メタデータによって含意されたすべての妥当性チェックの成功に応答して、メタデータ妥当性検証成功を指示するステップと、
をさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項１０】
コア妥当性検証失敗、サーバ証明書妥当性検証失敗、署名者識別情報妥当性検証失敗、またはメタデータ妥当性検証失敗に応答して、署名妥当性検証失敗を前記エンドユーザに報告するステップと、
コア妥当性検証成功、サーバ証明書妥当性検証成功、署名者識別情報妥当性検証成功、およびメタデータ妥当性検証成功に応答して、署名妥当性検証成功を前記エンドユーザに報告するステップと、
をさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項１１】
請求項１〜１０の何れか１項に記載の方法の各ステップをコンピュータに実行させる、コンピュータ・プログラム。
【請求項１２】
バス・システムと、
前記バス・システムに結合された通信システムと、
前記バス・システムに結合されたメモリであって、コンピュータ使用可能プログラム・コードを含むメモリと、
前記バス・システムに結合された処理ユニットであって、クライアントによる、電子文書のインスタンス化を求める要求を受信し、ｗｅｂアプリケーション・サーバと前記クライアントの間の相互認証の正常完了に応答して、前記電子文書を前記クライアントに提供し、修正文書を形成するための、前記電子文書に関連する１組の変更を受信し、前記クライアントから、前記修正文書のためのデジタル署名を生成するよう求める要求を受信したことに応答して、前記ｗｅｂアプリケーション・サーバの私有鍵と前記クライアントに関連するエンドユーザの識別情報とを使用して、前記デジタル署名を生成し、前記デジタル署名を用いて、前記修正文書に署名を行うための前記コンピュータ使用可能プログラム・コードを実行する処理ユニットと、
を備え、
前記ユニットがさらに、前記電子文書を前記クライアントに提供するにあたり、複数の保護リソース用の保存ハッシュ値を取得し、デジタル署名生成中に前記ｗｅｂアプリケーション・サーバの前記私有鍵を用いて暗号化されたすべての保存ハッシュ値を、前記ｗｅｂアプリケーション・サーバの公開鍵を用いて暗号解除し、前記複数の保護リソース用の暗号ハッシュ値を再計算し、前記暗号ハッシュ値を前記保存ハッシュ値と比較するための前記コンピュータ使用可能プログラム・コードを実行する、
データ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理システムに関し、詳細には、デジタル署名に関する。より詳細には、本発明は、リッチｗｅｂアプリケーション・コンテンツ（rich web application content）に対する安全なデジタル署名を生成するための、コンピュータ実施方法、装置、およびコンピュータ使用可能プログラム・コードに関する。
【背景技術】
【０００２】
公開鍵暗号は、公開鍵と私有鍵のペアを使用する、暗号の一形態である。私有鍵は、秘密に保たれ、私有鍵の保有者にだけ知られている。私有鍵とペアをなす公開鍵は、私有鍵に数学的に関連づけられ、公に配布することができる。デジタル署名は、暗号の一タイプであり、私有鍵を使用して署名を作成する。その場合、公開鍵を有するどのユーザも、署名を検証することができる。
【０００３】
したがって、デジタル署名は、メッセージを改ざんから保護することと、個人の識別情報をメッセージ内容と関連づけることの両方のための、暗号で守られた手段である。メッセージは、限定することなく例を挙げると、電子メール・メッセージ、ビジネス取引や契約を表す電子フォームの拡張マークアップ言語（ＸＭＬ）、または他の任意の有限長のバイト列など、任意のタイプの情報または通信である。フォームは、特にデータ収集およびデータ転送を可能にする、汎用アプリケーションである。デジタル署名の署名者は、フォームによって表される取引または契約など、取引または契約を行うユーザである。
【０００４】
デジタル署名は一般に、メッセージ認証トークン（messageauthentication token）と、署名者認証トークン（signer authentication token）を含む。メッセージ用の認証トークンは、暗号で守られるべきである。同様に、署名者用の認証トークンは、暗号で守られた方式で、メッセージにバインドされるべきである。これらの方策は、デジタル署名を無効化することなくメッセージを改ざんすること、または署名を無効化することなく署名者の認証トークンを変更されたメッセージに関連づけることが、計算的に実現不可能であることを保証する必要がある。さらに、署名者の資格証明（credential）の満了または取消によって署名を無効化することが、実現可能であるべきである。
【０００５】
署名識別情報は、私有鍵と、公開鍵証明書（public key certificate）とからなる。デジタル署名の生成を助けるために、署名者の私有鍵材料（privatekey material）が使用されなければならず、署名者の身元を署名されたメッセージ・コンテンツと関連づける。署名者の私有鍵が関係する動作へのアクセスは、エンドユーザのコンピュータ上の信用されたアプリケーションにだけ許可される。これは、クライアントサイドｗｅｂブラウザ以外のクライアントサイド実行可能コードの配備を制限するｗｅｂアプリケーションにとって、問題をはらんだ要件である。加えて、完全なｗｅｂアプリケーションを構成するコンテンツの大部分は、サーバによって維持されるので、ユーザの豊かなｗｅｂアプリケーション体験を完全に表現するコンテンツにデジタル署名を施すことは困難である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
現行の一実践では、リッチ・コンテンツ文書（rich content document）への署名は、クライアントサイド・ソフトウェアを介して提供される。しかし、このソリューションは、リッチ・コンテンツ文書サーバによって提供されるリッチ・コンテンツ文書へのデジタル署名を可能にするために、クライアントサイド・ソフトウェアをインストールまたはアップデートするようユーザに要求する。
【０００７】
現行の別の実践では、リッチ・コンテンツ文書は、デジタル署名によるセキュリティ保護が行えない、ゼロ・フットプリントｗｅｂアプリケーション・サーバ（zero footprint web application server）製品によって提供される。ゼロ・フットプリントｗｅｂアプリケーション・サーバは、アプリケーションに関連するソフトウェアをクライアントにダウンロードまたはインストールすることなしに、ｗｅｂアプリケーションへのアクセスを提供するサーバである。しかし、このソリューションは、デジタル署名によるセキュリティ保護がユーザには利用できないので、文書の安全性および真正性を危険にさらす。
【課題を解決するための手段】
【０００８】
説明的な実施形態は、電子文書をインスタンス化するよう求めるクライアントからの要求を受信するための、コンピュータ実施方法、装置、およびコンピュータ・プログラム製品を提供する。ｗｅｂアプリケーション・サーバとクライアントの間の相互認証が正常に完了した後、ｗｅｂアプリケーション・サーバは、電子文書をクライアントに提供する。その後、ｗｅｂアプリケーション・サーバは、修正文書を形成するための、電子文書に関連する１組の変更を受信することがある。修正文書用に生成されたデジタル署名を求めるクライアントからの要求を受信した後、ｗｅｂアプリケーション・サーバは、ｗｅｂアプリケーション・サーバの私有鍵とクライアントに関連するエンドユーザの識別情報とを使用して、デジタル署名を生成する。その後、ｗｅｂアプリケーション・サーバは、そのデジタル署名を用いて、修正文書に署名を行う。
【０００９】
また別の実施形態では、文書が少なくとも１回デジタル署名を施された後、電子文書をインスタンス化するよう求めるクライアントからのさらなる要求に応答するためのプロセスは拡大される。文書に関連するどのデジタル署名も、ｗｅｂアプリケーション・サーバの公開鍵証明書に加えて、署名者の公開鍵証明書または公開識別情報（public identity）、および他の任意のメタデータにも基づいて、正当性が確認される。
【００１０】
本発明に特徴的と思われる新規な特徴が、添付の特許請求の範囲において説明される。しかし、本発明自体に加え、その好ましい使用態様、さらなる目的および利点は、説明的な実施形態についての以下の詳細な説明を、添付の図面と併読しながら参照することによって、最もよく理解されよう。
【発明を実施するための最良の形態】
【００１１】
ここで図面を、特に図１〜図２を参照すると、説明的な実施形態が実施され得る、データ処理環境の例示的な図が提供されている。図１〜図２は、例示的なものであるにすぎず、異なる実施形態が実施され得る環境に関する限定を主張または暗示することを意図したものではないことを理解されたい。表された環境に対して多くの修正を施すことができる。
【００１２】
図１は、説明的な実施形態が実施され得る、データ処理システムのネットワークの絵図を表している。ネットワーク・データ処理システム１００は、説明的な実施形態が実施され得る、コンピュータのネットワークである。ネットワーク・データ処理システム１００は、ネットワーク１０２を含み、ネットワーク１０２は、ネットワーク・データ処理システム１００内で共に接続される様々なデバイスおよびコンピュータの間の通信リンクを提供するために使用される媒体である。ネットワーク１０２は、有線通信リンク、無線通信リンク、または光ファイバ・ケーブルなどのコネクションを含むことができる。
【００１３】
表された例では、サーバ１０４およびサーバ１０６は、記憶ユニット１０８と共に、ネットワーク１０２に接続する。この例では、サーバ１０４は、ゼロ・フットプリントｗｅｂアプリケーション・サーバであり、サーバ１０６は、標準ｗｅｂアプリケーション・サーバである。ゼロ・フットプリントｗｅｂアプリケーション・サーバは、クライアント１１０、１１２、１１４にリッチ・コンテンツｗｅｂアプリケーション・ソフトウェアをインストールすることなしに、ネットワーク１０２を介してソフトウェア・アプリケーションをクライアント１１０、１１２、１１４に送付する、ソフトウェア・エンジンである。サーバ１０４は、署名バリデータ（signature validator）と、署名ジェネレータ（signature generator）を含む。サーバ１０４は、説明的な実施形態が実施され得る、サーバの一例である。別の例では、サーバ１０６も、署名バリデータと、署名ジェネレータを含むことができる。
【００１４】
加えて、クライアント１１０、１１２、１１４も、ネットワーク１０２に接続する。クライアント１１０、１１２、１１４は、例えば、パーソナル・コンピュータまたはネットワーク・コンピュータとすることができる。表された例では、サーバ１０６は、ブート・ファイル、オペレーティング・システム・イメージ、およびアプリケーションなどのデータを、クライアント１１０、１１２、１１４に提供する。クライアント１１０、１１２、１１４は、この例では、サーバ１０４または１０６に対するクライアントである。図１では、クライアント１１０は、サーバ１０４または１０６との相互認証プロセスを完了するための、ユーザ私有鍵を含む。相互認証とは、当事者双方が相手の身元を確信できる方法で、クライアントまたはユーザがサーバに対して自らの真正性を証明し、サーバがユーザに対して自らの真正性を証明することである。ネットワーク・データ処理システム１００は、図示されていない、さらなるサーバ、クライアント、および他のデバイスを含むことができる。
【００１５】
表された例では、ネットワーク・データ処理システム１００は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）というプロトコル・スイートを使用して互いに通信を行う、ネットワークおよびゲートウェイの世界規模の集まりを表す、ネットワーク１０２を含むインターネットである。インターネットの中核には、データおよびメッセージをルーティングする、非常に多数の商用、政府用、教育用、および他のコンピュータ・システムからなる主要ノードまたはホスト・コンピュータの間に、基幹となる高速データ通信線が存在する。もちろん、ネットワーク・データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）などの、多くの異なるタイプのネットワークとして実施されてもよい。図１は、一例として意図されており、異なる説明的な実施形態に対するアーキテクチャ面での限定として意図されてはいない。
【００１６】
ここで図２を参照すると、説明的な実施形態が実施され得る、データ処理システムのブロック図が示されている。データ処理システム２００は、図１のサーバ１０４またはクライアント１１０などの、コンピュータの一例であり、説明的な実施形態のために、プロセスを実施するコンピュータ使用可能プログラム・コードまたは命令が配置できる。この説明的な例では、データ処理システム２００は、通信構造２０２を含み、通信構造２０２は、プロセッサ・ユニット２０４、メモリ２０６、永続記憶２０８、通信ユニット２１０、入力／出力（Ｉ／Ｏ）ユニット２１２、およびディスプレイ２１４の間の通信を提供する。
【００１７】
プロセッサ・ユニット２０４は、メモリ２０６にロードできるソフトウェアの命令を実行するように働く。プロセッサ・ユニット２０４は、具体的な実施に応じて、１つまたは複数のプロセッサの組とすることができ、またはマルチプロセッサ・コアとすることができる。さらに、プロセッサ・ユニット２０４は、シングル・チップ上にメイン・プロセッサとセカンダリ・プロセッサが存在する、１つまたは複数の異種プロセッサ・システムを使用して実施することができる。別の説明的な例では、プロセッサ・ユニット２０４は、複数の同じタイプのプロセッサを含む、対称マルチプロセッサ・システムとすることができる。
【００１８】
メモリ２０６は、これらの例では、例えば、ランダム・アクセス・メモリ、または他の任意の適切な揮発性もしくは不揮発性記憶デバイスとすることができる。永続記憶２０８は、具体的な実施に応じて、様々な形態を取ることができる。例えば、永続記憶２０８は、１つまたは複数のコンポーネントまたはデバイスを含むことができる。例えば、永続記憶２０８は、ハード・ドライブ、フラッシュ・メモリ、リライタブル光ディスク、リライタブル磁気テープ、または上記の何らかの組合せとすることができる。永続記憶２０８によって使用される媒体は、着脱可能でもよい。例えば、着脱可能ハード・ドライブが、永続記憶２０８のために使用できる。
【００１９】
通信ユニット２１０は、これらの例では、他のデータ処理システムまたはデバイスとの通信を提供する。これらの例では、通信ユニット２１０は、ネットワーク・インタフェース・カードである。通信ユニット２１０は、物理的通信リンクおよび無線通信リンクの一方または両方を使用することによって通信を提供することができる。
【００２０】
入力／出力ユニット２１２は、データ処理システム２００に接続できる他のデバイスを用いたデータの入力および出力を可能にする。例えば、入力／出力ユニット２１２は、キーボードおよびマウスを介したユーザ入力用のコネクションを提供することができる。さらに、入力／出力ユニット２１２は、出力をプリンタに送ることができる。ディスプレイ２１４は、ユーザに情報を表示するための機構を提供する。
【００２１】
オペレーティング・システムおよびアプリケーションまたはプログラムのための命令は、永続記憶２０８に配置される。これらの命令は、プロセッサ・ユニット２０４によって実行するために、メモリ２０６にロードすることができる。異なる実施形態のプロセスは、メモリ２０６などのメモリに配置できるコンピュータ実施命令を使用して、プロセッサ・ユニット２０４によって実行することができる。これらの命令は、プログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ可読プログラム・コードと呼ばれ、プロセッサ・ユニット２０４内のプロセッサによって読み出し、実行することができる。異なる実施形態におけるプログラム・コードは、メモリ２０６または永続記憶２０８などの、異なる物理的または有形のコンピュータ可読媒体上に具象化することができる。
【００２２】
コンピュータ使用可能プログラム・コード２１６は、着脱可能であることを選択できるコンピュータ可読媒体２１８上に機能可能な形式で配置され、プロセッサ・ユニット２０４によって実行するために、データ処理システム２００にロードまたは転送することができる。コンピュータ使用可能プログラム・コード２１６およびコンピュータ可読媒体２１８は、これらの例では、コンピュータ・プログラム製品２２０を形成する。一例では、コンピュータ可読媒体２１８は、例えば、永続記憶２０８の部分であるハード・ドライブなどの記憶デバイスに転送するために、永続記憶２０８の部分であるドライブまたは他のデバイス内に挿入または配置される光ディスクまたは磁気ディスクといった有形な形態を取ることができる。有形な形態では、コンピュータ可読媒体２１８は、データ処理システム２００に接続される、ハード・ドライブ、サム・ドライブ、またはフラッシュ・メモリといった永続記憶の形態も取ることができる。有形な形態のコンピュータ可読媒体２１８は、コンピュータ記録可能記憶媒体とも呼ばれる。場合によっては、コンピュータ記録可能媒体２１８は、着脱可能とすることはできない。
【００２３】
代替として、コンピュータ使用可能プログラム・コード２１６は、通信ユニット２１０への通信リンクを介して、または入力／出力ユニット２１２へのコネクションを介して、あるいはその両方を介して、コンピュータ可読媒体２１８からデータ処理システム２００に転送することができる。通信リンクまたはコネクションあるいはその両方は、説明的な実施形態では、物理的または無線とすることができる。コンピュータ可読媒体は、プログラム・コードを含む通信リンクまたは無線伝送など、非有形媒体の形態も取ることができる。
【００２４】
データ処理システム２００に関して例示された異なるコンポーネントは、異なる実施形態が実施され得る方法に対するアーキテクチャ面での限定を提供することを意図していない。異なる説明的な実施形態は、データ処理システム２００に関して例示されたコンポーネントの追加または代替コンポーネントを含むデータ処理システムにおいて実施することができる。図２に示される他のコンポーネントは、示された説明的な例から変更されることができる。
【００２５】
一例として、データ処理システム２００内の記憶デバイスは、データを保存できる任意のハードウェア装置である。メモリ２０６、永続記憶２０８、およびコンピュータ可読媒体２１８は、有形な形態の記憶デバイスの例である。
【００２６】
別の例では、通信構造２０２を実施するために、バス・システムが使用でき、バス・システムは、システム・バスまたは入力／出力バスなどの１つまたは複数のバスからなることができる。もちろん、バス・システムは、バス・システムに接続された異なるコンポーネントまたはデバイスの間でデータ転送を提供する、任意の適切なタイプのアーキテクチャを使用して実施することができる。加えて、通信ユニットは、モデムまたはネットワーク・アダプタなど、データを送信および受信するために使用される、１つまたは複数のデバイスを含むことができる。さらに、メモリは、例えば、通信構造２０２内に存在し得るインタフェースおよびメモリ・コントローラ・ハブ内で見出されるような、メモリ２０６またはキャッシュとすることができる。
【００２７】
説明的な実施形態は、デジタル署名を無効化することなくメッセージを改ざんすることの実現不可能性という要件、デジタル署名を無効化することなく署名者の認証トークンを変更されたメッセージに関連づけることの実現不可能性という要件、および署名者の資格証明の満了または取消によって署名を無効化することの実現可能性を依然として保証するという要件を満たす、リッチｗｅｂアプリケーション・コンテンツに対する暗号で守られたデジタル署名を作成可能なシステムが必要とされていることを認識している。
【００２８】
したがって、説明的な実施形態は、電子文書をインスタンス化するようｗｅｂアプリケーション・サーバに求める要求を受信するための、コンピュータ実施方法、装置、およびコンピュータ・プログラム製品を提供する。ｗｅｂアプリケーション・サーバとクライアントの間の相互認証が正常に完了した後、ｗｅｂアプリケーション・サーバは、電子文書をクライアントに提供する。その後、ｗｅｂアプリケーション・サーバは、修正文書を形成するための、電子文書に対する１組の変更を受信する。修正文書用に生成されたデジタル署名を求めるクライアントからの要求を受信した後、ｗｅｂアプリケーション・サーバは、ｗｅｂアプリケーション・サーバの私有鍵とクライアントに関連するエンドユーザの識別情報とを使用して、デジタル署名を生成する。その後、ｗｅｂアプリケーション・サーバは、そのデジタル署名を用いて、修正文書に署名を行う。
【００２９】
図３は、説明的な実施形態に従ってデジタル署名が生成される際のデータ・フローを示すブロック図である。ネットワーク・データ処理システム３００は、図１および図２に表された、パーソナル・コンピュータ、ラップトップ、携帯情報端末、サーバ、または他の任意のコンピューティング・デバイスを含むが、これらに限定されない、任意のタイプのコンピューティング・デバイスを使用して実施することができる。
【００３０】
ｗｅｂアプリケーション・サーバ３０２は、ネットワークを介してクライアントにアプリケーションを提供するための、当技術分野で知られた任意のタイプのサーバとすることができる。例えば、ｗｅｂアプリケーション・サーバ３０２は、標準ｗｅｂアプリケーション・サーバまたはゼロ・フットプリントｗｅｂアプリケーション・サーバとすることができる。ゼロ・フットプリント・アプリケーション・サーバは、ｗｅｂブラウザだけを配備し、他のタイプのクライアントサイド実行可能コードを配備しない。
【００３１】
この例では、ｗｅｂアプリケーション・サーバ３０２は、文書／ＨＴＭＬトランスレータ（documentto HTML translator）３０４と、文書ランナ（document runner）３０６と、アクセス・コントローラ３０８と、署名ジェネレータ３１０と、署名バリデータ３１２と、文書テンプレートまたは一部完成文書のリポジトリ（repositoryof document templates or partially completed documents）３１４と、データ記憶デバイス３１６と、ランニング文書リポジトリ（runningdocument repository）３１８を含む。しかし、ｗｅｂアプリケーション・サーバ３０２は、説明的な実施形態の範囲から逸脱することなく、図３に示されていない付加的な機能およびコンポーネントも含むことができる。
【００３２】
文書／ＨＴＭＬトランスレータ３０４は、特定の時間にエンドユーザが対話しなければならない、リッチｗｅｂアプリケーション文書の部分に関するハイパーテキスト・マークアップ言語（ＨＴＭＬ）およびＪａｖａ（Ｒ）ｓｃｒｉｐｔ／ＡＪＡＸコンテンツを作成するソフトウェア・コンポーネントである。文書ランナ３０６は、ｗｅｂアプリケーション・サーバ３０２内で完了される、状態遷移およびサブタスクを生成し、監視する。一例では、文書ランナ３０６は、エンドユーザに代わって文書を実行し、またはバックエンド・ビジネス・プロセスを推進するために、文書から情報を抽出し、その情報に基づいて動作するように設計された、カスタム・サーブレットおよびポートレットの要求で文書を実行する。別の例では、文書ランナ３０６は、文書が最初にロードされた時に文書内に存在する署名の妥当性検証を行い、要求時に特定の署名の妥当性再検証を行う。
【００３３】
アクセス・コントローラ３０８は、サーバ私有鍵を始めとする、サーバとエンドユーザの間の相互認証に関するすべての情報を含む。署名ジェネレータ３１０および署名バリデータ３１２は、エンドユーザからの要求に応答して、署名を生成し、また署名の妥当性検証を行うために、アクセス・コントローラ３０８に保存された情報を使用する。文書テンプレートまたは一部完成文書のリポジトリ３１４は、システムによってインスタンス化され得る、空のリッチｗｅｂアプリケーション文書および一部完成文書の両方を含む。例えば、文書テンプレートまたは一部完成文書のリポジトリ３１４は、リッチｗｅｂアプリケーション文書、誘導インタビュー（guided interview）の一ステージ、またはウィザード・プロセスを含むことができる。本明細書で使用される文書テンプレートは、フォーム、一部完成文書、または１人もしくは複数人のユーザによって署名を施されているが、完成させるには１つもしくは複数の追加の署名を必要とする一部完成文書を含むが、これらに限定されない。文書テンプレートは、例えば、ビジネス取引または契約とすることができる。データ記憶デバイス３１６は、ランニング文書リポジトリ３１８を含む。この例では、ランニング文書リポジトリ３１８は、エンドユーザ用に作成されて、現在、完全な取引記録になる過程にある、文書テンプレートおよび一部完成文書のインスタンスを含む。
【００３４】
ｗｅｂブラウザ・クライアント３２０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）送信エンジン３２２と、非同期Ｊａｖａ（Ｒ）ＳｃｒｉｐｔおよびＸＭＬ（ＡＪＡＸ）ならびにＪａｖａ（Ｒ）Ｓｃｒｉｐｔエンジン３２４と、セキュア・ソケット・レイヤ（ＳＳＬ）モジュール３２６と、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）レンダラ３２８と、ユーザ私有鍵３３０と、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）文書３３２を含む。ｗｅｂブラウザ・クライアント３２０のコンポーネントは、この実施形態では、完全に機能するハイパーテキスト・マークアップ言語（ＨＴＭＬ）文書にとって必要とされる、典型的なコンポーネントの例である。ｗｅｂブラウザ・クライアント３２０は、セキュア・ソケット・レイヤ（ＳＳＬ）認証のためにユーザの私有鍵材料にアクセスできる、信用できるアプリケーションである。この実施形態では、ユーザ体験は、ｗｅｂアプリケーション・サーバ３０２によってクライアントサイドに動的に送付されるハイパーテキスト・マークアップ言語（ＨＴＭＬ）文書と結び付けられる、これらの事前に存在する信用できるコンポーネントによってもっぱら支配される。このシステムのためには、他のクライアントサイド・ソフトウェアは必要とされないので、このシステムで達成できるアプリケーション挙動の一例は、ゼロ・フットプリント・アプリケーションの挙動である。ゼロ・フットプリント・アプリケーションは、サーバ上にすべてが保存されて、クライアントサイド実行可能コードを配備しない、エンドユーザ・アプリケーションである。
【００３５】
したがって、この実施形態では、ｗｅｂブラウザ・クライアント３２０は、ｗｅｂアプリケーション・サーバ３０２に文書要求３３４を送信する。要求３３４は、文書テンプレートまたは一部完成文書のリポジトリ３１４からの文書テンプレートまたは一部完成文書のインスタンス化を求める要求である。ＨＴＴＰ送信エンジン３２２は、ｗｅｂアプリケーション・サーバ３０２に要求３３４を転送または伝達するために使用される要求／応答プロトコルである。
【００３６】
ｗｅｂブラウザ・クライアント３２０から、文書のインスタンス化を求める要求３３４を受信したことに応答して、ｗｅｂアプリケーション・サーバ３０２は、ｗｅｂブラウザ・クライアント３２０に相互認証要求３３６を送信し、相互認証を開始する。相互認証を正常に完了するには、正しいユーザ私有鍵材料が使用されなければならない。相互認証は、ＳＳＬ相互認証を介したシングル・サインオン（single sign-on）、ＨＴＴＰ基本認証（HTTP basic authentication）、または他の非公開鍵基盤（非ＰＫＩ）認証（non-publickey infrastructure authentication）方法を含むが、これらに限定されない、当技術分野で知られた方法のいずれかを使用して実施することができる。相互認証を正常に完了するため、正しい私有鍵が使用される。ｗｅｂブラウザ・クライアント３２０は、ｗｅｂアプリケーション・サーバ３０２に相互認証完了３３８を送信する。認証が成功した場合、ｗｅｂアプリケーション・サーバ３０２は、文書ランナ３０６を始めとするアプリケーション・コンテキストから利用可能な、ｗｅｂブラウザ・クライアント３２０に関連する公開鍵または他の公開識別情報を作成する。
【００３７】
ｗｅｂアプリケーション・サーバ３０２は、その後、要求された文書テンプレートまたは一部完成文書をインスタンス化し、その文書をｗｅｂブラウザ・クライアント３２０上で利用可能なランタイム・フォーマットに変換する。文書／ＨＴＭＬトランスレータ３０４が、文書を適切なランタイム・フォーマットに変換する。例えば、この実施形態では、サーバは、文書／ＨＴＭＬトランスレータ３０４を使用して、文書をＨＴＭＬおよびＪａｖａ（Ｒ）ｓｃｒｉｐｔ／ＡＪＡＸに変換し、文書送付３４０を介して図３のｗｅｂブラウザ・クライアント３２０に文書を送付する。
【００３８】
ＨＴＭＬレンダラ３２８は、ｗｅｂブラウザ・クライアント３２０においてユーザに表示するために、文書をレンダリングする。ＡＪＡＸならびにＪａｖａ（Ｒ）Ｓｃｒｉｐｔエンジン３２４は、ｗｅｂブラウザ・クライアント３２０においてユーザによって行われた文書への変更を反映させるために、ｗｅｂアプリケーション・サーバ３０２とデータを交換する。データ転送は、ネットワークを介してｗｅｂアプリケーション・サーバ３０２に転送されるメッセージを保護するためにセキュア・ソケット・レイヤ・プロトコルを使用する、ＳＳＬモジュール３２６によって安全に行うことができる。ｗｅｂブラウザ・クライアント３２０は、その後、文書用に生成されたデジタル署名を求める署名生成要求３４２を送信する。
【００３９】
ｗｅｂアプリケーション・サーバ３０２は、文書の記入または変更を行うため、また文書がマルチページ文書の場合にページ変更を行うためのエンドユーザ入力と、文書用に生成されたデジタル署名を求める署名生成要求３４２とを受信した後、エンドユーザ識別情報に基づいて、文書に署名を施す。ｗｅｂアプリケーション・サーバ３０２は、相互認証プロセス中に、エンドユーザ識別情報を取得する。次に、ｗｅｂアプリケーション・サーバ３０２は、ｗｅｂブラウザ・クライアント３２０に署名完了通知３４４を送信し、文書がデジタル署名を用いて署名されたことをエンドユーザに通知する。ｗｅｂアプリケーション・サーバ３０２は、その後、署名された文書をサブミットして処理にまわすための、文書サブミット要求３４６を受信する。そのような処理は、さらなる対話や、他のクライアントによる文書に対する１組の変更および１組の署名を可能にするために、文書テンプレートまたは一部完成文書のリポジトリ３１４に保存することを含むことができる。
【００４０】
図４は、説明的な実施形態による、エンドユーザ要求に応答してトランザクションを完了するためのプロセスを示すフローチャートである。図４のプロセスは、図３のｗｅｂアプリケーション・サーバ３０２などのｗｅｂアプリケーション・サーバによって実施される。
【００４１】
プロセスは、トランザクション・プロセスを開始または継続するために、文書テンプレートまたは文書のインスタンス化を求める要求を受信することによって開始する（ステップ４０２）。次に、サーバは、相互認証を開始し（ステップ４０４）、エンドユーザの相互認証の完了を受信する（ステップ４０６）。
【００４２】
サーバは、その後、要求された文書テンプレートまたは文書をインスタンス化し、その文書をクライアントサイドｗｅｂブラウザ・システム上で利用可能なランタイム・フォーマットに変換する（ステップ４０８）。サーバは、図３の文書／ＨＴＭＬトランスレータ３０４などのトランスレータを使用して、文書を変換する。
【００４３】
次に、サーバは、修正文書を形成するため、また文書がマルチページ文書の場合にはページを変更するための１組の変更をエンドユーザから受信する（ステップ４１０）。１組の変更は、本明細書では、変更なし、１つの変更、および２つ以上の変更を含むものとして定義される。修正文書は、本明細書では、変更がない文書、変更が１つある文書、および変更が２つ以上ある文書を含むものとして定義される。サーバは、その後、修正文書用に生成されたデジタル署名を求める要求を受信する（ステップ４１２）。サーバは、相互認証プロセス中に取得されたエンドユーザ識別情報に基づいて、修正文書に署名を施す（ステップ４１４）。署名生成中に確立されたデジタル署名と文書の間の関係は、エンベロープト署名（enveloped signature）（デジタル署名が文書内容に添付される、もしくは文書内容内に出現する）、エンベローピング署名（envelopingsignature）（文書内容が署名内に出現する）、または分離署名（separated signature）（署名が独立して保存され、ＵＲＩもしくは他の外部リソース・ポインタを使用して文書を参照する）を含むが、これらに限定されない、当技術分野で知られた方法のいずれかによることができる。次に、サーバは、修正文書が署名されたことをエンドユーザに知らせる通知をｗｅｂブラウザ・クライアントに送信する（ステップ４１６）。サーバは、その後、完成されて署名が施された文書を処理するよう求める要求を受信し（ステップ４１８）、プロセスは、その後で終了する。
【００４４】
図５は、説明的な実施形態による、署名を生成するためのプロセスを示すフローチャートである。図５のプロセスは、図３のｗｅｂアプリケーション・サーバ３０２などのｗｅｂアプリケーション・サーバによって実施される。
【００４５】
プロセスは、サーバが、デジタル署名を求める要求を受信した時に開始する（ステップ５０２）。サーバは、すべての必要とされるメタデータを署名プロパティに追加する（ステップ５０４）。例えば、メタデータは、タイムスタンプまたはレイアウト・データとすることができる。サーバは、エンドユーザ（署名者）の公開鍵証明書または公開識別情報あるいはその両方を署名プロパティに追加する（ステップ５０６）。例えば、サーバは、ＳＳＬ認証において、公開鍵証明書を追加することができる。他の例では、サーバは、非公開鍵基盤認証方法で、公開識別情報を追加することができる。次に、サーバは、リファレンスを署名プロパティに追加する（ステップ５０８）。リファレンスは、署名に追加される必要なメタデータを示し、将来の署名妥当性検証目的で有用である。サーバは、ｗｅｂアプリケーション・サーバの私有鍵を使用して、修正文書内容、関連リソース、および署名プロパティに対するデジタル署名を生成し（ステップ５１０）、プロセスは、その後で終了する。
【００４６】
図６は、説明的な実施形態による、署名の妥当性検証を行うためのプロセスを示すフローチャートである。図６のプロセスは、図３のｗｅｂアプリケーション・サーバ３０２などのｗｅｂアプリケーション・サーバによって実施される。
【００４７】
プロセスは、相互認証が成功した後、サーバが、送付する文書を準備する時に開始する（ステップ６０１）。サーバは、保護リソース用の保存ハッシュ値を取得し、必要に応じて、ｗｅｂアプリケーション・サーバの署名証明書からの公開鍵を用いて暗号解除する（ステップ６０２）。次に、サーバは、すべての保護リソース用の暗号ハッシュ値を再計算し、保存値と等しいかどうか比較する（ステップ６０４）。保存ハッシュ値と再計算ハッシュ値が等しい場合、コア妥当性検証成功が発生する。ハッシュ値が等しくない場合、コア妥当性検証は失敗する。
【００４８】
サーバは、すべての対応するハッシュ値のペアに関する等価性比較の成功に基づいて、コア妥当性検証が成功したかどうかを判定する（ステップ６０６）。コア妥当性検証が成功しなかった場合、サーバは、署名妥当性検証失敗を報告する（ステップ６０８）。コア妥当性検証が成功した場合、サーバは次に、サーバの公開鍵証明書を取得し（ステップ６１０）、別の妥当性検証チェックを実行して、証明書有効性、満了、および取消チェックが成功したかどうかを判定する（ステップ６１２）。それらのチェックが成功しなかった場合、サーバは、署名妥当性検証失敗を報告する（ステップ６０８）。
【００４９】
それらのチェックが成功した場合、サーバは次に、デジタル署名から署名者の公開鍵証明書を取得する（ステップ６１４）。署名者の識別情報が公開鍵証明書と共に提供される場合、サーバは、証明書有効性、満了、および取消チェックが成功したかどうかを判定する（ステップ６１６）。チェックが成功しなかった場合、サーバは、署名妥当性検証失敗を報告する（ステップ６０８）。チェックが成功した場合、サーバは、署名メタデータによって含意される他のすべての妥当性チェックを実行して、認証を判定する（ステップ６１８）。最終チェックが成功しなかった場合、サーバは、署名妥当性検証失敗を報告する（ステップ６０８）。最終チェックが成功した場合、文書のデジタル署名は有効であり（ステップ６２０）、プロセスは、その後で終了する。ゼロまたは１以上のデジタル署名の妥当性が検証されると、文書は、クライアントサイドで処理され得るフォーマットに変換され、その後、クライアント・エンドユーザに送付される。
【００５０】
異なる表された実施形態におけるフローチャートおよびブロック図は、装置、方法、およびコンピュータ・プログラム製品のいくつかの可能な実施の構成、機能、および動作を示している。この点で、フローチャートまたはブロック図の各ブロックは、１つまたは複数の指定された機能を実施するための１つまたは複数の実行可能命令を含むコンピュータ使用可能または可読プログラム・コードのモジュール、セグメント、または部分を表すことができる。いくつかの代替実施では、ブロック内で言及される１つまたは複数の機能は、図において言及された順序と異なる順序で発生してもよい。例えば、いくつかのケースでは、連続して示された２つのブロックは、含まれる機能に応じて、実質的に同時に実行されてよく、または時には逆の順序で実行されてよい。
【００５１】
したがって、異なる実施形態は、特に、相互認証が可能なｗｅｂブラウザ以外の特別なコンピュータ・コードをクライアント装置に配備またはインストールすることなしに、電子文書にデジタル署名を施し、そのデジタル署名の妥当性検証を行うための、コンピュータ実施方法、装置、およびコンピュータ・プログラム製品を提供する。
【００５２】
デジタル署名は、ｗｅｂアプリケーション・サーバの私有鍵を用いて生成されるが、署名メタデータは、相互認証中に取得されるエンドユーザ（署名者）の公開識別情報を少なくとも含む。一実施形態では、クライアント上でのエンドユーザの私有鍵が関係する相互認証が成功した後に初めて、公開識別情報がｗｅｂアプリケーション・サーバによって取得され得るように、エンドユーザの公開鍵証明書が、公開識別情報を提供する。
【００５３】
デジタル署名妥当性検証は、ｗｅｂアプリケーション・サーバの公開鍵証明書を用いたコア妥当性検証に加えて、署名者の公開識別情報の妥当性検証を少なくとも含む、署名メタデータに関する妥当性検証ステップも含む。
【００５４】
本発明は、すべてのハードウェア実施形態、すべてのソフトウェア実施形態、またはハードウェア要素およびソフトウェア要素の両方を含む実施形態の形態を取ることができる。好ましい一実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されない、ソフトウェアで実施される。
【００５５】
さらに、本発明は、コンピュータまたは任意の命令実行システムによって使用されるプログラム・コード、またはそれらに関連するプログラム・コードを提供する、コンピュータ使用可能またはコンピュータ可読媒体から入手可能な、コンピュータ・プログラム製品の形態を取ることができる。この説明の趣旨では、コンピュータ使用可能またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって使用されるプログラム、またはそれらに関連するプログラムを格納、保存、伝達、伝播、または転送することができる、任意の有形な装置とすることができる。
【００５６】
媒体は、電子、磁気、光、電磁気、赤外線、または半導体システム（または装置もしくはデバイス）とすることができ、あるいは伝播媒体とすることができる。コンピュータ可読媒体の例は、半導体または固体メモリ、磁気テープ、着脱可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、固定磁気ディスク、および光ディスクを含む。現在における光ディスクの例は、コンパクト・ディスク−リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。
【００５７】
プログラム・コードの保存または実行あるいはその両方に適したデータ処理システムは、システム・バスを介してメモリ要素に直接的または間接的に結合された、少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードを実際に実行している最中に利用されるローカル・メモリ、大容量ストレージ、および実行中に大容量ストレージからコードを取り出さなければならない回数を減らすために、少なくともいくらかのプログラム・コードの一時記憶を提供するキャッシュ・メモリを含むことができる。
【００５８】
（キーボード、ディスプレイ、ポインティング・デバイスなどを含むが、これらに限定されない）入力／出力すなわちＩ／Ｏデバイスは、直接的に、または仲介Ｉ／Ｏコントローラを介して、システムに結合することができる。
【００５９】
ネットワーク・アダプタも、システムに結合することができ、データ処理システムを、介在する私的または公的ネットワークを介して、他のデータ処理システムまたはリモート・プリンタもしくは記憶デバイスに結合することを可能にする。モデム、ケーブル・モデム、およびイーサネット（Ｒ）・カードは、現在利用可能なタイプのネットワーク・アダプタの中のほんのいくつかである。
【００６０】
本発明の説明が、例示および説明を目的として提供されたが、網羅的であること、または開示された形態に本発明を限定することは意図していない。多くの修正および変形が、当業者には明らかであろう。本発明の原理、実践的応用を最もよく説明するように、また他の当業者が本発明を理解して、企図される具体的な使用に適した様々な修正が施された様々な実施形態を可能にするように、実施形態は選択され、説明された。
【図面の簡単な説明】
【００６１】
【図１】説明的な実施形態が実施され得る、データ処理システムのネットワークの絵図である。
【図２】説明的な実施形態が実施され得る、データ処理システムのブロック図である。
【図３】説明的な実施形態に従ってデジタル署名が生成される際のデータ・フローを示すブロック図である。
【図４】説明的な実施形態による、リッチ・コンテンツ文書に対するデジタル署名を作成するためのプロセスを示すフローチャートである。
【図５】説明的な実施形態による、ｗｅｂアプリケーション・サーバによってデジタル署名を生成するためのプロセスを示すフローチャートである。
【図６】説明的な実施形態による、デジタル署名の妥当性検証を行うためのプロセスを示すフローチャートである。
【符号の説明】
【００６２】
１００  ネットワーク・データ処理システム
１０２  ネットワーク
１０４  サーバ
１０６  サーバ
１０８  記憶ユニット
１１０  クライアント
１１２  クライアント
１１４  クライアント
２００  データ処理システム
２０２  通信構造
２０４  プロセッサ・ユニット
２０６  メモリ
２０８  永続記憶
２１０  通信ユニット
２１２  入力／出力ユニット
２１４  ディスプレイ
２１６  コンピュータ使用可能プログラム・コード
２１８  コンピュータ可読媒体
２２０  コンピュータ・プログラム製品
３００  ネットワーク・データ処理システム
３０２  ｗｅｂアプリケーション・サーバ
３０４  文書／ＨＴＭＬトランスレータ
３０６  文書ランナ
３０８  アクセス・コントローラ
３１０  署名ジェネレータ
３１２  署名バリデータ
３１４  文書テンプレートまたは一部完成文書のリポジトリ
３１６  データ記憶デバイス
３１８  ランニング文書リポジトリ
３２０  ｗｅｂブラウザ・クライアント
３２２  ハイパーテキスト転送プロトコル（ＨＴＴＰ）送信エンジン
３２４  非同期Ｊａｖａ（Ｒ）ＳｃｒｉｐｔおよびＸＭＬ（ＡＪＡＸ）ならびにＪａｖａ（Ｒ）Ｓｃｒｉｐｔエンジン
３２６  セキュア・ソケット・レイヤ（ＳＳＬ）モジュール
３２８  ハイパーテキスト・マークアップ言語（ＨＴＭＬ）レンダラ
３３０  ユーザ私有鍵
３３２  ハイパーテキスト・マークアップ言語（ＨＴＭＬ）文書
３３４  文書要求
３３６  相互認証要求
３３８  相互認証完了
３４０  文書送付
３４２  署名生成要求
３４４  署名完了通知
３４６  文書サブミット要求
【図１】
0005284758.tif 000002
【図２】
0005284758.tif 000003
【図３】
0005284758.tif 000004
【図４】
0005284758.tif 000005
【図５】
0005284758.tif 000006
【図６】
0005284758.tif 000007