JPH11119650A - ディジタル署名の長期検証のための方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 テ゛ィシ゛タル署名の信憑性及び保全性を正確に検
証できる期間をそれに関連する認証の満了時を超えて延
長させる技法を提供すること。 【解決手段】 テ゛ィシ゛タル署名を検証できる期間を有効に
延長させ、即ち、該署名が依存する認証の何れか又は全
ての満了時を十分に超えて延長させる方法及び装置。一
実施態様では「状態セーフ゛」手法と称するLTSVを解決する
ための手法が提供される。これは暗号情報及び暗号化技
術の利用を大いに必要とし、このためアーカイフ゛機構を用い
て文書自体に加えてPKI状態（例えば認証及びCRL等の暗
号情報）が記憶される。この情報は、後に署名検証フ゜ロセ
スを再生するために必要となる全てを構成する。ユーサ゛が
文書の署名の再検証を望む場合、LTSVサーハ゛は、該文書が
当初に提出された時点におけるPKIの正確な状態を再生
する。LTSVサーハ゛は、該状態を復元し、その署名検証フ゜ロセ
スは、該LTSVサーハ゛が数年前に実行したフ゜ロセスを正確に実行
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ディジタル署名の
利用に関し、特に、ディジタル署名の長期検証のための
方法及び装置に関する。

【０００２】

【従来の技術】ディジタル署名の技術によって、電子商
取引のためのディジタルネットワーク（インターネット
を含む）の利用が増大する可能性が切り開かれた。今
や、1人以上の関係者に対して商取引を表すディジタル
署名付き文書の送受信を行うことが実現可能である。

【０００３】現在では、ディジタル署名は、それが依存
するディジタル認証が満了していない限り検証可能であ
る。ある認証の有効期間が１〜２年間の範囲内にあると
予測される場合、現在の技術は、時間の経過に対するデ
ィジタル署名の永続性を必要とする浮上してきた電子商
取引市場の要求をサポートしないものとなる。用途によ
っては、ディジタル署名済み文書の受領者が、該文書の
署名後数年が経過した後に、署名時に該文書の信憑性を
検証できるのと全く同様に、該文書の信憑性を検証でき
ることが望ましい。残念ながら、現在の技術の状態で
は、認証の満了後におけるこれらディジタル署名の検証
は提供されない。これは、所定期間（典型的には１年後
又は2年）の後に満了することが、文書の署名及び暗号
化に用いられるキー及び認証の特性であるからである。
これは、少なくとも部分的には、計算速度の向上や暗号
解読の飛躍的な進歩等の要因のためキーの効力が時間の
経過につれて低下することが予測されることに起因す
る。更に、キーが使用される期間が長くほど、敵対者が
該キーの解読を試みる期間も長くなる。従って、キーを
定期的に交換するのが標準的なやり方である。これが、
認証に特定の満了日がある理由である。

【０００４】技術の現状を調査した結果、関連する認証
が全て満了になった署名付き文書を検証する要求がなさ
れた場合にディジタル署名検証モジュールが機能しなく
なることが明らかになった。図１は、認定の満了を表す
概略的なブロック図である。この単純な例から明らかな
ように、認証10の有効期間を２年（例えば1996年4月1日
〜1998年4月1日）とすると、該認証の発行後6カ月間
（例えば1996年10月1日まで）は署名を有効に正常に検
証することができるが（100）、3年後（例えば1999年4
月1日）には同署名の検証ができなくなる（102）。例え
ば、契約書等の文書の有効期間を認証の有効期間を超え
て延長しなければならない場合には、上記の検証動作は
明らかに許容不能なものとなる。

【０００５】更に、現行システムの中には、認証無効用
リスト（ＣＲＬ）を利用し、認証の満了時に該認証を無
効にして該リストから除去するものがある。これは、該
ＣＲＬのレコードが一般に消失するため、既知の技法を
用いた長期にわたる署名の検証が不可能になることを意
味している。

【０００６】過去の信用の復元については既知の通りで
ある（A．Menezes，P.van Oorschot，S.Vanstone，Hand
book of Applied Cryptography，CRC Press，pp583(199
6）を参照のこと）。この手法では、過去の時点に関す
る署名の再検証と問題の解決との両方に、過去の時点か
らの信用連鎖(chains of trust)の復元が必要とされる
可能性がある。これには、キー入力資料(keying materi
al)及び過去の信用連鎖の復元に関する情報の保存が必
要になる。公証人が利用される場合にはかかる過去の連
鎖の直接的な復元が不要であることが教示されている。
公証人は、或る時点における文書の存在を確認するだけ
でなく或る時点における一層一般的な陳述の真実性を保
証することが可能な一般的な公務員として定義される。
公証人の本来の検証は、一定の時点における信用連鎖の
存在を立証することであると教示され、またその記録は
後に以前の有効性の証拠として働くものであると教示さ
れている。また、監査を目的として元の信用連鎖の詳細
を記録することが可能であることが教示されている。満
了した認証の存在に基づいて文書を検証できるとは教示
されていない。そうではなく、公証人の利用に頼ってい
る。将来の時点では、保存されたキー入力資料を証拠と
して用いることにより、非自動的な手続きによる問題と
なる署名の解決が可能になると教示されている。

【０００７】

【発明が解決しようとする課題】本発明の目的は、ディ
ジタル署名の信憑性及び保全性を正確に検証することが
可能な期間を、それに関連する認証の満了時を超えて延
長させるための技法を提供することにある。

【０００８】

【課題を解決するための手段】本発明によれば、ディジ
タル署名を検証することが可能な期間を有効に延長さ
せ、即ち、署名が依存する認証の何れか又は全ての満了
時を十分に超えて延長させる方法及び装置が提供され
る。本発明は、ユーザが、長期にわたり存続する文書
（例えば契約書）に対するディジタル署名を付与し、該
署名の後、数年又は数十年にわたり該ディジタル署名の
個別の検証が可能であることを所望する、適用分野で用
いることが可能である。本発明の望ましい実施態様によ
れば、長期署名検証（ＬＴＳＶ）を提供する解決法を構
成する２つの代替的な手法が得られる。

【０００９】本発明の一実施態様によれば、本明細書で
「状態セーブ」手法と称するＬＴＳＶを解決するための
手法が提供される。この本発明の実施態様は、暗号情報
及び暗号化技術の利用を大いに必要とする。従って、ア
ーカイブ機構を用いて、文書自体に加えて、公開キーイ
ンフラストラクチャ（Public Key Infrastructure:ＰＫ
Ｉ）状態（例えば認証及びＣＲＬ等の暗号情報）が記憶
される。この情報は、後に署名検証プロセスを再生する
ために必要となる全てを構成するものである。また、プ
ライバシー上の理由から、暗号化情報（署名、認証、及
びＣＲＬ等）とは別個にソース文書を記憶することが望
ましい場合もある。例えば、ユーザがソース文書の管理
を所望する場合である。ＰＫＩ状態情報は、認証及びＣ
ＲＬ等の暗号化により保護された情報と、ルート認定権
威者の公開キー又はポリシー情報等の暗号化により保護
されていない情報との一方又は両方を含むことが可能で
ある。

【００１０】ユーザが（おそらくは数年後に）文書の署
名の再検証を望む場合、ＬＴＳＶサーバは、該文書が当
初に提出された時点におけるＰＫＩの正確な状態を再生
する。ＬＴＳＶサーバは、該状態を復元し、その署名検
証プロセスは、該ＬＴＳＶサーバが数年前に実行した
（又は実行したと思われる）プロセスを正確に実行す
る。署名検証プロセスを再生するための基礎として用い
られる時間は、提出時の時間である必要はない。そうで
はなく、該時間は、発信者により文書に署名がされたと
き又はその検証が受信者により行われたとき等の、他の
何らかの関連する時間とすることが可能である。

【００１１】本発明の別の実施態様では、暗号化の効力
と、安全なデータ記憶に現在関連のある（非公開キー）
技術及び手順の立証された障害許容力とが組み合わせら
れる。この実施態様の一例により、 ● 将来の再検証に備えてＰＫＩ状態をセーブし、 ● ファイアウォール、アクセス制御機構、監査機構、
侵入検出機構、物理分離、及びネットワーク分離といっ
たサービスによって保護されている記憶保全機構内にＰ
ＫＩ状態情報をし、及び／又は（例えばＬＴＳＶサーバ
を使用してＰＫＩ状態情報に署名し又はキーイングハッ
シュアルゴリズムを使用する）暗号保護機構を用いるこ
とにより、ＰＫＩ状態情報を侵入から保護する、メカニ
ズムが提供される。

【００１２】更に、かかる手法に他の非暗号機能を追加
することにより、保全性及び信頼性の高いＬＴＳＶ解決
法が提供される。かかる非暗号機能の一例としては、Ｐ
ＫＩ状態情報（暗号情報並びに非暗号情報）の参照並び
にシステムのセキュリティの視覚的な監視を行うための
ユーティリティが挙げられる。これらのユーティリティ
を利用して、問題解決のための視覚的証拠を提供するこ
とが可能である。

【００１３】本明細書に開示の記憶保全手法を強化する
ことによって、認証連鎖等の所定の証拠をアーカイブに
保持するものである。この情報は、実際の再検証に使用
する必要のないものであり、疑問が生じた場合に備えて
単に証拠を維持するものとして用いられるものである。

【００１４】

【発明の実施の形態】本明細書において用いられる用語
のいくつかに関する意味は、一般的な用法とは幾分異な
る場合がある。下記の定義は、本明細書における用法に
関連してそれぞれの用語の意味を明確にすることを意図
したものである。

【００１５】アーカイブ： 電子情報の記憶及び読み出
しを行うための任意の機構。

【００１６】認証： ディジタル署名のベースとなるア
ーティファクト。認証は、あるエンティティを該エンテ
ィティの公開キーで確実に拘束するものである。

【００１７】暗号リフレッシュ： 長期にわたり暗号情
報を記憶する場合にキーが劣化する問題を解決する手
段。このプロセスは、旧い暗号アーティファクト（暗号
データ、ディジタル署名、及びメッセージの要約等）を
一層強力なアルゴリズム及び／又は一層長いキーを用い
て再エンコードすることを伴なうものである。

【００１８】文書： 文書は、電子的又は光学的に提示
可能な任意の情報（例えば、任意のビットストリーム）
とすることが可能である。

【００１９】キー劣化／アルゴリズム劣化： キーに基
づく暗号化により文書に付与された保護の有効性が時間
の経過と共に失われてゆくプロセス。例えば、計算速度
の向上及び暗号解読の飛躍的な進歩等に起因して、今日
では確実に暗号化されている文書が数年後には解読可能
になることが予測される。この特性は、ディジタル署名
を含めたあらゆる暗号情報に影響を及ぼし得るものであ
る。この問題は、単方向ハッシュアルゴリズムといっ
た、キー式及び非キー式の暗号化プロセス及びアーティ
ファクトに一般化される可能性がある。これらにより提
供されるセキュリティは、やはり時間と共に弱体化する
ことが予測される。

【００２０】ＬＴＳＶ： 長期署名検証。かかる検証に
用いられる認証の満了後にディジタル署名の検証を行う
ための本明細書に記載の方法及び装置。

【００２１】ＬＴＳＶクライアント： ＬＴＳＶサーバ
のサービスを要求／利用するエンティティ。

【００２２】ＬＴＳＶサーバ： ＬＴＳＶサービスを提
供するエンティティ。ただし、これは、該エンティティ
が独立したコンポーネントでなければならいことを意味
するものではない。

【００２３】ＬＴＳＶ提示： 将来のある時点でのディ
ジタル署名の再検証を可能にするために必要な機能（例
えばＰＫＩ状態のセーブ）を実行するための、ＬＴＳＶ
クライアントからＬＴＳＶサーバへの要求。

【００２４】ＰＫＩ： 公開キーインフラストラクチ
ャ。文書にディジタル署名及び検証を行う能力を提供す
るために必要な全てのコンポーネント、プロトコル、ア
ルゴリズム、及びインターフェイスを称するものであ
る。本明細書では、分かりやすくするため、ＰＫＩに
は、長期署名検証のためのサービスモジュール（ＬＴＳ
Ｖサーバ）が含まれていないが、実際には、ＰＫＩは、
かかるモジュールを包含するように設計される可能性が
ある。

【００２５】署名再検証： 当初の検証後におけるディ
ジタル署名検証プロセスの再生。これは、特に、以前に
セーブされたＰＫＩ状態の復元に基づく検証プロセスに
関連するプロセスを表している。

【００２６】署名検証： 所与の文書についてのディジ
タル署名が真正であるか否かを判定するプロセス。

【００２７】署名検証モジュール： ディジタル署名の
検証を実行する責務を負うモジュール。

【００２８】タイムスタンプ： ディジタルタイムスタ
ンプは、現在の日時と特定の文書とを関連づける電子標
識である。タイムスタンプは、特定の時点における文書
の存在を立証するのに有用なものである。タイムスタン
プは、安全で、経時的な永続性を有し、その利用者に信
用されるものであることが望ましい。

【００２９】本明細書における論述は、公開キー、ディ
ジタル署名、及びX.509認証を利用したＰＫＩインフラ
ストラクチャについて理解されていることを仮定したも
のである。かかる技法の適用に関する実際の情報につい
ては、当業者には周知のところであると考えられる。本
発明の背景となる情報については、例えば、B．Schnie
r，Applied Cryptography：Protocols，Algorithms，a
nd Source Code inC，John Wiley ＆ Sons，In
c，（1996）；W．Ford，M．Baum，Secure Electronic
Commerce，Prentice Hall PTR（1997）；及び、X.5
09 v.3規格（［X．509−AM］ISO／IEC JTC1／SC21，D
raft Amendments DAM4 to ISO／IEC9594−2，DAM2
to ISO／IEC9594−6，DAM1 to ISO／IEC9594−7，
及び、DAM1to ISO／IEC9594−8 on Certificate Ex
tensions，1996年12月1日）に見ることができる。本明
細書に解説の本発明は、X.509インフラストラクチャに
基づいて構成することが可能なものである。

【００３０】以下の説明は、暗号技術に関する背景を提
供するものである。暗号アルゴリズムは、一般に、２つ
のカテゴリ、即ち、公開キー（例えばRSA）と秘密キー
（例えばDES）とに分けることができる。両タイプのア
ルゴリズムとも、暗号化及び暗号解読プロセスのための
キーを利用して普通テキストを暗号文へと変換する。

【００３１】公開キー及び秘密キーアルゴリズムは、両
方とも安全であるとみなされている。セキュリティの点
で、一方は他方ほど有効ではない。解読されるという点
で、各アルゴリズムの強度は、主として、用いられるキ
ーの長さの関数となる。しかし、公開キーを特徴づける
主たる特性は、２つのキー（１つは暗号化用のキー、も
う１つは暗号解読用のキー）を用いる点にあるが、秘密
キーアルゴリズムは、１つのキーしか用いない（同じキ
ーが暗号化と暗号解読とに用いられる）。このため、秘
密キーアルゴリズムが対称アルゴリズムと呼ばれ、公開
キーアルゴリズムが非対称アルゴリズムと呼ばれる場合
がある。

【００３２】秘密キーアルゴリズムに関する１つの問題
点として、全ての関係者間でキーを分配しなければなら
ないことがある。これは、安全なチャネルの幾つかをキ
ーの分配のために利用可能にしなければならないことを
意味している。

【００３３】実際には、公開キーベースのシステムにお
ける各エンティティは１つのキー対（即ち１つの個人用
キー及び１つの公開キー）を備えている。個人用キーは
その所有者だけしか知らないが、公開キーは全ての関係
者に知られている。公開キーから私用キーを判断するの
は計算上実行不可能である。

【００３４】公開キー暗号により提供される２つの主な
サービスは、対称キーの安全な交換サービス（公開キー
技術を用いて対称セッションキーを暗号することによる
もの）とディジタル署名を介した非否認サービスであ
る。

【００３５】公開キー暗号を用いて秘密キーアルゴリズ
ムに関するキー交換の問題を解決することができる。こ
れは、該技術を用いて受信者の公開キーに基づき秘密キ
ーを暗号化することにより達成される。次いで、受信者
は、自分自身の個人用キーを用いてそれを解読すること
ができる。

【００３６】ディジタル署名は、署名エンティティの個
人用キーを用いてデータを暗号化することにより可能と
なる。あやゆるエンティティは、署名者の公に利用可能
な公開キーを用いてその解読を行うことが可能であり、
その個人用キーを知るのはその一個人だけであるため、
他にその暗号化を行い得たものがないことを知ることが
できる。公開キーのこの特定の用法によって、公開キー
暗号の主たる用途である無否認サービスが提供される。
ディジタル署名は、極めて強力な概念であり、一般に
は、下記の特性を示すものとなる。

【００３７】偽造することができない。

【００３８】個別に検証可能である。

【００３９】異なるデータに再利用又は転写することが
できない。

【００４０】データの完全性のチェックが含まれてお
り、改ざんの検出が可能となる。

【００４１】しかしながら、公開キー暗号手法により提
供される新たなサービスは無料にはならない。これは、
かかるサービスが、支えとなる公開キーインフラストラ
クチャの存在を必要とするからである。公開キーシステ
ムの効力は、全ての関係者が、通信を望むエンティティ
の公開キーを確実に知っているか否かで決まる。ユーザ
と該ユーザの公開キーとの確実な対応が維持できない場
合には、別のエンティティに扮することや別のエンティ
ティのために意図された暗号データを読むことが可能に
なってしまう。

【００４２】この問題の標準的な解決法は、各関係者に
対するディジタル認証（X.509認証）の発行である。こ
の認証によって、公開キーとその所有者の名前とが確実
に連結される。該認証は、認定権威者（ＣＡ : Certifi
cation Authority）と呼ばれる信用ある第三者により発
行され、該ＣＡによる署名がなされ、これにより改ざん
が防止される。認証は、該認証が有効であると考えられ
る限られた期間（開始日及び終了日）に関して発行され
る。認証は、その有効性の終了日の後には満了したもの
とみなされる。

【００４３】エンティティの公開キー（X.509認証に埋
め込まれている）は、公に利用可能でなければならな
い。利用可能な分配機構又はアクセス機構は多数存在す
る。

【００４４】公開キーインフラストラクチャの保全機能
は、幾つかの信用の上に成り立つものである。各エンテ
ィティは、それ自体のＣＡを必ず信用しなければならな
い。しかし、多数のＣＡとの関係を包含するように所与
のＰＫＩ領域を拡張する場合には、信用の数も拡大しな
ければならない。特定のエンドエンティティにおかれる
信用（即ち、該エンティティの認証又は署名）は、それ
らのエンティティを認定するＣＡ間の信用関係に直接関
係する。

【００４５】ＣＡは、互いに認定することによって他の
ＣＡとの信用関係を創り出すことが可能である。これ
は、単一方向の信用関係とすることが可能であり、この
場合には、ＣＡがエンドユーザに認証を発行するのと全
く同じように１つのＣＡが別のＣＡに対して認証を発行
するだけである。また、２つのＣＡが、相互認証（各方
向に１つずつ２つの別個の認証を含む特殊な形式の認
証）を発行することにより、相互に信用すること（双方
向信用関係）に互いに同意することも可能である。

【００４６】２つのエンティティが同じＣＡ領域内にあ
る場合には、両者とも同じＣＡを信用しているため、Ｃ
Ａの信用については心配はない。しかし、これは、異な
るＣＡにより認定されたエンティティが安全な取引の実
施を試みるシナリオを取り扱う場合には当てはまらな
い。該取引のセキュリティは当該ＣＡ間の信用によって
決まる。より一般的には、ＰＫＩにより提供されるセキ
ュリティは、互いに信用することを選択した異なるＣＡ
間の信用関係により実施された信用モデルによって決ま
る。具体的には、これらの信用関係の変化によっては、
署名の検証が成功する場合もあれば失敗する場合もあり
得る。

【００４７】本発明によれば、ディジタル署名を検証で
きる期間を有効に延長する（即ち、該署名が依存する認
証の何れか又は全ての満了時期を十分に超えて延長す
る）方法及び装置が提供される。本発明は、ユーザが、
長期にわたり存続する文書（例えば契約書）に対するデ
ィジタル署名の使用を所望し、及び該文書の署名後数年
又は数十年にわたり該ディジタル署名の個別の検証が可
能であることを所望する適用領域に用いることが可能で
ある。本発明の好適実施例によれば、長期署名検証（Ｌ
ＴＳＶ）を提供する解決法を構成するための２つの代替
的な手法が提供される。

【００４８】図２は、本発明の「状態セーブ」実施例を
示す概略的なブロック図である。該実施例では、本発明
は、暗号情報及び技術の利用を大いに必要とする。従っ
て、アーカイブ機構20を用いて、ソース文書自体に加
え、公開キーインフラストラクチャ（ＰＫＩ）状態24
（例えば認証及びＣＲＬ等の暗号情報）が記憶される。
例えば、ＬＴＳＶクライアント25は、かかる情報の記憶
を達成するためにＬＴＳＶサーバ26のサービスを要求す
る。該ステップを図２の「状態セーブ」ステップとして
示す。ＰＫＩ状態情報は、認証及びＣＲＬ等の暗号によ
って保護された情報と、ルート認定権威者の公開キー又
はポリシー情報等の暗号によって保護されていない情報
との一方又は両方を含むことが可能である。

【００４９】この情報は、後に（即ち（例えばＬＴＳＶ
クライアントにより要求される）「状態復元」ステップ
時に）署名検証プロセスの再生に必要となる全てを構成
するものとなる。プライバシー上の理由から、暗号情報
（署名、認証、及びＣＲＬ等）とは別個にソース文書を
記憶することが望ましい場合もある。例えば、ユーザが
ソース文書の管理を所望する場合がある。

【００５０】ユーザが（おそらく数年後に）文書の署名
の再検証を所望する場合には、ＬＴＳＶサーバ26は、該
文書が最初に提出された時点におけるＰＫＩの正確な状
態を再生する。ＬＴＳＶサーバは、その状態を復元し、
数年前に実行された（又は実行されたと考えられる）プ
ロセスが署名検証プロセス28によって正確に実行され
る。署名検証プロセスを再生するためのベースとして用
いられる時間は、提出された時間である必要はない。そ
うではなく、該時間は、文書に発信者による署名がなさ
れた時間又は受信者がその検証を行った時間といった他
の何らかの関連する時間とすることが可能である。

【００５１】図３は、本発明の「状態セーブ」、「記憶
保全」実施例を示す概略的なブロック図である。この本
発明の実施例は、暗号の効力と、現時点でのデータ記憶
保全に関連する（非公開キー）技術及び手順の立証され
た障害許容力とを組み合わせたものである。その一実施
例は、(図２に関連して解説したように)将来の再検証に
備えてＰＫＩ状態をセーブし、ファイアウォール、アク
セス制御機構、監査機構、侵入検出機構、物理分離、及
びネットワーク分離といったサービスによって保護され
る記憶保全機構中にＰＫＩ状態情報を維持し、及び／又
は、（例えばＬＴＳＶサーバを利用してＰＫＩ状態情報
に署名し又はキー式ハッシュアルゴリズムを利用した）
暗号保護機構を用いることにより、ＰＫＩ状態情報を侵
入から保護する。

【００５２】更に、かかる手法に他の非暗号機能（例え
ば、ＰＫＩ状態情報（暗号並びに非暗号）の参照及びシ
ステムのセキュリティの視覚的な監視を行うためのユー
ティリティ30を含む）を追加して、保全性及び信用性の
高いＬＴＳＶ解決法を提供することが可能である。かか
るユーティリティを利用することにより、問題点を解決
するための視覚的な証拠を提供することができる。

【００５３】本明細書に開示の記憶保全手法を強化する
ことにより、認証連鎖等の所定の証拠がアーカイブ中に
維持される。この情報は、実際の再検証に用いる必要は
なく、疑問視される場合に支えとなる証拠として単に用
いられるものである。（既述の）公証サービスに関連し
て該強化を実施することが可能な態様については、A．M
enezes，P．van Oorschot，S．Vanstone，Handbook o
f Applied Cryptography，CRC Press，pp．583（199
6）を参照されたい。

【００５４】暗号及び非暗号技術を組み合わせることに
よりハイブリッドＬＴＳＶ解決法を構成することが可能
な本発明のもう１つの実施例が存在する。特定の適用領
域に関する最良の組み合わせは、当該適用例のセキュリ
ティ要件とコスト上の制約との組み合わせよって決ま
る。

【００５５】現在のところは、完全なディジタル署名検
証プロセスを再生する能力に関する暗号の効力に基づく
本発明の（上述の）第２の実施例と、記憶保全を提供す
るために用いられる従来の技術により植え付けられる信
用とを組み合わせ、証拠の参照及び記憶保全管理の監視
を行うための監査及び参照機構に関連して用いるのが望
ましい。実際、特定の用途に関する本発明の最も有用な
実施例は、最低コストでユーザ又は用途上の要件を満た
すものとすることが可能なものである。

【００５６】ＬＴＳＶを実施したシステムの設計に関す
る幾つかの問題について以下に述べる。問題を解決する
ための代替案を提示し、並びに各代替案に関する利点及
び欠点について述べる。問題解決のための如何なる最良
の手法も、ＬＴＳＶサービスを利用する用途のセキュリ
ティ要件並びにコスト上の制約によって決まる。全ての
用途にとって最良の解決法というものは存在しない。

【００５７】ＰＫＩ状態のセーブ時期 署名の再検証は特定の時期と関連づけることが望まし
い。これは、そのプロセスの結果がＰＫＩ状態によって
（例えば認証の取り消し又は相互認証の作成／削除のた
めに）変化し得るからである。ＰＫＩ状態をセーブすべ
き時期については下記を含めて多くの可能性が存在す
る。

【００５８】● 署名作成時。この手法は、個人が署名
の作成時に該署名の妥当性を立証したい場合に利用され
る。これは、おそらくはＰＫＩ状態を記憶するための最
も間違いのない時間である。その理由は、該記憶された
ＰＫＩ状態が、署名の信憑性を評価する場合の決定的な
時間であると考えられる署名時における状態を反映する
ものとなるからである。この時点以降、ＰＫＩ状態に変
化が生じることになり、該変化の中には署名再検証の結
果に影響を及ぼし得るものがある。従って、署名後の如
何なる時点でＰＫＩ状態をセーブしても、署名の妥当性
について署名者から見たものと受信者から見たものとの
間に不一致が生じる可能性がある。

【００５９】● 署名検証時。この手法は、受信者が、
別の個人から受信した署名付き文書の妥当性を立証した
い場合に有用である。

【００６０】● 保存（アーカイブ）時。文書を長期記
憶のため保存すべきであるとユーザが決定した時も、Ｐ
ＫＩ状態のセーブに適した時期である。

【００６１】● 明示的に要求された時。一定の用途に
特有の文書のライフサイクルが重大な時期を迎える場合
があり、該時点において、ユーザが将来の再検証に備え
てＰＫＩ状態のセーブを所望する可能性がある。

【００６２】● ＰＫＩ状態の変更（例えば認定証の取
り消し）の直前。この手法では、ＰＫＩの変化が監視さ
れなければならないため、ＰＫＩとの緊密な結びつきが
必要とされる。

【００６３】ＰＫＩ状態をセーブすべき正しい時間は、
好適には、ＬＴＳＶサービスを用いて当該用途の制約及
び要件によって決定する。ローバストな（robust:頑強
な）ＬＴＳＶによる解決法は、これを考慮して全ての
（又は大部分の）用途の要求に適応することが可能であ
る。

【００６４】ＰＫＩ状態の内容ＰＫＩ状態の正確な構成
は、各ベンダにより選択される実施態様に応じて該ベン
ダの製品毎に多少異なる。更に、情報によってはベンダ
毎に異なるフォーマットで記憶されるものがある。更
に、システムに新たな能力（及び支えとなるデータ）を
追加する際に、ＰＫＩ状態の内容が時間の経過につれて
変化する可能性もある。最後に、必要とされるＰＫＩ状
態の内容は、各用途の要件（例えばセキュリティのレベ
ル及び法的要件）に応じて各用途毎に変化する可能性が
ある。

【００６５】かかる不確定性にもかかわらず、セーブの
候補となるＰＫＩ状態情報のクラスが存在する。これら
のクラスには以下のものが含まれる。

【００６６】● 認証連鎖（認定権威者（ＣＡ）及びエ
ンドエンティティを含む、１つのエンティティからもう
１つのエンティティへの認証のリスト） ● ＣＲＬ（認証連鎖における各ＣＡ毎に１つずつ存在
する） ● ＣＡポリシー陳述又は識別子 ● 属性認証 ● 日時 ● 信用情報（例えば、信用あるルートＣＡの公開キー
又は認証、ポリシー制約） ポリシー制約は、例えば、ＬＴＳＶアーカイブ内に記憶
された非暗号情報である。信用あるルートＣＡの公開キ
ーは、暗号によって保護されていてもいなくてもかまわ
ない。公開キーが認証中に埋め込まれている場合、該公
開キーはＣＡにより署名される。しかし、分離された公
開キーとすることも可能であり、この場合には、暗号に
よって保護されることはない。

【００６７】上記リスト中の項目は、ＰＫＩの実施態様
によってはサポートされず又利用できない可能性があ
る。更に、別の実施態様でのＰＫＩ状態には、何らかの
追加のデータが含まれる可能性がある。従って、上記リ
ストは、技術の現状を考えた場合にＰＫＩ状態情報の重
要な部分と考えることが可能なものの一例に過ぎない。
技術が進化し総括的な基準が登場する時点まで、ＬＴＳ
Ｖサービスの実施態様を特定のＰＫＩの実施態様と結び
付けることが望ましい。

【００６８】ＰＫＩ状態の記憶方法 ＰＫＩ状態の記憶は、下記の２つの一般的な方法の何れ
かで実施することが望ましい。

【００６９】● 各文書に別個に関連するＰＫＩ状態の
全てを記憶する。

【００７０】● ＰＫＩ状態を中央に記憶し、及びＰＫ
Ｉ状態情報への参照のみを各文書と共に記憶する。この
手法では、多数の文書にわたるＰＫＩ状態情報の冗長な
記憶が排除されて記憶効率が改善される。例えば、ＬＴ
ＳＶサーバに対して２つの文書がほぼ同時に提示された
場合、ＰＫＩ状態に含まれるＣＲＬは両方の提示につい
て全く同じである。この情報を中央に記憶するというこ
とは、ＬＴＳＶサーバが該情報を１度しか記憶しないこ
とを可能にするものである。

【００７１】ＬＴＳＶに関する状態セーブ解決法に関す
る記憶要件は、認証のサイズ、認証連鎖の長さ、及び
（更に重要には）ＣＲＬのサイズに応じて、極めて大き
なものとなり得る。記憶技術の選択は全体的なデータ記
憶要件に大きく影響し得る。長期保存及び考え得る将来
の再検証のために記憶されるあらゆる文書と共に膨大な
ＣＲＬを記憶するのは、明らかに望ましくない。このた
め、上述の第２の代替案が、現在のところ望ましい手法
であると考えられる。

【００７２】しかしながら、この第２の手法は、ＬＴＳ
ＶサーバがＰＫＩから完全に独立したコンポーネントと
なる用途、及び、多数のＰＫＩのサポートがＬＴＳＶサ
ーバの主たる設計目標である用途の場合には、幾つかの
問題を呈する可能性がある。かかる場合、ＬＴＳＶサー
バに対してＰＫＩ状態を不透明な状態に(opaque)維持す
ることが有利であり、これにより多数のＰＫＩベンダの
サポートが容易になる。１つのベンダにとってＰＫＩ状
態を構成するものが別のベンダにとっては異なるものと
なる可能性がある場合には、ＬＴＳＶサーバとＰＫＩと
の間に不透明なインターフェイスを維持することが望ま
しい。一方、記憶効率を改善することができるのは、Ｐ
ＫＩ状態情報の内容及びフォーマットがＬＴＳＶサーバ
に知らされる場合に限られる。これら矛盾する要件（許
容可能な記憶サイズと不透明性）により、ＬＴＳＶサー
ビスの設計に難問が課せられることになる。

【００７３】考え得る幾つかの代替案を以下に列挙す
る。

【００７４】● インターフェイスを不透明に保ち、現
在存在する状態でＰＫＩ状態（完全な認証連鎖及びＣＲ
Ｌ）を記憶する。このオプションは、不透明性の要件に
全焦点を合わせ、データサイズの要件を犠牲にしたもの
である。この解決法の主たる利点は、その単純さと迅速
な配置にある。

【００７５】● ＰＫＩ状態がＬＴＳＶサーバに見える
ようにして不透明要件を除去する。これにより、ＬＴＳ
Ｖサーバが認証及びＣＲＬをマニュアルで管理すること
が可能になり、その結果、データ記憶におけるこれらオ
ブジェクトの重複が回避される。この解決法は、効率の
良い記憶の達成と引き換えにマルチベンダのサポートの
容易さを潜在的に犠牲にするものとなる。

【００７６】● 他のＰＫＩ状態情報が不透明な場合に
ＬＴＳＶサーバにＣＲＬが見えるようにして妥協する。
この解決法は、ＣＲＬがＰＫＩ状態を構成するデータの
最大の部分である可能性が高いため、興味深いものとな
る。ＣＲＬは、ほぼ全てのＰＫＩにわたり標準的なもの
であるため、該可視性によってマルチベンダサポートに
関する問題が生じてはならない。この解決法は、両方の
要件を取り扱うものであるが、ＣＲＬの管理という重荷
をＬＴＳＶサーバに負わせるものとなる。

【００７７】● 本発明の代替実施例により、各々が不
透明な多数の部分へとＰＫＩ状態を分割する、上記解決
法の変形例が提供される。ＰＫＩは、これらオブジェク
トのうちのどれが多数の署名付き文書に対して共通であ
るかを示す（例えばＣＲＬ及び認証）。ＰＫＩは、これ
らのオブジェクトに一意のハンドル（識別子）でラベル
付けし、これにより、ＬＴＳＶサーバが、それらオブジ
ェクトを記憶し、及び署名の再検証が必要な場合に効率
よく読み出すことが可能になる（その間中、それらオブ
ジェクトの不透明性が維持される）。

【００７８】● ＣＲＬを用いることの代替策として暗
号により保護された取り消し状態に関する簡潔な表明を
行うことをＰＫＩベンダに奨励する（例えば、取り消さ
れた者をＣＲＬが示す。ＰＫＩが、或る認証が所与の時
点で取り消されていないことの陳述を行うことができれ
ば一層効率的である。これにより、ＣＲＬを記憶する必
要性をなくすことが可能となる）。この手法は、標準的
なものではないが、許容可能なものである。これは、こ
れらのＰＫＩにより生成される表明がＰＫＩ以外のアプ
リケーションから見えないからである。この手法の主た
る利点は、状態の不透明性が保持されると共に、状態情
報の記憶の非効率性が幾つか除去されることにある。

【００７９】ＬＴＳＶサーバが特定のＰＫＩ専用のもの
である場合には、２つのコンポーネント間に緊密な結び
つきを生成し、これにより、ＬＴＳＶサーバがＰＫＩ状
態情報の内容及びフォーマットについて知り、及びそれ
を考え得る最も効率的な態様で記憶することを可能にす
ることが望ましい。（例えば複数のＰＫＩにわたる可搬
性のために）ＬＴＳＶサーバをＰＫＩから分離させなけ
ればならない場合には、上記選択肢の内の１つ（おそら
くは最初の２つを除く）を利用することが可能である。

【００８０】ソースデータの場所 ＬＴＳＶの提示に関連するソースデータは、クライアン
ト又はとＬＴＳＶサーバ自体の何れかによって記憶する
ことが可能である。ＬＴＳＶクライアントの中には、プ
ライバシーを懸念して、記憶のためにＬＴＳＶサーバに
明確なテキストを提示する選択をしないものもある（Ｌ
ＴＳＶクライアントとＬＴＳＶサーバとの間におけるチ
ャネルのプライバシーは、クライアントに、ＬＴＳＶサ
ーバの公開キーに基づき提示を暗号化させることによ
り、達成することが可能である）。ＬＴＳＶへの提示
は、該ＬＴＳＶが解読できないように暗号化することが
可能である。これは、ＬＴＳＶサーバにとって許容可能
なことである。しかし、クライアントは、提示の解読方
法を判定しなければならない。

【００８１】ＬＴＳＶサーバがソースデータをビットス
トリームとして見る場合、当該メッセージをその提示前
にＬＴＳＶクライアントにより暗号化することが可能で
ある（汎用ＬＴＳＶサーバがソース文書をビットストリ
ームとして扱うという事実は、提示されるデータの内容
を知っている特定用途ＬＴＳＶサーバが実施される可能
性を排除するものではない）。ＬＴＳＶサーバは、暗号
化されたデータをソースとして扱う。かかる先行技術に
よる符号化は、用途によってはプライバシー上の必要性
を十分に満たす場合もある。しかし、この場合には、ク
ライアントが解読キーを維持しなければならず、又はＬ
ＴＳＶサーバによってキーが明らかにされて記憶されな
ければならない（これはおそらく許容不能である）。

【００８２】代替案として、ＬＴＳＶクライアントが
（単方向ハッシュ機能の結果として生じる）メッセージ
の要約をソース文書として提示することが可能である。
この場合、クライアントは、実ソース文書を維持する責
務を負う。ソース文書がクライアントによって記憶され
る場合には、ＬＴＳＶサーバのアーカイブには（ソース
文書に対する参照又は提示者と共に）ＰＫＩ状態情報の
みが記憶される。

【００８３】ソースデータがクライアントとＬＴＳＶサ
ーバとの何れによって記憶されるかにかかわらず、文書
の再検証が必要な場合には該ソースデータが生成されな
ければならない。ソースデータは署名検証プロセスで必
要とされる構成要素である。

【００８４】キー及びアルゴリズムの劣化 暗号によって符号化された情報（例えばディジタル署名
又は暗号化データ）がかなりの期間にわたり記憶されて
いた場合には、キー及びアルゴリズムの劣化に関する問
題（即ち暗号キー又はアルゴリズムの有効性の考え得る
経時的な損失）に対処しなければならない。署名付き文
書は、強力な暗号アルゴリズムにより確実に保護される
ことが期待されるが、アルゴリズム及び該アルゴリズム
と関連するキーの長さの効力は、コンピュータの高速化
及び暗号解読の新たな発展により時間の経過と共に低下
する。暗号アルゴリズム及びキーの長さには、限られた
有効期間があると考えられる。一般に認められているよ
うに、それらは、定期的な間隔で、検査、修正、及び／
又は置換が行われることが望ましい。この妥当なセキュ
リティに関する懸念は、文書が有効となる期間が長くな
るにつれて大きくなり、該有効期間が数十年に近づくと
極めて深刻なセキュリティ上の脅威となる。

【００８５】例えば、RSA及び512ビットキーを利用して
今日実施されているディジタル署名は、極めて強力なも
のと考えられる（即ちその捏造には数年を要するであろ
う）。しかし、この署名は、10年も経たないうちに簡単
に捏造できるようになる可能性もある。これは、新型の
コンピュータ又は計算技術を用いて、キー空間を一層速
く探索する（これによりメッセージの署名に用いられた
キーを見つけ出す）能力が向上するためである。同様
に、大きな素数を因数分解する技術が発展を続ける可能
性がある（その困難がRSAアルゴリズムの効力の根拠と
なっている）。これらの能力は両方とも時間の経過と共
に改良されると考えるのが妥当である（ただし、これら
変化のペースについては定かではない）。

【００８６】従って、暗号によって符号化された文書が
数年を超えて存続しなければならない場合には、該文書
を上記脅威から保護することが賢明である。これは、Ｌ
ＴＳＶサーバに提示されると予想される文書にも該当す
ることであり、本明細書に開示の状態セーブ手法を用い
る場合には特に該当する。従って、ＬＴＳＶ機構は、こ
の問題に取り組むべきである。アーカイブに記憶される
署名付き文書が該脅威から保護されなければならないだ
けでなく、アーカイブに記憶される他の全ての暗号デー
タ又はメタデータも保護されるべきである（暗号データ
には、主にキー付き情報、即ち、個人用キーに基づき署
名又は暗号化された情報が含まれている。かかる情報は
また、MD5等のハッシュアルゴリズムからの出力といっ
た非キー付き暗号データを含むことが可能である）。該
データはまた、発行元のＣＡによりディジタル署名が行
われた認証及びＣＲＬ等の項目を含むことが可能であ
る。

【００８７】ＬＴＳＶ機構がこの問題を取り扱う方法が
幾つか存在する。その例を以下に示す。

【００８８】● 暗号リフレッシュの必要がある場合に
ネスト式署名を利用して全てのデータに定期的に副署を
行う。該手法では、ＬＴＳＶサーバは、数年毎に一層長
いキー（又は一層強力なアルゴリズム）を順次用いて署
名を行うことにより、データの暗号効力を有効にリフレ
ッシュする。各副署は、包含される署名の暗号の効力を
ロックする(lock in)効果を有しており、これにより、
包含される文書の暗号の有効期間が延長される。この副
署は、ＬＴＳＶサーバの所有するキーを用いて該ＬＴＳ
Ｖサーバにより実施されるのが望ましい。再検証時にお
ける高コストの署名の解明、又はアーカイブ中の全ての
文書に副署を行うという潜在的に時間を浪費するタスク
を回避するために、簡便な実施方法が必要になる可能性
がある。かかる簡便な方法のとしては、新たな副署を行
う前に以前の副署を除去し、又は個々の各文書の代わり
にアーカイブ全体若しくはその一部に副署することが挙
げられる。

【００８９】● 上述の暗号手法を修正することによ
り、極めて長いキー（即ち、数十年以上にわたって解く
ことができないと考えられるキー）を用いて、アーカイ
ブ中の情報に一度だけ副署を行うことが可能になる。こ
れにより副署の必要が全くなくなる。これは単なる理論
的な解決法にすぎない可能性がある。これは、かかる長
期にわたり保全されるアルゴリズム及びキーの長さが見
つかることを予測することは不可能だからである。従っ
て、例えば、独自のアルゴリズムが解明された(crack)
場合に備えて、何らかのバックアップ機構を設けること
も必要性が依然として存在する。

【００９０】● アーカイブ中に含まれる個々の文書で
はなくアーカイブ自体を分離することによってアーカイ
ブの暗号情報を保護し、これにより、暗号による解決法
の必要性がなくなる。この手法では、アーカイブは、ア
クセス制御その他の手順制御を介して保護される。アー
カイブを侵入及び修正から有効に分離することができる
場合には、キーの劣化は問題ではなくなり、暗号リフレ
ッシュは不要になる。

【００９１】● タイムスタンプ機構を用いて時間に関
して暗号情報に捺印する。かかる機構は、キーの劣化の
問題の解決に必要とされる全ての特性を提供するものと
考えられている。このタイムスタンプ機構は、上記の技
術のうちの１つを用いることが可能であり、また独立し
たサービスとすることも可能である（タイムスタンプに
関する説明については以下を参照されたい）。

【００９２】タイムスタンプとの関係 安全で広範なＬＴＳＶ解決法は好適にはタイムスタンプ
機構を伴なうものとなる。ディジタル署名の長期検証の
ためには、特定の事象が生じた時点（例えば、署名時又
は署名の検証時）を知って該時点で文書が有効であった
か否かを判定することが必要になる場合が多い。文書の
署名時に関して疑問がある場合、その署名時が不明確で
あるが故に、後の文書の再検証が疑わしいものになる可
能性がある。

【００９３】図４は、本発明に対するタイムスタンプの
適用可能性を示す２つの代替的なシナリオを示すフロー
チャートである。

【００９４】シナリオ１： ● アリスが時刻T1で文書に署名し、それをボブに送信
する（140）。

【００９５】● アリスの認証が、時刻T2で取り消され
る（142）。

【００９６】● ボブが時刻T3でアリスの署名を検証す
る（144）。

【００９７】シナリオ2： ● アリスの認証が時刻T1で取り消される（150）。

【００９８】● アリスが時刻T2で文書に署名し、それ
をボブに送信する（152）。

【００９９】● ボブが時刻T3でアリスの署名を検証す
る（154）。

【０１００】ボブは、（時刻T3で）検証を行う場合に、
該文書にアリスが署名したときを知らない。これは重大
なことである。なぜなら、アリスのキー（認証）がメッ
セージの署名前に取り消された場合には、ボブによる署
名の検証が失敗することになり、ボブはそのメッセージ
の内容を信用すべきでないからである。一方、署名の実
施後に取り消された場合には、該署名は有効であり信用
に値すると考えることができる。分かりやすくするた
め、この例では、ＣＲＬの遅延に関する複雑な問題（即
ち、認証の取り消しの開始時とこの情報がＣＲＬ上で利
用可能になる時点との間の時間）については考慮してい
ない。

【０１０１】この例は、ディジタル署名の領域における
安全で信頼のおけるタイムスタンプ機構の必要性を証明
するものである。ディジタル署名が生成された現在の日
時を単に記録するだけでは、ほとんどの用途で不十分で
ある。これは、受信者がその時間のソースを信用するこ
とができないからである。しかし、その影響は、ディジ
タル署名の短期の署名検証プロセスだけでなく長期検証
にも及ぶものとなる。上述の例を仮定すると、ＬＴＳＶ
サーバは、シナリオ１又はシナリオ２（又はそれらの両
方）に関連するＰＫＩ状態を（時刻T1で）セーブするこ
とが可能である。数年後における該メッセージに関する
署名検証の結果は、この検証プロセスに用いられたＰＫ
Ｉ状態並びに該検証のための目標時間による影響を大き
く受けるものとなる。

【０１０２】上記で強調した問題は、ＬＴＳＶサービス
が時間の認識力のあるものであるべきことを例証するも
のである。即ち、● 文書が最初に署名された時点を確
実な態様で判定することができ、● 過去の目標時間に
おいてアクティブであったＰＫＩ状態を正確に再生する
ことができ、● 現在の日時を正確に判定することがで
き、及び、● 最低でも特定の目標時間に関連するＰＫ
Ｉ状態をセーブできるべきである。

【０１０３】これらの要件により、署名及び検証（及び
再検証）プロセスにタイムスタンプ機構を結び付けるの
が望ましいことが確立される。また文書の署名時に、該
事象が生じた正確な瞬間を確実な態様で文書にタイムス
タンプすることも望ましい。ＬＴＳＶサービスは、ＰＫ
Ｉ状態をセーブすべき時間を知り、適当な状態（目標時
間でのアクティブな状態）を確実にセーブし、及び、署
名の再検証プロセスを正しい時間に関して実行すべきで
ある。

【０１０４】シナリオの使用 図５(a)〜(c)は、本発明による３つの長期署名検証に使
用するシナリオを示す概略的なブロック図である。

【０１０５】シナリオ１では、クライアント（エンティ
ティA）50が、長期署名検証のためにＬＴＳＶ機構52に
文書を提示する。これは、幾つかの情報を有しているこ
とを文書に記録することにエンティティAが関与する単
純な場合である。

【０１０６】シナリオ２では、エンティティB56が、エ
ンティティA54から文書を受信し、該文書をＬＴＳＶ機
構58に提示する。この場合、エンティティBは、エンテ
ィティAから情報を受信したことを文書に記録すること
を所望する。

【０１０７】シナリオ３では、エンティティA60がエン
ティティB64とＬＴＳＶ機構62とに同一の文書を送信す
る。この場合にはカーボンコピー機構が提供され、これ
により、エンティティAが、エンティティBに送信した情
報を更にＬＴＳＶ機構に提出することにより、該情報を
文書に記録することができる。

【０１０８】上述の各シナリオは、暗号化、個人用キー
アクセス、及び、信用モデルに関して問題を呈するもの
となる。

【０１０９】暗号化及び個人用キーアクセス 文書は、暗号化及び／又は署名を行うことが可能であ
る。理想的には、ＬＴＳＶ機構は、かかるあらゆる文書
を受容するものとなる。しかしながら、これにより、Ｌ
ＴＳＶモジュールが暗号化に関していかなる働きをする
かについて問題が生じる。公開キーシステム下で暗号化
を行う場合には、文書は受信者の公開キーに基づき有効
に暗号化され、これにより、受信者（対応する個人用キ
ーの所有者）がその情報を解読できる唯一のエンティテ
ィであることが保証される（この説明のため、対称キー
及びアルゴリズムとの相互作用については無視すること
とする）。

【０１１０】この原理をシナリオ１に適用する際に、署
名付きメッセージも暗号化する場合、該暗号化をＬＴＳ
Ｖモジュールの個人用キーにより行うことができること
は明らかである。これにより、ＬＴＳＶコンポーネント
が署名付き文書を解明して長期検証のために保存するこ
とが可能になる。これは、エンティティAとＬＴＳＶサ
ービスとの間に機密性を提供するものとなるため、有用
な特徴である。このシナリオは、ＬＴＳＶモジュールに
対して署名され暗号された状態で送信されたソース文書
自体をエンティティAにしか分からないキーに基づき暗
号できることを排除するものではない。即ち、ＬＴＳＶ
は、普通テキスト版のソース文書にアクセスする必要は
ない。ＬＴＳＶモジュールは、暗号化された文書をソー
スとして扱う。エンティティAは、秘密キーに基づき文
書を暗号してからＬＴＳＶサービスに該文書を提示する
ことを決定した場合には、その文書の解読が必要になっ
た場合にそのキーを保持し続ける責務を負うことにな
る。

【０１１１】シナリオ２で、エンティティAからエンテ
ィティBへのメッセージが（エンティティBの公開キーに
基づき）暗号化され、次いで変更を加えることなくエン
ティティBによりＬＴＳＶサービスへ送られた場合、Ｌ
ＴＳＶコンポーネントは該メッセージを読むことができ
ない。これは、収容された署名付き文書を解読し解明す
るのに必要な個人用キーを所有していないからである。
この解明（解読）は、ＬＴＳＶモジュールがそのジョブ
を実施するのに不可欠なものである。

【０１１２】この問題に対処するための代替案が幾つか
存在し、これを以下に示す。

【０１１３】● ＬＴＳＶ機構がエンティティBの個人
用キーにアクセスできるようにする。

【０１１４】● エンティティAがエンティティBに暗号
文書を送信できないようにする。

【０１１５】● エンティティAから受信した署名付き
の暗号化文書のプライバシー上の側面をエンティティB
に剥ぎ取らせる(strip off)。エンティティBは、文書の
エンティティAによる署名を保存して後で検証できるよ
うにしたいため、この剥ぎ取りプロセスは署名の有効性
を変えることはできない。従って、エンティティAは、
該剥ぎ取られた（即ち普通テキストの）文書をＬＴＳＶ
サービスに送ること、又は、ＬＴＳＶモジュールの公開
キーに基づき該文書の再暗号化を行う（この場合、エン
ティティAによる元の署名は依然として保存される）こ
とが可能である。

【０１１６】上記の最後の手法は、現時点での好適な手
法である。上記の最初の手法は、エンティティの個人用
キーの分配を必要とするため、重大なセキュリティ上の
問題が生じる。上記の２番目の手法は、システムの利用
に当たり許容できない制限を加えるものとなる。

【０１１７】信用 ディジタル署名の検証は、常に２つ（及び２つだけ）の
エンティティ間で実行される。該検証プロセスは、（と
りわけ）２つのエンティティ（発信者（署名者）と受信
者（検証者））間における適当な信用関係に基づくもの
である。

【０１１８】図６は、本発明による２つのエンティティ
間における信用を示す概略的なブロック図である。該状
況では、エンティティA70は、ＣＡ１ 72によって認証が
発行され、エンティティB74は、ＣＡ２ 76によって認証
が発行され、該ＣＡ１及び該ＣＡ２は相互に認証を行っ
ている（相互認証は、２つのＣＡ間の相互信用を示す特
殊なタイプの認証である）。結果的に得られる信用モデ
ルによって、エンティティAとエンティティBとの間の信
用経路が設定され、互いにディジタル署名された文書の
検証を正しく行うことが可能になる（信用モデルは、Ｐ
ＫＩエンティティ（ＣＡ及びエンドユーザ）間における
信用関係から構成され、これらエンティティ間における
認証及び相互認証、並びに該信用を付与する根拠となる
ポリシーによって具現化される）。このモデルの３つの
経路のどれかが適正でなければ、２つのエンドパーティ
間でディジタル署名付きメッセージの交換を首尾良く行
うのに十分な信用に欠けることになる。該経路中のエン
ティティのどれかに信用のおけないものがあれば、署名
検証は失敗することになる。

【０１１９】該経路は、２つのエンティティ間における
認証から構成されるため、一般に、認証連鎖と呼ばれ
る。長期署名検証についての状態セーブ手法を考慮する
と、後に署名再検証を行うためにＰＫＩ状態の一部とし
て保存しなければならないのは（とりわけ）この信用経
路全体である。更に、ＬＴＳＶ機構によって記憶される
信用経路は、信用関係がエンティティ間で異なる可能性
のある他の時点（その前又は後）ではなく、要求時に存
在する関連する信用情報を含んでいなければならない。
例えば、ＣＡ間の相互認証は、ある時点で作成されたり
除去されたりする可能性がある。これは、２つのエンテ
ィティ間の信用に影響を与え、また署名検証の結果に影
響を与える可能性がある。

【０１２０】上述のように、２つのエンティティ間に存
在する信用モデルに関連する時間は、ＬＴＳＶ機構にと
って極めて重要であるが、ＬＴＳＶモジュールがどのよ
うに働くか（特に、後の署名検証のためにＬＴＳＶコン
ポーネントにより如何なる情報が必要とされ記憶される
か）に関する問題も存在する。このため、ＬＴＳＶコン
ポーネントが含まれる場合には、それが何らかのエンテ
ィティにより（何らかの信用経路を介して）信用されて
いるか否かにかかわらず、複雑化することになる。

【０１２１】図５(a)〜(c)に示す３つのシナリオについ
て考察する。

【０１２２】シナリオ１はかなり単純なものである。関
係するのは２つのエンティティだけである。ＬＴＳＶ機
構によって記憶される信用経路は、それら２つのパーテ
ィ（エンティティA及びＬＴＳＶ）間の経路である。こ
れらのエンティティ間には信用が存在するものと仮定す
る。さもなければ、エンティティAはＬＴＳＶサービス
に要求を提示しないことになる。

【０１２３】しかし、シナリオ２は、幾つかの問題を生
じさせるものである。エンティティBがＬＴＳＶサービ
スに要求を送る場合、エンティティBが後に如何なる署
名の検証を所望するのだろうか。最も可能性が高いの
は、エンティティBが、後にエンティティAの署名の検証
を所望するということである（エンティティBは、ＬＴ
ＳＶサービスが、エンティティAからの署名付き文書の
受信時に該文書が有効であった（正当な署名が含まれて
いた）ことを文書に記録することを所望する）。これに
より、次の２つの一般的な疑問が生じる。

【０１２４】● ＬＴＳＶサービスがエンティティAに
よって信用されているかどうか。通信パーティ（エンテ
ィティAとエンティティB、及びエンティティBとＬＴＳ
Ｖ）は、それらの間で何らかの信用を育てたものと仮定
することができる。しかし、この場合には、エンティテ
ィAとＬＴＳＶコンポーネントとの間に信用が存在しな
い可能性がある。

【０１２５】● ＬＴＳＶ機構によって記憶されるべき
信用経路。ＬＴＳＶによって記憶することができる考え
得る信用経路が３つ存在する、即ち、エンティティA,B
間の経路、エンティティBとＬＴＳＶコンポーネント自
体との間の経路、及び（もし存在すれば）エンティティ
AとＬＴＳＶコンポーネントとの間の経路である。

【０１２６】図７は、本発明による長期署名検証の信用
モデルを示す概略的なブロック図である。エンティティ
B 84がエンティティA80から受信した署名付き文書をＬ
ＴＳＶコンポーネント88へ提示するシナリオ2を仮定す
ると、ＬＴＳＶは、元の署名付き文書において実施され
た信用モデル（エンティティA 80 → ＣＡ１ 82 →ＣＡ
２ 86 → エンティティB 84）をセーブすることができ
る。この署名を後に検証する場合には、エンティティA
から該文書を受信した際にエンティティBによって最初
に実施された検証プロセスが再生される。しかし、ＬＴ
ＳＶサービスによって記憶されたＰＫＩ状態が、提示者
とＬＴＳＶサービスとの間の信用経路（エンティティB
84 → ＣＡ２ 86 → ＣＡ3 90 → ＬＴＳＶ88）しか含
んでいない場合には、最初に実施されたように元の文書
の再検証を行うことが不可能となる。実際、これは、提
示者とＬＴＳＶとの間の信用経路が重要であるシナリオ
１の説明のまさに典型である。

【０１２７】以上の論述から明らかなように、ＬＴＳＶ
コンポーネントが、クライアントの要件に従って何れか
の信用経路を記憶することができることには、十分な理
由がある。

【０１２８】シナリオ２の場合には、ＬＴＳＶは、（エ
ンティティAからエンティティBへの署名付き文書を再検
証するために）エンティティAからエンティティBへのメ
ッセージに対応する信用経路を記憶する可能性が最も高
い。シナリオ１の場合には、ＬＴＳＶは、（エンティテ
ィAからＬＴＳＶへの）提示自体に対応する信用経路を
記憶することになる。

【０１２９】同様に、シナリオ３は、どの信用経路を記
憶するかついてのフレキシビリティが必要とされる事例
を表している。この場合、ＬＴＳＶ機構に対するエンテ
ィティAの提示は、そのエンティティBとの対応を再検証
すること、又は（エンティティAとＬＴＳＶとの間の）
提示自体を再検証することを意図したものである可能性
がある。実際、両方の信用経路とも、クライアントにと
って有用なものである。ＬＴＳＶに関する要件は、採用
される特定の用途の業務内容によって決まる。このた
め、ＬＴＳＶに対するインターフェイスは、後の再検証
の要件に影響するので、クライアントが信用経路に関連
して要求を指示する能力をサポートすることが望まし
い。

【０１３０】望ましい実施例に関連して本発明の説明を
行ってきたが、当業者には容易に明らかになるように、
本発明の思想及び範囲を逸脱することなく本明細書に記
載の応用例の代わりに他の応用例を用いることも可能で
ある。したがって、本発明は、特許請求の範囲による制
限しか受けないものである。

【０１３１】以下においては、本発明の種々の構成要件
の組み合わせからなる例示的な実施例を示す。

【０１３２】１． ディジタル署名の長期検証を可能に
する方法であって、ソース文書又はその要約を署名検証
エンティティに提示し、アーカイブ機構を用いて、選択
された保存時間に前記文書に関する公開キーインフラス
トラクチャ（ＰＫＩ）状態を記憶する、という各ステッ
プを有することを特徴とする方法。

【０１３３】２． 前記保存されたＰＫＩ状態を用い
て、前記署名に関連する認証の満了後の選択された時間
に、前記文書に関する前記ＰＫＩ状態を再生するステッ
プを更に含み、前記文書に関連するディジタル署名を検
証することが可能な期間が、その署名が依存する認証の
何れか又は全ての満了時を超えて延長される、前項１に
記載の方法。

【０１３４】３． 前記文書を任意の関連する暗号情報
とは別個に記憶するステップを更に含む、前項１に記載
の方法。

【０１３５】４． 後続の署名検証プロセスの再生のた
めの基準として用いられる選択された保存時間が前記ソ
ース文書の提示時間である、前項１に記載の方法。

【０１３６】５． 後続の署名検証プロセスの再生のた
めの基準として用いられる選択された保存時間が、前記
ソース文書が発信者により署名された時間である、前項
１に記載の方法。

【０１３７】６． 後続の署名検証プロセスの再生のた
めの基準として用いられる選択された保存時間が、前記
ソース文書が受信者により検証された時間である、前項
１に記載の方法。

【０１３８】７． 前記ＰＫＩ状態情報を記憶保全機構
中に保全することにより該ＰＫＩ状態情報を侵入から保
護するステップを更に含む、前項１に記載の方法。

【０１３９】８． 前記記憶保全機構が、ファイアウォ
ール、アクセス制御機構、監査機構、侵入検出機構、物
理分離、及びネットワーク分離のうちの少なくとも１つ
を含む、前項7に記載の方法。

【０１４０】９． 非暗号ＰＫＩ状態情報を署名及びキ
ー式ハッシュアルゴリズムの何れかを介して保護するこ
とにより該非暗号ＰＫＩ状態情報を侵入から保護するス
テップを更に含む、前項１に記載の方法。

【０１４１】10． 前記ＰＫＩ状態情報を検分し、及び
システムのセキュリティを視覚的に監視するためのユー
ティリティを設けるステップを更に含む、前項１に記載
の方法。

【０１４２】11． 選択された文書に関連する証拠をア
ーカイブ中に保全するステップを更に含む、前項１に記
載の方法。

【０１４３】12． ＰＫＩ状態情報のクラスが、認定権
威者（ＣＡ）及びエンドエンティティを含む１つのエン
ティティからもう１つのエンティティへの１つまたは２
つ以上の認証連鎖、該認証連鎖における各ＣＡ毎に１つ
ずつ存在する認証取消リスト（ＣＲＬ）、認証実施陳述
書、属性認証、ポリシー制約条件、信用情報、及び日時
を含むことが可能である、前項１に記載の方法。

【０１４４】13． 更に、ネスト式署名を用いて暗号リ
フレッシュの必要がある全てのデータに定期的に副署す
るステップを更に含む、前項１に記載の方法。

【０１４５】14． 極めて長いキーを用いて前記アーカ
イブ機構中の情報に１回だけ副署を行うステップを更に
含む、前項１に記載の方法。

【０１４６】15． 前記アーカイブ機構中に含まれる個
々の文書ではなく該アーカイブ機構自体を保護し、前記
署名検証エンティティにおいて暗号保護機構を用いる、
という各ステップのうちの少なくとも一方を更に含む、
前項１に記載の方法。

【０１４７】16． タイムスタンプ機構を用いて時間に
関して暗号情報に捺印を行うステップを更に含む、前項
１に記載の方法。

【０１４８】17. ディジタル署名の長期検証を行う装
置であって、ソース文書と、選択された保存時間に前記
文書に関する公開キーインフラストラクチャ（ＰＫＩ）
状態を記憶するアーカイブ機構とを備えていることを特
徴とする装置。

【０１４９】18. 前記保存されたＰＫＩ状態が用いら
れて、前記署名に関連する認証の満了後の選択された時
間に前記文書に関する前記ＰＫＩ状態が再生され、前記
文書に関連するディジタル署名を検証することが可能な
選択された時間が、該署名が依存する認証の何れか又は
全ての満了時を超えて延長される、前項17に記載の装
置。

【０１５０】19. 前記文書を任意の関連する暗号情報
とは別個に記憶するための機構を更に備えている、前項
17に記載の装置。

【０１５１】20. 後続の署名検証プロセスの再生のた
めの基準として用いられる時間が、前記ソース文書の提
示時間である、前項17に記載の装置。

【０１５２】21. 後続の署名検証プロセスの再生のた
めの基準として用いられる時間が、前記ソース文書がそ
の発信者により署名された時間である、前項17に記載の
装置。

【０１５３】22. 後続の署名検証プロセスの再生のた
めの基準として用いられる時間が、前記ソース文書が受
信者により検証された時間である、前項17に記載の装
置。

【０１５４】23. 前記ＰＫＩ状態情報を侵入から保護
するよう該ＰＫＩ状態情報の保全を行う記憶保全機構を
更に備えている、前項17に記載の装置。

【０１５５】24. 前記記憶保全機構が、ファイアウォ
ール、アクセス制御機構、監査機構、侵入検出機構、物
理分離、及びネットワーク分離のうちの少なくとも１つ
を備えている、前項23に記載の装置。

【０１５６】25. 前記ＰＫＩ状態情報の検分及びシス
テムのセキュリティの視覚的な監視の何れかのための１
つまたは２つ以上のユーティリティを更に備えている、
前項17に記載の装置。

【０１５７】26. 選択された文書に関連する証拠がア
ーカイブ中に保全される、前項17に記載の装置。

【０１５８】27. ＰＫＩ状態情報のクラスが、認定権
威者（ＣＡ）及びエンドエンティティを含む１つのエン
ティティからもう１つのエンティティへの１つ又は２つ
以上の認証連鎖、該認証連鎖における各ＣＡ毎に１つず
つ存在する認証取消リスト（ＣＲＬ）、認証実施陳述
書、属性認証、ポリシー制約条件、信用情報、及び日時
を含むことが可能である、前項17に記載の装置。

【０１５９】28. ネスト式署名を用いて、暗号リフレ
ッシュの必要がある全てのデータに定期的に副署を行
う、前項17に記載の装置。

【０１６０】29. 極めて長いキーを用いて、前記アー
カイブ機構の情報に1回だけ副署を行う、前項17に記載
の装置。

【０１６１】30. 前記アーカイブ機構中に含まれる個
々の文書ではなく該アーカイブ機構自体を保護するため
の手段と、前記署名検証エンティティにおいて用いられ
る暗号保護機構とのうちの少なくとも一方を更に備えて
いる、前項17に記載の装置。

【０１６２】31. 時間に関して暗号情報に捺印を行う
タイムスタンプ機構を更に備えている、前項17に記載の
装置。

【０１６３】32. 非暗号ＰＫＩ状態情報を非検出の修
正から保護するための署名及びキー式ハッシュアルゴリ
ズムの何れかを備えており、前記非暗号ＰＫＩ状態情報
がアーカイブ中に保全される、前項17に記載の装置。

【図面の簡単な説明】

【図１】認定の満了を示す概略的なブロック図である。

【図２】本発明の「状態セーブ」実施例を示す概略的な
ブロック図である。

【図３】本発明の「状態セーブ」「記憶保全」実施例を
示す概略的なブロック図である。

【図４】本発明に対するタイムスタンプの適用可能性を
示す２つの代替的なシナリオを示すフローチャートであ
る。

【図５】(a)〜(c)は、本発明による長期署名検証を用い
た３つのシナリオを示す概略的なブロック図である。

【図６】本発明による２つのエンティティ間における信
用を示す概略的なブロック図である。

【図７】本発明による長期署名検証信用モデルを示す概
略的なブロック図である。

【符号の説明】

20 アーカイブ機構 24 公開キーインフラストラクチャ（ＰＫＩ）状態 25 ＬＴＳＶクライアント 26 ＬＴＳＶサーバ 28 署名検証モジュール

Claims (1)

【特許請求の範囲】
1. 【請求項１】ディジタル署名の長期検証を可能にする方
   法であって、 ソース文書又はその要約を署名検証エンティティに提示
   し、 アーカイブ機構を用いて、選択された保存時間に前記文
   書に関する公開キーインフラストラクチャ（ＰＫＩ）状
   態を記憶する、という各ステップを有することを特徴と
   する方法。