JP2007533182A - 署名付きファイルに証明書をリンクする方法およびシステム - Google Patents

Abstract

【課題】 証明書をそれに関連する署名付きファイルにリンクさせる方法およびシステムを提供する。
【解決手段】 本発明の方法およびシステムによれば、証明書が保管されているアドレスまたはＵＲＬは、ファイルと一緒に伝送されるように、署名付きファイルのファイル名内にエンコードされる。このような署名付きファイルを受信した場合、第１のステップは、ファイル名から証明書アドレスを抽出しデコードすることにある。署名付きファイルを開いて認証する前に、証明書アドレスを使用して、証明書にアクセスし、証明書をチェックすることができる。好ましい一実施形態では、署名付きファイルの署名はファイルの内容と秘密鍵に基づくものであり、対応する証明書は少なくとも対応する公開鍵を含む。
【選択図】 図４

Description

本発明は、一般に、ネットワーク・コンピューティング・セキュリティに関し、より具体的には、ファイルを開く前に使用できる署名者のＩＤおよび署名の妥当性に関する情報を提供するために、ネットワークを介してアクセス可能なデジタル証明書をデジタル署名付きファイルにリンクする方法およびシステムに関する。

著作権表示
本特許文書の開示内容の一部は、著作権保護の対象となる資料を含む。この特許開示内容は国立特許商標局の特許ファイルまたはレコードに現れるので、著作権所有者は、誰かが特許開示内容をファクシミリで複製することに対して何も異議はないが、さもなければ、一切無関係にすべての著作権権利を保有する。

コンピュータ・ネットワークによるデータ伝送セキュリティを改善し、デジタル偽造を防止するために、一般に、デジタル署名を使用してフィルを認証し、すなわち、ファイル保全性（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）」オプションを含むポップアップ・メニューを表示することができる。次に、前にクリップボードにメモされたかまたは他の手段によって選択されたパスは、図１〜図３を参照することによって説明した方法により、ファイルのファイル名内にエンコードされる。

当然、局地的要件および固有の要件を満足するために、当業者は、多くの修正および変更を上述の解決策に適用することができるが、それらはいずれも、特許請求の範囲によって定義された本発明の保護の範囲内に含まれる。

ファイルに署名するために使用される証明書が保管されるアドレスまたはＵＲＬをこのファイルのファイル名内にエンコードするために使用されるアルゴリズムの一例を例示する図である。 ファイルに署名するために使用される証明書が保管されるアドレスまたはＵＲＬをこのファイルのファイル名内にエンコードするために使用されるアルゴリズムの一例を例示する図である。 ファイルに署名するために使用される証明書が保管されるアドレスまたはＵＲＬをこのファイルのファイル名内にエンコードするために使用されるアルゴリズムの一例を例示する図である。 電子文書に署名するために使用されるアルゴリズムの一例を例示する図である。 保全性をチェックし、署名付きファイルの署名を検証するために使用されるアルゴリズムの一例を例示する図である。 本発明を実現可能な環境の一例を描写する図である。 本発明によりファイル名がエンコードされる署名付きファイル内容の一例を示す図である。 本発明を使用するときのユーザのインターフェースの一例を例示する図である。 本発明を使用するときのユーザのインターフェースの一例を例示する図である。 本発明を使用するときのユーザのインターフェースの一例を例示する図である。 本発明を使用するときのユーザのインターフェースの一例を例示する図である。 本発明を使用するときのユーザのインターフェースの一例を例示する図である。 本発明を使用するときのユーザのインターフェースの一例を例示する図である。

Claims (12)

1. 署名付きファイルのファイル名内に前記署名付きファイルを認証するために必要な証明書にアクセス可能なアドレスをエンコードする方法であって、
   前記署名付きファイルを認証するために必要な前記証明書にアクセス可能な前記アドレスをエンコードするステップ（ステップ１１０）と、
   前記ファイル名とエンコードされた前記アドレスを新しいファイル名内にマージするステップ（ステップ１１５）と、
   前記新しいファイル名で前記署名付きファイルを名前変更するステップ（ステップ１２０）と、
   を含み、
   前記ファイル名とエンコードされた前記アドレスが制御文字によって分離される方法。
2. 前記署名付きファイルを認証するために必要な前記証明書にアクセス可能な前記アドレスをエンコードする前記ステップが、
   前記署名付きファイルを認証するために必要な前記証明書にアクセス可能な前記アドレスを分析して、所定の文字を検出するステップ（ステップ１３５）と、
   前記所定の文字を関連の文字で置き換えるステップ（ステップ１４０）と、
   を含み、
   前記所定の文字と前記関連の文字が辞書編集テーブル（１４５）に保管される、請求項１に記載の方法。
3. エンコードされた前記アドレスを前記ファイル名の拡張子点の前に挿入することにより、エンコードされた前記アドレスが前記ファイル名とマージされる、請求項１または請求項２のいずれかに記載の方法。
4. エンコードされた前記アドレスのサイズを低減するための圧縮ステップをさらに含む、請求項１ないし３のいずれか１項に記載の方法。
5. 署名付きファイルを認証するために必要な証明書にアクセス可能なアドレスがエンコードされているファイル名を有する前記署名付きファイルを認証する方法であって、
   エンコードされた前記アドレスを抽出するステップと、
   エンコードされた前記アドレスをデコードするステップ（ステップ２２５）と、
   デコードされた前記アドレスを使用して、前記署名付きファイルを認証するために必要な前記証明書にアクセスするステップ（ステップ２３０および２３５）と、
   アクセスされた前記証明書を使用して、前記署名付きファイルを認証するステップ（ステップ２４０〜２５５）と、
   を含む方法。
6. 前記署名付きファイルを認証する前に前記証明書をチェックするステップをさらに含む、請求項５に記載の方法。
7. 前記署名付きファイルを認証するために必要な前記証明書にアクセスする前記ステップが、
   前記証明書に含まれる情報に応じた認証機能をダウンロードするステップ
   をさらに含む、請求項５または請求項６のいずれかに記載の方法。
8. 前記署名付きファイルを認証する前記ステップが、前記署名付きファイルの保全性をチェックするステップと前記署名を検証するステップのうちの少なくとも１つを含む、請求項５ないし７のいずれか１項に記載の方法。
9. 前記証明書から公開鍵を抽出するステップをさらに含み、前記公開鍵が前記署名付きファイルを認証するために使用される、請求項５ないし８のいずれか１項に記載の方法。
10. 前記証明書が認証局のサーバに保管される、請求項１ないし９のいずれか１項に記載の方法。
11. 請求項１ないし１０のいずれか１項に記載の前記方法の各ステップを実行するために適合された手段を含む装置。
12. 請求項１ないし１０のいずれか１項に記載の前記方法の各ステップを実行するための命令を含むコンピュータ様可読媒体。

Images