(57)【特許請求の範囲】
【請求項１】
公開鍵証明書が以前にサスペンドされたか否か指示するシステムであって、
サスペンド・ヒストリ・フィールドを含む認証廃棄リストと、
公開鍵証明書がサスペンドされるときに、前記証明書を前記認証廃棄リスト上の一定のフィールドにリストする手段と、
前記公開鍵証明書のサスペンドが終了する場合には、（１）前記一定のフィールド内の証明書のリストを“サスペンド”から“レジューム”に変更し、（２）前記証明書のサスペンドの期間を前記認証廃棄リスト上の前記証明書のリスト内部の前記サスペンド・ヒストリ・フィールドにリストする手段とを備えるシステム。
【請求項２】
前記サスペンド・ヒストリ・フィールドは、前記認証廃棄リストによって管理され且つ定義された時刻の後にそのサスペンドが終了した全ての証明書をリストし、
前記定義された時刻は、前記認証廃棄リスト上の定義フィールドにおいて確認される請求項１に記載のシステム。
【請求項３】
前記リストする手段は、前記証明書のサスペンドの期間を、前記サスペンド・ヒストリ・フィールドにおいて確認する手段を含む請求項１に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般的には、通信の保護に関し、特に、証明書管理のためのスキームに関する。
【０００２】
【従来の技術】
公開鍵暗号手法は、現在、機密保護の分野での暗号ソリューションにおいて重要な役割を果たしている。この手順に関して、暗号化アルゴリズムは、例えば、秘密鍵および公開鍵として知られる、一対の関連した数字によってパラメータ化される。公開鍵は、全利用者にとって既知であり、誰でもが特定の指定受信者に対するメッセージを暗号化することを可能にする。そして、秘密鍵は、指定された受信者にとってのみ既知であり、その受信者個人のみがメッセージを復号化することを可能にする。
【０００３】
公開鍵は、典型的には、公開鍵証明書（ＩＴＵ勧告Ｘ．５０９：１９９３、以後［Ｘ．５０９］）によって配布される。公開鍵証明書は、ユーザの識別名，その識別名と関連している公開鍵，および識別名を鍵に結び付ける第三者機関（一般的に認証局あるいはＣＡと呼ばれる）のディジタル署名を含む。証明書は、一般的に、有効期間と１つの認証局に基づく全ての証明書を一意的に識別するシリアル番号とを含む、追加フィールドをも含む。事実上、署名は、鍵が特定のユーザと関連しているということの第三者機関の保証に役立つ。他のシステム・ユーザが、標準の手法を用いて、証明書署名が正しいということを首尾良く確認するときには、彼らは、証明書内の公開鍵が真正であるということを合理的に保証され得、適切な暗号アプリケーションに対する範囲内で公開鍵を安全に使用し始めることができる。
【０００４】
公開鍵証明書は、一般的にディレクトリ［Ｘ．５０９］と称されるパブリック・データベースに典型的に格納される。証明書内の有効期間は、その期間の後に全てのユーザが鍵とユーザとの間の結合を無効とみなすこととなる、証明書のデフォルト満了期日を暗黙指定する。証明書に署名した認証局が、何らかの理由で、正常の満了期日よりも前に公開鍵のその保証を取り消そうとする場合には、証明書を廃棄またはサスペンドするための方法が求められる。証明書を廃棄する理由は、対応する秘密鍵の秘密性が危ういこともしくは秘密性が危うい疑いであってもよく、あるいは鍵の必要性の早期の終了であってもよい。
【０００５】
証明書廃棄の１つの方法は、認証廃棄リストすなわちＣＲＬの使用を含む。［Ｘ．５０９］に従うＣＲＬは、各ペアが証明書シリアル番号と証明書が廃棄された時刻または日付とを指示する、データ項目のゼロ以上のペアのリストを含む。複合リストは、また、発行の日付あるいは有効期間を含み、認証性を保証するために認証局によってディジタル的に署名される。典型的に、単一ＣＲＬ（もしくは、理由コードによって定義されるＣＲＬのファミリ）は、各認証局によって発行された１組の証明書と関連しており、ＣＲＬは、定期的な間隔で（例えば、日ごとにあるいは週ごとに）更新される。証明書から公開鍵を使用のために取り出すよりも前に、賢明なシステム・ユーザは、証明書上の署名，現在時刻が満了期日よりも前であるということ，および当該証明書のシリアル番号が最も最近の有効なＣＲＬに載っていないということを確認する。
【０００６】
証明書は、その間に証明書が使用できる期日を含む。その使用可能期間の間、証明書は、それがサスペンドあるいは廃棄されたという場合を除いて有効である。サスペンドは、証明書上に置かれた一時的なホールドである。証明書が廃棄される場合、証明書の使用可能期間は廃棄の時以降永続的に終了される。その使用可能期間の後、証明書は失効したものとみなされる。ＣＡは、認証廃棄リストにおいて廃棄あるいはサスペンドされた証明書の状態を公表する。
【０００７】
証明書がサスペンドされるときに、証明書はＣＲＬ上にリストされ、その後そのサスペンドが終了する場合には、証明書がＣＲＬから除去される。現在のところ、証明書のサスペンドが終了した後に、証明書が特定のより早い時点においてサスペンドされていたのかされていなかったのか判別するための簡易かつ効果的な方法は存在しない。これは、証明書の一時的なサスペンドの有用性を大幅に制限する。
【０００８】
【発明が解決しようとする課題】
本発明の目的は、過去のディジタル署名がサスペンド（中断）された証明書によって発行されたか否か判別するシステムを提供することである。
【０００９】
本発明の他の目的は、非拒絶証明書の一時的なサスペンドを効果的かつ有用にすることである。
【００１０】
本発明のさらなる目的は、データ・サスペンドのヒストリを記録する認証廃棄リスト内部のデータ構造を提供することである。
【００１１】
【課題を解決するための手段】
大部分のディジタルに署名されたドキュメントは、その公開メンバがＸ．５０９証明書によって認証される鍵ペアに属する秘密鍵を用いて署名される（詳細についてはＩＴＵ標準Ｘ．５０９あるいはＩＳＯ標準９５９４を参照されたい）。このような署名の検査の一部は、通常はユーザの証明書を発行したのと同じＣＡである認証局（ＣＡ）によって発行された認証廃棄リスト（ＣＲＬ）のチェックを含む。本発明によれば、証明書サスペンド・ヒストリ（ＣＳＨ）が、証明書サスペンドのヒストリをＸ．５０９ＣＲＬ内部に記録するために与えられ、こうして、以降のベリファイヤは、証明書が一定のトランザクションが行われた時においてサスペンドされていたか否かチェックすることができる。ＣＳＨは、Ｘ．５０９バージョン３によって定義される既存データ構造であるＣＲＬエントリ拡張機能としてＣＲＬ内部に組み込まれる。証明書サスペンドが除去されるときはいつでも、認証局は、サスペンドの期間と任意に理由も含む証明書サスペンド・エントリを、新たにレジュームされた証明書を管理するＣＲＬに追加することを行う。証明書サスペンド・ヒストリは、証明書サスペンド・エントリのシーケンスから構成される。
【００１２】
ＣＲＬからの証明書サスペンド・ヒストリの不在に基づく結論を可能にするために、サスペンド・ヒストリ使用（ＳＨＵ）として知られ、任意に時刻を含むことができる追加ＣＲＬ拡張機能（ＣＲＬエントリ拡張機能ではない）が定義される。この拡張機能が時刻を備えて存在する場合には、その時刻以降に終了する全てのサスペンドは、証明書サスペンド・ヒストリに記録されていると安全に推定することができる。その拡張機能が時刻を備えずに存在している場合には、ＣＲＬによって管理される証明書に関係する全てのサスペンドは、証明書サスペンド・ヒストリに記録されていると安全に推定することができる。
【００１３】
本発明のさらなる利点および有益性は、添付の図面と関連して与えられた、本発明の好適な実施の形態を詳述し示す以下の詳細な説明の考察から明らかにすることができる。
【００１４】
【発明の実施の形態】
図１は、公開鍵証明書の実施例を提供する。証明書１００は、証明書フォーマットを識別するバージョン番号１１０を含む。シリアル番号１２０は、特定ＣＡの範囲内で固有であり、証明書１００を識別する。ディジタル署名アルゴリズム識別コード１３０は、署名１９０を作成するために使用されたアルゴリズムと指定されたアルゴリズムに必要とされる全てのパラメータとを識別する。発行名１４０は、証明書１００を発行し、署名１９０を用いてそれに署名した認証局を識別する。
【００１５】
有効期間１５０は、その間に証明書１００が使用できる（すなわち、その使用可能期間内）期日を指定する。証明書１００は、一定の期日まで有効であり、一定の期日の後に無効になる。証明書１００は、ユーザと関連した情報も含む。特に、ユーザのＩＤ（例えば名前）は、ユーザ名１６０に含まれ、ユーザの公開鍵は、ユーザ公開鍵１７０において証明書内に含まれる。証明書は、また、他のユーザ・データ１８０，例えば電子メール・アドレスあるいはユーザの誕生日をも含むことができる。
【００１６】
署名１９０は、証明書１００を認証するために受信者によって使用される。署名１９０は、多数の異なる手法を用いて生成可能である。例えば、署名１９０は、証明書１００のフィールド１１０−１８０のメッセージ・ダイジェストを計算し、ＣＡの秘密鍵を用いてメッセージ・ダイジェストを暗号化した結果とすることができる。ＣＡの公開鍵は、証明書１００の署名を確認するために使用される。
【００１７】
証明書は、その使用可能期間の間有効である。その使用可能期間よりも前あるいは後に、証明書は使用されるべきではない。上述したように、証明書はその使用可能期間の間に使用できなくなることがある（例えば廃棄されもしくはサスペンドされる）。例えば、ユーザの秘密鍵は、秘密性が危うくなることがある。証明書は公開鍵を含むので、証明書は使用されるべきではない。
【００１８】
証明書を使用できなくするために、ＣＡは、証明書を廃棄あるいはサスペンドする。定期的な方式に基づいて、ＣＡは、最後のＣＲＬが発行された以降廃棄またはサスペンドされた証明書を識別するＣＲＬを発行する。図２は、ＣＲＬリポート・フォーマットの実施例を提供する。ＣＲＬ２００は、ＣＲＬの発行者の名前２０２，ＣＲＬの発行の日付２０４，および次のＣＲＬ発行の日付２０６を含む。
【００１９】
最後のＣＲＬの発行以降廃棄またはサスペンドされた各証明書についてのエントリは、リポートの領域２１４に含まれる。各エントリは、証明書シリアル番号２０８，サスペンドまたは廃棄日時２１０，および場合によってサスペンドまたは廃棄の理由（例えば、秘密鍵の秘密性が危うい）２１２を含む。
【００２０】
領域２１４内の各エントリの証明書シリアル番号２０８を、特定の証明書がＣＲＬ２００に含まれるか否か判別するために検討する必要がある。領域２１４は、１以上のエントリを含むことが可能である。ＣＲＬ２００は、複数ページとすることができる。
【００２１】
証明書サスペンド・ヒストリ（ＣＳＨ）２２０が、証明書サスペンドのヒストリをＸ．５０９ＣＲＬ内部に記録するために与えられ、こうして、以降のベリファイヤは、証明書が一定のトランザクションが行われた時においてサスペンドされていたか否かチェックすることができる。ＣＳＨは、Ｘ．５０９バージョン３によって定義される既存データ構造であるＣＲＬエントリ拡張機能としてＣＲＬ内部に組み込まれる。証明書サスペンドが除去されるときはいつでも、認証局は、サスペンドの期間と任意に理由も含む証明書サスペンド・エントリを、新たにレジューム（中断再開）された証明書を管理するＣＲＬに追加することを行う。証明書サスペンド・ヒストリは、証明書サスペンド・エントリのシーケンスから構成される。
【００２２】
ＣＲＬからの証明書サスペンド・ヒストリの不在に基づく結論を可能にするために、サスペンド・ヒストリ使用（ＳＨＵ）２３０として知られ、任意に時刻を含むことができる追加ＣＲＬ拡張機能（ＣＲＬエントリ拡張機能ではない）が定義される。この拡張機能が時刻を備えて存在する場合には、その時刻以降に終了する全てのサスペンドは、証明書サスペンド・ヒストリに記録されていると安全に推定することができる。その拡張機能が時刻を備えずに存在している場合には、ＣＲＬによって管理される証明書に関係する全てのサスペンドは、証明書サスペンド・ヒストリに記録されていると安全に推定することができる。
【００２３】
証明書サスペンド・ヒストリは、項目２０８−２１２が生ずるのと同様に、領域２１４（ＣＲＬエントリ）内部に生じる。サスペンド・ヒストリ使用は、ここに提供された他のどのフィールドとも異なり、ＣＲＬの最後において全てのＣＲＬエントリに対してグローバルな別個の領域の内部に生じる。
【００２４】
証明書サスペンド・ヒストリの記録は、現行のＣＲＬを用いる定期のディジタル署名の検査が、署名がその証明書がサスペンドされていた鍵によって作成されたか否かを正確に判別することを可能にする。これは、非拒絶証明書の一時的なサスペンドを効果的かつ有用にする。図３〜５に関して、ベリファイヤは、非失効証明書に対する以下のヒューリスティックを求めることが可能である。
【００２５】
１．証明書内の公開鍵を用いてドキュメント上のディジタル署名を確認する。
【００２６】
２．署名の時点と現在との間の日付のある証明書を管理するＣＲＬを得る。
【００２７】
３．証明書と同じ証明書シリアル番号を備えるエントリをサーチする。
【００２８】
４．この証明書についてのエントリが１つも存在しない場合であって、サスペンド・ヒストリ使用拡張機能が存在し、かつ署名の時点よりも後の時刻を有さない場合にはＶＡＬＩＤ（有効）をリターンし、そうでなければＣＯＮＤＩＴＩＯＮＡＬＬＹ＿ＶＡＬＩＤ（条件付の有効）をリターンする。
【００２９】
５．この証明書についてのエントリが、署名の時点より後でない廃棄日付を備えて存在し、ＣＲＬからの除去の理由コードを備えない場合には、ＩＮＶＡＬＩＤ（無効）をリターンする。
【００３０】
６．この証明書についてのエントリが署名の時点の後の廃棄日付を備えて存在し、かつその内部に証明書サスペンド・ヒストリが１つもない場合であって、サスペンド・ヒストリ使用拡張機能が存在し、かつ署名の時点よりも後の時刻を有さない場合にはＶＡＬＩＤをリターンし、そうでなければＣＯＮＤＩＴＩＯＮＡＬＬＹ＿ＶＡＬＩＤをリターンする。
【００３１】
７．この証明書についてのエントリが存在し、かつその第１のエントリが署名の時点よりも前のサスペンド時刻を有する証明書サスペンド・ヒストリを含む場合であって、署名の時点が証明書サスペンド・エントリのうちの１つの時刻範囲以内である場合にはＩＮＶＡＬＩＤをリターンし、そうでなければＶＡＬＩＤをリターンする。
【００３２】
８．この証明書についてのエントリが存在し、かつその第１のエントリが署名の時点よりも前のサスペンド時刻を有さない証明書サスペンド・ヒストリを含む場合であって、サスペンド・ヒストリ使用拡張機能が存在し、かつ署名の時点よりも後の時刻を有さない場合にはＶＡＬＩＤをリターンし、そうでなければＣＯＮＤＩＴＩＯＮＡＬＬＹ＿ＶＡＬＩＤをリターンする。
【００３３】
９．この証明書についてのエントリが、署名の時点よりも後でない廃棄日付を備えて存在し、ＣＲＬからの除去の理由コードを備えるが、証明書サスペンド・ヒストリを備えない場合には、ＣＯＮＤＩＴＩＯＮＡＬＬＹ＿ＶＡＬＩＤをリターンする。
【００３４】
本発明において定義される２つの拡張機能の使用がなければ、最も強い有効可能性は、ステップ４，６および９からリターンするＣＯＮＤＩＴＩＯＮＡＬＬＹ＿ＶＡＬＩＤに相当する。
【００３５】
図６は、実際に定義された拡張機能の記述を提供する。
【００３６】
ここに開示された発明は、上述の目的を満たすために十分に適合するということが明らかである一方、非常に多くの変更および実施の形態が当業者によって考案可能であるということが理解できる。添付の特許請求の範囲は、本発明の真の趣旨および範囲に含まれる全ての変更および実施の形態を包含するということが意図される。
【図面の簡単な説明】
【図１】公開鍵証明書の実施例を提供する。
【図２】ＣＲＬレポートのフォーマットを説明する。
【図３】非失効証明書がより早い時点においてサスペンドされたか否か判別する手順を示すフローチャートを説明する。
【図４】非失効証明書がより早い時点においてサスペンドされたか否か判別する手順を示すフローチャートを説明する。
【図５】非失効証明書がより早い時点においてサスペンドされたか否か判別する手順を示すフローチャートを説明する。
【図６】本発明の好適な実施例において使用される拡張機能の記述である。
【符号の説明】
１００  証明書
１１０  バージョン番号
１２０  シリアル番号
１３０  ディジタル署名アルゴリズム識別コード
１４０  発行名
１５０  有効期間
１６０  ユーザ名
１７０  ユーザ公開鍵
１８０  他のユーザ・データ
１９０  署名
【図１】
0003628642.tif 000002
【図２】
0003628642.tif 000003
【図３】
0003628642.tif 000004
【図４】
0003628642.tif 000005
【図５】
0003628642.tif 000006
【図６】
0003628642.tif 000007