(57)【特許請求の範囲】
【請求項１】
送信側コンピュータにより既存のファイル名を持つファイルを処理する方法であり、
前記送信側コンピュータは、送信する手段と、受け取る手段と、生成する手段と、署名する手段と、リネームする手段とを備え、
前記方法は、
送信側コンピュータが前記送信する手段により認証局へ要求を送信するステップと、
前記送信側コンピュータが前記受け取る手段によりデジタル証明書を発行した認証局から前記デジタル証明書に関連付けられた秘密鍵と前記デジタル証明書にアクセス可能な証明書アドレスとを受け取るステップと、
前記送信側コンピュータが前記生成する手段により前記ファイルと前記秘密鍵とに基づいてデジタル署名を生成するステップであって、前記デジタル証明書は前記秘密鍵に関連付けられた公開鍵を含み、生成された前記デジタル署名が公開鍵の使用により検証可能である、ステップと、
前記送信側コンピュータが前記署名する手段により前記ファイルを生成された前記デジタル署名を用いて署名するステップと、
前記送信側コンピュータが前記生成する手段により前記証明書アドレスをエンコードし、エンコードされたアドレスを生成するステップと、
前記送信側コンピュータが前記生成する手段により前記既存のファイル名と前記エンコードされたアドレスとをマージし、新たなファイル名を生成するステップと、
前記送信側コンピュータが前記リネームする手段により前記ファイルを前記新たなファイル名でリネームするステップと
を備える方法。
【請求項２】
前記エンコードは、前記アドレス中の予め定められたキャラクターを関連する置換キャラクターに置き換えるステップを含み、前記予め定められたキャラクターは、ファイルシステムにより新たなファイル名に使われるのが禁止されている請求項１に記載の方法。
【請求項３】
前記エンコードされたアドレスをＡとし、ＦとＥとをそれぞれ第一および第二のキャラクター列として前記既存のファイル名がＦ．Ｅと構造化され、前記新たなファイル名はＦ（Ａ）．Ｅと構造化される請求項１又は２に記載の方法。
【請求項４】
前記ファイルはドキュメントを含み、前記ファイルを署名することは、生成された前記デジタル署名を前記ファイルに付加し、前記ファイルの先頭、前記ドキュメントの前の開始タグと終了タグとの間に配置される請求項１乃至３のいずれかに記載の方法。
【請求項５】
前記送信側コンピュータが前記送信する手段により前記リネームされたファイルをデジタル証明書のオーナーからユーザに対して送信するステップを更に備える請求項１乃至４のいずれかに記載の方法。
【請求項６】
前記証明書アドレスは前記認証局のサーバのアドレスであり、前記デジタル証明書は前記サーバに記憶される請求項１乃至５のいずれかに記載の方法。
【請求項７】
コンピュータにより実行されることで、請求項１乃至６のいずれかに記載の方法を前記コンピュータが前記送信側コンピュータとして実行させるコンピュータ・プログラム。
【請求項８】
既存のファイル名を持つファイルを処理するコンピュータであり、
認証局へ要求を送信する手段と、
デジタル証明書を発行した認証局から前記デジタル証明書に関連付けられた秘密鍵と前記デジタル証明書にアクセス可能な証明書アドレスとを受け取る手段と、
前記ファイルと前記秘密鍵とに基づいてデジタル署名を生成する手段であって、前記デジタル証明書は前記秘密鍵に関連付けられた公開鍵を含み、生成された前記デジタル署名が公開鍵の使用により検証可能である、手段と、
前記ファイルを生成された前記デジタル署名を用いて署名する手段と、
前記証明書アドレスをエンコードし、エンコードされたアドレスを生成する手段と、
前記既存のファイル名と前記エンコードされたアドレスとをマージし、新たなファイル名を生成する手段と、
前記ファイルを前記新たなファイル名でリネームする手段と
を備えるコンピュータ。
【請求項９】
受信側コンピュータによりエンコードされたアドレスを備えるファイル名を持つファイルを認証する方法であり、前記ファイルは前記ファイルと秘密鍵とに基づいて生成されたデジタル署名を含み、
前記受信側コンピュータは、抽出する手段と、デコードする手段と、アクセスする手段と、検証する手段とを備え、
前記方法は、
前記受信側コンピュータが前記抽出する手段により前記ファイル名からエンコードされたアドレスを抽出するステップと、
前記受信側コンピュータが前記デコードする手段により前記抽出されたエンコードされたアドレスをデコードするステップであって、前記秘密鍵に関連付けられた公開鍵を含むデジタル証明書にアクセス可能な証明書アドレスを生成し、前記デジタル署名は前記公開鍵の使用により検証可能である、ステップと、
前記受信側コンピュータが前記アクセスする手段により前記生成された証明書アドレスから前記デジタル証明書にアクセスするステップと、
前記受信側コンピュータが前記抽出する手段により前記アクセスされたデジタル証明書から前記公開鍵を抽出するステップと、
前記受信側コンピュータが前記検証する手段により前記抽出された公開鍵を用いて検証アルゴリズムを実行することにより前記デジタル署名を検証するステップと
を備える方法。
【請求項１０】
前記受信側コンピュータがチェックする手段を更に備え、
前記デジタル証明書はデジタル証明書のオーナーを示し、前記受信側コンピュータが前記チェックする手段により前記アクセスされたデジタル証明書のオーナーを決定するため、前記デジタル証明書をチェックするステップを更に備える請求項９に記載の方法。
【請求項１１】
前記証明書アドレスは前記デジタル証明書を発行した認証局のサーバのアドレスである請求項９又は１０に記載の方法。
【請求項１２】
前記ファイル名は、前記エンコードされたアドレスをＡとし、ＦとＥとをそれぞれ第一および第二のキャラクター列として前記ファイル名はＦ（Ａ）．Ｅと構造化される請求項９乃至１１のいずれかに記載の方法。
【請求項１３】
前記ファイルはドキュメントを含み、前記ファイルを署名することは、生成された前記デジタル署名を前記ファイルに付加し、前記ファイルの先頭、前記ドキュメントの前の開始タグと終了タグとの間に配置される請求項９乃至１２のいずれかに記載の方法。
【請求項１４】
前記受信側コンピュータが受信する手段を更に備え、
前記ファイル名からエンコードされたアドレスを抽出するステップに先だって、前記受信側コンピュータが前記受信する手段により前記デジタル証明書のオーナーから前記ファイルを受信するステップを更に備える請求項９乃至１３のいずれかに記載の方法。
【請求項１５】
前記デジタル証明書により前記検証アルゴリズムが特定される請求項９乃至１４のいずれかに記載の方法。
【請求項１６】
コンピュータにより実行されることで、請求項９乃至１５のいずれかに記載の方法を前記コンピュータが前記受信側コンピュータとして実行させるコンピュータ・プログラム。
【請求項１７】
エンコードされたアドレスを備えるファイル名を持つファイルを認証するコンピュータであり、前記ファイルは前記ファイルと秘密鍵とに基づいて生成されたデジタル署名を含み、前記コンピュータは、
前記ファイル名からエンコードされたアドレスを抽出する手段と、
前記抽出されたエンコードされたアドレスをデコードする手段であって、前記秘密鍵に関連付けられた公開鍵を含むデジタル証明書にアクセス可能な証明書アドレスを生成し、前記デジタル署名は前記公開鍵の使用により検証可能である、手段と、
前記生成された証明書アドレスから前記デジタル証明書にアクセスする手段と、
前記アクセスされたデジタル証明書から前記公開鍵を抽出する手段と、
前記抽出された公開鍵を用いて検証アルゴリズムを実行することにより前記デジタル署名を検証する手段と
を備えるコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ネットワーク・コンピューティング・セキュリティに関し、より具体的には、ファイルを開く前に使用できる署名者のＩＤおよび署名の妥当性に関する情報を提供するために、ネットワークを介してアクセス可能なデジタル証明書をデジタル署名付きファイルにリンクする方法およびシステムに関する。
【背景技術】
【０００２】
著作権表示
本特許文書の開示内容の一部は、著作権保護の対象となる資料を含む。この特許開示内容は国立特許商標局の特許ファイルまたはレコードに現れるので、著作権所有者は、誰かが特許開示内容をファクシミリで複製することに対して何も異議はないが、さもなければ、一切無関係にすべての著作権権利を保有する。
【０００３】
コンピュータ・ネットワークによるデータ伝送セキュリティを改善し、デジタル偽造を防止するために、一般に、デジタル署名を使用してフィルを認証し、すなわち、ファイル保全性（integrity）をチェックし、署名者を認証している。このようなデジタル署名により、たとえば、受信ファイルの送信元を制御し、ファイル保全性を検証することが可能になる。デジタル署名は、デジタル署名に対応するユーザが、デジタル署名が付加されている電子文書またはその他の情報オブジェクトの内容を作成したかまたはさもなければその内容に同意したことを表明する（アサートする）ものである。筆記署名と同様に、デジタル署名は、署名者のＩＤの認証、署名付き文書に明記された条件の受諾、文書の内容の保全性の証明、および否認防止（換言すれば、署名者は自分が署名した内容を否認することができない）を可能にする。デジタル署名は一般に、使用するアルゴリズムとは無関係に、鍵によりセキュリティが提供される公開鍵アルゴリズムに基づくものであり、そのアルゴリズムは自由に公開または分析することができる。
【０００４】
デジタル証明書は、文書の署名者のＩＤを署名者の公開鍵にリンクさせる署名付き文書に対する添付物と見なすことができる。デジタル証明書は、他の当事者が証明書の所有者に関する情報を暗号化できるようにする暗号公開鍵を提供する。また、デジタル証明書は、文書を送信するユーザが自分で主張する通りの者であることを検証し、応答をエンコード（コード化）するための手段を受信側に提供することも可能にする。したがって、証明書は、認証サービス、許可サービス、暗号化サービス、および否認防止サービスを提供するために使用される公開鍵ペアの所有者を確実に識別する。デジタル証明書は、署名者の公開鍵を含み、認証局（ＣＡ：Certification Authority）のデジタル署名を有する。最も広く使用されているデジタル証明書に関する規格は、国際電気通信連合（ＩＴＵ：InternationalTelecommunications Union）によって公布されたＸ．５０９の第３版、「TheDirectory-Authentication Framework 1988」であり、これは公開鍵証明書に関する以下の構造を定義するものである。
−バージョン・フィールド（証明書フォーマットを識別する）
−シリアル番号（ＣＡ内で固有のもの）
−署名アルゴリズム（証明書に署名するために使用される発行者のハッシュおよびデジタル署名アルゴリズムを識別する）
−発行者名（ＣＡの名前）
−有効期間（「開始（Not Before）」の日付と「終了（Not After）」の日付の対）
−サブジェクト名（証明書が発行されるユーザの名前）
−サブジェクトの公開鍵フィールド（アルゴリズム名とサブジェクトの公開鍵を含む）
−拡張子（extension）
−ＣＡの署名
【０００５】
認証局とは、署名者と署名者の公開鍵とのリンクを提供するデジタル証明書を発行することがその責務であると誰もが確信している第三者機関である。また、認証局（ＣＡ）は、それが発行した証明書を使用して行われるトランザクションに関する記録を取る。文書に署名することを望む個人は、認証局からのデジタル証明書を申請する。デジタル証明書は、内容と送信元の保全性の両方を保証する発行側認証局によってデジタル署名される。ＣＡは、たとえば、印刷広報によるかまたはインターネット上でそれ自体の公開鍵を容易に使用可能なものにする。デジタル署名を行うという行為は証明書を実質的に改ざんできないものにし、したがって、追加の保護は不要である。保護の強さは、発行者のデジタル署名を作成する際に使用されるアルゴリズムおよび鍵サイズ（ハッシュおよびデジタル署名アルゴリズム）の強さにそのまま相当する。
【０００６】
署名検証プロセスは、ＣＡによって発行され、同じく文書に付加されるかまたは文書内で参照されなければならないデジタル証明書から抽出された公開検証鍵（Verification key）を使用して文書に付加または添付されたデジタル署名をチェックするものである。署名者の公開鍵を使用して、署名検証プロセスは、認証プロセス中に署名者の秘密鍵を使用して署名されたファイル内の署名者によって計算されたハッシュ値をデジタル署名から回復する。ファイルが真正なものであることを検証するために、受信側も文書のハッシュ値を計算し、暗号解読されたハッシュ値をファイルから計算された実ハッシュ値と比較する。両方のハッシュ値が同一である場合、ファイルは真正なものとして受け入れられ、さもなければ、ファイルは破壊されたものまたは偽物（fake）として拒否される。
【０００７】
あるファイルのデジタル署名が計算され、そのファイルが検証のためにデジタル署名で署名されると、受信側によるデジタル署名の検証を可能にするために、デジタル証明書を署名付きファイルに関連付けなければならない。
【０００８】
一般に、ファイルを認証するために使用されるデジタル証明書は、それが認証するファイルに付加される個別ファイルとして、たとえば、ファイル・ラッパ構造（file wrapper structure）の一部として伝送されるか、代わって、証明書は、参照またはアドレス、たとえば、発行側ＣＡのＷｅｂサーバ上の証明書のＵＲＬから検索することができる。
【０００９】
デジタル証明書および署名付き文書を個別ファイルとして伝送し維持すると、たとえば、署名付き文書に関連付けられたデジタル証明書はユーザのワークステーションまたはサーバに保管され、単純かつ十分理解された方法でいつでもファイル認証をサポートするという利点をもたらす。しかし、文書があとで新しい受信側に回されるかまたは移動される場合、関連のデジタル証明書は失われるか、偶発的に除去されるか、または欺そうとしている途中で故意に除去される可能性がある。
【００１０】
区切り文字（delimiter）でファイルをラップし、署名付きファイルの終わりにデジタル証明書または発行側ＣＡのＷｅｂサーバ上の前記証明書のＵＲＬを付加することは都合の良いことである。というのは、証明書または証明書アドレスと、署名付き内容の両方が一緒に移動するからである。逆に、ラッパ（wrapper）と証明書または証明書アドレスは、典型的には、ファイルを使用できるようになる前に除去する必要がある。したがって、署名の妥当性検査は、文書が検索されたときにのみ行われる。文書があとで回されるかまたは移動される場合、証明書または証明書アドレスが失われている可能性があるので、もう一度チェックすることは困難である可能性がある。その上、この方法は、認証前に認識できない、イメージ、ビデオ、オーディオ、または実行可能ファイルなどの標準ファイル・フォーマットと互換性のあるものではない。
【００１１】
受信側が電子文書を受信すると、デジタル証明書が署名付き文書に付加されている場合、受信側は以下の作業（タスク）を実行しなければならない。
−電子文書を開く。
−この電子文書に付加されたデジタル証明書およびデジタル署名部分を電子文書から識別し抽出する。
−デジタル証明書の内容を使用して、アドレスを識別し、付加された証明書が有効な証明書であることをチェックするようＣＡに連絡する。
−証明書内の公開鍵を使用して署名を検証する。
【００１２】
デジタル証明書が受信電子文書に付加されている場合、受信側は署名を検証するために必要なデジタル証明書にアクセスするために文書ファイルを開かなければならないことに気付かなければならない。証明書が付加される代わりに受信文書内で、たとえば、ネットワーク・アドレスまたはＵＲＬとして参照される場合でも、証明書にアクセスできるかまたは証明書を検索できるアドレス、たとえば、ＣＡのＷｅｂサーバまたはディレクトリ・アーカイブからのアドレスも送信側により署名付き文書に付加しなければならない。したがって、デジタル証明書にアクセスするために必要な前記アドレスを取得するためにも受信文書を開くことが必要である。
【００１３】
したがって、以下のように、受信側により受信またはアクセスされたファイルの信憑性を検証するために上述の方法に関連するセキュリティ上の問題が存在する。
−証明書が個別ファイルとして送信されると、署名付きファイルがあとで新しい受信側に回されるかまたは移動される場合、関連のデジタル証明書が失われる可能性がある。このような場合、これらの署名付きファイルを検証することは不可能である。
−証明書または証明書アドレスが署名付きファイルに付加されると、受信側は前記ファイルを検証するために受信ファイルを開いて処理しなければならない。受信ファイルを開き、関連の証明書を突き止めるために内容を解析し、関連の証明書を検索するかまたはそれにアクセスする前に、受信ファイルが署名されているかどうか、すなわち、それが「認証済み（authenticated）」ファイルまたは「偽名使用（impersonated）」ファイル（署名なし（non-signed）ファイル）であるかどうかを前もって判断する方法はまったく存在しない。同様に、証明書が有効であるかどうか、すなわち、それがＣＡによって発行されたかどうか、それが取り消されていないかどうか、および証明書の日付が有効であるかどうかを判断することは不可能である。
【００１４】
また、検証のためにファイルを開くことが重要なセキュリティ上の懸念を表していることは注目すべきことである。
【００１５】
多くのウィルスは、「偽名使用」として配布された電子メール添付物によりインターネット上で広まっている。受信した偽名使用ファイルが悪意をもってウィルスに感染させられている場合、署名検証という単純な目的のために感染ファイルを開くことは、ほぼ確実に受信側のコンピュータを感染させるためのドアを「開く」可能性がある。これは、本明細書で前に論じたクラスの公開鍵アルゴリズムの操作により例示される通り、上述のすべての署名方法に共通する「セキュリティ・ホール」である。
【００１６】
証明書は、認証局によって発行されなければならない。証明書が損なわれたものになった場合、認証局はあとで証明書を取り消すことができ、したがって、署名の取消し日後に署名されたすべてのファイルを無効にする。無許可の第三者機関が証明書に関連する秘密鍵を入手した場合、証明書は損なわれたものになる可能性がある。この秘密鍵は、典型的には、署名者のコンピュータに保管される。秘密鍵により、無許可の人でも本質的に署名を捏造することができる。取り消された証明書とともに署名されたファイルを受信側が受信した場合、それは無効または偽物として廃棄されなければならない。
【００１７】
したがって、受信ファイルを開く前に、以下の項目をチェックすることが賢明であると思われる。
−ファイルが署名されているかどうか、すなわち、付加または参照されたデジタル署名およびデジタル証明書をファイルが含むかどうか
−発行者名、すなわち、ＣＡの名前
−証明書が発行されたユーザの名前
−証明書の有効期間
【００１８】
したがって、ファイルの受信側が、受信ファイルが署名されているかどうか、すなわち、認証されているかどうかを判断し、署名検証のために前記ファイルを開く前に、署名者のＩＤ、たとえば、電子メールにより署名者に連絡すること、およびデジタル証明書の妥当性をチェックできるようにするために、署名付きファイルを開く前に前記署名付きファイルからのデジタル証明書にアクセスする方法およびシステムを提供する必要がある。
【非特許文献１】国際電気通信連合（ＩＴＵ：Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｎｉｏｎ）によって公布されたＸ．５０９の第３版、「Ｔｈｅ  Ｄｉｒｅｃｔｏｒｙ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ  １９８８」
【発明の開示】
【発明が解決しようとする課題】
【００１９】
したがって、本発明の広範な一目的は、上述の従来技術の短所を矯正することにある。
【００２０】
本発明の他の目的は、受信者が受信ファイルを開く前に前記ファイルが署名付きファイルであるかどうかをチェックできるようにするために適合された方法およびシステムを提供することにある。
【００２１】
本発明のさらに他の目的は、対応するファイルを開く前に署名者のデジタル証明書にアクセスするように適合された方法およびシステムを提供することにある。
【００２２】
本発明のさらに他の目的は、疑わしいファイルを開く前に署名者ＩＤを検証するために、ファイルの受信側にこのファイルの署名者のＩＤおよびアドレスを提供するために適合された方法およびシステムを提供することにある。
【課題を解決するための手段】
【００２３】
上記その他の関連目的の成就は、署名付きファイルを認証するために必要な証明書にアクセス可能なアドレスを前記署名付きファイルのファイル名内にエンコード（符号化）する方法であって、
−前記署名付きファイルを認証するために必要な証明書にアクセス可能な前記アドレスをエンコードするステップと、
−前記ファイル名とエンコードされた前記アドレスを新しいファイル名内にマージするステップと、
−前記新しいファイル名で前記署名付きファイルを名前変更（リネーム）するステップと、
を含み、
前記ファイル名とエンコードされた前記アドレスが制御文字によって分離される方法と、
署名付きファイルを認証するために必要な証明書にアクセス可能なアドレスがエンコードされているファイル名を有する署名付きファイルを認証する方法であって、
−エンコードされた前記アドレスを抽出するステップと、
−エンコードされた前記アドレスをデコード（逆符号化）するステップと、
−デコードされた前記アドレスを使用して、前記署名付きファイルを認証するために必要な前記証明書にアクセスするステップと、
−アクセスされた前記証明書を使用して、前記署名付きファイルを認証するステップと、
を含む方法によって達成される。
【００２４】
本発明の他の利点は、図面および詳細な説明を検討すると当業者にとって明らかなものになるであろう。いかなる追加の利点も本明細書に組み込まれることが意図されている。
【発明を実施するための最良の形態】
【００２５】
本発明によれば、ローカルでまたはコンピュータ・ネットワークを介してアクセスされるファイルのファイル名は、保全性をチェックし、ファイルの署名を検証するために使用できる証明書にアクセス可能なアドレスまたはＵＲＬをエンコードするために使用される。辞書編集（lexicography）は、ファイル・システムによって禁止される可能性のある特定の文字、たとえば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓシステム（Ｗｉｎｄｏｗｓはマイクロソフト社の商標である）による「￥」を回避するために、またはそのサイズを低減するためにアドレスをエンコードするために、あるいはその両方のために決定される。エンコードすべきアドレスは、たとえば、ローカル・アドレス、プライベート・ネットワーク内のアドレス、またはインターネット・アドレスなど、任意の形のものにすることができるが、例証のために、以下の説明で示される例はＵＲＬタイプのアドレスに基づくものである。証明書にアクセス可能なアドレスは、ファイルがサーバからユーザ・システムに伝送されるとき、あるいはそれがローカルで保管されるかまたは他のシステムに伝送されるときのいずれかの時期にエンコードすることができる。
【００２６】
図１〜図３は、証明書アドレスをエンコードするために使用されるアルゴリズムの一例を例示している。図１に示されている通り、第１のステップは、ファイルの基本ファイル名を取得する（ボックス１００）こと、すなわち、ファイルのファイル名と、以下の説明で証明書アドレスと呼ばれ、保全性をチェックし、ファイルの署名を検証するために必要な証明書のアドレスまたはＵＲＬとを取得する（ボックス１０５）ことにある。次に、証明書アドレスは、エンコードされ（ボックス１１０）、特定の区切り文字を使用して、ファイルの基本ファイル名とマージされ（ボックス１１５）、その後、ファイルは、基本ファイル名とエンコードされた証明書アドレスとを含むファイル名で名前変更される（ボックス１２０）。
【００２７】
図２は、エンコード・アルゴリズム（ボックス１１０）の一例を描写している。変数ｉはゼロに設定され（ボックス１２５）、ｉ番目の文字が証明書アドレス・ストリングから抽出される（ボックス１３０）。抽出された文字が有効であるか、さもなければ、ユーザの装置のファイル・システムによって課されたファイル名構文規則によって禁止されているかを判断するためのテストが実行される（ボックス１３５）。抽出された文字がファイル名有効文字である場合、変数ｉは増分され（ボックス１５０）、変数ｉがその最大値に到達しているかどうか、すなわち、証明書アドレス・ストリングのすべての文字が処理されているかどうかを判断するためのテストが実行される（ボックス１５５）。変数ｉがその最大値に到達していない場合、このアルゴリズムの最後の４ステップが繰り返される（ボックス１３５〜１５５）。あるいは、変数ｉがその最大値に到達している場合、プロセスは停止される。証明書アドレス・ストリングから抽出された文字がファイル名構文規則によって禁止されている場合、対応する有効文字または文字群が辞書編集テーブル１４５から選択され、この選択された文字または文字群が禁止されているものに置換される（ボックス１４０）。次に、変数ｉは増分され、変数ｉがその最大値に到達しているかどうかを判断するための上述と同じテストが実行される。
【００２８】
上述のアルゴリズムの例証として、「Ｂｅｒｒｙ．ｄｏｃ」という名前で、Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄフォーマット（Ｗｏｒｄはマイクロソフト社の商標である）に基づくファイルであって、ユーザが他の誰かに電子メール添付物として送信したいと望むと思われるファイルのケースを検討するが、この意味で以下のように証明書アドレス・ストリングをファイル名内にエンコードするための辞書編集テーブルを使用する。
「：」は「．．」に関連付けられる。
「／」は「（」に関連付けられる。
【００２９】
保全性をチェックし、この文書ファイルの署名を検証するために、このファイルに署名するために使用された秘密鍵に対応する証明書を使用することが必要である。例証のために、この証明書がｈｔｔｐ：／／ｗｗｗ．ｃｅｒｔａｕｔｈ．ｃｏｍ／ｃｅｒｔｉｆｉｃａｔｅｓ／Ｌｅｗｉｓ  Ｃａｒｒｏｌｌ．ｃｅｒというＵＲＬからダウンロード可能であると考慮することができる。
【００３０】
「Ｂｅｒｒｙ．ｄｏｃ」という文書の発信元が文書に署名するときに、保全性をチェックするかまたは文書の署名を検証するために必要な証明書にアクセス可能な証明書リポジトリのＵＲＬをエンコードするために「ファイルへのパスのコピー（Copy path to file）」などのオプションを選択することができる。
【００３１】
ファイル名は図１〜図３に例示されているアルゴリズムにより変更される。まず第一に、前の辞書編集テーブルを使用することにより、証明書リポジトリＵＲＬがｈｔｔｐ．．（（ｗｗｗ．ｃｅｒｔａｕｔｈ．ｃｏｍ（ｃｅｒｔｉｆｉｃａｔｅｓ（Ｌｅｗｉｓ  Ｃａｒｒｏｌｌ．ｃｅｒのようにエンコードされる。
【００３２】
次に、エンコードされたＵＲＬがファイル名とマージされる。この例では、エンコードされたＵＲＬは、区切り文字として使用される括弧内に囲まれている。エンコードされたＵＲＬは、Ｂｅｒｒｙ（ｈｔｔｐ．．（（ｗｗｗ．ｃｅｒｔａｕｔｈ．ｃｏｍ（ｃｅｒｔｉｆｉｃａｔｅｓ（Ｌｅｗｉｓ  Ｃａｒｒｏｌｌ．ｃｅｒ）．ｄｏｃのように基本ファイル名の拡張子点（extension dot）の前に挿入され、この変更されたファイル名を使用して、ファイルが名前変更される。
【００３３】
例証のために、このエンコード・アルゴリズムは故意に非常に単純なものになっていることに注目しなければならない。好ましいものは、一連の禁止文字を単一文字で置き換えること、たとえば、「／／：」を「（」で置き換えることにあるであろう。同様に、いくつかの文字セットはより短縮したコードで置き換えることができ、たとえば、「ｈｔｔｐ：／／」を「Ｈ！」で置き換えることができる。
【００３４】
図３は、添付ファイル１７０のファイル名１６５が前のアルゴリズムにより証明書アドレスのＵＲＬを組み込むために変更されている、電子メール１６０を描写している。
【００３５】
上述の電子メールの添付物が受信側によって処理されることが選択された場合、証明書アドレスをファイル名から抽出してデコードしなければならないかどうかを判断するために、ユーザが保全性チェックまたは署名検証を必要とするかどうかを判断するためのテストが実行される。
【００３６】
証明書アドレスをエンコードするためにファイルの送信側によって使用されたものと同じ辞書編集変換のテーブルを使用して、証明書アドレスまたはＵＲＬがファイル名から抽出され、デコードされる。そのために、「エンコードされたＵＲＬ」の特定の記号または記号群は、デコードされた有効なＵＲＬを取得するために、上述の通り、インターネット上のＵＲＬ規則と互換性のある記号または文字で置き換えられる。前と同じ例を使用すると、デコードされた証明書アドレスはｈｔｔｐ：／／ｗｗｗ．ｃｅｒｔａｕｔｈ．ｃｏｍ／ｃｅｒｔｉｆｉｃａｔｅｓ／Ｌｅｗｉｓ  Ｃａｒｒｏｌｌ．ｃｅｒになる。
【００３７】
証明書は、認証局サーバのデータベース内と、おそらく、証明書の所有者の装置内にローカルに保管される。各証明書は少なくとも、妥当性を検査するかまたは署名付きファイルの署名を検証するために第三者機関によってアクセス可能な公開鍵を含む。証明書の公開鍵は、証明書の所有者と認証局のみに知られている秘密鍵に対応し、この秘密鍵はファイルに署名するために使用される。好ましい一実施形態では、証明書は、上述の通り、所有者の名前、証明書の有効期間、および署名アルゴリズムなどの追加情報も含む。秘密鍵は証明書の所有者と認証局のみに知られているが、秘密鍵に関連し、証明書として編成されたその他のすべての情報は公然のものであり、証明書アドレスまたはＵＲＬを知っているどの第三者機関でもアクセス可能であることは明白でなければならない。
【００３８】
図４および図５は、電子文書に署名するために使用されるアルゴリズムと、保全性をチェックするか、署名付きファイルの署名を検証するか、あるいはその両方を行うために使用されるアルゴリズムの一例をそれぞれ例示している。
【００３９】
送信側がまだ認証局によって証明書を発行されていない場合、送信側はそれを発行するよう認証局に申請しなければならない。証明書には有効期間があるので、これは有効期間ごとに１回行わなければならない。したがって、証明書有効期間中にすべての文書に署名するために、送信側は認証局によって発行される証明書に関連する秘密鍵を使用することができる。証明書を取得するために、送信側は、送信側の名前などの必要な情報とともに認証局に要求を送信する（ステップ２００）。秘密鍵と公開鍵のペアを割り当てた後、認証局は証明書を作成し、セキュア接続を使用して、要求を送信したユーザに秘密鍵ならびに証明書アドレスを伝送する。秘密鍵と証明書アドレスは好ましくはユーザの装置上にローカルに保管されるが、この情報は、認証局のセキュア・サーバ上またはスマート・カードなどの個人用データ記憶手段上に保管することができる。
【００４０】
署名するためのファイルを選択した後、必要な秘密鍵および関連の証明書アドレスを受信または回復すると（ステップ２１０）、ユーザはファイルに署名する（ステップ２１５）。その意味で、署名すべきファイルおよび秘密鍵に基づく署名を計算するために、標準認証アルゴリズム、たとえば、ＲＳＡによるＭｅｓｓａｇｅ−Ｄｉｇｅｓｔ−５（ＭＤ５）またはＲＳＡによるＳＨＡハッシュ・アルゴリズムが使用される。
【００４１】
好ましい一実施形態では、署名は、図７に例示されている通り、文書に付加されるが、同図では、署名（４１０）はファイル（４００）の先頭に位置し、「署名開始（BEGIN SIGNATURE）」および「署名終了（END SIGNATURE）」というタグによって文書（４０５）の内容から分離されている。次に、保全性をチェックするかまたはファイルの署名を検証するために必要な公開鍵が保管されているサーバのアドレスまたはＵＲＬは、図１〜図３を参照することによって説明した通り、ファイル名内にエンコードされる（ステップ２２０）。上述の通り、この公開鍵が保管されているアドレスまたはＵＲＬは好ましくは証明書を発行するときに認証局によって提供されるが、送信側が文書に署名するたびに、要求あり次第、送信側に伝送することができる。したがって、図４に描写されているアルゴリズムの終了時に、結果として得られるファイルは署名され、そのファイルは、結果として得られるファイルの保全性をチェックするかまたは組み込まれた署名を検証するために証明書を回復可能なサーバへのリンクを含んでいる。
【００４２】
図５は、保全性をチェックするかまたは本発明によりエンコードされた署名付きファイルの署名を検証するために使用可能なアルゴリズムの一例を例示している。第１のステップは、上述の通り、ファイルのファイル名をデコードし、保全性をチェックするかまたは署名を検証するために必要な証明書が保管されているアドレスまたはＵＲＬを検索することにある（ステップ２２５）。次に、このデコードされたアドレスまたはＵＲＬを使用して、ユーザは、ファイルを開かずに、好ましくは認証局によって制御されるサーバから証明書にアクセスすることができる（ステップ２３０および２３５）。この段階で、ユーザは、証明書が配信された人の名前、証明書の有効期間、および署名アルゴリズムなど、証明書に関連する情報にアクセスすることができる。したがって、ユーザは、証明書をチェックして、証明書の所有者がそうであると予想される人であるかどうかを判断することができる（ステップ２４０および２４５）。次に、証明書の公開鍵を使用して、ファイルを認証すること、すなわち、標準認証アルゴリズムを使用することにより、ファイルの保全性をチェックするかまたは署名を検証するかあるいはその両方を行うことが可能である（ステップ２５０および２５５）。点線によって示唆される通り、ユーザは、証明書をチェックせずに署名付きファイルを認証することができる。当然、証明書は、認証局ポリシーに応じて、使用できるかまたは使用しなければならない認証アルゴリズムに関連する情報を含むことができる。依然として、好ましい一実施形態では、認証局は、保全性をチェックし、ファイルの署名を検証するために証明書にアクセスするときに認証アプレット（applet）をダウンロードするための手段をユーザに提供することができる。
【００４３】
図６は、本発明を実現可能な環境の一例を描写している。例証のために、図４および図５に記述されているアルゴリズムの主な諸ステップが参照矢印とともに例示されている。上述の通り、証明書を持たず、ファイルに署名したいと望んでいるユーザ（３００）は、ネットワーク（３０５）、たとえば、インターネットを介して認証局サーバ（３１０）にアクセスしなければならない。認証局（３２０）によって生成された証明書は、認証局サーバ（３１０）の証明書データベース（３１５）にローカルに保管される。同様に、署名付きファイル、たとえば、電子メール添付物として受信された署名付きファイルを有するユーザ（３２５）がその保全性をチェックし、署名を検証したいと希望する場合、そのユーザは、そのアドレスまたはＵＲＬがチェックすべき署名付きファイルのファイル名内にエンコードされている証明書の公開鍵にネットワーク（３０５）を介してアクセスする。
【００４４】
図７は、文書（４０５）と、ファイル保全性をチェックし、文書の作成者のＩＤを検証するために使用可能な署名（４１０）とを含む、署名付きファイル（４００）を示している。ファイルに署名するために使用される秘密鍵に対応する証明書が保管されている認証局サーバのアドレスまたはＵＲＬは、ファイル名（４１５）内にエンコードされ、保管される。
【００４５】
図８〜図１３は、本発明を使用するときのユーザのインターフェースの一例を例示している。図８〜図１１は証明書パネルの一例を描写し、図１２および図１３は証明書アドレスまたはＵＲＬをどのようにファイルにリンクできるかを示している。
【００４６】
図８〜図１１に例示されている証明書パネルは、これらの図のそれぞれに描写されている４つのタブをそれぞれ含み、これらのタブは以下の項目に関連する情報を含む。
−一般タブ
・証明書の所有者
・証明書を配信した認証局
・有効期間
−詳細タブ
・証明書フォーマットを識別するバージョン
・シリアル番号（認証局内で固有のもの）
・署名アルゴリズム（証明書に署名するために使用される発行者のハッシュ・アルゴリズムおよびデジタル署名アルゴリズムを識別する）
・発行者名（認証局の名前）
・有効期間の開始
・有効期間の終了
・サブジェクト名（証明書が発行されるユーザの名前）
・サブジェクトの公開鍵フィールド（アルゴリズム名とサブジェクトの公開鍵を含む）
・拡張子
・認証局の署名
−認証パス（認証局サーバ上の証明書のアドレスまたはＵＲＬ）
−ダウンロードＳＷ（たとえば、ファイルの妥当性をチェックするかまたは署名を検証するように適合されたソフトウェア・アプリケーションまたはアプレットへのリンクを含む）。
【００４７】
これらのフィールドのほとんどは、証明書に関する要求およびＩＤまたはサブジェクト名を受信した後に認証局によって入力される（complete）。秘密鍵と公開鍵は、標準アルゴリズムにより計算される。
【００４８】
図１２および図１３は、証明書アドレスまたはＵＲＬをファイルのファイル名内にエンコードするために使用可能なインターフェースの一例を描写している。ファイル・マネージャ内でファイルを選択した後、ユーザはマウスの右ボタンをクリックして、「ファイルへのパスの貼り付け（Paste path to file）」オプションを含むポップアップ・メニューを表示することができる。次に、前にクリップボードにメモされたかまたは他の手段によって選択されたパスは、図１〜図３を参照することによって説明した方法により、ファイルのファイル名内にエンコードされる。
【００４９】
当然、局地的要件および固有の要件を満足するために、当業者は、多くの修正および変更を上述の解決策に適用することができるが、それらはいずれも、特許請求の範囲によって定義された本発明の保護の範囲内に含まれる。
【図面の簡単な説明】
【００５０】
【図１】ファイルに署名するために使用される証明書が保管されるアドレスまたはＵＲＬをこのファイルのファイル名内にエンコードするために使用されるアルゴリズムの一例を例示する図である。
【図２】ファイルに署名するために使用される証明書が保管されるアドレスまたはＵＲＬをこのファイルのファイル名内にエンコードするために使用されるアルゴリズムの一例を例示する図である。
【図３】ファイルに署名するために使用される証明書が保管されるアドレスまたはＵＲＬをこのファイルのファイル名内にエンコードするために使用されるアルゴリズムの一例を例示する図である。
【図４】電子文書に署名するために使用されるアルゴリズムの一例を例示する図である。
【図５】保全性をチェックし、署名付きファイルの署名を検証するために使用されるアルゴリズムの一例を例示する図である。
【図６】本発明を実現可能な環境の一例を描写する図である。
【図７】本発明によりファイル名がエンコードされる署名付きファイル内容の一例を示す図である。
【図８】本発明を使用するときのユーザのインターフェースの一例を例示する図である。
【図９】本発明を使用するときのユーザのインターフェースの一例を例示する図である。
【図１０】本発明を使用するときのユーザのインターフェースの一例を例示する図である。
【図１１】本発明を使用するときのユーザのインターフェースの一例を例示する図である。
【図１２】本発明を使用するときのユーザのインターフェースの一例を例示する図である。
【図１３】本発明を使用するときのユーザのインターフェースの一例を例示する図である。
【図１】
0004949232.tif 000002
【図１ｂ】
0004949232.tif 000003
【図１ｃ】
0004949232.tif 000004
【図２】
0004949232.tif 000005
【図３】
0004949232.tif 000006
【図４】
0004949232.tif 000007
【図５】
0004949232.tif 000008
【図６】
0004949232.tif 000009
【図７】
0004949232.tif 000010
【図８】
0004949232.tif 000011
【図９】
0004949232.tif 000012
【図１０】
0004949232.tif 000013
【図１１】
0004949232.tif 000014
【図１２】
0004949232.tif 000015
【図１３】
0004949232.tif 000016