(57)【要約】【課題】  条件付き電子署名の生成、使用のための方法、装置、およびコンピュータ・プログラムを提供すること。【解決手段】  オンライン通信またはトランザクションの当事者が条件と署名済みデータ項目を明確にリンクするのを可能にし、データ項目および条件の真正性の検証と署名する当事者の同一性の検証を可能にする、条件付き電子署名の生成、使用のための方法、装置、およびコンピュータ・プログラムが提供される。データ項目および条件が別々にハッシュされ、結果として生じるダイジェスト（ハッシュ値）が連結され、最終ダイジェストを生成するためにその連結物がさらにハッシュされる。条件付きデジタル署名を生成するために、公開／秘密鍵暗号化方式の秘密鍵を使用して最終ダイジェストが暗号化される。データ項目および条件をそれぞれ検証することができる。検証は、条件付き署名の復号、および復号の結果と別に生成された最終ダイジェストとの比較を含む。２回目のレビューで１回目のレビューが取り消された場合、情報を関係者に伝播するためのソリューションも開示される。
2006511996.tif 000002
【特許請求の範囲】
【請求項１】
データ項目の電子署名に条件が指定されたことに応答して実行される、条件付き電子署名を生成するための方法であって、
前記データ項目を暗号化するステップと、
前記データ項目とは別に前記条件を暗号化するステップと、
暗号化された前記データ項目と暗号化された前記条件とを組み合わせるステップと、
前記データ項目および前記条件を表現するデジタル署名ブロックであって、前記データ項目および前記条件の両方の暗号検証を可能にするデジタル署名ブロックを生成するために、前記組合せを暗号化するステップと、
を含む方法。
【請求項２】
複数の指定された条件を別々に暗号化し、暗号化された前記複数の指定された条件を暗号化された前記データ項目と組み合わせ、その後さらに前記組合せを暗号化する、請求項１に記載の方法。
【請求項３】
前記データ項目の暗号化および前記条件の暗号化は、それぞれ前記データ項目および前記条件の検証可能な表現を生成するための単方向のハッシュ・ステップである、請求項１に記載の方法。
【請求項４】
ハッシュ済み前記データ項目およびハッシュ済み前記条件を組み合せるステップは、ハッシュ済み前記データ項目およびハッシュ済み前記条件を連結するステップと、最終ダイジェストを生成するために前記連結物をハッシュするステップと、デジタル署名ブロックを生成するために前記最終ダイジェストをさらに暗号化するステップとを含む、請求項３に記載の方法。
【請求項５】
前記組合せを暗号化するステップは、
（ａ）暗号化された前記データ項目と暗号化された前記条件とを組み合わせ、前記組合せを暗号化した結果が、
（ｂ）暗号化された前記データ項目と暗号化された前記条件の両方を暗号化した後、二重に暗号化された前記データ項目と前記条件とを組み合わせた結果とは異なる、
暗号化方法を使用する、請求項１または２に記載の方法。
【請求項６】
前記暗号化方法は、暗号化ブロック・チェーン暗号化を実施する、請求項５に記載の方法。
【請求項７】
前記データ項目の暗号化と前記条件の暗号化は、それぞれ暗号化ブロック・チェーン暗号化方法を使用する、請求項１または２に記載の方法。
【請求項８】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップは、条件付き署名を生成するために公開／秘密鍵暗号化技法を使用する、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップは、条件付き署名を生成するために対称鍵暗号化技法の対称鍵を使用する、請求項１乃至７のいずれか一項に記載の方法。
【請求項１０】
前記暗号化するステップを実行するために使用される前記暗号化プロセスへのアクセスを有し、対応する復号鍵へのアクセスを有する受信装置が、
前記デジタル署名ブロックを復号して第１の結果を生成するステップと、
前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせて、第２の結果を生成するステップと、
前記第１の結果と第２の結果とを比較して、両者が一致するかどうかを判定するステップと、
を実行可能にするように、前記データ項目、前記条件、および前記デジタル署名ブロックを受信装置に伝送するステップを含む、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
暗号化アルゴリズムを前記受信装置に伝送するステップを含む、請求項１０に記載の方法。
【請求項１２】
暗号化された前記データ項目と、
暗号化された前記条件と
を含む、前記暗号化するステップそれぞれの中間結果を前記受信装置に伝送するステップを含む、請求項１０または１１に記載の方法。
【請求項１３】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップにおいて、公開／秘密鍵暗号化技法の秘密鍵が使用され、前記方法は、前記公開／秘密鍵暗号化技法の公開鍵を前記受信装置に伝送するステップを含む、請求項１０乃至１２のいずれか一項に記載の方法。
【請求項１４】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップにおいて、公開／秘密鍵暗号化技法の秘密鍵が使用され、前記方法は、前記公開／秘密鍵暗号化技法の公開鍵を取得するための情報を前記受信装置に伝送するステップを含む、請求項１０乃至１２のいずれか一項に記載の方法。
【請求項１５】
それぞれの前記暗号化するステップの結果を含む暗号化結果の集合をコンパイルするステップを含み、前記伝送するステップは、前記暗号化結果の集合を前記受信装置に送信するステップを含む、請求項１０から１４のいずれか一項に記載の方法。
【請求項１６】
前記組合せを暗号化するステップを実行するために使用される前記暗号化プロセスへのアクセスを有し、対応する復号鍵へのアクセスを有する受信装置が、
前記デジタル署名ブロックを復号するステップと、
前記データ項目および前記条件のハッシュ済み表現を組み合わせて、組合せダイジェストを生成するステップと、
前記復号された署名ブロックと前記組合せダイジェストを比較して、両者が一致するかどうかを判定するステップと、
を実行可能とするように、前記データ項目および条件、ならびに前記デジタル署名ブロックのハッシュ済み表現を受信装置に伝送するステップを含む、請求項３に記載の方法。
【請求項１７】
前記ハッシュ済み表現を組み合わせて、組合せダイジェストを生成するステップは、
前記ハッシュ済み表現を連結してダブル・ダイジェストを生成するステップと、
前記ダブル・ダイジェストをハッシュして最終の組合せダイジェストを生成するステップと、
を有する、請求項１６に記載の方法。
【請求項１８】
複数のデータ項目のそれぞれを別々に暗号化して組み合わせ、前記組合せをその後さらに暗号化する、請求項１に記載の方法。
【請求項１９】
請求項１０に記載の方法によって生成された条件付き電子署名を検証するための方法であって、
伝送された前記データ項目、前記条件、および前記デジタル署名ブロックを前記受信装置が受信したことに応答して実行される、
前記デジタル署名ブロックを復号して第１の結果を生成するステップと、
前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせて、第２の結果を生成するステップと、
前記第１の結果と第２の結果とを比較して、両者が一致するかどうかを判定するステップと、
を含む方法。
【請求項２０】
請求項１に記載の方法を実行するために、プログラム・コードが実行されるデータ処理装置のオペレーションを制御するためのプログラム・コード命令を有するコンピュータ・プログラム。
【請求項２１】
請求項１９に記載の方法を実行するために、プログラム・コードが実行されるデータ処理装置のオペレーションを制御するためのプログラム・コード命令を有するコンピュータ・プログラム。
【請求項２２】
条件付き電子署名を生成するためのデータ処理装置であって、
データ項目の電子署名に条件が指定されたことに応答して、前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせ、前記データ項目および前記条件を表現するデジタル署名ブロックであって、前記データ項目および前記条件の両方の暗号検証を可能にするデジタル署名ブロックを生成するために前記組合せを暗号化するための、１以上の暗号化構成コンポーネントと、
前記データ項目、前記条件、および前記デジタル署名ブロックを、受信装置に伝送するための手段と、
を備える装置。
【請求項２３】
請求項１０に記載の方法によって生成された条件付き電子署名を検証するためのデータ処理装置であって、
伝送された前記データ項目、前記条件、および前記デジタル署名ブロックを受信するための手段と、
前記デジタル署名ブロックを復号して第１の結果を生成し、前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせて、第２の結果を生成し、前記第１の結果と第２の結果とを比較して両者が一致するかどうかを判定するための、１以上の暗号化コンポーネントと、
を備えるデータ処理装置。
【請求項２４】
条件付きで署名されたデータ項目のうちの１つの受信装置への転送または拒否が識別されたことに応答して、前記データ項目の受信装置リストを管理するレジストリを更新するための実行可能コンテンツを含む条件付きで署名されたデータ項目に関するステータス情報を送信するための方法であって、
前記条件付きで署名されたデータ項目の新しい受信装置への転送に応答して、前記レジストリ内の前記受信装置リストを更新するために前記実行可能コンテンツを実行するステップと、
前記条件付きで署名されたデータ項目に対する拒否の指示に応答して、前記レジストリを更新するために前記実行可能コンテンツを実行し、前記データ項目に対する拒否の指示を前記レジストリ・リスト内の前記受信装置に送信するステップと、
を含む方法。
【請求項２５】
条件付きで署名されたデータ項目に関するステータス情報を送信するためのデータ処理装置であって、
条件付きで署名されたデータ項目の受信装置リストを管理するためのレジストリと、
条件付きで署名されたデータ項目内における実行可能コンポーネントの存在を認識し、前記データ項目の新しい受信装置への転送に応答して、前記レジストリ内の受信装置リストを更新するために前記実行可能コンポーネントの実行を開始するための手段と、
前記データ項目の拒否の指示に応答して、前記拒否を示すように前記レジストリを更新するため、および前記データ項目の拒否の指示を前記リスト内の受信装置に送信するための手段と、
を備えるデータ処理装置。
【請求項２６】
請求項２４に記載の方法を実行するために、プログラム・コードが実行されるデータ処理装置のオペレーションを制御するためのプログラム・コード命令を有するコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子署名の生成、使用、およびメッセージ、文書その他のリソースのステータス変更のレポートのための方法、装置、およびコンピュータ・プログラムに関する。
【背景技術】
【０００２】
通常の電子的でない商取引においては、”subjectto contract”（契約の締結を条件とする）、”deliveryrequired within seven days”（７日以内の配送を要する）、”paidunder protest”（支払に異議を留保する）、”withoutprejudice”（権利放棄しない）といった条件を自分の署名の上に手書きで付加することが非常に一般的に行われている。このような注記には法的効力の疑わしいものもあるが、注記を付加した者にとっては法的効力の有無は重要ではなく、そのような条件の付加を希望すること自体が重要なのである。他の場合として、ビジネス交渉にとって条件の付加が不可欠な場合がある。
【０００３】
電子商取引では、通常、このような方法で条件を指定する機会は存在しないため、条件を付加することなくで電子的に署名するか、または署名しないかを決定しなければならない。ベンダーは、潜在的な購買者がオンラインで解決できないと思ったわずかな法律上の問題が原因でオンラインでの売上げを失ったり、署名した顧客が将来の購入をやめてしまう可能性がある。そして、不満を抱いた顧客は、戻ってこない。
【０００４】
このような例は企業と消費者の間のアプリケーションでは典型的なものであるが、企業同士の間のアプリケーションでも同様の要求が存在する。報道によれば、ある多忙な商品仕入れマネージャが自動販売機の貨物引渡通知書に署名の記載を求められた。しかし、彼は、自動販売機を数年間リースするという内容の個人としての契約に署名しているという自覚をしていなかった。そして、彼の会社が自動販売機供給業者の変更を決定したとき、供給業者はマネージャに対し、彼が署名した契約の履行を請求したのである。このような場合、裁判所がその契約を有効と判断するか、あるいは無効で強制できないものと判断するかにかかわらず、マネージャにとっては、引渡を確認するためにのみ署名しているという条件（自分の会社の法律顧問によって起案されることが好ましい）が付加できれば良かったのである。しかし、このようなことは、典型的な電子商取引のソリューションでは実現することはできない。
【０００５】
デジタル署名は、署名者の契約の承諾の確認、および文書またはメッセージの認証のために、手書き署名と同じ目的で使用することができる。一般に、デジタル署名は署名者の同一性を確認できるものでなければならない。メッセージ用の単純な形式のデジタル署名は、（メッセージ・ダイジェスト・アルゴリズム：ＭＤ５またはセキュア・ハッシング・アルゴリズム：ＳＨＡ／１を使用する）暗号化「ハッシュ」または「ダイジェスト」機能をメッセージに適用し、長いメッセージを表す短いダイジェストを生成するものである。ダイジェストまたはハッシュ値は、ほぼすべての長さが可能な入力にハッシュ機能を適用することによって生成される、固定サイズの文字列である。その後、署名者の秘密署名鍵を使用してダイジェストを暗号化し、（たとえばデジタル署名アルゴリズム、すなわちＤＳＡを使用して）メッセージ用の署名ブロックを生成する。メッセージ、署名ブロック、ハッシュおよび暗号化に使用されたアルゴリズム、ならびに署名者の公開鍵を取得する方法は受信装置に送信され、受信装置は、メッセージのハッシュ、署名ブロックの復号、および結果として生成するショート・ダイジェストの比較によって、署名ブロックの妥当性を確認することができる。公開鍵は、たとえば信頼できる第三者が発行するデジタル証明書から取得することができる。
【０００６】
二重秘密／公開鍵暗号化システムは、たとえば米国特許第５１５７７２６号で開示されている。米国特許第５１５７７２６号は、デジタル署名を認証するためのシステムを開示している。秘密鍵を使用して文書に署名し、その後公開鍵を使用して真正性をチェックする。デジタル署名を作成するためのプロセスは、米国特許第４８８１２６４号、第４３０９５６９号、第４６２５０７６号、および第４６５６４７４号、ならびに国際規格ＩＳＯ９７９６およびＣＣＩＴＴ  Ｘ５０９に開示されている。
【０００７】
日本の白浜町で２００２年１月２９日から２月１日にかけて開催された「暗号と情報セキュリティ・シンポジウム（ＳＣＩＳ）２００２」において、ビョンチョン・リーおよびクァンジョ・キムは、「Ｆａｉｒ  Ｅｘｃｈａｎｇｅ  ｏｆ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅｓ  Ｕｓｉｎｇ  Ｃｏｎｄｉｔｉｏｎａｌ  Ｓｉｇｎａｔｕｒｅ」として、「条件付き署名」に言及している。「条件付き署名」は、署名者が選択した条件を二当事者間の通信における秘密の交渉文として使用できるようにされている。具体的には、「条件付き署名」は、条件付き署名の検証に応答した条件なし署名の「公正な交換」の達成に焦点をあてたものである。リーらの「条件付き署名」とはメッセージと条件とをまとめた上での署名であり、具体的に言えば、従来の署名方式を使用してメッセージと条件の機能との組合せに署名するものである。
【特許文献１】米国特許第５１５７７２６号
【特許文献２】米国特許第４８８１２６４号
【特許文献３】米国特許第４３０９５６９号
【特許文献４】米国特許第４６２５０７６号
【特許文献５】米国特許第４６５６４７４号
【非特許文献１】国際規格ＩＳＯ９７９６
【非特許文献２】ＣＣＩＴＴ  Ｘ５０９
【非特許文献３】日本の白浜で２００２年１月２９日〜２月１日に開かれた暗号と情報セキュリティ・シンポジウム（ＳＣＩＳ）２００２でのビョンチョン・リーおよびクァンジョ・キムによる「Ｆａｉｒ  Ｅｘｃｈａｎｇｅ  ｏｆ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅｓ  Ｕｓｉｎｇ  Ｃｏｎｄｉｔｉｏｎａｌ  Ｓｉｇｎａｔｕｒｅ」
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、この技術分野では、柔軟性が明らかに向上した電子的でないソリューションを提供する上記の文献では未解決の問題に対処するソリューションが依然として必要とされている。
【課題を解決するための手段】
【０００９】
本発明は、条件付き電子署名を生成、使用するための方法、装置、およびコンピュータ・プログラムを提供する。本発明の第１の態様によれば、条件付き電子署名を生成するための方法は、データ項目の電子署名に条件が指定されるのに応答して実行され、データ項目を暗号化するステップと、データ項目とは別に条件を暗号化するステップと、暗号化されたデータ項目と暗号化された条件を組み合わせるステップと、データ項目および条件を表現するデジタル署名ブロックであって、データ項目および条件の両方の暗号検証を可能にするデジタル署名ブロックを生成するために、組合せを暗号化するステップを含む。
【００１０】
データ項目は、メッセージ、文書、イメージ・ファイルその他の任意のデータ・リソースとすることができる。
【００１１】
異なる者によって、または異なる時点において複数の条件が指定される場合、好ましくは、それぞれの条件は組み合わされる前に別々に（すなわち他の条件およびデータ項目とは別に）暗号化され、その後さらに暗号化される。
【００１２】
データ項目の暗号化および条件の暗号化は、好ましくはオリジナルのデータ項目および条件の簡潔で検証可能な表現を生成する単方向のハッシュ・ステップである。
【００１３】
ハッシュ済みデータ項目およびハッシュ済み条件を組み合せるステップおよびその後その組合せを暗号化するステップは、好ましくは、ハッシュ済みデータ項目およびハッシュ済み条件を連結するステップと、最終ダイジェストを生成するために連結の生成物をハッシュするステップと、条件付き署名を生成するために最終ダイジェストをさらに暗号化するステップとを含む。最終ダイジェストを暗号化するステップは、好ましくは公開／秘密鍵暗号化技法の秘密鍵を使用する。
【００１４】
代替の実施では、データ項目および条件をそれぞれ暗号化し、これら２つの暗号化された項目を連結した結果として生じる連結物（ｃｏｎｃａｔｅｎａｎｄ）を暗号化するステップのために、暗号化ブロック・チェーン（ＣＢＣ）のようなハッシュ以外の暗号化処理が使用される。連結物の暗号化を実行するために選択される暗号化プロセスは、連結物のそれぞれの半分が他方の半分に何があるかに応じて異なるように動作するため、連結物のそれぞれの半分を別々に暗号化した後に連結することによって、連結物の暗号化によって取得される暗号化ブロックが取得できないようにする、ＣＢＣプロセスなどのプロセスである。こうすることによって、許可されていない何者かによってメッセージおよび条件が一緒にされた場合、連結物に印加されたデジタル署名の検証が肯定的な結果を示さないようにすることが保証される。
【００１５】
本発明の代替の実施では、許可された署名者である参加者の閉鎖的なグループ内で文書を通信する場合、グループのメンバのみが知っている対称鍵を使用して最終ダイジェストに署名することができる。グループの各メンバは署名を検証して、データ項目および条件がグループのメンバによって署名されていることをチェックすることができる。
【００１６】
本明細書との関連における「デジタル署名」または「電子署名」とは、項目の認証を可能にする項目のデジタル処理の結果である。ひとたびデジタル形式で署名されれば、署名された項目に変更が加えられた場合に真正性が失われていることが判定できるようになる。署名は、署名者（作者、承認者、同意者など）の検証可能なデジタル識別子（署名者の手書きによる署名のデジタル化イメージを伴う場合と伴わない場合の両方を含む）とすることができる。このようなデジタル化イメージの生成は、この技術分野では周知である。以下の説明を簡略化するために、そのようなイメージを含まない例示的なソリューションについて説明する。
【００１７】
本明細書との関連における「条件」とは、契約書の署名者が署名を拘束力がないものであると主張できない絶対要件（ａｂｓｏｌｕｔｅ  ｒｅｑｕｉｒｅｍｅｎｔ）とすることができる。条件は、署名されたデータ項目の受領者による明示的な承諾のような何らかの動作を必要とする場合もあるし、必要としない場合もある。別の方法として、「条件」とは、署名者の意図または理解を表しているが絶対要件ではない、コメントまたはプリファレンスとすることができる。本明細書で「条件」という用語は、絶対要件およびコメントの両方を意味する。本発明は、署名済みのデータ項目および署名者の同一性に条件を明確にリンクさせることができる。
【００１８】
本発明の好ましい実施形態によれば、複数の条件を指定し、別々に署名することができる。具体的に言えば、電子通信またはトランザクションに対して、あるいは交渉の異なる段階において、異なる当事者が異なる条件を指定することができる。
【００１９】
本発明の好ましい実施形態は、異なるソースからの複数のメッセージまたは他のデータ項目が、暗号化によって署名され、組み合わせられた後に暗号化され、暗号化形式で配布されることをサポートする。異なる受信装置に理解されることを意図し、異なるメッセージを読む権限が与えられた特定の受信装置の公開鍵を使用して暗号化された複数のメッセージもサポートされる。受信装置はダイジェスト階層を使用して、メッセージの集合のいかなる部分も変更されていないことを保証することができる。
【００２０】
データ項目および条件を別々に暗号化し、複数の条件を別々に暗号化し、別々に暗号化された項目の組合せにデジタル署名を印加することによって、関連する署名ブロックを検証に使用できる場合、それぞれの構成要素を検証できるという利点を得ることができる。さらに、平文形式の他の構成要素を公表することなしに、特定の暗号化された構成要素を復号することができる。このことは、通信しているすべてのエンティティが、暗号化されたパッケージ（オリジナルのデータ項目および条件）のすべての構成要素へのアクセスを許可されているわけではなく、異なるエンティティが異なる構成要素を見る権限を有する場合に、特に有用であろう。単一のトランザクションに関与する複数の異なる署名者が存在し、それぞれの署名者が文書（またはその表現）を伝送しているか、承認あるいは他のコメントまたは条件を提供している場合がある。異なるエンティティによって、または異なる時点で、異なる構成要素を検証することができる。
【００２１】
代替の実施形態では、メッセージまたは条件への読み取りアクセスに関するいかなる制約を付することなく、本発明を使用して認証（メッセージおよび関連する条件の真正性の検査）を実行することができる。データ項目への条件の追加は、新しいハッシュ値または新しいデジタル署名を生成するステップを伴い、その後このハッシュ値または署名が、同様にデータ項目および条件を含む伝送パッケージに含められる。
【００２２】
本発明に従って電子署名を検証する方法は、公開復号鍵を使用して署名を復号するステップと、復号された署名を前述の連結物のプロダクトのハッシュの結果生じる最終ダイジェストと比較するステップとを有する。この方法では、潜在的には常にオリジナル・メッセージまたは条件を平文形式に変換することなく、データ項目および条件の両方の検証が実行可能である。こうすることによって、たとえば通信のすべての参加者がオリジナルを見ることを許可されているわけではないが、公開鍵を使用して真正性を検証することは許可されている場合にも、セキュリティが維持されることになる。
【００２３】
本発明の他の重要な潜在的な特典は、本発明の一実施形態が署名済みハッシュ値のみを戻すものであるため、検証処理を開始する前に実際のデジタル契約の発起人に戻る必要がある検証ソリューションに比べて、ネットワーク・トラフィックが削減されることである。この特典が強調される特定のアプリケーションは、署名済みデータ項目の送信者が未変更バージョンのデータ項目が首尾よく受け取られた旨の検証を希望するものである。署名済みダイジェストを送信者に戻すことによって、送信者が復号し、復号されたダイジェストが予想どおりであることを検証できる。
【００２４】
異なる受信装置宛ての資料をメッセージに含めることのできる実施形態では、他の装置宛ての資料を必要としない受信人は、無関係な資料はダイジェストのみを受信することによって、ネットワークの時間および記憶容量を節約することができる。
【００２５】
多くの商取引のアプリケーションでは、署名済みメッセージの受信装置はメッセージを使用して注文書または支払指図書などの書式を作成する。署名者が送信されたメッセージへの署名を望んでいない場合、メッセージを署名するように編集するのではなく別の条件を付加することによって、受信装置が署名者の条件を使用できるようにすれば、署名者の意図は受信装置に対して明確になる。本発明は、かかる条件を付加するための機構を提供する。
【００２６】
本発明の他の態様により、前述の方法に従って条件付きデジタル署名を生成するための電子署名処理装置が提供される。
【００２７】
他の態様は、前述の方法に従ってデータ項目および１以上の関連する条件の真正性を検証するための装置を提供する。
【００２８】
本発明は、プログラム・コードが実行されるデータ処理装置のオペレーションを制御するための、機械可読記録媒体上に記録されたプログラム・コードを有するコンピュータ・プログラムで実施可能である。
【００２９】
本発明の他の態様は、ステータス変更に先立ってデータ項目を受信したデータ項目の各受信装置に対してステータス変更情報の送信を含む、文書などのデータ項目のステータス変更を送信するための方法、装置、およびコンピュータ・プログラムを提供する。このソリューションは、第１の許可された承認者が承認を示すために文書またはコメントに署名し、その後第２の許可された承認者がこの承認を覆すような、電子的に署名された文書との関連における取消を処理する場合に有利である。
【００３０】
以下、本発明の好ましい実施形態について添付の図面を参照しながら例を挙げてより詳細に説明する。
【発明を実施するための最良の形態】
【００３１】
図１は、条件付き署名の構造に関する単純なプロセスを示す図である。このプロセスへの入力は、署名されるオリジナル・メッセージ１０、署名者が自分の署名への責任を伴う条件ステートメント２０、および署名のための署名者の公開／秘密鍵ペアのうちの秘密鍵３０である。プロセスへのコントロール（ＩＤＥＦＯ用語）は、使用されるハッシュ機能および暗号化機能である。
【００３２】
メッセージおよび条件は、いずれもダイジェスト５０を生成するためにハッシュされる（４０）。メッセージのダイジェストが第１番目とし、条件のダイジェストが第２番目として、ダイジェストは連結される（６０）。そして、連結物７０すなわちダブル・ダイジェスト自体がハッシュされ（８０）、最終ダイジェスト９０が生成される。その後、最終ダイジェストは秘密鍵３０を使用して暗号化され（１００）、条件付き署名ブロック１１０が生成される。
【００３３】
その後、メッセージ、条件、および条件付き署名ブロックが、ハッシュおよび暗号化に使用されるアルゴリズムならびに署名者の公開鍵（または公開鍵を取得する方法に関する情報）と共に受信装置に送信される。第１の実施では、受信装置は、最終ダイジェストを取り出すために条件付き署名ブロックを復号し、最終ダイジェストを再結合するためにオリジナルのメッセージおよび条件に関するハッシュおよび連結ステップを複製することができる。その後、これら２つのバージョンを比較することができる。最終ダイジェストの２つのバージョンが等しい場合、メッセージおよび条件は真正のものである。等しくない場合、メッセージおよび条件は信頼できないものである。第１の実施では、メッセージまたは条件への読み取りアクセスには制約は付されておらず、ハッシュ、連結、および暗号化ステップの唯一の目的は真正性の検証を可能にすることである。
【００３４】
本発明の第２の実施では、最終署名ブロックおよび初期にハッシュされたメッセージおよびハッシュされた条件（２つの初期ダイジェスト）のみが受信装置に伝送される。この場合、検証処理中にメッセージまたは条件のいずれも開示することなく検証を行うことができる。こうすることによって、平文形式でオリジナルのメッセージおよび／または条件の受信が許可されていないエンティティが、検証を実行することができるようになる。
【００３５】
図２は、前述の本発明の第１の実施に従って生成された条件付き署名を検証するための一連のステップを示す図である。受信装置は、上記のように最終ダイジェストを作成し、公開／秘密鍵ペアの公開鍵１６０を使用して条件付き署名ブロック１５０の復号（１４０）結果１３０と比較すること（１２０）によって、受信した条件付き署名が有効であること、すなわち上記の入力を使用する上記のプロセスによって条件付き署名ブロックが生成されたことを確認できる。
【００３６】
オリジナルのメッセージまたは条件の変更によってそれぞれのダイジェストの値が変化するので、メッセージおよび条件を別々にハッシュするプロセスによって、オリジナルのメッセージおよび条件が修正されていないことを受信装置が別々に検証する機構を提供することができる。いずれかのこうした修正がされると、署名された最終ダイジェストは計算された最終ダイジェストと異なるものとなる。検証の目的でダイジェストのみを伝送する場合は、オリジナルの文書および条件を検証エンティティに伝送する必要があるソリューションに比べて、かかる初期入力のハッシュによって、通信オーバヘッドが少なくなる。受信装置に対して１以上のメッセージまたは条件が示されない場合、ソリューションがオリジナルのメッセージまたは条件を伝送する必要がないので必要なセキュリティが維持されるという、潜在的なセキュリティの特典もある。
【００３７】
メッセージおよび条件が変更されているかどうかの判定を可能にするとともに、メッセージおよび条件が署名者によって組み合わされたことも受信装置に対して保証するため、メッセージおよび条件を別々にハッシュする結果として生じるダイジェストの連結をハッシュすることが望ましい。通常は暗号化ブロック・チェーン（ＣＢＣ）を使用しない一部の暗号化アルゴリズムでは、以下に示すように連結の暗号化は暗号化の連結と同じである。
Ｅ（ｋ，ｃｏｎｃａｔ（ｘ，ｙ））＝ｃｏｎｃａｔ（Ｅ（ｋ，ｘ），Ｅ（ｋ，ｙ））
【００３８】
こうした暗号化方法により、メッセージおよび条件がグループを形成していない場合にこれらをまとめて使用することが可能となる。本発明の本実施形態の範囲内でハッシュされたダブル・ダイジェスト・ソリューション、および結果として生じる最終ダイジェストの暗号化署名には、このような問題は生じない。
【００３９】
最終ダイジェストに（たとえば署名者の秘密暗号鍵を使用して）署名することによって、最終ダイジェストはその真正性を無効にすることなく変更できないことが保証される。本実施形態では、署名者以外は誰も秘密鍵にアクセスできないため、署名者のみが特定の暗号化を実行することができる。
【００４０】
前述のプロセスは、署名を作成したのが署名者自身であることを確認するだけでなく、条件付き署名ブロックが作成されてからメッセージまたは条件のどちらも変更されていないことも確認するものである。
【００４１】
前述のプロセスは、図３に示されるように、連結および結果として生じるダブル・ダイジェストのハッシュを繰り返すことによって拡張可能であるため、ユーザ（場合によっては、通信または交渉において異なる役割を持つ複数のユーザ）は、必要であれば複数の別の条件を追加することができる。さらなる拡張には、条件付き電子署名にタイムスタンプを押すための手順を適用することが含まれる。
【００４２】
一度に作成されたかまたは異なる時点で作成された一連の条件がある場合、いくつかのアプリケーションでは、最終ダブル・ダイジェストに署名するだけで十分である。しかしながら最終ダブル・ダイジェストだけに署名がされた場合、受信装置は中間の署名をチェックすることができず、構造全体が許可されているという最終署名者の言葉を信じなければならない。すべての条件が同じ人物によって主張されている場合（たとえば家の購入が、契約の対象、抵当権の対象、および調査の対象である場合）、条件の集合に対してしばしば１つの署名のみで承認がされる。その他に、複数の署名が存在するが、１以上の中間署名者の識別は秘密になっている場合がある。この場合、最終ダイジェストのみに署名することが有利である。
【００４３】
しかし、複数の署名者が存在し、受信装置がすべての中間署名を確認できる必要がある場合、すべての署名ブロックが入手できなければならない。この要件を満たすための２種類の実施は以下の通りである。
【００４４】
１．それぞれの新しいダブル・ダイジェストの構築を、先行するダブル・ダイジェストを新しい条件のハッシュに連結し、その結果をハッシュすることによって実行する。そして、この構築と並行してすべての必要な署名ブロックがこの受信装置に送信される。すべての署名動作を検証する必要があるような場合は、最終の署名ブロックに加えて中間ダブル・ダイジェストのための署名ブロックが必要となる。
【００４５】
２．代替の実施では、新しいダブル・ダイジェストは、以前の署名ブロックを新しい条件のハッシュに連結し、その結果をハッシュすることによって構築される。この実施では中間署名を省略することはできない。
【００４６】
ハードウェア環境の一例が図４に概略的に示す。ここでは、第１のユーザ・コンピュータ３００がインターネットあるいはイントラネットまたは他のネットワークなどのネットワーク３４０に接続され、他のネットワーク接続されたコンピュータ３１０、３２０、３３０との間での文書の送信および受信を実行可能にするコンピュータ・プログラムを実行している。第１のコンピュータ３００は、コンピュータ可読媒体上に格納されたコンピュータ・プログラム３５０、３６０に従って動作し、条件付き電子署名を生成し（３５０）、受信した文書の真正性をチェックするためにこうした署名を検証する（３６０）際に、ハッシュ、連結、および暗号化／復号ステップを実行する。
【００４７】
本明細書でさらに詳細に説明するように、本発明の好ましい実施形態には、条件付き電子署名を生成、検証、または使用するためにインストールされたコンピュータ・プログラムに従って動作する１以上のコンピュータを有するデータ処理システムが含まれる。
【００４８】
以下の説明の一部は、コンピュータ・メモリ内のデータに関するオペレーションのアルゴリズムおよび記号表現として、明示的または暗示的に提示される。アルゴリズムに関する説明および表現は、作業の実体を他の分野の技術者に伝える際に最も効果的であるとデータ処理分野の技術者に了解されている典型的な表記法である。アルゴリズムは、所望な結果につながる自己矛盾のない一連のステップである。ステップは、物理量の物理的操作を必要とする。通常、これらの物理量は、必須ではないが、格納、転送、組合せ、比較その他の操作が可能な電気的または磁気的な信号の形を取る。主に一般的な用法という理由で、場合によっては、これらの信号は、ビット、値、ダイジェスト、要素、構成要素、記号、文字、項、数字、またはその他と呼ぶのが便利であることが証明されている。
【００４９】
しかし、上記および同様の用語は適切な物理量に関連付けられるものであり、これらの物理量に適用される単なる便利なラベルである。本明細書全体を通じて、「コンピューティング」、「計算」、「決定」、「比較」、「生成」、「選択」、「出力」、その他の用語を使用した議論は、コンピュータ・システムのレジスタおよびメモリ内の物理（電子）量として表されるデータを操作して、コンピュータ・システムのメモリまたはレジスタあるいはこうした情報の記憶、伝送、または表示デバイス内の物理量として同様に表される他のデータに変換する、コンピュータ・システムまたは同様の電子デバイスの動作およびプロセスを表現するものである。
【００５０】
本明細書は、これらの方法のオペレーションを実行するための装置も開示する。かかる装置は、具体的に必要な目的のために構築されるか、あるいは１以上の汎用コンピュータ、またはコンピュータに格納されたコンピュータ・プログラムによって選択的に活動化または再構成される他のデバイスを備えることができる。本明細書に提示されたアルゴリズムは、本質的に特定のコンピュータまたは他の装置に関するものではない。様々な汎用マシンを本明細書の教示に従ったプログラムで使用することができる。別の方法として、必要な方法のステップを実行するためにより専用の装置の構築が適切な場合もある。
【００５１】
さらに、本明細書は、コンピュータ可読媒体および方法のオペレーションを実行するために媒体に記録されたコンピュータ・プログラムも開示する。本明細書は、コンピュータ可読媒体は、送信元と送信先との間でコンピュータ・プログラムを伝送するための任意の伝送媒体を含めるために利用される。伝送媒体は、磁気または光ディスク、メモリ・チップ、または汎用コンピュータとインターフェースするために好適な他の記憶デバイスといった記憶デバイスを含むことができる。伝送媒体は、有線媒体または（ＧＳＭ移動電話システムで例証されるような）無線媒体も含むことができる。本発明を実施するコンピュータ・プログラムは、特定プログラミング言語またはその実施に限定されることを意図するものではない。様々なプログラミング言語およびそのコーディングによって、本明細書に含まれる開示の教示を実施できることが理解されよう。
【００５２】
添付の図面において、同じ参照番号を有するステップおよび／または機能を参照する場合、それらのステップおよび／または機能は、逆の意図が示されない限り本明細書の目的で同様の機能またはオペレーションを有する。
【００５３】
次に、本発明の特定の実施形態について数学的な表記法を使用して説明する。以下で説明する暗号化手順（対称鍵暗号化）は、代替の暗号化技法の処理遅延を回避する好適な暗号化手順の一例であるが、低速な公開鍵暗号化などの他の既知の暗号化オペレーションも使用することができる。
【００５４】
ｃｏｎｃａｔ（ｘ，ｙ）を、ビット文字列ｘおよびビット文字列ｙの連結の結果として生じるビット文字列と定義する。
【００５５】
ｈ（ｘ）を、ハッシュ（別名ダイジェスト）アルゴリズムｈをビット文字列ｘに適用した結果として生じる短いビット文字列と定義する。
【００５６】
ハッシュ・アルゴリズムＳＨＡ／１およびＭＤ５では、ｈ（ｃｏｎｃａｔ（ｈ（ｘ），ｈ（ｙ）））が暗号化強度を保持することがわかっている。すなわち、たとえビット文字列ｘ、ビット文字列ｙ、およびアルゴリズムｈの３つすべてが判明している場合であっても、以下のように、そのうちの少なくとも１つがｘおよびｙとは異なるビット文字列ａおよびｂを見つけることは非常に困難である。
ｈ（ｃｏｎｃａｔ（ｈ（ａ），ｈ（ｂ）））＝ｈ（ｃｏｎｃａｔ（ｈ（ｘ），ｈ（ｙ）））
【００５７】
このコンテキストで非常に困難ということは、少なくとも、ｈ（ｐ）＝ｈ（ｑ）となるようにｑに等しくないｐを見つけることが困難であることを意味する。したがって、「ダブル・ダイジェスト」によって、システムに脆弱性が入り込むことはない。
【００５８】
Ｅ（ｋ，ｘ）を、鍵（ビット文字列でもある）ｋを使用してビット文字列ｘを暗号化した結果として生じるビット文字列と定義するが、ｋはゼロではない。
【００５９】
Ｅ（０，ｘ）を、ｘに等しくなるように定義する。
【００６０】
ｍ１、ｍ２、．．．ｍｋ（ここでｋは正の整数）を署名されるメッセージとし、ｃ０、ｃ１、ｃ２、．．．ｃｎ（ここでｎは正の整数）を付加される条件またはコメントとする。
【００６１】
ｐ１、ｐ２、．．．ｐｋを、それぞれのメッセージを読み取ることができるエンティティの公開鍵とする。
【００６２】
異なる受信装置を宛先としていても、異なるメッセージは一緒に署名されるのが有用である。商売人にとって、支払い権限を与えられた銀行に顧客がメッセージを送った旨を知ることが重要な場合がある。しかし、商売人が顧客の口座の詳細を知る必要がない場合は、顧客はその情報を秘密にすることができるようにすべきである。銀行にとっては、支払いが要求されたトランザクションを識別するダイジェストを有することが重要な場合があるが、銀行は顧客が何を購入しているかを知る必要がなく、顧客は機密性を保持することを望む場合がある。
【００６３】
ｑ１、ｑ２、．．．ｑｎを、それぞれの条件を読み取ることができるエンティティの公開鍵とする。
【００６４】
対応するメッセージまたは条件が秘密でない場合、いずれのｐまたはｑの値もゼロとすることができる。
【００６５】
ｒ１、ｒ２、．．．ｒｋおよびｔ１、ｔ２、．．．ｔｎをランダムな対称鍵とする。
【００６６】
メッセージ集合ｍ１、ｍ２、．．．ｍｉを表す「複数メッセージ・ダイジェスト」は、Ｍｉと総称される。
【００６７】
Ｍ１＝ｈ（Ｅ（ｒ１，ｍ１））および暗号ブロックＥ（ｐ１，ｒ１）は、Ｍ１に付随（ａｃｃｏｍｐａｎｙ）する。
【００６８】
ｉ＞１の場合、Ｍｉ＝ｈ（ｃｏｎｃａｔ（（Ｍ（ｉ−１）），ｈ（Ｅ（ｒｉ，ｍｉ））））であり、ダイジェストｈ（Ｅ（ｒ１，ｍ１））、ｈ（Ｅ（ｒ２，ｍ２））、．．．ｈ（Ｅ（ｒｉ，ｍｉ））および暗号ブロックＥ（ｐ１，ｒ１）、Ｅ（ｐ２，ｒ２）、Ｅ（ｐｉ，ｒｉ）、はＭｉに付随する。
【００６９】
その後Ｍｋが、全体として完全なメッセージ集合ｍ１、ｍ２、．．．ｍｋを表す複数メッセージ・ダイジェストとなる。
【００７０】
ｓ１、ｓ２、．．．ｓｎを、それぞれ条件ｃ１、ｃ２、．．．ｃｎの署名者の秘密鍵とする。
【００７１】
全体としてＭｋおよび条件ｃ１、ｃ２、．．．ｃｊを表す「条件付き署名」は、Ｓｊと呼ばれることになる。
【００７２】
Ｓ１＝Ｅ（ｓ１，ｈ（ｃｏｎｃａｔ（Ｍｋ，ｈ（Ｅ（ｔ１，ｃ１）））））およびダイジェストｈ（Ｅ（ｒ１，ｍ１））、ｈ（Ｅ（ｒ２，ｍ２））、．．．ｈ（Ｅ（ｒk
，ｍk））およびｈ（Ｅ（ｔ１，ｃ１））ならびに暗号ブロックＥ（ｐ１，ｒ１）、Ｅ（ｐ２，ｒ２）、．．．Ｅ（ｐｋ，ｒｋ）、およびＥ（ｑ１，ｔ１）はＳ１に付随する。
【００７３】
ｊ＞１の場合、Ｓｊ＝Ｅ（ｓｊ，ｈ（ｃｏｎｃａｔ（（Ｓ（ｊ−１）），ｈ（Ｅ（ｔｊ，ｃｊ）））））であり、ダイジェストｈ（Ｅ（ｒ１，ｍ１））、ｈ（Ｅ（ｒ２，ｍ２））、．．．ｈ（Ｅ（ｒｋ，ｍｋ））およびｈ（Ｅ（ｔ１，ｃ１））、ｈ（Ｅ（ｔ２，ｃ２））、．．．ｈ（Ｅ（ｔｊ，ｃｊ））ならびに暗号ブロックＥ（ｐ１，ｒ１）、Ｅ（ｐ２，ｒ２）、．．．Ｅ（ｐｋ，ｒｋ）、およびＥ（ｑ１，ｔ１）、Ｅ（ｑ２，ｔ２）、．．．Ｅ（ｑｊ，ｔｊ）はＳ１に付随する。
【００７４】
その後Ｓｎが最終条件付き署名となる。
【００７５】
上記で詳細に述べた本発明の実施形態は、最終ダイジェストに署名するための公開／秘密鍵暗号化を使用する。公開／秘密鍵暗号化は多くのアプリケーションにとって便利な技法であるが、承認済みの署名者のみが知っている鍵を使用する他のデジタル署名技法も好適である。
【００７６】
閉鎖的なグループ内では、最終ダイジェスト用のいくつかのアプリケーションで、グループのみに知られた対称鍵を使用して署名することが容認される。その後、グループの各メンバが署名をチェックし、メッセージおよび条件がグループのメンバによって署名されているかを確認できるようになるが、グループのどのメンバが署名したか不明となる可能性がある。メッセージが閉鎖的なグループの外部へ送信される場合は、署名のチェックが可能な鍵を送信すると異なるメッセージまたは条件を使用して代替署名を作成することが可能となってしまうため、一般に、対称鍵ソリューションは容認されない。秘密鍵を使用してメッセージに署名すればこの問題は解決されるが、アプリケーションでは秘密鍵をグループの人々で共用することが容認される。
【００７７】
対称鍵暗号化は、一般に公開／秘密鍵暗号化よりも高速である。しかし、ＭＤ５ダイジェスト（１６バイト長さ）またはＳＨＡ／１ダイジェスト（２０バイト長さ）に署名する場合、暗号化される項目のサイズは、対称鍵暗号化の高速処理を大幅に向上させるのに十分な長さではない。
【００７８】
前述の条件付き署名ソリューションは、ある者が署名した文書を、実行に移す前に承認または検証のために他の者へ転送しなければならないような状況に対処するものである。既知のソリューションでは解決されない他の状況とは、ある者の承認を他の者が取り消すという状況である。理解を容易なものとするために、以下の説明では取消しをする人物が取消命令を発する権限を有するものと仮定する。
【００７９】
以下、かかる取消命令に対処することができる、ソフトウェアで実施可能なデータ処理システムおよびプロセスについて説明する。
【００８０】
条件付き署名のアプリケーションの１つが、承認前に２人以上の署名者を必要とする文書に対処するものである。第１の署名者は任意の必要なコメントを付加して文書に署名し、第２の署名者は任意の必要なフォローアップ・コメントを追加して、その結果に署名する。たとえば教会を例に取ると、書籍の出版を希望する牧師は司祭のオフィスにいる職員にテキストを送付し、職員がテキストを査読する。問題がなければ、職員は書籍に「無害であることを証明する（“ｎｉｈｉｌ  ｏｂｓｔａｔ”）」（すなわち「問題なし（“ｎｏｔｈｉｎｇ  ｓｔａｎｄｓ  ｉｎ  ｉｔｓ  ｗａｙ”）」）と裏書する。そして、司祭は、その書籍に「出版許可（“ｉｍｐｒｉｍａｔｅｕｒ”）」（すなわち「印刷可（“ｌｅｔ  ｉｔ  ｂｅ  ｐｒｉｎｔｅｄ”）」）と裏書することができる。
【００８１】
このソリューションは特定の文書ステータスに限定されない。たとえば文書には、署名者が示した承認が法的な不服申立の手続の対象となるような条件（たとえば、不服申立提出に関する任意の適用可能な期日までの期間）を前提として署名する場合もある。
【００８２】
社員が文書を決定し許可できるようにし、さらにその社員の上司が最初の許可を取消すことができるようにしている企業が存在する。取消命令は必ずしも望ましい運用であるとは限らないが、運用が許可されている企業で許可の取消命令に対処するソリューションが求められている。
【００８３】
この問題を解決するためのシステムおよび方法を以下に記載する。システムおよび方法は、初期の許可のコピーを受け取ったすべての者が取消命令のコピーを受け取ることを保証する。初期の許可のコピーを受け取ったすべての者は、オリジナルの署名者が署名済み文書を送信先を含むが、より間接的なルートでコピーを受け取った人物も含まれる。
【００８４】
Ｏｐｅｎ  Ｇｒｏｕｐ規格Ｘ．５０９のバージョン２には、公開鍵証明書である特定ケース文書についての関連ソリューションが記載されている。認証機関（ＣＡ）が、特定の名前で知られているエンティティが特定の公開鍵を有することを主張する公開鍵証明書を発行した場合、公開鍵証明書の用紙には証明書取消リスト（ＣＲＬ）が取得可能なアドレスが含まれる。ＣＲＬには、機関によって発行されたが、その後（鍵所有者がＣＡの組織を離れた、対応する秘密鍵に障害が発生した、証明書が誤って発行された、または証明書が不正手段によって取得された、などの理由により）取り消された証明書のリストが含まれる。ＣＡの種類、ならびに公開鍵証明書、アドレス、およびＣＲＬのフォーマットは、すべて規格に定義されている。
【００８５】
規格に記載されているＣＲＬプロセスは、メッセージの固定形式に制約されているだけでなく、オリジナルのメッセージを受け取ったすべての人を含め、誰にもＣＲＬを送信するようにされていない。
【００８６】
取消命令をサポートするソリューションは、以下の３つの部分を含む。
【００８７】
１．「アクティブ・コンテンツ」は、取消命令を許可する組織に属する者が文書に署名した場合に条件に自動的に含まれるようにされている。アクティブ・コンテンツは、Ｍｉｃｒｏｓｏｆｔ（商標）のＡｃｔｉｖｅＸコントロールを使用するか、好ましい実施では、メッセージの送信先である任意のプラットフォーム上でＪａｖａランタイム・システムによって実行可能なカプセル化コードを有するＪａｖａ（商標）の「ａｇｌｅｔ」として、実施可能である。したがって、一般的なソリューションは使用される特定のアクティブ・コンテンツ・ツールには依存しない。文書が他の誰かに転送されるときには、アクティブ・コンテンツが必ず実行され、組織が管理するしているのレジスタに受信装置のアドレス（たとえば電子メール・アドレス）が送信される。
【００８８】
２．拡張電子メール・システム（たとえば、Ｌｏｔｕｓ  Ｄｅｖｅｌｏｐｍｅｎｔ  ＣｏｒｐｏｒａｔｉｏｎのＬｏｔｕｓ  Ｎｏｔｅｓ（商標）通信ソフトウェア）は、作者を識別する単純なエピローグを含む（偽造される可能性があるが、ほとんどの略式の電子メールに適切な）メッセージと、作者の秘密鍵を使用して暗号化方式で署名されることになるメッセージとの、相違点を認識する。後者は、作者が秘密鍵を保護するために使用するパスワードを何者かが見つけた場合に限って偽造される可能性がある。取消命令ソリューションは、電子メール・システムが
ｉ．署名されたメッセージ内のアクティブ・コンテンツの存在を認識し、メッセージが転送される場合は必ずアクティブ・コンテンツを実行し、
ｉｉ．メッセージが署名された場合、適切なアクティブ・コンテンツを作成する（電子メール・システム内に新しいオプションである「命令として署名」が提供され、組織が必要な場合にのみ追加の機能を使用できるようにする）し、
ｉｉｉ．電子メール・システムがレジストリに送信するメッセージを取り消す動作を認識するように、
電子メール・システムを拡張する。
【００８９】
３．ソリューションの第３の部分は、「命令として署名された」それぞれのメッセージのａｇｌｅｔから情報を受信してこれを保持するように、電子メール・システムにリンクされたレジスタである。電子メール・システムは取消命令を受信すると、オリジナル・メッセージを受信したとして登録されているすべてのアドレスにその取消命令を送信する。さらにレジスタは、メッセージおよび取消命令の記録を管理し、受信装置のうちの１人が後でそのメッセージを特定の者に転送する場合、レジスタおよび電子メール・システムが協働してその特定の者にも同様に取消命令を送信する。
【００９０】
アクティブ・コンテンツ（ａｇｌｅｔ）は、署名する際にメッセージに付加された条件の一部である。よって、条件のダイジェストを変更することなく、したがって署名の無効化および許可の取り消しをすることなく、ａｇｌｅｔを除去することは不可能である。
【００９１】
より一般的には、取消命令に関して上記で説明したソリューションを、文書その他のデータ項目のステータス変更を通知するために使用することができる。取消されたメッセージは、文書の状況を後続の決定によって変更できる、より一般的な状況の特定のケースである。条件付き署名ソリューションに関して上記で述べた方法で新しいステータスを文書に追加することが可能であり、ステータス変更通知ソリューションを使用してその新しいステータスを文書のすべての受信装置に送信することができる。
【００９２】
ステータス変更報告ソリューションの他のアプリケーションは、限定から秘密へ、または秘密から極秘への、文書の再分類を報告するためのものである。
【００９３】
本発明の一実施形態に従ってステータス変更報告を実現する方法は、以下のステップを含む
・適切なアクティブ・コンテンツ作成機構を使用して、適切なメッセージ用のアクティブ・コンテンツを作成するステップ
・メッセージの送信者または受信装置のいずれかによって、アクティブ・コンテンツを認識し、実行するステップ
・取消命令その他のステータス変更がされたことに応答して、ステータス変更に関する完全な配布リストを管理するレジスタにアクセスし、ステータス変更通知を配布するステップ
【００９４】
レジスタ自体の機能が分散されており、協働するレジスタによって実施される場合があり、協働する各レジスタは自分自身の領域の受信装置の配布リストを管理し、他の受信装置の詳細をそれらの領域のレジスタに転送する。しかし、組織は、メッセージまたは文書のステータス変更の全面的な監査記録が必要な環境において、単一のレジスタを実施するように選択をすることができる。
【図面の簡単な説明】
【００９５】
【図１】本発明の第１の実施形態に従って条件付き署名を生成するための方法の一連のステップを示す図である。
【図２】本発明の一実施形態に従って条件付き署名を検証するための一連のステップを示す図である。
【図３】本発明の一実施形態に従って複数の条件をメッセージに付加するための方法のステップを示す図である。
【図４】本発明の一方法を使用するのに好適な装置を示す概略図である。
【図１】
2006511996.tif 000003
【図２】
2006511996.tif 000004
【図３】
2006511996.tif 000005
【図４】
2006511996.tif 000006
【手続補正書】
【提出日】平成17年1月28日(2005.1.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ項目の電子署名に条件が指定されたことに応答して実行される、条件付き電子署名を生成するための方法であって、
前記データ項目を暗号化するステップと、
前記データ項目とは別に前記条件を暗号化するステップと、
暗号化された前記データ項目と暗号化された前記条件とを組み合わせるステップと、
前記データ項目および前記条件を表現するデジタル署名ブロックであって、前記データ項目および前記条件の両方の暗号検証を可能にするデジタル署名ブロックを生成するために、前記組合せを暗号化するステップと、
を含む方法。
【請求項２】
複数の指定された条件を別々に暗号化し、暗号化された前記複数の指定された条件を暗号化された前記データ項目と組み合わせ、その後さらに前記組合せを暗号化する、請求項１に記載の方法。
【請求項３】
前記データ項目の暗号化および前記条件の暗号化は、それぞれ前記データ項目および前記条件の検証可能な表現を生成するための単方向のハッシュ・ステップである、請求項１に記載の方法。
【請求項４】
ハッシュ済み前記データ項目およびハッシュ済み前記条件を組み合せるステップは、ハッシュ済み前記データ項目およびハッシュ済み前記条件を連結するステップと、最終ダイジェストを生成するために前記連結物をハッシュするステップと、デジタル署名ブロックを生成するために前記最終ダイジェストをさらに暗号化するステップとを含む、請求項３に記載の方法。
【請求項５】
前記組合せを暗号化するステップは、
（ａ）暗号化された前記データ項目と暗号化された前記条件とを組み合わせ、前記組合せを暗号化した結果が、
（ｂ）暗号化された前記データ項目と暗号化された前記条件の両方を暗号化した後、二重に暗号化された前記データ項目と前記条件とを組み合わせた結果とは異なる、
暗号化方法を使用する、請求項１または２に記載の方法。
【請求項６】
前記暗号化方法は、暗号化ブロック・チェーン暗号化を実施する、請求項５に記載の方法。
【請求項７】
前記データ項目の暗号化と前記条件の暗号化は、それぞれ暗号化ブロック・チェーン暗号化方法を使用する、請求項１または２に記載の方法。
【請求項８】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップは、条件付き署名を生成するために公開／秘密鍵暗号化技法を使用する、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップは、条件付き署名を生成するために対称鍵暗号化技法の対称鍵を使用する、請求項１乃至７のいずれか一項に記載の方法。
【請求項１０】
前記暗号化するステップを実行するために使用される前記暗号化プロセスへのアクセスを有し、対応する復号鍵へのアクセスを有する受信装置が、
前記デジタル署名ブロックを復号して第１の結果を生成するステップと、
前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせて、第２の結果を生成するステップと、
前記第１の結果と第２の結果とを比較して、両者が一致するかどうかを判定するステップと、
を実行可能にするように、前記データ項目、前記条件、および前記デジタル署名ブロックを受信装置に伝送するステップを含む、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
暗号化アルゴリズムを前記受信装置に伝送するステップを含む、請求項１０に記載の方法。
【請求項１２】
暗号化された前記データ項目と、
暗号化された前記条件と
を含む、前記暗号化するステップそれぞれの中間結果を前記受信装置に伝送するステップを含む、請求項１０または１１に記載の方法。
【請求項１３】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップにおいて、公開／秘密鍵暗号化技法の秘密鍵が使用され、前記方法は、前記公開／秘密鍵暗号化技法の公開鍵を前記受信装置に伝送するステップを含む、請求項１０乃至１２のいずれか一項に記載の方法。
【請求項１４】
デジタル署名ブロックを生成するために前記組合せを暗号化するステップにおいて、公開／秘密鍵暗号化技法の秘密鍵が使用され、前記方法は、前記公開／秘密鍵暗号化技法の公開鍵を取得するための情報を前記受信装置に伝送するステップを含む、請求項１０乃至１２のいずれか一項に記載の方法。
【請求項１５】
それぞれの前記暗号化するステップの結果を含む暗号化結果の集合をコンパイルするステップを含み、前記伝送するステップは、前記暗号化結果の集合を前記受信装置に送信するステップを含む、請求項１０から１４のいずれか一項に記載の方法。
【請求項１６】
前記組合せを暗号化するステップを実行するために使用される前記暗号化プロセスへのアクセスを有し、対応する復号鍵へのアクセスを有する受信装置が、
前記デジタル署名ブロックを復号するステップと、
前記データ項目および前記条件のハッシュ済み表現を組み合わせて、組合せダイジェストを生成するステップと、
前記復号された署名ブロックと前記組合せダイジェストを比較して、両者が一致するかどうかを判定するステップと、
を実行可能とするように、前記データ項目および条件、ならびに前記デジタル署名ブロックのハッシュ済み表現を受信装置に伝送するステップを含む、請求項３に記載の方法。
【請求項１７】
前記ハッシュ済み表現を組み合わせて、組合せダイジェストを生成するステップは、
前記ハッシュ済み表現を連結してダブル・ダイジェストを生成するステップと、
前記ダブル・ダイジェストをハッシュして最終の組合せダイジェストを生成するステップと、
を有する、請求項１６に記載の方法。
【請求項１８】
複数のデータ項目のそれぞれを別々に暗号化して組み合わせ、前記組合せをその後さらに暗号化する、請求項１に記載の方法。
【請求項１９】
請求項１０に記載の方法によって生成された条件付き電子署名を検証するための方法であって、
伝送された前記データ項目、前記条件、および前記デジタル署名ブロックを前記受信装置が受信したことに応答して実行される、
前記デジタル署名ブロックを復号して第１の結果を生成するステップと、
前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせて、第２の結果を生成するステップと、
前記第１の結果と第２の結果とを比較して、両者が一致するかどうかを判定するステップと、
を含む方法。
【請求項２０】
請求項１乃至１８に記載の発明を実施するために、コンピュータ・プログラムがコンピュータ上で実行された場合に実効するためのソフトウェア・コード部分を有する、デジタル・コンピュータの内部メモリにロード可能なコンピュータ・プログラム。
【請求項２１】
請求項１９に記載の発明を実施するために、コンピュータ・プログラムがコンピュータ上で実行された場合に実効するためのソフトウェア・コード部分を有する、デジタル・コンピュータの内部メモリにロード可能なコンピュータ・プログラム。
【請求項２２】
条件付き電子署名を生成するためのデータ処理装置であって、
データ項目（１０）の電子署名に条件（２０）が指定されたことに応答して、前記データ項目を暗号化し（５０）、前記データ項目とは別に前記条件を暗号化し（５０）、暗号化された前記データ項目と暗号化された前記条件とを組み合わせ（６０）、前記データ項目および前記条件を表現するデジタル署名ブロック（１１０）であって、前記データ項目および前記条件の両方の暗号検証を可能にするデジタル署名ブロック（１１０）を生成するために前記組合せを暗号化するための、１以上の暗号化構成コンポーネントと、
前記データ項目、前記条件、および前記デジタル署名ブロック（１１０）を、受信装置に伝送するための手段と、
を備える装置。
【請求項２３】
請求項１０に記載の方法によって生成された条件付き電子署名を検証するためのデータ処理装置であって、
伝送された前記データ項目、前記条件、および前記デジタル署名ブロック（１１０）を受信するための手段と、
前記デジタル署名ブロックを復号して第１の結果を生成し、前記データ項目を暗号化し、前記データ項目とは別に前記条件を暗号化し、暗号化された前記データ項目と暗号化された前記条件とを組み合わせて、第２の結果を生成し、前記第１の結果と第２の結果とを比較して両者が一致するかどうかを判定するための、１以上の暗号化コンポーネントと、
を備えるデータ処理装置。
【請求項２４】
条件付きで署名されたデータ項目のうちの１つの受信装置への転送または拒否が識別されたことに応答して、前記データ項目の受信装置リストを管理するレジストリを更新するための実行可能コンテンツを含む条件付きで署名されたデータ項目に関するステータス情報を送信するための方法であって、
前記条件付きで署名されたデータ項目の新しい受信装置への転送に応答して、前記レジストリ内の前記受信装置リストを更新するために前記実行可能コンテンツを実行するステップと、
前記条件付きで署名されたデータ項目に対する拒否の指示に応答して、前記レジストリを更新するために前記実行可能コンテンツを実行し、前記データ項目に対する拒否の指示を前記レジストリ・リスト内の前記受信装置に送信するステップと、
を含む方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子署名の生成、使用、およびメッセージ、文書その他のリソースのステータス変更のレポートのための方法、装置、およびコンピュータ・プログラムに関する。
【背景技術】
【０００２】
通常の電子的でない商取引においては、”subjectto contract”（契約の締結を条件とする）、”deliveryrequired within seven days”（７日以内の配送を要する）、”paidunder protest”（支払に異議を留保する）、”withoutprejudice”（権利放棄しない）といった条件を自分の署名の上に手書きで付加することが非常に一般的に行われている。このような注記には法的効力の疑わしいものもあるが、注記を付加した者にとっては法的効力の有無は重要ではなく、そのような条件の付加を希望すること自体が重要なのである。他の場合として、ビジネス交渉にとって条件の付加が不可欠な場合がある。
【０００３】
電子商取引では、通常、このような方法で条件を指定する機会は存在しないため、条件を付加することなくで電子的に署名するか、または署名しないかを決定しなければならない。ベンダーは、潜在的な購買者がオンラインで解決できないと思ったわずかな法律上の問題が原因でオンラインでの売上げを失ったり、署名した顧客が将来の購入をやめてしまう可能性がある。そして、不満を抱いた顧客は、戻ってこない。
【０００４】
このような例は企業と消費者の間のアプリケーションでは典型的なものであるが、企業同士の間のアプリケーションでも同様の要求が存在する。報道によれば、ある多忙な商品仕入れマネージャが自動販売機の貨物引渡通知書に署名の記載を求められた。しかし、彼は、自動販売機を数年間リースするという内容の個人としての契約に署名しているという自覚をしていなかった。そして、彼の会社が自動販売機供給業者の変更を決定したとき、供給業者はマネージャに対し、彼が署名した契約の履行を請求したのである。このような場合、裁判所がその契約を有効と判断するか、あるいは無効で強制できないものと判断するかにかかわらず、マネージャにとっては、引渡を確認するためにのみ署名しているという条件（自分の会社の法律顧問によって起案されることが好ましい）が付加できれば良かったのである。しかし、このようなことは、典型的な電子商取引のソリューションでは実現することはできない。
【０００５】
デジタル署名は、署名者の契約の承諾の確認、および文書またはメッセージの認証のために、手書き署名と同じ目的で使用することができる。一般に、デジタル署名は署名者の同一性を確認できるものでなければならない。メッセージ用の単純な形式のデジタル署名は、（メッセージ・ダイジェスト・アルゴリズム：ＭＤ５またはセキュア・ハッシング・アルゴリズム：ＳＨＡ／１を使用する）暗号化「ハッシュ」または「ダイジェスト」機能をメッセージに適用し、長いメッセージを表す短いダイジェストを生成するものである。ダイジェストまたはハッシュ値は、ほぼすべての長さが可能な入力にハッシュ機能を適用することによって生成される、固定サイズの文字列である。その後、署名者の秘密署名鍵を使用してダイジェストを暗号化し、（たとえばデジタル署名アルゴリズム、すなわちＤＳＡを使用して）メッセージ用の署名ブロックを生成する。メッセージ、署名ブロック、ハッシュおよび暗号化に使用されたアルゴリズム、ならびに署名者の公開鍵を取得する方法は受信装置に送信され、受信装置は、メッセージのハッシュ、署名ブロックの復号、および結果として生成するショート・ダイジェストの比較によって、署名ブロックの妥当性を確認することができる。公開鍵は、たとえば信頼できる第三者が発行するデジタル証明書から取得することができる。
【０００６】
二重秘密／公開鍵暗号化システムは、たとえば米国特許第５１５７７２６号で開示されている。米国特許第５１５７７２６号は、デジタル署名を認証するためのシステムを開示している。秘密鍵を使用して文書に署名し、その後公開鍵を使用して真正性をチェックする。デジタル署名を作成するためのプロセスは、米国特許第４８８１２６４号、第４３０９５６９号、第４６２５０７６号、および第４６５６４７４号、ならびに国際規格ＩＳＯ９７９６およびＣＣＩＴＴ  Ｘ５０９に開示されている。
【０００７】
日本の白浜町で２００２年１月２９日から２月１日にかけて開催された「暗号と情報セキュリティ・シンポジウム（ＳＣＩＳ）２００２」において、ビョンチョン・リーおよびクァンジョ・キムは、「Ｆａｉｒ  Ｅｘｃｈａｎｇｅ  ｏｆ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅｓ  Ｕｓｉｎｇ  Ｃｏｎｄｉｔｉｏｎａｌ  Ｓｉｇｎａｔｕｒｅ」として、「条件付き署名」に言及している。「条件付き署名」は、署名者が選択した条件を二当事者間の通信における秘密の交渉文として使用できるようにされている。具体的には、「条件付き署名」は、条件付き署名の検証に応答した条件なし署名の「公正な交換」の達成に焦点をあてたものである。リーらの「条件付き署名」とはメッセージと条件とをまとめた上での署名であり、具体的に言えば、従来の署名方式を使用してメッセージと条件の機能との組合せに署名するものである。
【０００８】
欧州特許出願第９３２０２９４５．７は、公開鍵保持者の識別を認証する拡張デジタル署名証明書を備えた公開鍵／署名暗号化システムを開示する。署名が証明されている個人の権限および責務のレベルを示す、入れ子階層の証明書および署名が採用されている。
【０００９】
２００２年４月２５日公開の米国特許出願公開第２００２／００４９６０１Ａ１号は、２当事者間で値項目を公正に交換するための方法を開示しており、第三者は例外的な状況でのみ関与する。各当事者は、交換手順の初期に、値項目が束縛されているという事実を受信者側が検証できるような方法でその値項目を束縛する許可を、他方の当事者に送信する。
【００１０】
１９９９年８月１２日公開のＰＣＴ国際特許出願第ＷＯ９９／４４０７０２号は、階層型ハッシュを使用した効率的な認証および整合性チェックのための方法および装置を開示する。データに署名するためおよびデータを検証するための方法が提供される。データの署名には、データの集合をパケットに分割すること、ハッシュ値を含むハッシュ・ブロックを生成するためにそれぞれのパケット内のデータをハッシュすること、およびデジタル署名をハッシュ・ブロックに付加することが含まれる。
【特許文献１】米国特許第５１５７７２６号
【特許文献２】米国特許第４８８１２６４号
【特許文献３】米国特許第４３０９５６９号
【特許文献４】米国特許第４６２５０７６号
【特許文献５】米国特許第４６５６４７４号
【特許文献６】欧州特許出願第９３２０２９４５．７
【特許文献７】米国特許出願公開第２００２／００４９６０１Ａ１号
【特許文献８】国際特許出願第ＷＯ９９／４４０７０２号
【非特許文献１】国際規格ＩＳＯ９７９６
【非特許文献２】ＣＣＩＴＴ  Ｘ５０９
【非特許文献３】日本の白浜で２００２年１月２９日〜２月１日に開かれた暗号と情報セキュリティ・シンポジウム（ＳＣＩＳ）２００２でのビョンチョン・リーおよびクァンジョ・キムによる「Ｆａｉｒ  Ｅｘｃｈａｎｇｅ  ｏｆ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅｓ  Ｕｓｉｎｇ  Ｃｏｎｄｉｔｉｏｎａｌ  Ｓｉｇｎａｔｕｒｅ」
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従って、この技術分野では、柔軟性が明らかに向上した電子的でないソリューションを提供する上記の文献では未解決の問題に対処するソリューションが依然として必要とされている。
【課題を解決するための手段】
【００１２】
本発明は、条件付き電子署名を生成、使用するための方法、装置、およびコンピュータ・プログラムを提供する。本発明の第１の態様によれば、条件付き電子署名を生成するための方法は、データ項目の電子署名に条件が指定されるのに応答して実行され、データ項目を暗号化するステップと、データ項目とは別に条件を暗号化するステップと、暗号化されたデータ項目と暗号化された条件を組み合わせるステップと、データ項目および条件を表現するデジタル署名ブロックであって、データ項目および条件の両方の暗号検証を可能にするデジタル署名ブロックを生成するために、組合せを暗号化するステップを含む。
【００１３】
データ項目は、メッセージ、文書、イメージ・ファイルその他の任意のデータ・リソースとすることができる。
【００１４】
異なる者によって、または異なる時点において複数の条件が指定される場合、好ましくは、それぞれの条件は組み合わされる前に別々に（すなわち他の条件およびデータ項目とは別に）暗号化され、その後さらに暗号化される。
【００１５】
データ項目の暗号化および条件の暗号化は、好ましくはオリジナルのデータ項目および条件の簡潔で検証可能な表現を生成する単方向のハッシュ・ステップである。
【００１６】
ハッシュ済みデータ項目およびハッシュ済み条件を組み合せるステップおよびその後その組合せを暗号化するステップは、好ましくは、ハッシュ済みデータ項目およびハッシュ済み条件を連結するステップと、最終ダイジェストを生成するために連結の生成物をハッシュするステップと、条件付き署名を生成するために最終ダイジェストをさらに暗号化するステップとを含む。最終ダイジェストを暗号化するステップは、好ましくは公開／秘密鍵暗号化技法の秘密鍵を使用する。
【００１７】
代替の実施では、データ項目および条件をそれぞれ暗号化し、これら２つの暗号化された項目を連結した結果として生じる連結物（ｃｏｎｃａｔｅｎａｎｄ）を暗号化するステップのために、暗号化ブロック・チェーン（ＣＢＣ）のようなハッシュ以外の暗号化処理が使用される。連結物の暗号化を実行するために選択される暗号化プロセスは、連結物のそれぞれの半分が他方の半分に何があるかに応じて異なるように動作するため、連結物のそれぞれの半分を別々に暗号化した後に連結することによって、連結物の暗号化によって取得される暗号化ブロックが取得できないようにする、ＣＢＣプロセスなどのプロセスである。こうすることによって、許可されていない何者かによってメッセージおよび条件が一緒にされた場合、連結物に印加されたデジタル署名の検証が肯定的な結果を示さないようにすることが保証される。
【００１８】
本発明の代替の実施では、許可された署名者である参加者の閉鎖的なグループ内で文書を通信する場合、グループのメンバのみが知っている対称鍵を使用して最終ダイジェストに署名することができる。グループの各メンバは署名を検証して、データ項目および条件がグループのメンバによって署名されていることをチェックすることができる。
【００１９】
本明細書との関連における「デジタル署名」または「電子署名」とは、項目の認証を可能にする項目のデジタル処理の結果である。ひとたびデジタル形式で署名されれば、署名された項目に変更が加えられた場合に真正性が失われていることが判定できるようになる。署名は、署名者（作者、承認者、同意者など）の検証可能なデジタル識別子（署名者の手書きによる署名のデジタル化イメージを伴う場合と伴わない場合の両方を含む）とすることができる。このようなデジタル化イメージの生成は、この技術分野では周知である。以下の説明を簡略化するために、そのようなイメージを含まない例示的なソリューションについて説明する。
【００２０】
本明細書との関連における「条件」とは、契約書の署名者が署名を拘束力がないものであると主張できない絶対要件（ａｂｓｏｌｕｔｅ  ｒｅｑｕｉｒｅｍｅｎｔ）とすることができる。条件は、署名されたデータ項目の受領者による明示的な承諾のような何らかの動作を必要とする場合もあるし、必要としない場合もある。別の方法として、「条件」とは、署名者の意図または理解を表しているが絶対要件ではない、コメントまたはプリファレンスとすることができる。本明細書で「条件」という用語は、絶対要件およびコメントの両方を意味する。本発明は、署名済みのデータ項目および署名者の同一性に条件を明確にリンクさせることができる。
【００２１】
本発明の好ましい実施形態によれば、複数の条件を指定し、別々に署名することができる。具体的に言えば、電子通信またはトランザクションに対して、あるいは交渉の異なる段階において、異なる当事者が異なる条件を指定することができる。
【００２２】
本発明の好ましい実施形態は、異なるソースからの複数のメッセージまたは他のデータ項目が、暗号化によって署名され、組み合わせられた後に暗号化され、暗号化形式で配布されることをサポートする。異なる受信装置に理解されることを意図し、異なるメッセージを読む権限が与えられた特定の受信装置の公開鍵を使用して暗号化された複数のメッセージもサポートされる。受信装置はダイジェスト階層を使用して、メッセージの集合のいかなる部分も変更されていないことを保証することができる。
【００２３】
データ項目および条件を別々に暗号化し、複数の条件を別々に暗号化し、別々に暗号化された項目の組合せにデジタル署名を印加することによって、関連する署名ブロックを検証に使用できる場合、それぞれの構成要素を検証できるという利点を得ることができる。さらに、平文形式の他の構成要素を公表することなしに、特定の暗号化された構成要素を復号することができる。このことは、通信しているすべてのエンティティが、暗号化されたパッケージ（オリジナルのデータ項目および条件）のすべての構成要素へのアクセスを許可されているわけではなく、異なるエンティティが異なる構成要素を見る権限を有する場合に、特に有用であろう。単一のトランザクションに関与する複数の異なる署名者が存在し、それぞれの署名者が文書（またはその表現）を伝送しているか、承認あるいは他のコメントまたは条件を提供している場合がある。異なるエンティティによって、または異なる時点で、異なる構成要素を検証することができる。
【００２４】
代替の実施形態では、メッセージまたは条件への読み取りアクセスに関するいかなる制約を付することなく、本発明を使用して認証（メッセージおよび関連する条件の真正性の検査）を実行することができる。データ項目への条件の追加は、新しいハッシュ値または新しいデジタル署名を生成するステップを伴い、その後このハッシュ値または署名が、同様にデータ項目および条件を含む伝送パッケージに含められる。
【００２５】
本発明に従って電子署名を検証する方法は、公開復号鍵を使用して署名を復号するステップと、復号された署名を前述の連結物のプロダクトのハッシュの結果生じる最終ダイジェストと比較するステップとを有する。この方法では、潜在的には常にオリジナル・メッセージまたは条件を平文形式に変換することなく、データ項目および条件の両方の検証が実行可能である。こうすることによって、たとえば通信のすべての参加者がオリジナルを見ることを許可されているわけではないが、公開鍵を使用して真正性を検証することは許可されている場合にも、セキュリティが維持されることになる。
【００２６】
本発明の他の重要な潜在的な特典は、本発明の一実施形態が署名済みハッシュ値のみを戻すものであるため、検証処理を開始する前に実際のデジタル契約の発起人に戻る必要がある検証ソリューションに比べて、ネットワーク・トラフィックが削減されることである。この特典が強調される特定のアプリケーションは、署名済みデータ項目の送信者が未変更バージョンのデータ項目が首尾よく受け取られた旨の検証を希望するものである。署名済みダイジェストを送信者に戻すことによって、送信者が復号し、復号されたダイジェストが予想どおりであることを検証できる。
【００２７】
異なる受信装置宛ての資料をメッセージに含めることのできる実施形態では、他の装置宛ての資料を必要としない受信人は、無関係な資料はダイジェストのみを受信することによって、ネットワークの時間および記憶容量を節約することができる。
【００２８】
多くの商取引のアプリケーションでは、署名済みメッセージの受信装置はメッセージを使用して注文書または支払指図書などの書式を作成する。署名者が送信されたメッセージへの署名を望んでいない場合、メッセージを署名するように編集するのではなく別の条件を付加することによって、受信装置が署名者の条件を使用できるようにすれば、署名者の意図は受信装置に対して明確になる。本発明は、かかる条件を付加するための機構を提供する。
【００２９】
本発明の他の態様により、前述の方法に従って条件付きデジタル署名を生成するための電子署名処理装置が提供される。
【００３０】
他の態様は、前述の方法に従ってデータ項目および１以上の関連する条件の真正性を検証するための装置を提供する。
【００３１】
本発明は、プログラム・コードが実行されるデータ処理装置のオペレーションを制御するための、機械可読記録媒体上に記録されたプログラム・コードを有するコンピュータ・プログラムで実施可能である。
【００３２】
本発明の他の態様は、ステータス変更に先立ってデータ項目を受信したデータ項目の各受信装置に対してステータス変更情報の送信を含む、文書などのデータ項目のステータス変更を送信するための方法、装置、およびコンピュータ・プログラムを提供する。このソリューションは、第１の許可された承認者が承認を示すために文書またはコメントに署名し、その後第２の許可された承認者がこの承認を覆すような、電子的に署名された文書との関連における取消を処理する場合に有利である。
【００３３】
以下、本発明の好ましい実施形態について添付の図面を参照しながら例を挙げてより詳細に説明する。
【発明を実施するための最良の形態】
【００３４】
図１は、条件付き署名の構造に関する単純なプロセスを示す図である。このプロセスへの入力は、署名されるオリジナル・メッセージ１０、署名者が自分の署名への責任を伴う条件ステートメント２０、および署名のための署名者の公開／秘密鍵ペアのうちの秘密鍵３０である。プロセスへのコントロール（ＩＤＥＦＯ用語）は、使用されるハッシュ機能および暗号化機能である。
【００３５】
メッセージおよび条件は、いずれもダイジェスト５０を生成するためにハッシュされる（４０）。メッセージのダイジェストが第１番目とし、条件のダイジェストが第２番目として、ダイジェストは連結される（６０）。そして、連結物７０すなわちダブル・ダイジェスト自体がハッシュされ（８０）、最終ダイジェスト９０が生成される。その後、最終ダイジェストは秘密鍵３０を使用して暗号化され（１００）、条件付き署名ブロック１１０が生成される。
【００３６】
その後、メッセージ、条件、および条件付き署名ブロックが、ハッシュおよび暗号化に使用されるアルゴリズムならびに署名者の公開鍵（または公開鍵を取得する方法に関する情報）と共に受信装置に送信される。第１の実施では、受信装置は、最終ダイジェストを取り出すために条件付き署名ブロックを復号し、最終ダイジェストを再結合するためにオリジナルのメッセージおよび条件に関するハッシュおよび連結ステップを複製することができる。その後、これら２つのバージョンを比較することができる。最終ダイジェストの２つのバージョンが等しい場合、メッセージおよび条件は真正のものである。等しくない場合、メッセージおよび条件は信頼できないものである。第１の実施では、メッセージまたは条件への読み取りアクセスには制約は付されておらず、ハッシュ、連結、および暗号化ステップの唯一の目的は真正性の検証を可能にすることである。
【００３７】
本発明の第２の実施では、最終署名ブロックおよび初期にハッシュされたメッセージおよびハッシュされた条件（２つの初期ダイジェスト）のみが受信装置に伝送される。この場合、検証処理中にメッセージまたは条件のいずれも開示することなく検証を行うことができる。こうすることによって、平文形式でオリジナルのメッセージおよび／または条件の受信が許可されていないエンティティが、検証を実行することができるようになる。
【００３８】
図２は、前述の本発明の第１の実施に従って生成された条件付き署名を検証するための一連のステップを示す図である。受信装置は、上記のように最終ダイジェストを作成し、公開／秘密鍵ペアの公開鍵１６０を使用して条件付き署名ブロック１５０の復号（１４０）結果１３０と比較すること（１２０）によって、受信した条件付き署名が有効であること、すなわち上記の入力を使用する上記のプロセスによって条件付き署名ブロックが生成されたことを確認できる。
【００３９】
オリジナルのメッセージまたは条件の変更によってそれぞれのダイジェストの値が変化するので、メッセージおよび条件を別々にハッシュするプロセスによって、オリジナルのメッセージおよび条件が修正されていないことを受信装置が別々に検証する機構を提供することができる。いずれかのこうした修正がされると、署名された最終ダイジェストは計算された最終ダイジェストと異なるものとなる。検証の目的でダイジェストのみを伝送する場合は、オリジナルの文書および条件を検証エンティティに伝送する必要があるソリューションに比べて、かかる初期入力のハッシュによって、通信オーバヘッドが少なくなる。受信装置に対して１以上のメッセージまたは条件が示されない場合、ソリューションがオリジナルのメッセージまたは条件を伝送する必要がないので必要なセキュリティが維持されるという、潜在的なセキュリティの特典もある。
【００４０】
メッセージおよび条件が変更されているかどうかの判定を可能にするとともに、メッセージおよび条件が署名者によって組み合わされたことも受信装置に対して保証するため、メッセージおよび条件を別々にハッシュする結果として生じるダイジェストの連結をハッシュすることが望ましい。通常は暗号化ブロック・チェーン（ＣＢＣ）を使用しない一部の暗号化アルゴリズムでは、以下に示すように連結の暗号化は暗号化の連結と同じである。
Ｅ（ｋ，ｃｏｎｃａｔ（ｘ，ｙ））＝ｃｏｎｃａｔ（Ｅ（ｋ，ｘ），Ｅ（ｋ，ｙ））
【００４１】
こうした暗号化方法により、メッセージおよび条件がグループを形成していない場合にこれらをまとめて使用することが可能となる。本発明の本実施形態の範囲内でハッシュされたダブル・ダイジェスト・ソリューション、および結果として生じる最終ダイジェストの暗号化署名には、このような問題は生じない。
【００４２】
最終ダイジェストに（たとえば署名者の秘密暗号鍵を使用して）署名することによって、最終ダイジェストはその真正性を無効にすることなく変更できないことが保証される。本実施形態では、署名者以外は誰も秘密鍵にアクセスできないため、署名者のみが特定の暗号化を実行することができる。
【００４３】
前述のプロセスは、署名を作成したのが署名者自身であることを確認するだけでなく、条件付き署名ブロックが作成されてからメッセージまたは条件のどちらも変更されていないことも確認するものである。
【００４４】
前述のプロセスは、図３に示されるように、連結および結果として生じるダブル・ダイジェストのハッシュを繰り返すことによって拡張可能であるため、ユーザ（場合によっては、通信または交渉において異なる役割を持つ複数のユーザ）は、必要であれば複数の別の条件を追加することができる。さらなる拡張には、条件付き電子署名にタイムスタンプを押すための手順を適用することが含まれる。
【００４５】
一度に作成されたかまたは異なる時点で作成された一連の条件がある場合、いくつかのアプリケーションでは、最終ダブル・ダイジェストに署名するだけで十分である。しかしながら最終ダブル・ダイジェストだけに署名がされた場合、受信装置は中間の署名をチェックすることができず、構造全体が許可されているという最終署名者の言葉を信じなければならない。すべての条件が同じ人物によって主張されている場合（たとえば家の購入が、契約の対象、抵当権の対象、および調査の対象である場合）、条件の集合に対してしばしば１つの署名のみで承認がされる。その他に、複数の署名が存在するが、１以上の中間署名者の識別は秘密になっている場合がある。この場合、最終ダイジェストのみに署名することが有利である。
【００４６】
しかし、複数の署名者が存在し、受信装置がすべての中間署名を確認できる必要がある場合、すべての署名ブロックが入手できなければならない。この要件を満たすための２種類の実施は以下の通りである。
【００４７】
１．それぞれの新しいダブル・ダイジェストの構築を、先行するダブル・ダイジェストを新しい条件のハッシュに連結し、その結果をハッシュすることによって実行する。そして、この構築と並行してすべての必要な署名ブロックがこの受信装置に送信される。すべての署名動作を検証する必要があるような場合は、最終の署名ブロックに加えて中間ダブル・ダイジェストのための署名ブロックが必要となる。
【００４８】
２．代替の実施では、新しいダブル・ダイジェストは、以前の署名ブロックを新しい条件のハッシュに連結し、その結果をハッシュすることによって構築される。この実施では中間署名を省略することはできない。
【００４９】
ハードウェア環境の一例が図４に概略的に示す。ここでは、第１のユーザ・コンピュータ３００がインターネットあるいはイントラネットまたは他のネットワークなどのネットワーク３４０に接続され、他のネットワーク接続されたコンピュータ３１０、３２０、３３０との間での文書の送信および受信を実行可能にするコンピュータ・プログラムを実行している。第１のコンピュータ３００は、コンピュータ可読媒体上に格納されたコンピュータ・プログラム３５０、３６０に従って動作し、条件付き電子署名を生成し（３５０）、受信した文書の真正性をチェックするためにこうした署名を検証する（３６０）際に、ハッシュ、連結、および暗号化／復号ステップを実行する。
【００５０】
本明細書でさらに詳細に説明するように、本発明の好ましい実施形態には、条件付き電子署名を生成、検証、または使用するためにインストールされたコンピュータ・プログラムに従って動作する１以上のコンピュータを有するデータ処理システムが含まれる。
【００５１】
以下の説明の一部は、コンピュータ・メモリ内のデータに関するオペレーションのアルゴリズムおよび記号表現として、明示的または暗示的に提示される。アルゴリズムに関する説明および表現は、作業の実体を他の分野の技術者に伝える際に最も効果的であるとデータ処理分野の技術者に了解されている典型的な表記法である。アルゴリズムは、所望な結果につながる自己矛盾のない一連のステップである。ステップは、物理量の物理的操作を必要とする。通常、これらの物理量は、必須ではないが、格納、転送、組合せ、比較その他の操作が可能な電気的または磁気的な信号の形を取る。主に一般的な用法という理由で、場合によっては、これらの信号は、ビット、値、ダイジェスト、要素、構成要素、記号、文字、項、数字、またはその他と呼ぶのが便利であることが証明されている。
【００５２】
しかし、上記および同様の用語は適切な物理量に関連付けられるものであり、これらの物理量に適用される単なる便利なラベルである。本明細書全体を通じて、「コンピューティング」、「計算」、「決定」、「比較」、「生成」、「選択」、「出力」、その他の用語を使用した議論は、コンピュータ・システムのレジスタおよびメモリ内の物理（電子）量として表されるデータを操作して、コンピュータ・システムのメモリまたはレジスタあるいはこうした情報の記憶、伝送、または表示デバイス内の物理量として同様に表される他のデータに変換する、コンピュータ・システムまたは同様の電子デバイスの動作およびプロセスを表現するものである。
【００５３】
本明細書は、これらの方法のオペレーションを実行するための装置も開示する。かかる装置は、具体的に必要な目的のために構築されるか、あるいは１以上の汎用コンピュータ、またはコンピュータに格納されたコンピュータ・プログラムによって選択的に活動化または再構成される他のデバイスを備えることができる。本明細書に提示されたアルゴリズムは、本質的に特定のコンピュータまたは他の装置に関するものではない。様々な汎用マシンを本明細書の教示に従ったプログラムで使用することができる。別の方法として、必要な方法のステップを実行するためにより専用の装置の構築が適切な場合もある。
【００５４】
さらに、本明細書は、コンピュータ可読媒体および方法のオペレーションを実行するために媒体に記録されたコンピュータ・プログラムも開示する。本明細書は、コンピュータ可読媒体は、送信元と送信先との間でコンピュータ・プログラムを伝送するための任意の伝送媒体を含めるために利用される。伝送媒体は、磁気または光ディスク、メモリ・チップ、または汎用コンピュータとインターフェースするために好適な他の記憶デバイスといった記憶デバイスを含むことができる。伝送媒体は、有線媒体または（ＧＳＭ移動電話システムで例証されるような）無線媒体も含むことができる。本発明を実施するコンピュータ・プログラムは、特定プログラミング言語またはその実施に限定されることを意図するものではない。様々なプログラミング言語およびそのコーディングによって、本明細書に含まれる開示の教示を実施できることが理解されよう。
【００５５】
添付の図面において、同じ参照番号を有するステップおよび／または機能を参照する場合、それらのステップおよび／または機能は、逆の意図が示されない限り本明細書の目的で同様の機能またはオペレーションを有する。
【００５６】
次に、本発明の特定の実施形態について数学的な表記法を使用して説明する。以下で説明する暗号化手順（対称鍵暗号化）は、代替の暗号化技法の処理遅延を回避する好適な暗号化手順の一例であるが、低速な公開鍵暗号化などの他の既知の暗号化オペレーションも使用することができる。
【００５７】
ｃｏｎｃａｔ（ｘ，ｙ）を、ビット文字列ｘおよびビット文字列ｙの連結の結果として生じるビット文字列と定義する。
【００５８】
ｈ（ｘ）を、ハッシュ（別名ダイジェスト）アルゴリズムｈをビット文字列ｘに適用した結果として生じる短いビット文字列と定義する。
【００５９】
ハッシュ・アルゴリズムＳＨＡ／１およびＭＤ５では、ｈ（ｃｏｎｃａｔ（ｈ（ｘ），ｈ（ｙ）））が暗号化強度を保持することがわかっている。すなわち、たとえビット文字列ｘ、ビット文字列ｙ、およびアルゴリズムｈの３つすべてが判明している場合であっても、以下のように、そのうちの少なくとも１つがｘおよびｙとは異なるビット文字列ａおよびｂを見つけることは非常に困難である。
ｈ（ｃｏｎｃａｔ（ｈ（ａ），ｈ（ｂ）））＝ｈ（ｃｏｎｃａｔ（ｈ（ｘ），ｈ（ｙ）））
【００６０】
このコンテキストで非常に困難ということは、少なくとも、ｈ（ｐ）＝ｈ（ｑ）となるようにｑに等しくないｐを見つけることが困難であることを意味する。したがって、「ダブル・ダイジェスト」によって、システムに脆弱性が入り込むことはない。
【００６１】
Ｅ（ｋ，ｘ）を、鍵（ビット文字列でもある）ｋを使用してビット文字列ｘを暗号化した結果として生じるビット文字列と定義するが、ｋはゼロではない。
【００６２】
Ｅ（０，ｘ）を、ｘに等しくなるように定義する。
【００６３】
ｍ１、ｍ２、．．．ｍｋ（ここでｋは正の整数）を署名されるメッセージとし、ｃ０、ｃ１、ｃ２、．．．ｃｎ（ここでｎは正の整数）を付加される条件またはコメントとする。
【００６４】
ｐ１、ｐ２、．．．ｐｋを、それぞれのメッセージを読み取ることができるエンティティの公開鍵とする。
【００６５】
異なる受信装置を宛先としていても、異なるメッセージは一緒に署名されるのが有用である。商売人にとって、支払い権限を与えられた銀行に顧客がメッセージを送った旨を知ることが重要な場合がある。しかし、商売人が顧客の口座の詳細を知る必要がない場合は、顧客はその情報を秘密にすることができるようにすべきである。銀行にとっては、支払いが要求されたトランザクションを識別するダイジェストを有することが重要な場合があるが、銀行は顧客が何を購入しているかを知る必要がなく、顧客は機密性を保持することを望む場合がある。
【００６６】
ｑ１、ｑ２、．．．ｑｎを、それぞれの条件を読み取ることができるエンティティの公開鍵とする。
【００６７】
対応するメッセージまたは条件が秘密でない場合、いずれのｐまたはｑの値もゼロとすることができる。
【００６８】
ｒ１、ｒ２、．．．ｒｋおよびｔ１、ｔ２、．．．ｔｎをランダムな対称鍵とする。
【００６９】
メッセージ集合ｍ１、ｍ２、．．．ｍｉを表す「複数メッセージ・ダイジェスト」は、Ｍｉと総称される。
【００７０】
Ｍ１＝ｈ（Ｅ（ｒ１，ｍ１））および暗号ブロックＥ（ｐ１，ｒ１）は、Ｍ１に付随（ａｃｃｏｍｐａｎｙ）する。
【００７１】
ｉ＞１の場合、Ｍｉ＝ｈ（ｃｏｎｃａｔ（（Ｍ（ｉ−１）），ｈ（Ｅ（ｒｉ，ｍｉ））））であり、ダイジェストｈ（Ｅ（ｒ１，ｍ１））、ｈ（Ｅ（ｒ２，ｍ２））、．．．ｈ（Ｅ（ｒｉ，ｍｉ））および暗号ブロックＥ（ｐ１，ｒ１）、Ｅ（ｐ２，ｒ２）、Ｅ（ｐｉ，ｒｉ）、はＭｉに付随する。
【００７２】
その後Ｍｋが、全体として完全なメッセージ集合ｍ１、ｍ２、．．．ｍｋを表す複数メッセージ・ダイジェストとなる。
【００７３】
ｓ１、ｓ２、．．．ｓｎを、それぞれ条件ｃ１、ｃ２、．．．ｃｎの署名者の秘密鍵とする。
【００７４】
全体としてＭｋおよび条件ｃ１、ｃ２、．．．ｃｊを表す「条件付き署名」は、Ｓｊと呼ばれることになる。
【００７５】
Ｓ１＝Ｅ（ｓ１，ｈ（ｃｏｎｃａｔ（Ｍｋ，ｈ（Ｅ（ｔ１，ｃ１）））））およびダイジェストｈ（Ｅ（ｒ１，ｍ１））、ｈ（Ｅ（ｒ２，ｍ２））、．．．ｈ（Ｅ（ｒk
，ｍk））およびｈ（Ｅ（ｔ１，ｃ１））ならびに暗号ブロックＥ（ｐ１，ｒ１）、Ｅ（ｐ２，ｒ２）、．．．Ｅ（ｐｋ，ｒｋ）、およびＥ（ｑ１，ｔ１）はＳ１に付随する。
【００７６】
ｊ＞１の場合、Ｓｊ＝Ｅ（ｓｊ，ｈ（ｃｏｎｃａｔ（（Ｓ（ｊ−１）），ｈ（Ｅ（ｔｊ，ｃｊ）））））であり、ダイジェストｈ（Ｅ（ｒ１，ｍ１））、ｈ（Ｅ（ｒ２，ｍ２））、．．．ｈ（Ｅ（ｒｋ，ｍｋ））およびｈ（Ｅ（ｔ１，ｃ１））、ｈ（Ｅ（ｔ２，ｃ２））、．．．ｈ（Ｅ（ｔｊ，ｃｊ））ならびに暗号ブロックＥ（ｐ１，ｒ１）、Ｅ（ｐ２，ｒ２）、．．．Ｅ（ｐｋ，ｒｋ）、およびＥ（ｑ１，ｔ１）、Ｅ（ｑ２，ｔ２）、．．．Ｅ（ｑｊ，ｔｊ）はＳ１に付随する。
【００７７】
その後Ｓｎが最終条件付き署名となる。
【００７８】
上記で詳細に述べた本発明の実施形態は、最終ダイジェストに署名するための公開／秘密鍵暗号化を使用する。公開／秘密鍵暗号化は多くのアプリケーションにとって便利な技法であるが、承認済みの署名者のみが知っている鍵を使用する他のデジタル署名技法も好適である。
【００７９】
閉鎖的なグループ内では、最終ダイジェスト用のいくつかのアプリケーションで、グループのみに知られた対称鍵を使用して署名することが容認される。その後、グループの各メンバが署名をチェックし、メッセージおよび条件がグループのメンバによって署名されているかを確認できるようになるが、グループのどのメンバが署名したか不明となる可能性がある。メッセージが閉鎖的なグループの外部へ送信される場合は、署名のチェックが可能な鍵を送信すると異なるメッセージまたは条件を使用して代替署名を作成することが可能となってしまうため、一般に、対称鍵ソリューションは容認されない。秘密鍵を使用してメッセージに署名すればこの問題は解決されるが、アプリケーションでは秘密鍵をグループの人々で共用することが容認される。
【００８０】
対称鍵暗号化は、一般に公開／秘密鍵暗号化よりも高速である。しかし、ＭＤ５ダイジェスト（１６バイト長さ）またはＳＨＡ／１ダイジェスト（２０バイト長さ）に署名する場合、暗号化される項目のサイズは、対称鍵暗号化の高速処理を大幅に向上させるのに十分な長さではない。
【００８１】
前述の条件付き署名ソリューションは、ある者が署名した文書を、実行に移す前に承認または検証のために他の者へ転送しなければならないような状況に対処するものである。既知のソリューションでは解決されない他の状況とは、ある者の承認を他の者が取り消すという状況である。理解を容易なものとするために、以下の説明では取消しをする人物が取消命令を発する権限を有するものと仮定する。
【００８２】
以下、かかる取消命令に対処することができる、ソフトウェアで実施可能なデータ処理システムおよびプロセスについて説明する。
【００８３】
条件付き署名のアプリケーションの１つが、承認前に２人以上の署名者を必要とする文書に対処するものである。第１の署名者は任意の必要なコメントを付加して文書に署名し、第２の署名者は任意の必要なフォローアップ・コメントを追加して、その結果に署名する。たとえば教会を例に取ると、書籍の出版を希望する牧師は司祭のオフィスにいる職員にテキストを送付し、職員がテキストを査読する。問題がなければ、職員は書籍に「無害であることを証明する（“ｎｉｈｉｌ  ｏｂｓｔａｔ”）」（すなわち「問題なし（“ｎｏｔｈｉｎｇ  ｓｔａｎｄｓ  ｉｎ  ｉｔｓ  ｗａｙ”）」）と裏書する。そして、司祭は、その書籍に「出版許可（“ｉｍｐｒｉｍａｔｅｕｒ”）」（すなわち「印刷可（“ｌｅｔ  ｉｔ  ｂｅ  ｐｒｉｎｔｅｄ”）」）と裏書することができる。
【００８４】
このソリューションは特定の文書ステータスに限定されない。たとえば文書には、署名者が示した承認が法的な不服申立の手続の対象となるような条件（たとえば、不服申立提出に関する任意の適用可能な期日までの期間）を前提として署名する場合もある。
【００８５】
社員が文書を決定し許可できるようにし、さらにその社員の上司が最初の許可を取消すことができるようにしている企業が存在する。取消命令は必ずしも望ましい運用であるとは限らないが、運用が許可されている企業で許可の取消命令に対処するソリューションが求められている。
【００８６】
この問題を解決するためのシステムおよび方法を以下に記載する。システムおよび方法は、初期の許可のコピーを受け取ったすべての者が取消命令のコピーを受け取ることを保証する。初期の許可のコピーを受け取ったすべての者は、オリジナルの署名者が署名済み文書を送信先を含むが、より間接的なルートでコピーを受け取った人物も含まれる。
【００８７】
Ｏｐｅｎ  Ｇｒｏｕｐ規格Ｘ．５０９のバージョン２には、公開鍵証明書である特定ケース文書についての関連ソリューションが記載されている。認証機関（ＣＡ）が、特定の名前で知られているエンティティが特定の公開鍵を有することを主張する公開鍵証明書を発行した場合、公開鍵証明書の用紙には証明書取消リスト（ＣＲＬ）が取得可能なアドレスが含まれる。ＣＲＬには、機関によって発行されたが、その後（鍵所有者がＣＡの組織を離れた、対応する秘密鍵に障害が発生した、証明書が誤って発行された、または証明書が不正手段によって取得された、などの理由により）取り消された証明書のリストが含まれる。ＣＡの種類、ならびに公開鍵証明書、アドレス、およびＣＲＬのフォーマットは、すべて規格に定義されている。
【００８８】
規格に記載されているＣＲＬプロセスは、メッセージの固定形式に制約されているだけでなく、オリジナルのメッセージを受け取ったすべての人を含め、誰にもＣＲＬを送信するようにされていない。
【００８９】
取消命令をサポートするソリューションは、以下の３つの部分を含む。
【００９０】
１．「アクティブ・コンテンツ」は、取消命令を許可する組織に属する者が文書に署名した場合に条件に自動的に含まれるようにされている。アクティブ・コンテンツは、Ｍｉｃｒｏｓｏｆｔ（商標）のＡｃｔｉｖｅＸコントロールを使用するか、好ましい実施では、メッセージの送信先である任意のプラットフォーム上でＪａｖａランタイム・システムによって実行可能なカプセル化コードを有するＪａｖａ（商標）の「ａｇｌｅｔ」として、実施可能である。したがって、一般的なソリューションは使用される特定のアクティブ・コンテンツ・ツールには依存しない。文書が他の誰かに転送されるときには、アクティブ・コンテンツが必ず実行され、組織が管理するしているのレジスタに受信装置のアドレス（たとえば電子メール・アドレス）が送信される。
【００９１】
２．拡張電子メール・システム（たとえば、Ｌｏｔｕｓ  Ｄｅｖｅｌｏｐｍｅｎｔ  ＣｏｒｐｏｒａｔｉｏｎのＬｏｔｕｓ  Ｎｏｔｅｓ（商標）通信ソフトウェア）は、作者を識別する単純なエピローグを含む（偽造される可能性があるが、ほとんどの略式の電子メールに適切な）メッセージと、作者の秘密鍵を使用して暗号化方式で署名されることになるメッセージとの、相違点を認識する。後者は、作者が秘密鍵を保護するために使用するパスワードを何者かが見つけた場合に限って偽造される可能性がある。取消命令ソリューションは、電子メール・システムが
ｉ．署名されたメッセージ内のアクティブ・コンテンツの存在を認識し、メッセージが転送される場合は必ずアクティブ・コンテンツを実行し、
ｉｉ．メッセージが署名された場合、適切なアクティブ・コンテンツを作成する（電子メール・システム内に新しいオプションである「命令として署名」が提供され、組織が必要な場合にのみ追加の機能を使用できるようにする）し、
ｉｉｉ．電子メール・システムがレジストリに送信するメッセージを取り消す動作を認識するように、
電子メール・システムを拡張する。
【００９２】
３．ソリューションの第３の部分は、「命令として署名された」それぞれのメッセージのａｇｌｅｔから情報を受信してこれを保持するように、電子メール・システムにリンクされたレジスタである。電子メール・システムは取消命令を受信すると、オリジナル・メッセージを受信したとして登録されているすべてのアドレスにその取消命令を送信する。さらにレジスタは、メッセージおよび取消命令の記録を管理し、受信装置のうちの１人が後でそのメッセージを特定の者に転送する場合、レジスタおよび電子メール・システムが協働してその特定の者にも同様に取消命令を送信する。
【００９３】
アクティブ・コンテンツ（ａｇｌｅｔ）は、署名する際にメッセージに付加された条件の一部である。よって、条件のダイジェストを変更することなく、したがって署名の無効化および許可の取り消しをすることなく、ａｇｌｅｔを除去することは不可能である。
【００９４】
より一般的には、取消命令に関して上記で説明したソリューションを、文書その他のデータ項目のステータス変更を通知するために使用することができる。取消されたメッセージは、文書の状況を後続の決定によって変更できる、より一般的な状況の特定のケースである。条件付き署名ソリューションに関して上記で述べた方法で新しいステータスを文書に追加することが可能であり、ステータス変更通知ソリューションを使用してその新しいステータスを文書のすべての受信装置に送信することができる。
【００９５】
ステータス変更報告ソリューションの他のアプリケーションは、限定から秘密へ、または秘密から極秘への、文書の再分類を報告するためのものである。
【００９６】
本発明の一実施形態に従ってステータス変更報告を実現する方法は、以下のステップを含む
・適切なアクティブ・コンテンツ作成機構を使用して、適切なメッセージ用のアクティブ・コンテンツを作成するステップ
・メッセージの送信者または受信装置のいずれかによって、アクティブ・コンテンツを認識し、実行するステップ
・取消命令その他のステータス変更がされたことに応答して、ステータス変更に関する完全な配布リストを管理するレジスタにアクセスし、ステータス変更通知を配布するステップ
【００９７】
レジスタ自体の機能が分散されており、協働するレジスタによって実施される場合があり、協働する各レジスタは自分自身の領域の受信装置の配布リストを管理し、他の受信装置の詳細をそれらの領域のレジスタに転送する。しかし、組織は、メッセージまたは文書のステータス変更の全面的な監査記録が必要な環境において、単一のレジスタを実施するように選択をすることができる。
【図面の簡単な説明】
【００９８】
【図１】本発明の第１の実施形態に従って条件付き署名を生成するための方法の一連のステップを示す図である。
【図２】本発明の一実施形態に従って条件付き署名を検証するための一連のステップを示す図である。
【図３】本発明の一実施形態に従って複数の条件をメッセージに付加するための方法のステップを示す図である。
【図４】本発明の一方法を使用するのに好適な装置を示す概略図である。
【国際調査報告】
2006511996.tif 000007
2006511996.tif 000008
2006511996.tif 000009
2006511996.tif 000010
2006511996.tif 000011