JP5158125B2 - 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体 - Google Patents

公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体 Download PDF

Info

Publication number
JP5158125B2
JP5158125B2 JP2010096580A JP2010096580A JP5158125B2 JP 5158125 B2 JP5158125 B2 JP 5158125B2 JP 2010096580 A JP2010096580 A JP 2010096580A JP 2010096580 A JP2010096580 A JP 2010096580A JP 5158125 B2 JP5158125 B2 JP 5158125B2
Authority
JP
Japan
Prior art keywords
path
public key
key certificate
certificate
validity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2010096580A
Other languages
English (en)
Other versions
JP2010161821A (ja
Inventor
洋子 熊谷
孝宏 藤城
忠司 鍛
慎吾 羽根
仁 下之薗
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2010096580A priority Critical patent/JP5158125B2/ja
Publication of JP2010161821A publication Critical patent/JP2010161821A/ja
Application granted granted Critical
Publication of JP5158125B2 publication Critical patent/JP5158125B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Description

本発明は、公開鍵基盤(Public Key Infrastructure:以下PKIという)において、ある端末が受け取った電子手続に対する署名を検証するための公開鍵証明書に関して、その有効性を確認するのに好適な技術に関する。
民間系、公共系の様々な組織、団体において、従来、書面で行ってきた様々な手続を電子化するべく、PKIの導入、整備が進んでいる。
図12は、PKIにおいて、認証局(Certificate Authority:以下CAという)が複数ある場合における各CAの関係の例を示している。
図示するように、公開鍵証明書の発行とその管理を行う各CAは、ルートCA1を頂点とするツリー構造を持つグループを形成している。このグループはセキュリティドメインと呼ばれており、1つのポリシー管理機関の基で運用されるPKIの単位である。ルートCA1は、自身より1つ下流側に位置する各CA2〜CA2に対して公開鍵証明書を発行する。また、CA2〜CA2各々は、自身より1つ下位に位置する各CA3〜CA3n1に対して公開鍵証明書を発行する。このように、ツリー上、1つ上位に位置するCAが自身より1つ下位側に位置するCAに対して公開鍵証明書を発行する。そして、ツリー上、最下位に位置するCA(以下、エンドエンティティ証明書発行CAと呼ぶ)CAs〜CAsnmは、電子手続を行うユーザ(以下、End Entity:EEと呼ぶ)EE〜EEに対して公開鍵証明書を発行する。
EE〜EE各々の装置が電子文書の署名を生成する際に使用する秘密鍵(署名鍵)
の正当性は、自身を収容する端末収容認証局CAs〜CAsnmが発行した公開鍵証明書によって証明され、端末収容認証局CAs〜CAsnm各々の装置が発行する公開鍵証明書の署名を生成する際に使用する秘密鍵の正当性は、自身を収容する認証局CA(s−1)〜CA(s−1)n(m−1)が発行した公開鍵証明書によって証明される。したがって、EE〜EE各々の装置が署名を生成する際に使用する秘密鍵は、最終的に、ルート認証局CA1が発行する公開鍵証明書によって証明される。このEE〜EEの装置が署名を生成する際に使用する鍵の正当性を最終的に証明する認証局、云いかえれば、EE〜EEが信頼する、ツリー上、最上位のCAをトラストアンカーCAと呼ぶ。
さて、図12において、EE装置は、EE装置に送信すべき電子文書に対して、EEが保持する自身の秘密鍵で署名を行う。そして、署名した電子文書に、CAsが発行した前記秘密鍵と対のEEの公開鍵証明書を添付して、EE装置に送信する。
EE装置は、EE装置から受け取った電子文書の署名を、当該電子文書に添付されたEEの公開鍵証明書を用いて検証することができる。しかし、EEの公開鍵証明書はEEの証明書発行CAsnmが発行したものではないので、EEは、自身のトラストアンカーCAであるルートCA1によって当該公開鍵証明書の有効性が証明されるものであることを確認しなければ、当該公開鍵証明書を信頼することはできない。この公開鍵証明書の有効性確認処理は、以下の手順によって行われる。
(1)トラストアンカーCAから公開鍵証明書の発行元CAまでのパスの検索
トラストアンカーCA(ここでは、ルートCA1)を起点CAとし、起点CAが発行した公開鍵証明書の発行先を調べ、当該発行先にCAが含まれる場合は当該CAが発行した公開鍵証明書の発行先をさらに調べる処理を、当該公開鍵証明書の発行先に、EE証明書発行CA(ここでは、EEの公開鍵証明書を発行するCAs1)が含まれるまで続け、トラストアンカーCAからEE証明書発行CAまでのパスを検索する。
(2)検索したパスの検証
上記(1)により検索したパス上の各CAから、パス上において当該CAの1つ下位側のCAに対して発行した公開鍵証明書を入手する。そして、有効性確認対象の公開鍵証明書(ここでは、EE証明書発行CAsがEEに対して発行した公開鍵証明書)の署名を、当該公開鍵証明書を発行したCA(ここでは、EE証明書発行CAs)より1つ上位のCAが発行した公開鍵証明書で検証し、検証できた場合は、当該1つ上位のCAが発行した公開鍵証明書の署名をさらに1つ上位のCAが発行した公開鍵証明書で検証する処理を、当該1つ上位のCAがトラストアンカーCAとなるまで続ける。そして、このような公開鍵証明書の署名検証がトラストアンカーまでできた場合に、有効性確認対象の公開鍵証明書の有効性が確認されたものとする。
EE装置は、EE装置より受け取った電子文書の署名を当該電子文書に添付されたEEの公開鍵証明書を用いて検証すると共に、上記の(1)、(2)に示す手順に従い当該電子文書の署名検証に用いたEEの公開鍵証明書の有効性を確認することにより、当該電子文書の正当性を確認することができる。
なお、以上では、公開鍵証明書の有効性確認処理をEE装置で行うことを前提としている。しかし、公開鍵証明書の有効性確認処理は負荷が重く、これをEEで行うためには、当該EE装置に高い処理能力が要求される。そこで、ネットワークを介してEE装置に接続された証明書の有効性確認局(以下、Validation Authority:VAという)を設け、当該VA装置に、当該EEの代わりに公開鍵証明書の有効性確認を行わせることが、インターネットに関するさまざまな技術の標準化を定める団体であるIETF(Internet Research Task Force)により提案されている。VA装置において、公開鍵証明書の有効性確認を行う場合、まずEE装置は公開鍵証明書の有効性確認依頼を、VA装置に送付する。次に、VA装置において、上記(1)、(2)の処理を行い、最後に、その結果をEE装置に送付する。
このとき、EE装置が公開鍵証明書の有効性確認を依頼してから、その結果が分かるまでにかかる時間を短くするための方法として、次のようなものがある。
VA装置において、予め定期的にパスを検索し、パスデータベースに登録しておく。そして、あるEE装置から公開鍵証明書の有効性確認の依頼があった場合に、VA装置のパスデータベースに、対応するパスを検索し、検索したパスの検証を行うことにより、前記公開鍵証明書の有効性を確認する(例えば特許文献1を参照)。
また、もう1つの方法では、VA装置において、予め定期的に全てのパスを検索し、検索したパスの検証を行う。検証が成功したパス(有効なパス)についてのみ、パスデータベースに登録しておく。そして、あるEE装置から公開鍵証明書の有効性確認の依頼があった場合に、VA装置のパスデータベースに、対応するパスが登録されているか否かを調べることで、前記公開鍵証明書の有効性を確認する(例えば特許文献2を参照)。
米国特許第6134550号明細書 米国特許出願公開第2002/046340号明細書
上記特許文献2に記載されていた方法では、EE装置から受け取った公開鍵証明書の有効性確認依頼に対応するパスが、パスデータベースに登録されていない場合は、有効性確認対象証明書が有効でないものと判断していた。しかし、この方法に従うと、パス検索時に存在しなかったパスが、EE装置からの公開鍵証明書の有効性確認依頼を受け取った時に、新たに存在する場合には、有効な公開鍵証明書を有効でないと判断してしまうことがある。上記特許文献2には、このような場合の処理については記述されていなかった。
また、上記特許文献1にも、EE装置から受け取った公開鍵証明書の有効性確認依頼に対応するパスが、パスデータベースに登録されていない場合の処理については記述されていなかった。
このような、VAで受け付けた有効性確認依頼に対応するパスがパスデータベースに登録されていない場合に、新たにパス検索、検証を行うことで適切な結果を応答することができる。しかし、この場合の有効性確認処理時間が長くなってしまうという課題がある。
現在、民間系、公共系のさまざまな組織、団体において、PKIの導入、整備が進んでおり、その結果、多数のセキュリティドメインが並列し、複雑なPKI構成となることが予想される。さらに、PKIを利用したアプリケーションが普及すると、たくさんの有効性確認依頼がなされると予想される。このような場合、EEが公開鍵証明書の有効性確認を依頼してから、その結果が分かるまでにかかる時間が長くなり、サービスの低下を招いてしまう。
上記課題を解決するために、本発明では、VA装置が、公開鍵証明書の有効性を確認するために以下の処理を行う。すなわち、VA装置において、パスの検索と、検索したパスの検証と、を行い、前記検索と検証の結果を、記憶部に登録し、公開鍵証明書の有効性確認要求に基づいて、当該有効性確認要求に対応する有効なパスが前記記憶部に登録されている場合、該パスを用いて検証し、当該有効性確認要求に対応する有効なパスが前記記憶部に登録されていない場合、新たにパス検索、および検証することにより、公開鍵証明書の有効性を短時間で確認する、というものである。
本発明によれば、パス検索時より後に新たなパスが形成された場合でも、適切な結果を応答することができ、および/または、EEが公開鍵証明書の有効性確認を依頼してからその結果が分かるまでにかかる時間を短縮することができる。
本発明の一実施形態が適用されたPKIシステムの概略構成を示す図である。 図1に示すPKIシステムでの各CAの関係の一例を示す図である。 図1に示すEEの概略構成を示す図である。 図1に示すVAの概略構成を示す図である。 図1に示すVAの概略構成を示す図である。 図3〜図5に示すEE、CAおよびVAの各々のハードウェア構成例を示す図である。 図5に示すVAで行われるパスの検索、検証および管理動作を説明するためのフロー図である。 図5に示すVAで行われるパスの検索、検証および管理動作を説明するためのフロー図である。 各CAが図2に示す関係にある場合に、VAのパス検索部51で検出される全てのパスを示す図である。 図5に示すVAで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。 図5に示すVAで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。 従来のPKIにおいて、認証局が複数ある場合におけるCAの関係の一例を示す図である。
図1は、本発明の一実施形態が適用されたPKIシステムの概略構成を示す図である。
本実施例のPKIシステムは、電子的に手続を行う複数のEE装置(11)〜EE装置(11)(EE装置(11)と総称する)と、公開鍵証明書発行業務を行うCA装置(13)〜CA装置(13)と、公開鍵証明書の有効性確認局VA(14)と、それぞれを接続するインターネット等のネットワーク(以下、NETという)16からなる。
図2は、図1に示すPKIシステムでの各CAの関係の一例を示す図である。
図示するように、本実施形態のPKIシステムでは、民間系、政府系といった複数のセキュリティドメインSD(SD1〜SD2)が並存していることを前提としている。また、各セキュリティドメインSDのルートCA(図2ではCA11、CA21、)は、例えば、ブリッジ認証局CAbridgeに対して公開鍵証明書を発行すると共に、CAbridgeから公開鍵証明書を発行してもらうことにより、CAbridgeとの間で相互認証を行っているものとする。このようにすることで、あるセキュリティドメインSDに属するCAと他のセキュリティドメインSDに属するCAとの間に、一方のCAが発行した公開鍵証明書の有効性を、他方のCAにて確認できるようにするためのパスが形成される。
次に、図1のPKIシステムを構成する各装置について説明する。
まず、図3を用いて、EE装置(11)を説明する。
EE装置(11)は、処理部30aと記憶部30bと、NET16を介して他装置と通信を行うための通信部30cと、ユーザ(EE)が作成した電子文書や他のEEから受け取った電子文書の入出力やユーザからの指示の受付を行う入出力部30dと、を有する。
処理部30aは、電子文書に対する署名を生成する署名生成部31と、署名の検証を行う署名検証部32と、EE装置の各部を統括的に制御する制御部33と、を有する。
記憶部30bは、利用者が作成した電子文書を保持する電子文書保持部34と、秘密鍵(署名鍵)と、これと対になる公開鍵の公開鍵証明書と、当該EE装置を運用するEEが信頼するCAの自己署名証明書を保持する鍵保持部35と、他のEEから受け取った署名付きの電子文書と公開鍵証明書を保持する検証対象保持部36と、を有する。
このような構成において、制御部33は、入出力部30dを介してユーザから、電子文書保持部34に保持してある電子文書を他のEEに送信すべき旨の指示を受け付けると、当該電子文書を電子文書保持部34から読み出し、これを署名生成部31に渡す。署名生成部31は、鍵保持部35に保持されている秘密鍵を用いて渡された当該電子文書に対する署名を生成する。
制御部33は、電子文書保持部34から読み出した電子文書に署名生成部31で生成された署名を付して、署名付き電子文書を作成し、作成した署名付き電子文書と鍵保持部35に保持されている公開鍵証明書とを、通信部30cを介して、ユーザから指示された送信先のEE装置へ送信する。制御部33は、通信部30cを介して、他のEE装置から署名付き電子文書と公開鍵証明書を受け取ると、これらを関連づけて検証対象保持部36に保持させると共に、これらの検証要求を署名検証部32に通知する。
これを受けて、署名検証部32は、検証対象保持部36に保持されている署名付き電子文書の署名を、対応する公開鍵証明書を用いて検証する。署名検証部32は、VA装置(14)に、上記の署名検証に用いた公開鍵証明書の有効性の確認依頼を送信する。この際、必要に応じて、前記署名付き電子文書により行おうとしている電子手続に関するポリシー(例えば、取引額等の信頼度)の検証依頼を、前記確認依頼に含める。そして、VA装置(14)において、上記ポリシーの検証も含めた当該公開鍵証明書の有効性が確認された場合にのみ、署名付き電子文書を正当なものとして扱い、必要に応じて入出力部30dから出力する。
次に、図4を用いてCA装置(13)を説明する。
CA装置(13)は、処理部40aと、記憶部40bと、NET16を介して他装置と通信を行うための通信部40cと、公開鍵証明書等の入出力や当該装置の操作者からの指示の受付や処理結果の出力を行う入出力部30dと、を有する。
処理部40aは、公開鍵証明書を発行する発行部41と、発行部41が発行した公開鍵証明書の管理を行う管理部42と、CA装置の各部を統括的に制御する制御部43と、を有する。
記憶部40bは、発行部41が発行した公開鍵証明書を保持する公開鍵証明書データベース44と、公開鍵証明書データベース44に保持されている各公開鍵証明書の発行先が
記述されていた発行先管理リストを保持する発行先管理リスト保持部45と、失効明書リスト保持部46と、を有する。
このような構成において、制御部43は、入出力部40dあるいは通信部40cを介して公開鍵証明書の発行依頼を受け付けると、その旨を発行部41に伝える。これを受けて、発行部41は、これに対する公開鍵証明書を作成する。この際、CAの秘密鍵で公開鍵証明書に署名をする。また、必要に応じて、公開鍵証明書中に、当該公開鍵証明書の有効期限や、信頼しない他の認証局の名称(Name Constrains)や、当該公開鍵証明書の有効性確認のために許容される最大パス長(パス上の許容最大認証局数)や、電子手続の取引額等を表したポリシーを記述する。そして、作成した公開鍵証明書を入出力部40dあるいは通信部40cを介して、郵送あるいは通信により、発行依頼元に渡す。また、この公開鍵証明書を公開鍵証明書データベース44に登録すると共に、その発行先(つまり発行依頼元)の情報を、発行先管理リスト保持部45に保持されている発行先管理リストに記述する。
制御部43は、入出力部40dあるいは通信部40cを介して、公開鍵証明書の失効依頼を受け付けると、その旨を管理部42に伝える。これを受けて、管理部42は、失効対象の公開鍵証明書を公開鍵証明書データベース43から削除すると共に、当該公開鍵証明書の発行先の情報を、発行先管理リスト保持部44に保持されている発行先管理リストから削除する。そして、管理部42は、失効依頼により公開鍵証明書データベース43から削除した公開鍵証明書に関する情報が記述された失効証明書リストを、定期的に作成し、これを失効証明書リスト保持部45に保持させる。なお、管理部42は、作成した失効証明書リストに、次回の失効証明書リストの作成予定日時を記述するものとする。
また、制御部43は、通信部40cを介して、他装置より公開鍵証明書の失効情報の問い合わせを受け取ると、失効証明書リスト保持部45に保持されている失効証明書リストを検索して、問い合わせのあった公開鍵証明書が失効しているか否かを調べる。そして、その結果を、通信部40cを介して、問い合わせをした他装置に応答することもできる。(このような問い合わせと応答に用いる通信プロトコルとして、OSCP(Online Certification status protocol)がある)。
管理部42は、公開鍵証明書データベース44に格納されている各公開鍵証明書の有効期限を調査し、有効期限を過ぎている公開鍵証明書の発行先の情報を、発行管理リスト保持部45に保持されている発行先管理リストから削除する処理も行う。
次に、図5を用いて、VA装置(14)を説明する。
図示するように、VA装置(14)は、処理部50aと、記憶部50bと、ネットワークNET16を介して他装置と通信を行うための通信部50cと、公開鍵証明書等の入出力やユーザよりの指示の受付けを行う入出力部50dと、を有する。
処理部50aは、パス検索部51と、パス検証部52と、有効期限/失効状態調査部53と、有効性確認部54と、VA装置の各部を統括的に制御する制御部55と、を有する。
また、記憶部50bは、パスデータベース56と、失効証明書リスト作成予定日データベース57とを有する。このうちパスデータベース56は、有効なパスデータベース56Aと、有効でないパスデータベース56Bと、を有する。
パス検索部51は、例えば定期的に、任意のCAをトラストアンカーCAとして、当該トラストアンカーCAから、EE証明書を発行する全てのEE証明書発行CAまでのパスを検索する。また、検出したパスのEE証明書発行CAが発行する、EE証明書に関する失効証明書リスト(CRL)を取得する。トラストアンカーCAは、全てのCA、または設定を設けることにより一部のCAとして、検索を行うことができる。
パス検証部52は、パス検索部51でパスの検索が行われる毎に、当該パス検索部51で検出されたパスの検証を行う。また、パス検索部51において当該パスに対応するCRLを取得できた場合には、当該CRLの検証を行う。そして、当該パスの両端に位置することとなる、トラストアンカーCAの名称と、EE証明書発行CAの名称とのペアに対応付けて、当該パスを構成する各CA名と、各証明書と、EE証明書に関するCRLとを、当該検証結果に応じて、有効なパスデータベース56A、または有効でないデータベース56Bに登録する。
有効期限/失効状態調査部53は、有効なパスデータベース56Aに登録されているパス各々について、当該パスを構成する各公開鍵証明書の有効期限や失効の有無を調査する。そして、その結果に応じてパスデータベース56を更新する。また、有効期限/失効状態調査部53は、各CAの失効証明書リスト保持部46から入手した失効証明書リストに記述されている次回の失効証明書リスト作成予定日時を当該CAに対応付けて、失効証明書リスト作成予定日時データベース57に登録する。
有効性確認部54は、EE装置からの依頼に従い、トラストアンカーCAを信頼の起点として、公開鍵証明書の有効性の確認を行う。
なお、図3〜図5に示すEE装置(11)、CA装置(13)とVA装置(14)の各々は、例えば、図6に示すような、CPU61と、メモリ62と、ハードディスク等の外部記憶装置63と、CD−ROM等の可搬性を有する記憶媒体69から情報を読み取る読み取り装置64と、NET16を介して他装置と通信を行うための通信装置65と、キーボードやマウス等の入力装置66と、モニタやプリンタ等の出力装置67と、これらの各装置間のデータ送受を行うインタフェース68とを備えた、一般的な電子計算機上に構築できる。
そして、CPU61が外部記憶装置63からメモリ62上にロードされた所定のプログラムを実行することにより、上述の各処理部を実現できる。すなわち、通信部30c、40c、50cは、CPU61が通信装置66を利用することにより、入出力部30d、40d、50dは、CPU61が入力装置66や出力装置67や読み取り装置64を利用することにより、そして、記憶部30b、40b、50bは、CPU61がメモリ62や外部記憶装置63を利用することにより実現される。また、処理部30a、40a、50aは、CPU61のプロセスとして実現される。
上記所定のプログラムは、予め外部記憶装置63に格納されていても良いし、上記電子計算機が利用可能な記憶媒体69に格納されており、読み取り装置64を介して、必要に応じて読み出され、あるいは、上記電子計算機が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置66と接続された他の装置から、必要に応じてダウンロードされて、外部記憶装置63に導入されるものであってもよい。
次に、上記構成のVA装置(14)の動作を説明する。
本実施形態のVA装置(14)の動作は、パスの検索、検証および管理動作と、公開鍵証明書の有効性の確認動作とに分かれる。
図7〜図8のフロー図を用いて、VA装置(14)で行われるパスの検索、検証および管理動作を説明する。
制御部55は、VAの運営者によって定められた所定時間(例えば1日)を経過すると(ステップS1001)、パスデータベース56の登録内容を一旦クリアし(ステップS1002)、パス検索部51にパス検索を依頼する。これを受けて、パス検索部51は、任意のCAをトラストアンカーCAとしたときの、EE証明書発行CAまでのパスを検索する(ステップS1003)。
具体的には、パス検索部51は、トラストアンカーCAにアクセスし、トラストアンカーCAが発行し、発行先管理リスト保持部45に保持されている、公開鍵証明書の発行先の情報を入手する。そして、入手した各発行先がCAの場合は、各発行先にアクセして、発行先管理リスト保持部45に保持されている、各CAが発行した公開鍵証明書の発行先をさらに調べる。この処理を、公開鍵証明書の発行先がEEとなるまで続けることにより、トラストアンカーCAからEE証明書発行CAまでのパスを検索する。ここで、パスのループにより上記の処理が無限に繰り返されるのを防止するため、あるCAから入手した発行先に、それまでに形成された部分パスに存在するCAが含まれる場合は、当該CAを発行先とした上記の処理を行わないものとする。また、パスの端点に位置するEEへ証明書を発行したCAが発行するCRLを取得する。
ステップS1003でのパス検索処理を、各CAが図2に示す関係にある場合を例に取り、より具体的に説明する。
まず、パス検索部51は、トラストアンカーCAをCAbridgeとしてパス検索を行う。パス検索部51は、CAbridgeにアクセスし、発行先管理リスト保持部45に保持されている、CAbridgeが発行した公開鍵証明書の発行先の情報として、CA11、CA21の情報を入手する。
次に、パス検索部51は、CAbridgeから入手した発行先(CA11、CA21
)のうちのいずれか1つに注目して、以下の処理を実行する。すなわち、注目した発行先がCA(以下、注目CAと呼ぶこととする)であるならば、CAbridge−注目CAという部分パスを設定する。そして、注目CAの発行先管理リスト保持部45にアクセスして、当該注目CAが発行した公開鍵証明書の発行先の情報をさらに入手する。ここでは、注目した発行先がCA11であるとして、CAbridge−CA11という部分パスを設定し、CA11から、発行先の情報として、CAbridge、CA12、CA13の情報を入手したものとする。
次に、パス検索部51は、認証局CA11から入手した発行先(CAbridge、CA12、CA13)に、部分パス上のCA(以下、ループCAと呼ぶこととする)が含まれているか否かを調べる。含まれている場合はその発行先を注目対象から除外する。したがって、ここでは、CAbridgeを注目対象から除外することになる。次に、パス検索部51は、CA11から入手した発行先にEEが含まれるか否かを調べる。あるCAが発行した証明書の発行先にEEが含まれている場合、そのCAはEE証明書発行CAとなる。しかし、CA11から入手した発行先にEEは含まれていないので、CA11はEE証明書発行CAではない。したがって、CAbridge−CA11という部分パスを、EE証明書発行CAまで延長すべく、CA11から入手した、ループCAを除く発行先(CA12、CA13)のうちのいずれか1つに注目する。
注目した発行先がCAであるならば、それまでに設定した部分パスにこの注目CAを接続した部分パスを設定する。そして、この注目CAの発行先管理リスト保持部45にアクセスして、当該注目CAが発行した公開鍵証明書の発行先の情報をさらに入手する。ここでは、注目した発行先がCA12であるとして、CAbridge−CA11−CA12というパスを設定し、CA12から、発行先の情報として、EE、EEを入手したものとする。
次に、パス検索部51は、CA12から入手した発行先(EE、EE)に、ループ
CAが含まれているか否かを調べる。含まれている場合はその発行先を注目対象から除外する。ここでは、ループCAは含まれないので、パス検索部51は、次の処理へ移行し、CA12から入手した発行先にEEが含まれるか否かを調べる。ここで、入手した発行先はすべてEEであるので、CA12はEE証明書発行CAである。そこで、このCA12を端点とするパスを、トラストアンカーCAbridgeから、EE証明書発行CA12までのパス(CAbridge−CA11−CA12)として検出する。
さらに、パス検索部51は、EE証明書発行CAまでのパスを検出した場合、当該EE証明書発行CA12が発行するCRLを、失効証明書リスト保持部46にアクセスし、取得する。
次に、パス検索部51は、検出したパス上の端点に位置するCA12から入手した発行先の情報の中に、未だ注目していない発行先(ループCA以外のCA)があるか否かを調べ、そのような発行先があれば、これを注目CAとして、上記の処理を続ける。一方、そのような発行先がなければ、1つ前に位置するCA11から入手した発行先の情報の中に、未だ注目していない発行先(ループCA以外のCA)があるか否かを調べる。そして、そのような発行先があれば、これを注目CAとして、上記の処理を続ける。ここでは、CA11から入手した発行先の情報のうち、CA13について未だ注目していないので、これを注目CAとして上記の処理を行うことにより、CAbridgeからEE証明書発行CA13までのパス(CAbridge−CA11−CA13)およびCA13が発行するCRLを検出する。
このように、パス検索部51は、上記の処理を、検出したパス上に位置する全てのCA各々について、当該CAから入手した発行先の情報の中に、未だ注目していない発行先(ループCA以外のCA)がなくなるまで続けることにより、CAbridgeからEE証明書発行CAまでのパスを検出する。
以上が、任意のCAをトラストアンカーCAとした場合のステップ1003の処理である。
後述するように、CA11、CA21各々のCAをトラストアンカーCAとした場合に
ついても、同様にパス検索を行う。
制御部55は、パス検索部51によりパスが検出されると(ステップS1004でYes)、パス検証部52にパスの検証を依頼する。これを受けて、パス検証部52は、パス検索部51により検出されたパスの検証を行う(ステップS1005)。
具体的には、パス検索部51により検出されたパス各々について、以下の処理を行う。
すなわち、まず、パス検証部52は、パス上の各CAの公開鍵証明書データベース44にアクセスし、各CAが当該パス上の1つ次に位置するCA(アクセス先CAがEE証明書発行CAの場合はEE)に対して発行した公開鍵証明書を入手する。
次に、パス検証部52は、パスの最後に位置するEE証明書発行CAが発行した公開鍵証明書の署名を、EE証明書発行CAの公開鍵証明書で検証し、検証できた場合は当該EE証明書発行CAの公開鍵証明書の署名をさらに1つ前に位置するCAの公開鍵証明書で検証する。この処理を、当該1つ前に位置する認証局CAがトラストアンカーCAとなるまで続けることにより、当該パスを検証する。さらに、当該EE証明書発行CAが発行するCRLについて、当該EE証明書発行CAの公開鍵証明書で検証する。
例えば、図2においてCAbridgeからEE証明書発行CA12までのパス(CAbridge−CA11−CA12)およびCRLを検証する場合、まず、EE証明書発行CA12の公開鍵証明書の署名を、パス中でCA12の1つ前に位置するCA11の公
開鍵証明書を用いて検証する。そして、検証できた場合は、CA11の公開鍵証明書の署名を、パス中でCA11より1つ前に位置するCAbridgeの公開鍵証明書を用いて検証する。そして、この検証できた場合、さらに、当該EE証明書発行CA12が発行するCRLについて、当該EE証明書発行CA12の公開鍵証明書で検証する。この、パスおよびCRLの検証できた場合に、CAbridgeからEE証明書発行CA12までのパスが仮に検証できたものとする。
次に、パス検証部52は、パスが仮に検証できたならば、当該パス上の各認証局CAから入手した公開鍵証明書中に、信頼しない他の認証局の名称(Name Constrains)や当該公開鍵証明書の有効性確認のために許容される最大パス長(パス上の許容最大認証局数)などの制限の記述があるか否かを調べる。そのような記述がある場合は、当該パスがその制限を満たしているか否かを調べ、満たしている場合にのみ、当該パスが検証できたものとする。
さて、制御部55は、上記のようにして、パス検索部51により検出されたパス各々に対するパス検証部52での検証が終了したならば、登録処理を行う。制御部55は、パス検証部52でパスが検証できた場合(ステップS1006でYes)、当該パスをトラストアンカーCAと、EE証明書発行CAと、EE証明書発行CAが発行するCRLと、に対応付けて、有効なパスデータベース56Aに登録し(ステップS1007)、ステップS1003へ移行する。また、制御部55は、パス検証部52でパスが検証できなかった場合(ステップS1006でNo)、当該パスをトラストアンカーCAと、EE証明書発行CAと、EE証明書発行CAが発行するCRLと、に対応付けて、有効でないパスデータベース56Bに登録し(ステップS1008)、ステップ1003へ移行する。
制御部55は、ステップS1003〜ステップS1008のステップを、パスが検出されなくなる(ステップS1004でNo)まで繰り返し、パスデータベース56を作成する。このとき、全てのCAをトラストアンカーとして、対応する全てのパスを検索する。
CAの構成が図2の場合は、CA11、CA21、CAbridgeの3つのCAをトラストアンカーとして、各々に対応する全てのパスを検索する。
ステップS1003〜ステップS1008までの処理を行った結果、各CAが図2に示す関係にある場合、パス検索部51により検出される、全てのパスは、図9に示すとおりとなる。
一方、有効期限/失効状態調査部53は、有効なパスデータベース56Aに登録されている公開鍵証明書の中に、有効期限切れの公開鍵証明書があるか否かを調べる(ステップS1009)。有効期限切れの公開鍵証明書がある場合は、当該公開鍵証明書の発行元CAの公開鍵証明書データベース44にアクセスして、当該公開鍵証明書の発行先に対して新たに発行された公開鍵証明書を検索する(ステップS1010)。
そして、そのような公開鍵証明書が前記発行元CAの公開鍵証明書データベース44中になければ、前記有効期限切れの公開鍵証明書に対応付けて登録されているパスに関する情報を、有効なパスデータベース56Aから削除し、有効でないパスデータベース56Bへ登録する(ステップS1011)。一方、そのような公開鍵証明書が前記発行元CAの公開鍵証明書データベース44中にあればこれを入手する。そして、前記有効期限切れの公開鍵証明書に対応付けて、有効なパスデータベース56Aに登録されているパスの検証を、当該有効期限切れの公開鍵証明書の代わりに新たに入手した公開鍵証明書を用いて、上記のステップS1005と同じ要領で行う(ステップS1012)。
さて、パスが検証できた場合(ステップS1013でYes)は、当該パスに対応付けられて有効なパスデータベース56Aに登録されている前記有効期限切れの公開鍵証明書を、新たに入手した公開鍵証明書に置き換える(ステップS1014)。一方、パスが検証できなかった場合(ステップS1013でNo)は、前記有効期限切れの公開鍵証明書に対応付けて登録されているパスを、有効なパスデータベース31から削除し、新たに入手した公開鍵証明書に置き換えたパスを、有効でないパスデータベースに置き換える(ステップS1015)。
次に、有効期限/失効状態調査部53は、失効証明書リスト作成予定日時データベース57を調べ、既に経過した失効証明書リスト作成予定日時に対応付けられているCAを検索する(ステップS1016)。そのような認証局CAが存在する場合(ステップS1017でYes)は、当該CAの失効証明書リスト保持部46にアクセスして、当該CAが発行した最新の失効証明書リストを入手する(ステップS1018)。そして、失効証明書リスト作成予定日時データベース57にて、当該認証局CAに対応付けて登録されている失効証明書リスト作成予定日時を、入手した最新の失効証明書リストに記述されている失効証明書リスト作成予定日時に更新する(ステップS1019)。
それから、有効期限/失効状態調査部53は、入手した最新の失効証明書リストに記述されている公開鍵証明書が、有効なパスデータベース56Aに登録されているか否かを調べ(ステップS1020)、登録されている場合は、当該公開鍵証明書に対応付けられているパスに関する情報を有効なパスデータベース56Aから削除し、有効でないパスデータベース56Bへ登録する(ステップS1021)。
次に、公開鍵証明書の有効性の確認動作について説明する。
図10〜図11は、本実施形態のVA装置(14)で行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
制御部55は、通信部50cを介して、EEから、少なくとも当該EEが信頼するトラストアンカーCAの名称を含んだ、他EEの公開鍵証明書の有効性確認依頼を受け取ると(ステップS2001)、その旨を有効性確認部54に通知する。
これを受けて、有効性確認部54は、証明書の有効性確認依頼の記述から特定される、トラストアンカーCAと、当該証明書を発行したEE証明書発行CAと、に対応付けられたパスが、有効なパスデータベース56Aに登録されているか否かを調べる(ステップS2002)。
その結果、証明書の有効性確認依頼に記述された、トラストアンカーCAと、当該証明書を発行したEE証明書発行CAと、に対応付けられたパスが、有効なパスデータベース56Aに登録されていることが確認できたならば(ステップS2002でYes)、有効性確認部54は、当該パスの端点であるEE証明書発行CAの公開鍵証明書を用いて、EE証明書の署名検証を行う。さらに、有効性確認部54は、当該パスと対応付けられて登録されているCRLを用いて、EE証明書が失効していないかどうかを確認する(ステップS2003)。
EE証明書の署名検証が失敗した場合(ステップ2003でNo)、又はEE証明書がCRLに記述され失効されていた場合、有効性確認部54は、EE証明書有効でないものと判断し、その旨を、通信部50cを介して、依頼元のEEに通知する(ステップS2009)。
一方、各証明書には、信頼しない認証局名による制限や、当該公開鍵証明書の有効性確認のために許容される最大パス長(パス上の許容最大認証局数)を記述できる拡張項目がある。ステップ2003で、EE証明書の署名検証および、失効していないかどうかの確認が成功した場合(Yesの場合)、EE証明書および当該パスに含まれる各CAの証明書に、上述の制限が記述されているか否かをさらに調べる(ステップS2004)。
そのような制限の記述がない場合、ステップS2006に移行する。
そのような制限の記述がある場合は、ステップS2005に移行して、EE証明書がその制限に反していないか否かを調べる。EE証明書が制限事項に反している場合、有効性確認部54は、公開鍵証明書が有効性でない旨を、通信部50cを介して、依頼元のEE装置(11)に通知する(ステップS2009)。EE証明書が制限事項に反していない場合は、ステップS2006に移行する。
ステップS2006では、有効性確認部54は、EE装置(11)から受け取った確認依頼に、当該EEが行おうとしている電子手続の取引額等を示したポリシーが含まれているか否かを調べる。
ポリシーが含まれている場合は、EE証明書および当該パスを構成する各公開鍵証明書中に、前記ポリシーを満たすポリシーの記述があるか否かをさらに調べる(ステップS2007)。
EE証明書および当該パスに、前記ポリシーを満たすポリシーの記述がない場合は、EE証明書を、依頼元のEEが行おうとしている電子手続のための公開鍵証明書の有効性確認に利用できないものと判断し、公開鍵証明書が有効でない旨を、通信部50cを介して、依頼元のEE装置(11)に通知する(ステップS2009)。
一方、EEから受け取った確認依頼に当該EEが行おうとしている電子手続を示すポリシーが含まれていない場合(ステップS2006でNo)、あるいは、含まれていても、当該パスおよびEE証明書に記述されているポリシーが前記ポリシーを満たす場合(ステップS2007でYes)は、公開鍵証明書は有効であると判断し、公開鍵証明書が有効である旨を、通信部50cを介して、依頼元のEEに通知する(ステップS2008)。
また、ステップS2002において、証明書の有効性確認依頼に記述された、トラストアンカーCAと、当該証明書を発行したEE証明書発行CAと、に対応付けられたパスが、有効なパスデータベース56Aに登録されていない場合(ステップS2002でNo)、当該パスが有効でないパスデータベース56Bに登録されているか否かを確認する(ステップS2010)。有効でないデータベース56Bに、当該パスが登録されていない場合(ステップS2010でNo)、図11のステップS2012に移行する。
ステップS2012では、パス検索部51が、確認依頼記述されたトラストアンカーCAから、確認対象のEE証明書までのパスを検索する。この検索は、パス検索部51が予め定められた所定の規則に従って行うものとは異なり、臨時に行う。
パス検索部51が、トラストアンカーCAから、EE証明書までのパスを検出しなかった場合(ステップS2013でNo)、有効性確認部54は、EE証明書が有効性でない旨を、通信部50cを介して、依頼元のEEに通知する(ステップS2019)。一方、パス検索部51が、トラストアンカーCAから、EE証明書までのパスを検出した場合(ステップS2013でYes)、パス検証部52において、検出したパスを検証する(ステップS2014)。
検出したパスが検証できた場合(ステップS2015でYes)、当該パスのトラストアンカーCAから、EE証明書発行CAまでのパスと、EE証明書発行CAが発行するCRLを、有効なパスデータベースへ登録する(ステップS2016)。そして、有効性確認部54は、EE証明書が有効性である旨を、通信部50cを介して、依頼元のEEに通知する(ステップS2017)。
一方、ステップ2015において、検出したパスが検証できなかった場合(S2015でNo)、当該パスのトラストアンカーCAから、EE証明書発行CAまでのパスと、EE証明書発行CAが発行するCRLを、有効でないパスデータベースへ登録する(ステップS2018)。そして、ステップS2011へ移行し、これまで検出したパス以外に、パスが存在するかどうか検索を行い、それ以降のステップを同じように実行する。
また、図10のステップ2010において、有効でないパスデータベース56Bに、当該パスが登録されていた場合(ステップS2010でYes)、さらに当該登録されていたパス以外に、有効性確認依頼に対応するパスを検出した場合(ステップS2011でYes)、ステップS2014に移行し、当該検出したパスの検証、登録処理を行う(ステップS2014〜ステップS2019)。
一方、当該登録されていたパス以外に、有効性確認依頼に対応するパスを検出しなかった場合(ステップS2011でNo)、有効性確認部54は、公開鍵証明書が有効性でない旨を、通信部50cを介して、依頼元のEEに通知する(ステップS2009)。
以上の実施形態では、トラストアンカーCAから各EE証明書発行CAまでのパスの検索および検証を、EEからの公開鍵証明書の有効性確認依頼とは独立した所定の規則に従って、例えば定期的に行う。
検索、検証したパスは、有効なパスまたは有効でないパスに分類し、パスデータベースに登録しておく。そして、有効性確認依頼に対応するパスが、有効なパスとして登録されているか、有効でないパスとして登録されているかを調べることにより、当該EE証明書が有効であるか否かを判断する。
このとき、当該有効性確認依頼に対するパスが、有効でないパスに登録されている場合は、当該有効でないパス以外に対応するパスがあるかどうかを、検索、検証し、確認を行う。また、当該有効性確認依頼に対するパスが、パスデータベースに登録されていない場合には、パス検索、検証を臨時に行う。したがって、認証局の構成が変化した場合にも、最新のパス情報により検証を行うため、適切な有効性確認結果を応答することができる。また、有効でないパスをキャッシュしておくことにより、公開鍵証明書を受け付けてから、当該有効性を確認するまでにかかる時間を短縮することができる。
また、本実施形態では、パスを登録する際に、パスの端点となるEE証明書発行CAが発行するCRLを、当該CRLの検証結果とともに登録しておく。そして、あるEEから公開鍵証明書の有効性確認依頼を受けた場合、当該EE証明書が失効しているかどうかを、当該CRLを用いて確認する。したがって、公開鍵証明書の有効性確認にかかる時間をより短縮することができる。
なお、本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内数々の変形が可能である。
例えば、上記の実施形態では、VAは、パスをデータベースに登録する際に、有効なパスデータベース56Aと、有効でないパスデータベース56Bの、二つのデータベースに分類して登録している。しかし、一つのデータベースに、当該パスの状態を示すフラグをつけて、有効なパスと、有効でないパスを分類してもよい。
また、上記の実施形態では、説明をわかりやすくするため、図2に示すように、EE証明書発行CAはEEに対してのみ公開鍵証明書を発行し、その他のCAはCAに対してのみ公開鍵証明書を発行するものと仮定したが、EEとCAの両方に対して公開鍵証明書を発行するCAを含む場合でも、本発明は適用できる。
また、上記の実施形態では、説明を分かりやすくするため、図2に示すように、CAの構成を階層構造と仮定したが、CAの構成がより複雑なメッシュ構造となっている場合でも、本発明は適用できる。
CA・・・認証局,VA・・・証明書の有効性確認局,EE・・・エンドエンティティ,SD・・・セキュリティドメイン,11・・・EE,12・・・EE,13・・・CA,14・・・CA,15・・・VA,16・・・VA,30a,40a,50a・・・処理部,30b,40b,50b・・・記憶部,30c,40c,50c・・・通信部,30d,40d,50d・・・入出力部,31・・・署名生成部,32・・・署名検証部,33,43,55・・・制御部,34・・・電子文書保持部,35・・・鍵保持部,36・・・検証対象保持部,41・・・発行部,42・・・管理部,44・・・公開鍵証明書データベース,45・・・発行先管理リスト保持部,46・・・失効証明書リスト保持部,51・・・パス検索部,52・・・パス検証部,53・・・有効期限/執行状態調査部,54・・・有効性確認部,56・・・パスデータベース,56A・・・有効なパスデータベース,56B・・・有効でないパスデータベース,57・・・失効証明書リスト作成予定日時データベース,61・・・CPU、62・・・メモリ、63・・・外部記憶装置、64・・・読取装置、65・・・通信装置、66・・・入力装置、67・・・出力装置、68・・・インタフェース、69・・・記憶媒体。

Claims (8)

  1. 証明書の有効性確認局装置により実施する、公開鍵証明書の有効性確認方法であって、
    パスの検索と、検索したパスの検証と、を行うステップと、
    前記検索と検証の結果を、記憶部に登録する、パス登録ステップと、
    公開鍵証明書の有効性確認要求に基づいて、当該有効性確認要求に対応する有効なパスが前記記憶部に登録されている場合、該パスを用いて検証し、当該有効性確認要求に対応する有効なパスが前記記憶部に登録されていない場合、新たにパス検索、および検証する、有効性確認ステップと、を有する公開鍵証明書の有効性確認方法
  2. 請求項1記載の公開鍵証明書の有効性確認方法であって、
    前記パス登録ステップにおいて、前記パスの検索と、該検索したパスの検証結果に応じて、前記有効なパスか、有効でないパスかを示す情報を前記記憶部に登録し、
    前記有効性確認ステップにおいて、当該有効性確認要求に対応するパスが、前記有効なパス、または前記有効でないパスとして、前記記憶部に登録されている場合は、前記登録結果に従って、前記依頼された公開鍵証明書の有効性確認を行う公開鍵証明書の有効性確認方法
  3. 請求項2記載の公開鍵証明書の有効性確認方法であって、
    前記有効性確認ステップにおいて、当該有効性確認要求に対応するパスが、前記有効なパスとして前記記憶部に登録されている場合でも、当該公開鍵証明書または当該パスに含まれる公開鍵証明書に、制限事項が記述されている場合は、前記有効性確認要求に応じてパス検証を行い、
    当該公開鍵証明書および当該パスが前記制限事項を満たしているかどうかを調べるステップと、
    制限事項を満たしていれば、前記有効なパスと判断するステップと、を有する公開鍵証明書の有効性確認方法
  4. 請求項2記載の公開鍵証明書の有効性確認方法であって、
    前記有効性確認ステップにおいて、当該有効性確認要求に対応するパスが、前記有効なパスとして前記記憶部に登録されている場合でも、当該有効性確認要求または当該公開鍵証明書または当該パスに含まれる公開鍵証明書に、ポリシーが記載されている場合は、前記有効性確認要求に応じてパス検証を行い、当該公開鍵証明書および当該パスが、電子手続きのポリシーを満たしているかどうかを調べるステップと、
    前記ポリシーを満たしている場合に、前記有効なパスと判断するステップと、を有する公開鍵証明書の有効性確認方法
  5. 請求項2記載の、公開鍵証明書の有効性確認方法であって、
    前記パス登録ステップは、トラストアンカー認証局から、エンドエンティティ証明書を発行する認証局までのパスを検索するステップと、
    当該エンドエンティティ証明書を発行する認証局が発行する、エンドエンティティ証明書に関する失効リストを取得、検証するステップと、
    当該失効リストの検証結果とともに、失効リストを登録するステップと、を有する公開鍵証明書の有効性確認方法
  6. 請求項5記載の公開鍵証明書の有効性確認方法であって、
    前記有効性確認ステップにおいて、当該有効性確認要求に対応するパスが、前記記憶部に有効なパスとして登録されている場合、前記失効リストの検証を行わずに、当該公開鍵証明書が失効していないことを確認する公開鍵証明書の有効性確認方法
  7. コンピュータに、請求項1乃至6の何れか1項に記載の公開鍵証明書の有効性確認方法を実行させるためのプログラム。
  8. コンピュータにより読み出し可能なプログラムを格納した記憶媒体であって、請求項7記載のプログラムを格納したことを特徴とする記憶媒体。
JP2010096580A 2010-04-20 2010-04-20 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体 Expired - Lifetime JP5158125B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010096580A JP5158125B2 (ja) 2010-04-20 2010-04-20 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010096580A JP5158125B2 (ja) 2010-04-20 2010-04-20 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2006103728A Division JP4529936B2 (ja) 2006-04-05 2006-04-05 公開鍵証明書検証の高速化方法、および装置

Publications (2)

Publication Number Publication Date
JP2010161821A JP2010161821A (ja) 2010-07-22
JP5158125B2 true JP5158125B2 (ja) 2013-03-06

Family

ID=42578576

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010096580A Expired - Lifetime JP5158125B2 (ja) 2010-04-20 2010-04-20 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体

Country Status (1)

Country Link
JP (1) JP5158125B2 (ja)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1145259A (ja) * 1997-07-25 1999-02-16 Canon Inc ハイパーテキスト閲覧装置及び方法及び記憶媒体
JP3588042B2 (ja) * 2000-08-30 2004-11-10 株式会社日立製作所 証明書の有効性確認方法および装置
JP2002163395A (ja) * 2000-11-27 2002-06-07 Hitachi Software Eng Co Ltd 電子証明書有効性確認支援方法とそれを用いる情報処理装置

Also Published As

Publication number Publication date
JP2010161821A (ja) 2010-07-22

Similar Documents

Publication Publication Date Title
JP3894181B2 (ja) 公開鍵証明書検証の高速化方法、および装置
JP3588042B2 (ja) 証明書の有効性確認方法および装置
JP5452099B2 (ja) 証明書の有効性確認方法、証明書検証サーバ、プログラム及び記憶媒体
JP5576985B2 (ja) 署名に用いる暗号アルゴリズムの決定方法、検証サーバおよびプログラム
EP2187590B1 (en) Method of validation public key certificate and validation server
JP4594962B2 (ja) 検証サーバ、プログラム及び検証方法
JP4474845B2 (ja) Crl発行通知機能付き認証基盤システム
US7409553B2 (en) Public key certificate generation method, validation method and apparatus thereof
JP2011193416A (ja) 証明書の有効性確認方法、検証サーバ、プログラム及び記憶媒体
EP3966997A1 (en) Methods and devices for public key management using a blockchain
JP5743946B2 (ja) サービス提供装置、共同署名検証装置、利用者の識別・認証方法及びプログラム
KR100844436B1 (ko) 지역적인 공개키 기반 구조를 갖는 지역분포형 로컬 씨에이시스템
JP4529936B2 (ja) 公開鍵証明書検証の高速化方法、および装置
JP2013225938A (ja) 公開鍵証明書の検証方法及び検証サーバ
JP5158125B2 (ja) 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体
JP2006277186A (ja) 分散計算機管理プログラム、分散計算機管理装置、分散計算機管理方法
JP5018849B2 (ja) Crl発行通知機能付き認証基盤システム
JP5641493B2 (ja) 公開鍵証明書検証処理システム
JP2004297639A (ja) 公開鍵証明書の失効情報提供方法、および装置
JP2006174518A (ja) Crl発行通知機能付き認証基盤システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100420

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121018

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121113

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121126

R151 Written notification of patent or utility model registration

Ref document number: 5158125

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151221

Year of fee payment: 3

EXPY Cancellation because of completion of term