JP3588042B2 - 証明書の有効性確認方法および装置 - Google Patents
証明書の有効性確認方法および装置 Download PDFInfo
- Publication number
- JP3588042B2 JP3588042B2 JP2000261065A JP2000261065A JP3588042B2 JP 3588042 B2 JP3588042 B2 JP 3588042B2 JP 2000261065 A JP2000261065 A JP 2000261065A JP 2000261065 A JP2000261065 A JP 2000261065A JP 3588042 B2 JP3588042 B2 JP 3588042B2
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- public key
- path
- validity
- key certificate
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）において、ある端末が受け取った電子手続に対する署名を検証するための公開鍵証明書が、当該端末が信頼する認証局とは異なる認証局が発行したものである場合に、その有効性を確認するのに好適な技術に関する。
【０００２】
【従来の技術】
民間系、公共系の様々な組織、団体において、従来、紙面で行ってきた様々な手続を電子化するべく、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の導入、整備が進んでいる。
【０００３】
図１２は、従来のＰＫＩにおいて、認証局が複数ある場合における各認証局の関係を示している。
【０００４】
図示するように、公開鍵証明書の発行とその管理を行う各認証局は、ルート認証局ＣＡ１を頂点とするツリー構造を持つグループを形成している。このグレープはセキュリティドメインと呼ばれている。ルート認証局ＣＡ１は、自身より１つ下流側に位置する各認証局ＣＡ２１〜ＣＡ２ｎに対して公開鍵証明書を発行する。また、認証局ＣＡ２１〜ＣＡ２ｎ１各々は、自身より１つ下流側に位置する各認証局ＣＡ３１〜ＣＡ３ｎ２に対して公開鍵証明書を発行する。このように、ツリー上、１つ上流側に位置する認証局が自身より１つ下流側に位置する認証局に対して公開鍵証明書を発行する。そして、ツリー上、最下流に位置する認証局（以下、端末収容認証局と呼ぶ）ＣＡＳ１〜ＣＡＳｎｍは、電子手続を行うユーザ端末（以下、エンドエンティティと呼ぶ）ＥＥ１〜ＥＥｘに対して公開鍵証明書を発行する。
【０００５】
エンドエンティティＥＥ１〜ＥＥｘ各々が電子文書の署名に使用する秘密鍵（署名鍵）の正当性は、自身を収容する端末収容認証局ＣＡＳ１〜ＣＡＳｎｍが発行した公開鍵証明書によって証明され、端末収容認証局ＣＡＳ１〜ＣＡＳｎｍ各々が発行する公開鍵証明書の署名に使用する秘密鍵の正当性は、自身を収容する認証局ＣＡ（Ｓ−１）１〜ＣＡ（Ｓ−１）ｎ（ｍ−１）が発行した公開鍵証明書によって証明される。したがって、エンドエンティティＥＥ１〜ＥＥｘ各々が署名に使用する秘密鍵は、最終的に、ルート認証局ＣＡ１が発行する公開鍵証明書によって証明されることになる。このエンドエンティティＥＥ１〜ＥＥｘが署名に使用する鍵の正当性を最終的に証明する認証局、云いかえれば、エンドエンティティＥＥ１〜ＥＥｘが信頼する、ツリー上、最上流側の認証局をトラストアンカーと呼ぶ。
【０００６】
さて、図１２において、エンドエンティティＥＥ１は、エンドエンティティＥＥｘに送信すべき申請書等の電子文書に対して、エンドエンティティＥＥ１が保持する自身の秘密鍵で署名を行う。そして、署名した電子文書に、エンドエンティティＥＥ１を収容する端末収容認証局ＣＡＳ１が発行した前記秘密鍵と対の公開鍵証明書を添付して、エンドエンティティＥＥｘに送信する。
【０００７】
エンドエンティティＥＥｘは、エンドエンティティＥＥ１より受け取った電子文書の署名を、当該電子文書に添付された公開鍵証明書を用いて検証することができる。しかし、公開鍵証明書はエンドエンティティＥＥｘを収容する端末収容認証局ＣＡＳｎｍが発行したものではないので、エンドエンティティＥＥｘは、当該公開鍵証明書を直ちに信頼することはできない。この場合、エンドエンティティＥＥｘは、自身のトラストアンカーであるルート認証局ＣＡ１によって当該公開鍵証明書の有効性が証明されるものであることを確認しなければならない。この公開鍵証明書の有効性確認処理は、以下の手順によって行われる。
【０００８】
▲１▼トラストアンカーから公開鍵証明書の発行元認証局までのパスの検索
トラストアンカー（ここでは、ルート認証局ＣＡ１）を起点認証局とし、起点認証局が発行した公開鍵証明書の発行先を調べ、当該発行先に認証局が含まれる場合は当該認証局が発行した公開鍵証明書の発行先をさらに調べる処理を、当該公開鍵証明書の発行先に、公開鍵証明書の発行元認証局（ここでは、エンドエンティティＥＥ１を収容する端末収容認証局ＣＡＳ１）が含まれるまで続け、トラストアンカーから公開鍵証明書の発行元認証局までのパスを検索する。
【０００９】
▲２▼検出したパスの検証
上記▲１▼により検出したパス上の各認証局から、パス上において当該認証局の１つ下流側の認証局に対して発行した公開鍵証明書を入手する。そして、有効性確認対象の公開鍵証明書（ここでは、端末収容認証局ＣＡＳ１がエンドエンティティＥＥ１に対して発行した公開鍵証明書）の署名を、当該公開鍵証明書を発行した認証局（ここでは、端末収容認証局ＣＡＳ１）より１つ上流側の認証局が発行した公開鍵証明書で検証し、検証が成立した場合は、当該１つ上流側の認証局が発行した公開鍵証明書の署名をさらに１つ上流側の認証局が発行した公開鍵証明書で検証する処理を、当該１つ上流側の認証局がトラストアンカーとなるまで続ける。そして、このような公開鍵証明書の署名検証がトラストアンカーまで成立した場合に、有効性確認対象の公開鍵証明書の有効性が確認されたものとする。
【００１０】
エンドエンティティＥＥｘは、エンドエンティティＥＥ１より受け取った電子文書の署名を当該電子文書に添付された公開鍵証明書を用いて検証すると共に、上記の▲１▼、▲２▼に示す手順に従い当該電子文書の署名検証に用いた公開鍵証明書の有効性を確認することにより、当該電子文書の正当性を確認することができる。
【００１１】
なお、以上では、公開鍵証明書の有効性確認処理をエンドエンティティで行うことを前提としている。しかし、公開鍵証明書の有効性確認処理は負荷が重く、これをエンドエンティティで行うためには、当該エンドエンティティに高い処理能力が要求される。そこで、ネットワークを介してエンドエンティティに接続された証明書の有効性確認サーバを設け、当該サーバに、当該エンドエンティティの代わりに公開鍵証明書の有効性確認を行わせることがＩＥＴＦにより提案されている。
【００１２】
【発明が解決しようとする課題】
ところで、従来提案されている証明書の有効性確認サーバは、エンドエンティティから依頼を受ける都度、上記の▲１▼、▲２▼に示す手順を実行して公開鍵証明書の有効性を確認している。このため、エンドエンティティが公開鍵証明書の有効性確認を依頼をしてからその結果がわかるまでに、少なくとも、上記の▲１▼、▲２▼に示す手順を実行するための時間がかかってしまう。
【００１３】
なお、図１２では、セキュリティドメインが１つであることを前提にしているが、上述したように、民間系、公共系の様々な組織、団体においてＰＫＩの導入、整備が行われており、その結果、複数のセキュリティドメインが並存することが予想される。これらの異なるセキュリティドメイン間においても、各セキュリティドメインのルート認証局同士で、互いに相手の公開鍵証明書を発行するなどして相互認証を行ったり、あるいは、各セキュリティドメインのルート認証局各々との間でこのような相互認証を行ったブリッジ認証局を設置することにより、上記の▲１▼、▲２▼にその手順を示した公開鍵証明書の有効性確認処理を実現することができる。しかしこのように、複数のセキュリティドメイン間で公開鍵証明書の有効性確認処理を行うと、認証局数が増大し、また、各認証局の関係も、図１２に示すような単純なツリー構造ではなく、より複雑化するため、上記の▲１▼、▲２▼に示す手順を実行するための負荷が増大する。このため、エンドエンティティが公開鍵証明書の有効性確認を依頼をしてからその結果がわかるまでにかかる時間がさらに長くなり、サービスの低下を招いてしまう。
【００１４】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短くすることにある。
【００１５】
【課題を解決するための手段】
上記課題を解決するために、本発明では、ネットワークを介して、複数の端末（エンドエンティティ）や認証局に接続された証明書の有効性確認サーバにおいて、ある端末からの依頼に応じて、当該端末が信頼する認証局とは異なる認証局が発行した公開鍵証明書の有効性を確認するために以下の処理を行う。
【００１６】
すなわち、任意の認証局を起点認証局とし、当該起点認証局が発行した公開鍵証明書の発行先を調べ、当該発行先に認証局が含まれる場合は当該認証局が発行した公開鍵証明書の発行先をさらに調べる処理を、当該公開鍵証明書の発行先が全て端末となるまで続けることにより、前記起点認証局から任意の端末に対して公開鍵証明書を発行した端末収容認証局までのパスを検索するパス検索ステップと、
前記パス検索ステップにより検出されたパスについて、前記起点認証局を上流とし、当該パス上の端末収容認証局が発行した公開鍵証明書の署名を１つ上流側の認証局が発行した公開鍵証明書で検証し、検証が成立した場合は当該１つ上流側の認証局が発行した公開鍵証明書の署名をさらに１つ上流側の認証局が発行した公開鍵証明書で検証する処理を、当該１つ上流側の認証局が前記起点認証局となるまで続けることにより、当該パスを検証するパス検証ステップと、
前記パス検証ステップにより検証が成立したパスをデータベースに登録するパス登録ステップとを、端末からの公開鍵証明書の有効性確認依頼とは無関係に、例えば定期的に行う。
【００１７】
そして、ある端末から、当該端末が信頼する認証局とは異なる端末収容認証局が発行した公開鍵証明書の有効性確認依頼があった場合に、前記端末が信頼する認証局と前記起点認証局との間のパス、および、前記異なる端末収容認証局と前記起点認証局との間のパスが、前記データベースに登録されているか否かを調べることで、前記公開鍵証明書の有効性を確認する。
【００１８】
本発明によれば、ある端末から公開鍵証明書の有効性確認依頼を受けた場合に、それから、上記の▲１▼、▲２▼に示した、当該端末のトラストアンカーから当該公開鍵証明書の発行元認証局までのパスの検索、および、検出したパスの検証を行う必要がない。したがって、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短縮できる。
【００１９】
【発明の実施の形態】
以下に、本発明の一実施形態について説明する。
【００２０】
図１は、本発明の一実施形態が適用されたＰＫＩシステムの概略構成を示す図である。
【００２１】
図示するように、本実施形態のＰＫＩシステムは、電子手続を行うユーザ端末あるいはユーザ端末からの依頼を受けて電子手続を代行する受付サーバである複数のエンドエンティティＥＥと、公開鍵証明書の発行とその管理を行う複数の認証局ＣＡと、エンドエンティティＥＥからの依頼に応じ公開鍵証明書の有効性の確認を行う証明書有効性確認センタＶＣとが、ＬＡＮ、ＷＡＮおよびこれらを繋ぐインターネット等により構成されたネットワークＮＥＴを介して、互いに接続されて構成される。
【００２２】
図２は、図１に示すＰＫＩシステムでの各認証局ＣＡの関係の一例を示す図である。
【００２３】
図示するように、本実施形態のＰＫＩシステムでは、民間系、政府系といった複数のセキュリティドメインＳＤ（ＳＤ１〜ＳＤ３）が並存していることを前提としている。そして、そのうちの幾つかのセキュリティドメインＳＤ（図２ではＳＤ２、ＳＤ３）は、ルート認証局ＣＡ（図２ではＣＡ２１、ＣＡ３１）同士で、例えば互いに公開鍵証明書を発行し合うことにより相互認証を行っているものとする。また、各セキュリティドメインＳＤのルート認証局ＣＡ（図２ではＣＡ１１、ＣＡ２１、ＣＡ３１）は、例えば、ブリッジ認証局ＣＡｂｒｉｄｇｅに対して公開鍵証明書を発行すると共に、ブリッジ認証局ＣＡｂｒｉｄｇｅから公開鍵証明書を発行してもらうことにより、ブリッジ認証局ＣＡｂｒｉｄｇｅとの間で相互認証を行っているものとする。このようにすることで、あるセキュリティドメインＳＤに属する認証局ＣＡと他のセキュリティドメインＳＤに属する認証局ＣＡとの間に、一方の認証局ＣＡが発行した公開鍵証明書の有効性を、他方の認証局ＣＡにて確認できるようにするためのパスが形成される。
【００２４】
次に、上記のＰＫＩシステムを構成するエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣについて説明する。
【００２５】
まず、エンドエンティティＥＥについて説明する。
【００２６】
図３は、エンドエンティティＥＥの概略構成を示す図である。
【００２７】
図示するように、エンドエンティティＥＥは、処理部１０ａと、記憶部１０ｂと、ネットワークＮＥＴを介して他装置と通信を行うための通信部１６と、ユーザが作成した電子文書や他のエンドエンティティＥＥあるいはユーザ端末から受け取った電子文書の入出力やユーザよりの指示の受付けを行う入出力部１７と、を有する。
【００２８】
処理部１０ａは、署名生成部１４と、署名検証部１５と、エンドエンティティＥＥの各部を統括的に制御する制御部１８と、を有する。
【００２９】
記憶部１０ｂは、ユーザが作成した（エンドエンティティＥＥが受付サーバの場合はユーザ端末から受け取った）電子文書を保持する電子文書保持部１１と、秘密鍵（署名鍵）とこれに対の公開鍵証明書とを保持する鍵保持部１２と、他のエンドエンティティＥＥから受け取った署名付きの電子文書と公開鍵証明書を保持する検証対象保持部１３と、を有する。
【００３０】
このような構成において、制御部１８は、入出力部１７を介してユーザから、電子文書保持部１１に保持してある電子文書を他のエンドエンティティＥＥに送信すべき旨の指示を受け付けると、当該電子文書を電子文書保持部１１から読み出し、これを署名生成部１４に渡す。これを受けて、署名生成部１４は、鍵保持部１２に保持されている秘密鍵を用いて当該電子文書に対する署名を生成する。それから、制御部１８は、電子文書保持部１１から読み出した電子文書に署名生成部１４で生成された署名を付して、署名付き電子文書を作成する。そして、作成した署名付き電子文書に鍵保持部１２に保持されている公開鍵証明書を添付して、通信部１６を介して、ユーザより指示された送信先のエンドエンティティＥＥのアドレスへ送信する。
【００３１】
また、制御部１８は、通信部１６を介して、他のエンドエンティティＥＥから署名付き電子文書と公開鍵証明書を受け取ると、これらを検証対象保持部１３に保持させると共に、その旨を署名検証部１５に通知する。これを受けて、署名検証部１５は、検証対象保持部１３に保持されている署名付き電子文書の署名を、当該電子文書と共に受け取った公開鍵証明書を用いて検証する。そして、検証が成立した場合にのみ、署名付き電子文書を正当なものとして扱い、必要に応じて入出力部１７から出力する。
【００３２】
ただし、上記の署名検証が成立した場合でも、当該署名検証に用いた公開鍵証明書が、自エンドエンティティＥＥを収容する（つまり、自エンドエンティティＥＥに対して公開鍵証明書を発行した）端末収容認証局ＣＡ以外の端末収容認証局ＣＡの場合は、証明書有効性確認センタＶＣに、上記の署名検証に用いた公開鍵証明書の有効性の確認依頼を送信する。この際、必要に応じて、前記署名付き電子文書により行おうとしている電子手続の取引額等で示した信頼度（ポリシー）を、前記確認依頼に含める。そして、証明書有効性確認センタＶＣにて、当該公開鍵証明書の有効性が確認された場合にのみ、署名付き電子文書を正当なものとして扱い、必要に応じて入出力部１７から出力する。
【００３３】
次に、認証局ＣＡについて説明する。
【００３４】
図４は、認証局ＣＡの概略構成を示す図である。
【００３５】
図示するように、認証局ＣＡは、処理部２０ａと、記憶部２０ｂと、ネットワークＮＥＴを介して他装置と通信を行うための通信部２６と、公開鍵証明書等の入出力やユーザよりの指示の受付けを行う入出力部２７と、を有する。
【００３６】
処理部２０ａは、公開鍵証明書を発行する発行部２１と、発行部２１が発行した公開鍵証明書の管理を行う管理部２２と、認証局ＣＡの各部を統括的に制御する制御部２８と、を有する。
【００３７】
記憶部２０ｂは、発行部２１が発行した公開鍵証明書を保持する公開鍵証明書データベース２３と、公開鍵証明書データベース２３に保持されている各公開鍵証明書の発行先が記述された発行先管理リストを保持する発行先管理リスト保持部２４と、失効証明書リスト保持部２５と、を有する。
【００３８】
このような構成において、制御部２８は、入出力部２７あるいは通信部２６を介して、公開鍵証明書の発行依頼を受け付けると、その旨を発行部２１に伝える。これを受けて、発行部２１は、発行依頼主が署名生成に用いる秘密鍵（署名鍵）とこれに対の公開鍵証明書を作成する。この際、自認証局ＣＡの秘密鍵で公開鍵証明書に署名をする。また、必要に応じて、公開鍵証明書中に、当該公開鍵証明書の有効期限や、信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や、当該公開鍵証明書の有効性確認のために許容される最大パス長（パス上の許容最大認証局数）や、電子手続の取引額等で表した当該公開鍵証明書と対の秘密鍵による署名の信頼度（ポリシー）を記述する。そして、作成した公開鍵証明書と秘密鍵を、入出力部２７あるいは通信部２６を介して、郵送あるいは通信により、発行依頼主に渡す。また、この公開鍵証明書を公開鍵証明書データベース２３に登録すると共に、その発行先（つまり発行依頼主）の情報を、発行先管理リスト保持部２４に保持されている発行先管理リストに記述する。
【００３９】
また、制御部２８は、入出力部２７あるいは通信部２６を介して、公開鍵証明書の失効依頼を受け付けると、その旨を管理部２２に伝える。これを受けて、管理部２２は、失効対象の公開鍵証明書を公開鍵証明書データベース２３から削除すると共に、当該公開鍵証明書の発行先の情報を、発行先管理リスト保持部２４に保持されている発行先管理リストから削除する。そして、管理部２２は、失効依頼により公開鍵証明書データベース２３から削除した公開鍵証明書に関する情報が記述された失効証明書リスト（一般に、ＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）、ＡＲＬ（Ａｕｔｈｏｒｉｔｙ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）と呼ばれている）を、定期的に作成し、これを失効証明書リスト保持部２５に保持させる。なお、管理部２２は、作成した失効証明書リストに、次回の失効証明書リストの作成予定日時を記述するものとする。
【００４０】
また、制御部２８は、通信部２６を介して、他装置より公開鍵証明書の失効情報の問い合わせを受け取ると、失効証明書リスト保持部２５に保持されている失効証明書リストを検索して、問い合わせのあった公開鍵証明書が失効しているか否かを調べる。そして、その結果を、通信部２６を介して、問い合わせをした他装置に応答する（このような問い合わせと応答に用いる通信プロトコルとして、ＯＳＣＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｉｏｎ ｓｔａｔｕｓ ｐｒｏｔｏｃｏｌ）がある）。
【００４１】
なお、管理部２２は、公開鍵証明書データベース２３に格納されている各公開鍵証明書の有効期限を調査し、有効期限を過ぎている公開鍵証明書を公開鍵証明書データベース２３から削除すると共に、当該公開鍵証明書の発行先の情報を、発行先管理リスト保持部２４に保持されている発行先管理リストから削除する処理も行う。
【００４２】
次に、証明書有効性確認センタＶＣについて説明する。
【００４３】
図５は、証明書有効性確認センタＶＣの概略構成を示す図である。
【００４４】
図示するように、証明書有効性確認センタＶＣは、処理部３０ａと、記憶部３０ｂと、ネットワークＮＥＴを介して他装置と通信を行うための通信部３６と、公開鍵証明書等の入出力やユーザよりの指示の受付けを行う入出力部３７と、を有する。
【００４５】
処理部３０ａは、パス検索部３２と、パス検証部３３と、有効期限／失効状態調査部３４と、有効性確認部３５と、証明書有効性確認センタＶＣの各部を統括的に制御する制御部３８とを有する。また、記憶部３０ｂは、パスデータベース３１と、失効証明書リスト作成予定日時データベース３９とを有する。
【００４６】
パス検索部３１は、定期的に、ブリッジ認証局ＣＡｂｒｉｄｇｅからエンドエンティティＥＥに対して公開鍵証明書を発行した各端末収容認証局ＣＡまでのパスを検索する。
【００４７】
パス検証部３２は、パス検索部３１でパスの検索が行われる毎に、当該パス検索部３１で検出されたパスの検証を行う。そして、検証が成立したパスを、証明書有効性確認センタＶＣを上流とした場合に当該パス上の最下流に位置することとなる端末収容認証局ＣＡの名称と、当該パス上の各認証局ＣＡから入手した当該パス上の１つ下流側に位置する認証局ＣＡ（発行元の認証局ＣＡが端末収容認証局ＣＡの場合はエンドエンティティＥＥ）に対して発行した公開鍵証明書とに対応付けて、パスデータベース３１に登録する。
【００４８】
有効期限／失効状態調査部３４は、パスデータベース３１に登録されているパス各々について、当該パス上の各認証局ＣＡが当該パス上の１つ下流側に位置する認証局ＣＡ（発行元の認証局ＣＡが端末収容認証局ＣＡの場合はエンドエンティティＥＥ）に対して発行した公開鍵証明書の有効期限や失効の有無を調査する。そして、その結果に応じてパスデータベース３３を更新する。
【００４９】
また、有効期限／失効状態調査部３４は、各認証局ＣＡの失効証明書リスト保持部２５から入手した失効証明書リストに記述されている次回の失効証明書リスト作成予定日時を当該認証局ＣＡに対応付けて、失効証明書リスト作成予定日時データベース３９に登録する。
【００５０】
有効性確認部３５は、エンドエンティティＥＥからの依頼に従い、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡ以外の端末収容認証局ＣＡが発行した公開鍵証明書の、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡに対する有効性の確認を行う。
【００５１】
なお、図３〜図５に示すエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣの各々は、例えば、図６に示すような、ＣＰＵ６１と、メモリ６２と、ハードディスク等の外部記憶装置６３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体６９から情報を読み取る読取装置６４と、ネットワークを介して他装置と通信を行うための通信装置６５と、キーボードやマウス等の入力装置６６と、モニタやプリンタ等の出力装置６７と、これらの各装置間のデータ送受を行うインターフェース６８とを備えた、一般的な電子計算機において、ＣＰＵ６１がメモリ６２上にロードされた所定のプログラムを実行することにより、実現できる。すなわち、通信部１６、２６、３６は、ＣＰＵ６１が通信装置６６を利用することにより、入出力部１７、２７、３７は、ＣＰＵ６１が入力装置６６や出力装置６７や読取装置６４を利用することにより、そして、記憶部１０ｂ、２０ｂ、３０ｂは、ＣＰＵ６１がメモリ６２や外部記憶装置６３を利用することにより実現される。また、処理部１０ａ、２０ａ、３０ａは、ＣＰＵ６１上のプロセスとして実現される。
【００５２】
このような、電子計算機上にエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣを各々実現するための所定のプログラムは、読取装置６４を介して記憶媒体６９から読み出され、あるいは、通信装置６６を介してネットワーク経由で他のサーバからダウンロードされて、一旦、外部記憶装置６３に格納された後、そこからメモリ６２上にロードされて、あるいは、外部記憶装置６３に格納されることなく、直接メモリ６２上にロードされて、ＣＰＵ６１に実行されるようにすればよい。
【００５３】
次に、上記構成の証明書有効性確認センタＶＣの動作について説明する。
【００５４】
本実施形態の証明書有効性確認センタＶＣの動作は、パスの検索、検証および管理動作と、公開鍵証明書の有効性の確認動作とに分かれる。
【００５５】
まず、パスの検索・検証および管理動作について説明する。
【００５６】
図７〜図８は、本実施形態の証明書有効性確認センタＶＣで行われるパスの検索、検証および管理動作を説明するためのフロー図である。
【００５７】
制御部３８は、所定時間（例えば１日）を経過すると（ステップＳ１００１）、パス検索部３２にパス検索を依頼する。これを受けて、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを検索する（ステップＳ１００２）。
【００５８】
具体的には、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅの発行先管理リスト保持部２４にアクセスし、ブリッジ認証局ＣＡｂｒｉｄｇｅが発行した公開鍵証明書の発行先の情報を入手する。そして、入手した各発行先が認証局ＣＡの場合は、各発行先の認証局ＣＡの発行先管理リスト保持部２４にアクセスして、各認証局ＣＡが発行した公開鍵証明書の発行先をさらに調べる。この処理を、公開鍵証明書の発行先がエンドエンティティＥＥとなるまで続けることにより、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを検索する。ここで、パスのループにより上記の処理が無限に繰り返されるのを防止するため、ある認証局ＣＡの発行先管理リスト保持部２４から入手した発行先に、それまでに形成された部分パスの上流側に位置する認証局ＣＡが含まれる場合は、当該認証局ＣＡを発行先とした上記の処理を行わないものとする。
【００５９】
ステップＳ１００２でのパス検索処理を、各認証局ＣＡが図２に示す関係にある場合を例に取り、より具体的に説明する。
【００６０】
まず、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅの発行先管理リスト保持部２４にアクセスし、ブリッジ認証局ＣＡｂｒｉｄｇｅが発行した公開鍵証明書の発行先の情報として、認証局ＣＡ１１、ＣＡ２１、ＣＡ３１の情報を入手する。
【００６１】
次に、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅから入手した発行先（認証局ＣＡ１１、ＣＡ２１、ＣＡ３１）のうちのいずれか１つに注目して、以下の処理を実行する。
【００６２】
すなわち、注目した発行先が認証局ＣＡ（以下、注目認証局ＣＡと呼ぶこととする）であるならば、ブリッジ認証局ＣＡｂｒｉｄｇｅ−注目認証局ＣＡ間に、ブリッジ認証局ＣＡｂｒｉｄｇｅ側を上流とする部分パスを設定する。そして、注目認証局ＣＡの発行先管理リスト保持部２４にアクセスして、当該注目認証局ＣＡが発行した公開鍵証明書の発行先の情報をさらに入手する。ここでは、注目した発行先が認証局ＣＡ１１であるとして、ブリッジ認証局ＣＡｂｒｉｄｇｅ−認証局ＣＡ１１間に部分パスを設定し、認証局ＣＡ１１から、発行先の情報として、認証局ＣＡｂｒｉｄｇｅ、ＣＡ１２、ＣＡ１３の情報を入手したものとする。
【００６３】
次に、パス検索部３２は、認証局ＣＡ１１から入手した発行先（認証局ＣＡｂｒｉｄｇｅ、ＣＡ１２、ＣＡ１３）に、部分パス上の認証局ＣＡ（以下、ループ認証局ＣＡと呼ぶこととする）が含まれているか否かを調べる。含まれている場合はその発行先を注目対象から除外する。したがって、ここでは、認証局ＣＡｂｒｉｄｇｅを注目対象から除外することになる。次に、パス検索部３２は、認証局ＣＡ１１から入手した発行先にエンドエンティティＥＥが含まれるか否を調べる。エンドエンティティＥＥが含まれている場合、認証局ＣＡ１１は端末収容認証局となる。しかし、認証局ＣＡ１１から入手した発行先にエンドエンティティＥＥは含まれていない。したがって、ブリッジ認証局ＣＡｂｒｉｄｇｅ−認証局ＣＡ１１間に設定した部分パスを、端末収容認証局ＣＡまで延長すべく、認証局ＣＡ１１から入手した、ループ認証局ＣＡを除く発行先（認証局ＣＡ１２、ＣＡ１３）のうちのいずれか１つに注目する。
【００６４】
注目した発行先が認証局ＣＡであるならば、それまでに設定した部分パスの下流側にこの注目認証局ＣＡを接続した部分パスを設定する。そして、この注目認証局ＣＡの発行先管理リスト保持部２４にアクセスして、当該注目認証局ＣＡが発行した公開鍵証明書の発行先の情報をさらに入手する。ここでは、注目した発行先が認証局ＣＡ１２であるとして、ブリッジ認証局ＣＡｂｒｉｄｇｅ−認証局ＣＡ１１−認証局ＣＡ１２間に部分パスを設定し、認証局ＣＡ１２から、発行先の情報として、エンドエンティティＥＥ１、ＥＥ２を入手したものとする。
【００６５】
次に、パス検索部３２は、認証局ＣＡ１２から入手した発行先（ＥＥ１、ＥＥ２）に、ループ認証局ＣＡが含まれているか否かを調べる。含まれている場合はその発行先を注目対象から除外する。ここでは、ループ認証局ＣＡは含まれないので、パス検索部３２は、次の処理へ移行し、端末収容認証局ＣＡ１２から入手した発行先にエンドエンティティＥＥが含まれるか否を調べる。ここで、入手した発行先はすべてエンドエンティティＥＥであるので、認証局ＣＡ１２は端末収容認証局である。そこで、この認証局ＣＡ１２を最下流とする部分パスを、ブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１２までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ１１−ＣＡ１２）として検出する。
【００６６】
次に、パス検索部３２は、検出したパス上の最下流側に位置する認証局ＣＡ１２から入手した発行先の情報の中に、未だ注目していない発行先（ループ認証局ＣＡ以外の認証局ＣＡ）があるか否かを調べ、そのような発行先があれば、これを注目認証局ＣＡとして、上記の処理を続ける。一方、そのような発行先がなければ、１つ上流側に位置する認証局ＣＡ１１から入手した発行先の情報の中に、未だ注目していない発行先（ループ認証局ＣＡ以外の認証局ＣＡ）があるか否かを調べる。そして、そのような発行先があれば、これを注目認証局ＣＡとして、上記の処理を続ける。ここでは、認証局ＣＡ１１から入手した発行先の情報のうち、認証局ＣＡ１３について未だ注目していないので、これを注目認証局ＣＡとして上記の処理を行うことにより、ブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１３までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ１１−ＣＡ１３）を検出する。
【００６７】
このように、パス検索部３２は、上記の処理を、検出したパス上に位置する全ての認証局ＣＡ各々について、当該認証局ＣＡから入手した発行先の情報の中に、未だ注目していない発行先（ループ認証局ＣＡ以外の認証局ＣＡ）がなくなるまで続けることにより、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを検出する。その結果、各認証局ＣＡが図２に示す関係にある場合、パス検索部３２により検出される、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスは、図９に示すとおりとなる。
【００６８】
さて、制御部３８は、パス検索部３２によりブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスが検出されると、パス検証部３３にパスの検証を依頼する。これを受けて、パス検証部３３は、パス検索部３２により検出されたパスの検証を行う（ステップＳ１００３）。
【００６９】
具体的には、パス検索部３２により検出されたパス各々について、以下の処理を行う。
【００７０】
すなわち、まず、パス検証部３３は、パス上の各認証局ＣＡの公開鍵証明書データベース２３にアクセスし、各認証局ＣＡが当該パス上の１つ下流側に位置する認証局ＣＡ（アクセス先認証局ＣＡが端末認証局ＣＡの場合はエンドエンティティＥＥ）に対して発行した公開鍵証明書を入手する。
【００７１】
次に、パス検証部３３は、パスの最下流に位置する端末収容認証局ＣＡが発行した公開鍵証明書の署名を、１つ上流側の認証局ＣＡが発行した公開鍵証明書で検証し、検証が成立した場合は当該１つ上流側の認証局ＣＡが発行した公開鍵証明書の署名をさらに１つ上流側の認証局ＣＡが発行した公開鍵証明書で検証する。この処理を、当該１つ上流側の認証局ＣＡがブリッジ認証局ＣＡｂｒｉｄｇｅとなるまで続けることにより、当該パスを仮検証する。
【００７２】
例えば、図２においてブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１３までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ１１−ＣＡ１３）を仮検証する場合、まず、端末収容認証局ＣＡ１３が発行した公開鍵証明書の署名を、端末収容認証局ＣＡ１３より１つ上流側の認証局ＣＡであるルート認証局ＣＡ１１が端末収容認証局ＣＡ１３に対して発行した公開鍵証明書を用いて検証する。そして、検証が成立した場合は、ルート認証局ＣＡ１１が発行した公開鍵証明書の署名を、ルート認証局ＣＡ１１より１つ上流側の認証局ＣＡであるブリッジ認証局ＣＡｂｒｉｄｇｅがルート認証局ＣＡ１１に対して発行した公開鍵証明書を用いて検証する。そして、この検証が成立した場合に、ブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１３までのパスの仮検証が成立したものとする。
【００７３】
次に、パス検証部３３は、パスの仮検証が成立したならば、当該パス上の各認証局ＣＡから入手した公開鍵証明書中に、信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や当該公開鍵証明書の有効性確認のために許容される最大パス長（パス上の許容最大認証局数）などの制限の記述があるか否かを調べる。そのような記述がある場合は、当該パスがその制限を満たしているか否かを調べ、満たしている場合にのみ、当該パスの検証が成立したものとする。
【００７４】
例えば、図２においてブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ２６までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ３１−ＣＡ２１−ＣＡ２２−ＣＡ２５−ＣＡ２６）の仮検証が成立した場合において、認証局ＣＡ２６から入手した公開鍵証明書中に信頼しない他の認証局の名称として認証局ＣＡ３１が記述されている場合、当該パスの検証は成立しなかったものとする。また、上記の場合において、認証局ＣＡ２６から入手した公開鍵証明書中にパス長として認証局数＝５が記述されている場合、当該パスの検証は成立しなかったものとする。
【００７５】
さて、制御部３８は、上記のようにして、パス検索部３２により検出されたパス各々に対するパス検証部３３での検証が終了したならば、パスデータベース３１の登録内容を一旦クリアし、それから、パス検証部３３での検証が成立したパス各々を、当該パス上の最下流に位置する端末収容認証局ＣＡと、当該パス上の各認証局ＣＡから入手した公開鍵証明書とに対応付けて、パスデータベース３１に登録する（ステップＳ１００４）。
【００７６】
一方、有効期限／失効状態調査部３４は、パスデータベース３１に登録されている公開鍵証明書の中に、有効期限切れの公開鍵証明書があるか否かを調べる（ステップＳ１００５）。有効期限切れの公開鍵証明書がある場合は、当該公開鍵証明書の発行元認証局ＣＡの公開鍵証明書データベース２３にアクセスして、当該公開鍵証明書の発行先に対して新たに発行された公開鍵証明書を検索する（ステップＳ１００６）。
【００７７】
そして、そのような公開鍵証明書が前記発行元認証局ＣＡの公開鍵証明書データベース２３中になければ、前記有効期限切れの公開鍵証明書に対応付けて登録されているパスに関する情報をパスデータベース３１から削除する（ステップＳ１００７）。一方、そのような公開鍵証明書が前記発行元認証局ＣＡの公開鍵証明書データベース２３中にあればこれを入手する。そして、前記有効期限切れの公開鍵証明書に対応付けてパスデータベース３１に登録されているパスの検証を、当該有効期限切れの公開鍵証明書の代わりに新たに入手した公開鍵証明書を用いて、上記のステップＳ１００３と同じ要領で行う（ステップＳ１００８）。
【００７８】
なお、ステップＳ１００８でのパス検証に代えて、新たに入手した公開鍵証明書の署名を、当該パス上において、当該公開鍵証明書の発行元認証局ＣＡより１つ上流側に位置する認証局ＣＡが発行した公開鍵証明書で検証し、検証が成立した場合に、当該パスの検証が成立したものとして扱うようにしてもよい。
【００７９】
さて、パスの検証が成立した場合（ステップＳ１００９でＹｅｓ）は、当該パスに対応付けられてパスデータベース３１に登録されている前記有効期限切れの公開鍵証明書を、新たに入手した公開鍵証明書に置き換える（ステップＳ１０１０）。一方、パスの検証が成立しなかった場合（ステップＳ１００９でＮｏ）は、前記有効期限切れの公開鍵証明書に対応付けて登録されているパスをパスデータベース３１から削除する（ステップＳ１０１１）。
【００８０】
次に、有効期限／失効状態調査部３４は、失効証明書リスト作成予定日時データベース３９を調べ、既に経過した失効証明書リスト作成予定日時に対応付けられている認証局ＣＡを検索する（ステップＳ１０１２）。そのような認証局ＣＡが存在する場合（ステップＳ１０１３でＹｅｓ）は、当該認証局ＣＡの失効証明書リスト保持部２５にアクセスして、当該認証局ＣＡが発行した最新の失効証明書リストを入手する（ステップＳ１０１４）。そして、失効証明書リスト作成予定日時データベース３９にて、当該認証局ＣＡに対応付けて登録されている失効証明書リスト作成予定日時を、入手した最新の失効証明書リストに記述されている失効証明書リスト作成予定日時に更新する（ステップＳ１０１５）。
【００８１】
それから、有効期限／失効状態調査部３４は、入手した最新の失効証明書リストに記述されている公開鍵証明書が、パスデータベース３１に登録されているか否かを調べ（ステップＳ１０１６）、登録されている場合は、当該公開鍵証明書に対応付けられているパスに関する情報をパスデータベース３１から削除する（ステップＳ１０１７）。
【００８２】
次に、公開鍵証明書の有効性の確認動作について説明する。
【００８３】
図１０〜図１１は、本実施形態の証明書有効性確認センタＶＣで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
【００８４】
制御部３８は、通信部３６を介して、エンドエンティティＥＥから、少なくとも当該エンドエンティティＥＥを収容する端末収容認証局ＣＡの名称を含んだ、当該端末収容認証局ＣＡ以外の端末収容認証局ＣＡが発行した公開鍵証明書の有効性の確認依頼を受け取ると（ステップＳ２００１）、その旨を有効性確認部３５に通知する。
【００８５】
これを受けて、有効性確認部３５は、依頼対象の公開鍵証明書の記述から特定される当該証明書を発行した端末収容認証局ＣＡに対応付けられたパスと、依頼主のエンドエンティティＥＥを収容する端末収容認証局ＣＡに対応付けられたパスとが、パスデータベース３１に登録されているか否かを調べる（ステップＳ２００２）。
【００８６】
その結果、依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡに対応付けられたパス、および、依頼主のエンドエンティティＥＥを収容する端末収容認証局ＣＡに対応付けられたパスの両方が、パスデータベース３１に登録されていないことが判明したならば、有効性確認部３５は、公開鍵証明書が有効でない旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００３）。
【００８７】
一方、依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡに対応付けられたパス、および、依頼主のエンドエンティティＥＥを収容する端末収容認証局ＣＡに対応付けられたパスの両方が、パスデータベース３１に登録されていることが確認できたならば、有効性確認部３５は、これら２つのパスのいずれかに対応付けられてパスデータベース３１に登録されている各公開鍵証明書中に、信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や当該公開鍵証明書の有効性確認のために許容される最大パス長（パス上の許容最大認証局数）などの制限の記述があるか否かをさらに調べる（ステップＳ２００４）。
【００８８】
そのような制限の記述がない場合、ステップＳ２００６に移行する。一方、そのような制限の記述がある場合は、ステップＳ２００５に移行して、これら２つのパスがその制限を満たしているか否か、すなわち、各公開鍵証明書中に、これら２つのパス上のいずれかの認証局を信頼しない旨が記述されているか否か、および、最大パス長として、これら２つのパス上の認証局数よりも少ない認証局数が記述されているか否かを調べる。
【００８９】
そして、そのような記述がある場合、有効性確認部３５は、これら２つのパスがその制限を満たしていないものと判断し、公開鍵証明書が有効性でない旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００３）。一方、そのような記述がない場合は、これら２つのパスがその制限を満たしているものと判断し、ステップＳ２００６に移行する。
【００９０】
ステップＳ２００６では、有効性確認部３５は、エンドエンティティＥＥから受け取った確認依頼に、当該エンドエンティティＥＥが行おうとしている電子手続の取引額等で示された信頼度（ポリシー）が含まれているか否かを調べる。電子手続の信頼度が含まれている場合は、これら２つのパスのいずれかに対応付けられてパスデータベース３１に登録されている各公開鍵証明書中に、前記電子手続の信頼度よりも低い信頼度の記述があるか否かをさらに調べる（ステップＳ２００７）。
【００９１】
そして、そのような記述がある場合は、これら２つのパスを、依頼主のエンドエンティティＥＥが行おうとしている電子手続のための公開鍵証明書の有効性確認に利用できないものと判断し、公開鍵証明書が有効でない旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００３）。
【００９２】
一方、エンドエンティティＥＥから受け取った確認依頼に当該エンドエンティティＥＥが行おうとしている電子手続の信頼度が含まれていない場合、あるいは、含まれていても、これら２つのパスのいずれかに対応付けられてパスデータベース３１に登録されている各公開鍵証明書中に記述されている信頼度が前記電子手続の信頼度よりも高い場合は、公開鍵証明書は有効であると判断し、公開鍵証明書が有効である旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００８）。
【００９３】
以上、本発明の第１実施形態について説明した。
【００９４】
本実施形態では、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスの検索および検証を、エンドエンティティＥＥからの公開鍵証明書の有効性確認依頼とは独立して、定期的に行うようにしている。そして、あるエンドエンティティＥＥから公開鍵証明書の有効性確認依頼を受けた場合、予め検索、検証したパスを用いて、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡと依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡとの間に、ブリッジ認証局ＣＡｂｒｉｄｇｅを介したパスを構築することができるか否かを調べることで、当該公開鍵証明書が有効であるか否かを判断するようにしている。したがって、公開鍵証明書の有効性確認依頼を受けてから、当該有効性を確認するまでにかかる時間を短縮することができる。
【００９５】
また、本実施形態では、あるエンドエンティティＥＥから公開鍵証明書の有効性確認依頼を受けた場合、予め検索、検証したパスを用いて、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡと依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡとの間に、ブリッジ認証局ＣＡｂｒｉｄｇｅを介したパスを構築することができるか否かを調べ、できた場合に、当該パス上の認証局が発行した公開鍵証明書中に記述された制限（信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や最大パス長（パス上の許容最大認証局数）や信頼度（ポリシー）等）を考慮して、依頼対象の公開鍵証明書が有効であるか否かを最終的に判断するようにしている。したがって、公開鍵証明書の有効性確認の判断をより正確に行うことが可能となる。
【００９６】
なお、本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【００９７】
例えば、上記の実施形態では、証明書有効性確認センタＶＣは、ブリッジ認証局ＣＡｂｒｉｄｇｅを起点認証局とし、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスの検索および検証を行うようにしている。しかし、本発明はこれに限定されない。他の任意の認証局ＣＡを起点認証局として、各端末収容認証局ＣＡまでのパスの検索および検証を行うこともできる。例えば、各認証局ＣＡが図２に示す関係にある場合、各セキュリティドメインＳＤのルート認証局ＣＡ１１、ＣＡ２１、ＣＡ３１のいずれかを起点認証局として、各端末収容認証局ＣＡまでのパスの検索および検証を行うようにしてもよい。
【００９８】
また、上記の実施形態では、説明をわかりやすくするため、図２に示すように、端末収容認証局ＣＡはエンドエンティティＥＥに対してのみ公開鍵証明書を発行し、その他の認証局ＣＡは認証局ＣＡに対してのみ公開鍵証明書を発行するものとしているが、本発明は、当然のことながら、エンドエンティティＥＥと認証局ＣＡの両方に対して公開鍵証明書を発行するような認証局ＣＡを含む場合でも、同様に適用できる。
【００９９】
【発明の効果】
以上説明したように、本発明によれば、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短縮することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態が適用されたＰＫＩシステムの概略構成を示す図である。
【図２】図１に示すＰＫＩシステムでの各認証局ＣＡの関係の一例を示す図である。
【図３】図１に示すエンドエンティティＥＥの概略構成を示す図である。
【図４】図１に示す認証局ＣＡの概略構成を示す図である。
【図５】図１に示す証明書有効性確認センタＶＣの概略構成を示す図である。
【図６】図３〜図５に示すエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣの各々のハードウエア構成例を示す図である。
【図７】図５に示す証明書有効性確認センタＶＣで行われるパスの検索、検証および管理動作を説明するためのフロー図である。
【図８】図５に示す証明書有効性確認センタＶＣで行われるパスの検索、検証および管理動作を説明するためのフロー図である。
【図９】各認証局ＣＡが図２に示す関係にある場合に、証明書有効性確認センタＶＣのパス検索部３２で検出される、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを示す図である。
【図１０】図５に示す証明書有効性確認センタＶＣで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
【図１１】図５に示す証明書有効性確認センタＶＣで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
【図１２】従来のＰＫＩにおいて、認証局が複数ある場合における各認証局の関係の一例を示す図である。
【符号の説明】
ＣＡ…認証局、ＶＣ…証明書有効性確認センタ、ＥＥ…エンドエンティティ、ＳＤ…セキュリティドメイン、１０ａ，２０ａ，３０ａ…処理部、１０ｂ，２０ｂ，３０ｂ…記憶部、１１…電子文書保持部、１２…鍵保持部、１３…検証対象保持部、１４…署名生成部、１５…署名検証部、１６，２６，３６…通信部、１７，２７，３７…入出力部、１８，２８，３８…制御部、２１…発行部、２２…管理部、２３…公開鍵証明書データベース、２４…発行先リスト保持部、２５…失効証明書リスト保持部、３１…パスデータベース、３２…パス検索部、３３…パス検証部、３４…有効期限／失効状態調査部、３５…有効性確認部、３９…失効証明書リスト作成予定日時データベース、６１…ＣＰＵ、６２…メモリ、６３…外部記憶装置、６４…読取装置、６５…通信装置、６６…入力装置、６７…出力装置、６８…インターフェース、６９…記憶媒体
【発明の属する技術分野】
本発明は、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）において、ある端末が受け取った電子手続に対する署名を検証するための公開鍵証明書が、当該端末が信頼する認証局とは異なる認証局が発行したものである場合に、その有効性を確認するのに好適な技術に関する。
【０００２】
【従来の技術】
民間系、公共系の様々な組織、団体において、従来、紙面で行ってきた様々な手続を電子化するべく、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の導入、整備が進んでいる。
【０００３】
図１２は、従来のＰＫＩにおいて、認証局が複数ある場合における各認証局の関係を示している。
【０００４】
図示するように、公開鍵証明書の発行とその管理を行う各認証局は、ルート認証局ＣＡ１を頂点とするツリー構造を持つグループを形成している。このグレープはセキュリティドメインと呼ばれている。ルート認証局ＣＡ１は、自身より１つ下流側に位置する各認証局ＣＡ２１〜ＣＡ２ｎに対して公開鍵証明書を発行する。また、認証局ＣＡ２１〜ＣＡ２ｎ１各々は、自身より１つ下流側に位置する各認証局ＣＡ３１〜ＣＡ３ｎ２に対して公開鍵証明書を発行する。このように、ツリー上、１つ上流側に位置する認証局が自身より１つ下流側に位置する認証局に対して公開鍵証明書を発行する。そして、ツリー上、最下流に位置する認証局（以下、端末収容認証局と呼ぶ）ＣＡＳ１〜ＣＡＳｎｍは、電子手続を行うユーザ端末（以下、エンドエンティティと呼ぶ）ＥＥ１〜ＥＥｘに対して公開鍵証明書を発行する。
【０００５】
エンドエンティティＥＥ１〜ＥＥｘ各々が電子文書の署名に使用する秘密鍵（署名鍵）の正当性は、自身を収容する端末収容認証局ＣＡＳ１〜ＣＡＳｎｍが発行した公開鍵証明書によって証明され、端末収容認証局ＣＡＳ１〜ＣＡＳｎｍ各々が発行する公開鍵証明書の署名に使用する秘密鍵の正当性は、自身を収容する認証局ＣＡ（Ｓ−１）１〜ＣＡ（Ｓ−１）ｎ（ｍ−１）が発行した公開鍵証明書によって証明される。したがって、エンドエンティティＥＥ１〜ＥＥｘ各々が署名に使用する秘密鍵は、最終的に、ルート認証局ＣＡ１が発行する公開鍵証明書によって証明されることになる。このエンドエンティティＥＥ１〜ＥＥｘが署名に使用する鍵の正当性を最終的に証明する認証局、云いかえれば、エンドエンティティＥＥ１〜ＥＥｘが信頼する、ツリー上、最上流側の認証局をトラストアンカーと呼ぶ。
【０００６】
さて、図１２において、エンドエンティティＥＥ１は、エンドエンティティＥＥｘに送信すべき申請書等の電子文書に対して、エンドエンティティＥＥ１が保持する自身の秘密鍵で署名を行う。そして、署名した電子文書に、エンドエンティティＥＥ１を収容する端末収容認証局ＣＡＳ１が発行した前記秘密鍵と対の公開鍵証明書を添付して、エンドエンティティＥＥｘに送信する。
【０００７】
エンドエンティティＥＥｘは、エンドエンティティＥＥ１より受け取った電子文書の署名を、当該電子文書に添付された公開鍵証明書を用いて検証することができる。しかし、公開鍵証明書はエンドエンティティＥＥｘを収容する端末収容認証局ＣＡＳｎｍが発行したものではないので、エンドエンティティＥＥｘは、当該公開鍵証明書を直ちに信頼することはできない。この場合、エンドエンティティＥＥｘは、自身のトラストアンカーであるルート認証局ＣＡ１によって当該公開鍵証明書の有効性が証明されるものであることを確認しなければならない。この公開鍵証明書の有効性確認処理は、以下の手順によって行われる。
【０００８】
▲１▼トラストアンカーから公開鍵証明書の発行元認証局までのパスの検索
トラストアンカー（ここでは、ルート認証局ＣＡ１）を起点認証局とし、起点認証局が発行した公開鍵証明書の発行先を調べ、当該発行先に認証局が含まれる場合は当該認証局が発行した公開鍵証明書の発行先をさらに調べる処理を、当該公開鍵証明書の発行先に、公開鍵証明書の発行元認証局（ここでは、エンドエンティティＥＥ１を収容する端末収容認証局ＣＡＳ１）が含まれるまで続け、トラストアンカーから公開鍵証明書の発行元認証局までのパスを検索する。
【０００９】
▲２▼検出したパスの検証
上記▲１▼により検出したパス上の各認証局から、パス上において当該認証局の１つ下流側の認証局に対して発行した公開鍵証明書を入手する。そして、有効性確認対象の公開鍵証明書（ここでは、端末収容認証局ＣＡＳ１がエンドエンティティＥＥ１に対して発行した公開鍵証明書）の署名を、当該公開鍵証明書を発行した認証局（ここでは、端末収容認証局ＣＡＳ１）より１つ上流側の認証局が発行した公開鍵証明書で検証し、検証が成立した場合は、当該１つ上流側の認証局が発行した公開鍵証明書の署名をさらに１つ上流側の認証局が発行した公開鍵証明書で検証する処理を、当該１つ上流側の認証局がトラストアンカーとなるまで続ける。そして、このような公開鍵証明書の署名検証がトラストアンカーまで成立した場合に、有効性確認対象の公開鍵証明書の有効性が確認されたものとする。
【００１０】
エンドエンティティＥＥｘは、エンドエンティティＥＥ１より受け取った電子文書の署名を当該電子文書に添付された公開鍵証明書を用いて検証すると共に、上記の▲１▼、▲２▼に示す手順に従い当該電子文書の署名検証に用いた公開鍵証明書の有効性を確認することにより、当該電子文書の正当性を確認することができる。
【００１１】
なお、以上では、公開鍵証明書の有効性確認処理をエンドエンティティで行うことを前提としている。しかし、公開鍵証明書の有効性確認処理は負荷が重く、これをエンドエンティティで行うためには、当該エンドエンティティに高い処理能力が要求される。そこで、ネットワークを介してエンドエンティティに接続された証明書の有効性確認サーバを設け、当該サーバに、当該エンドエンティティの代わりに公開鍵証明書の有効性確認を行わせることがＩＥＴＦにより提案されている。
【００１２】
【発明が解決しようとする課題】
ところで、従来提案されている証明書の有効性確認サーバは、エンドエンティティから依頼を受ける都度、上記の▲１▼、▲２▼に示す手順を実行して公開鍵証明書の有効性を確認している。このため、エンドエンティティが公開鍵証明書の有効性確認を依頼をしてからその結果がわかるまでに、少なくとも、上記の▲１▼、▲２▼に示す手順を実行するための時間がかかってしまう。
【００１３】
なお、図１２では、セキュリティドメインが１つであることを前提にしているが、上述したように、民間系、公共系の様々な組織、団体においてＰＫＩの導入、整備が行われており、その結果、複数のセキュリティドメインが並存することが予想される。これらの異なるセキュリティドメイン間においても、各セキュリティドメインのルート認証局同士で、互いに相手の公開鍵証明書を発行するなどして相互認証を行ったり、あるいは、各セキュリティドメインのルート認証局各々との間でこのような相互認証を行ったブリッジ認証局を設置することにより、上記の▲１▼、▲２▼にその手順を示した公開鍵証明書の有効性確認処理を実現することができる。しかしこのように、複数のセキュリティドメイン間で公開鍵証明書の有効性確認処理を行うと、認証局数が増大し、また、各認証局の関係も、図１２に示すような単純なツリー構造ではなく、より複雑化するため、上記の▲１▼、▲２▼に示す手順を実行するための負荷が増大する。このため、エンドエンティティが公開鍵証明書の有効性確認を依頼をしてからその結果がわかるまでにかかる時間がさらに長くなり、サービスの低下を招いてしまう。
【００１４】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短くすることにある。
【００１５】
【課題を解決するための手段】
上記課題を解決するために、本発明では、ネットワークを介して、複数の端末（エンドエンティティ）や認証局に接続された証明書の有効性確認サーバにおいて、ある端末からの依頼に応じて、当該端末が信頼する認証局とは異なる認証局が発行した公開鍵証明書の有効性を確認するために以下の処理を行う。
【００１６】
すなわち、任意の認証局を起点認証局とし、当該起点認証局が発行した公開鍵証明書の発行先を調べ、当該発行先に認証局が含まれる場合は当該認証局が発行した公開鍵証明書の発行先をさらに調べる処理を、当該公開鍵証明書の発行先が全て端末となるまで続けることにより、前記起点認証局から任意の端末に対して公開鍵証明書を発行した端末収容認証局までのパスを検索するパス検索ステップと、
前記パス検索ステップにより検出されたパスについて、前記起点認証局を上流とし、当該パス上の端末収容認証局が発行した公開鍵証明書の署名を１つ上流側の認証局が発行した公開鍵証明書で検証し、検証が成立した場合は当該１つ上流側の認証局が発行した公開鍵証明書の署名をさらに１つ上流側の認証局が発行した公開鍵証明書で検証する処理を、当該１つ上流側の認証局が前記起点認証局となるまで続けることにより、当該パスを検証するパス検証ステップと、
前記パス検証ステップにより検証が成立したパスをデータベースに登録するパス登録ステップとを、端末からの公開鍵証明書の有効性確認依頼とは無関係に、例えば定期的に行う。
【００１７】
そして、ある端末から、当該端末が信頼する認証局とは異なる端末収容認証局が発行した公開鍵証明書の有効性確認依頼があった場合に、前記端末が信頼する認証局と前記起点認証局との間のパス、および、前記異なる端末収容認証局と前記起点認証局との間のパスが、前記データベースに登録されているか否かを調べることで、前記公開鍵証明書の有効性を確認する。
【００１８】
本発明によれば、ある端末から公開鍵証明書の有効性確認依頼を受けた場合に、それから、上記の▲１▼、▲２▼に示した、当該端末のトラストアンカーから当該公開鍵証明書の発行元認証局までのパスの検索、および、検出したパスの検証を行う必要がない。したがって、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短縮できる。
【００１９】
【発明の実施の形態】
以下に、本発明の一実施形態について説明する。
【００２０】
図１は、本発明の一実施形態が適用されたＰＫＩシステムの概略構成を示す図である。
【００２１】
図示するように、本実施形態のＰＫＩシステムは、電子手続を行うユーザ端末あるいはユーザ端末からの依頼を受けて電子手続を代行する受付サーバである複数のエンドエンティティＥＥと、公開鍵証明書の発行とその管理を行う複数の認証局ＣＡと、エンドエンティティＥＥからの依頼に応じ公開鍵証明書の有効性の確認を行う証明書有効性確認センタＶＣとが、ＬＡＮ、ＷＡＮおよびこれらを繋ぐインターネット等により構成されたネットワークＮＥＴを介して、互いに接続されて構成される。
【００２２】
図２は、図１に示すＰＫＩシステムでの各認証局ＣＡの関係の一例を示す図である。
【００２３】
図示するように、本実施形態のＰＫＩシステムでは、民間系、政府系といった複数のセキュリティドメインＳＤ（ＳＤ１〜ＳＤ３）が並存していることを前提としている。そして、そのうちの幾つかのセキュリティドメインＳＤ（図２ではＳＤ２、ＳＤ３）は、ルート認証局ＣＡ（図２ではＣＡ２１、ＣＡ３１）同士で、例えば互いに公開鍵証明書を発行し合うことにより相互認証を行っているものとする。また、各セキュリティドメインＳＤのルート認証局ＣＡ（図２ではＣＡ１１、ＣＡ２１、ＣＡ３１）は、例えば、ブリッジ認証局ＣＡｂｒｉｄｇｅに対して公開鍵証明書を発行すると共に、ブリッジ認証局ＣＡｂｒｉｄｇｅから公開鍵証明書を発行してもらうことにより、ブリッジ認証局ＣＡｂｒｉｄｇｅとの間で相互認証を行っているものとする。このようにすることで、あるセキュリティドメインＳＤに属する認証局ＣＡと他のセキュリティドメインＳＤに属する認証局ＣＡとの間に、一方の認証局ＣＡが発行した公開鍵証明書の有効性を、他方の認証局ＣＡにて確認できるようにするためのパスが形成される。
【００２４】
次に、上記のＰＫＩシステムを構成するエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣについて説明する。
【００２５】
まず、エンドエンティティＥＥについて説明する。
【００２６】
図３は、エンドエンティティＥＥの概略構成を示す図である。
【００２７】
図示するように、エンドエンティティＥＥは、処理部１０ａと、記憶部１０ｂと、ネットワークＮＥＴを介して他装置と通信を行うための通信部１６と、ユーザが作成した電子文書や他のエンドエンティティＥＥあるいはユーザ端末から受け取った電子文書の入出力やユーザよりの指示の受付けを行う入出力部１７と、を有する。
【００２８】
処理部１０ａは、署名生成部１４と、署名検証部１５と、エンドエンティティＥＥの各部を統括的に制御する制御部１８と、を有する。
【００２９】
記憶部１０ｂは、ユーザが作成した（エンドエンティティＥＥが受付サーバの場合はユーザ端末から受け取った）電子文書を保持する電子文書保持部１１と、秘密鍵（署名鍵）とこれに対の公開鍵証明書とを保持する鍵保持部１２と、他のエンドエンティティＥＥから受け取った署名付きの電子文書と公開鍵証明書を保持する検証対象保持部１３と、を有する。
【００３０】
このような構成において、制御部１８は、入出力部１７を介してユーザから、電子文書保持部１１に保持してある電子文書を他のエンドエンティティＥＥに送信すべき旨の指示を受け付けると、当該電子文書を電子文書保持部１１から読み出し、これを署名生成部１４に渡す。これを受けて、署名生成部１４は、鍵保持部１２に保持されている秘密鍵を用いて当該電子文書に対する署名を生成する。それから、制御部１８は、電子文書保持部１１から読み出した電子文書に署名生成部１４で生成された署名を付して、署名付き電子文書を作成する。そして、作成した署名付き電子文書に鍵保持部１２に保持されている公開鍵証明書を添付して、通信部１６を介して、ユーザより指示された送信先のエンドエンティティＥＥのアドレスへ送信する。
【００３１】
また、制御部１８は、通信部１６を介して、他のエンドエンティティＥＥから署名付き電子文書と公開鍵証明書を受け取ると、これらを検証対象保持部１３に保持させると共に、その旨を署名検証部１５に通知する。これを受けて、署名検証部１５は、検証対象保持部１３に保持されている署名付き電子文書の署名を、当該電子文書と共に受け取った公開鍵証明書を用いて検証する。そして、検証が成立した場合にのみ、署名付き電子文書を正当なものとして扱い、必要に応じて入出力部１７から出力する。
【００３２】
ただし、上記の署名検証が成立した場合でも、当該署名検証に用いた公開鍵証明書が、自エンドエンティティＥＥを収容する（つまり、自エンドエンティティＥＥに対して公開鍵証明書を発行した）端末収容認証局ＣＡ以外の端末収容認証局ＣＡの場合は、証明書有効性確認センタＶＣに、上記の署名検証に用いた公開鍵証明書の有効性の確認依頼を送信する。この際、必要に応じて、前記署名付き電子文書により行おうとしている電子手続の取引額等で示した信頼度（ポリシー）を、前記確認依頼に含める。そして、証明書有効性確認センタＶＣにて、当該公開鍵証明書の有効性が確認された場合にのみ、署名付き電子文書を正当なものとして扱い、必要に応じて入出力部１７から出力する。
【００３３】
次に、認証局ＣＡについて説明する。
【００３４】
図４は、認証局ＣＡの概略構成を示す図である。
【００３５】
図示するように、認証局ＣＡは、処理部２０ａと、記憶部２０ｂと、ネットワークＮＥＴを介して他装置と通信を行うための通信部２６と、公開鍵証明書等の入出力やユーザよりの指示の受付けを行う入出力部２７と、を有する。
【００３６】
処理部２０ａは、公開鍵証明書を発行する発行部２１と、発行部２１が発行した公開鍵証明書の管理を行う管理部２２と、認証局ＣＡの各部を統括的に制御する制御部２８と、を有する。
【００３７】
記憶部２０ｂは、発行部２１が発行した公開鍵証明書を保持する公開鍵証明書データベース２３と、公開鍵証明書データベース２３に保持されている各公開鍵証明書の発行先が記述された発行先管理リストを保持する発行先管理リスト保持部２４と、失効証明書リスト保持部２５と、を有する。
【００３８】
このような構成において、制御部２８は、入出力部２７あるいは通信部２６を介して、公開鍵証明書の発行依頼を受け付けると、その旨を発行部２１に伝える。これを受けて、発行部２１は、発行依頼主が署名生成に用いる秘密鍵（署名鍵）とこれに対の公開鍵証明書を作成する。この際、自認証局ＣＡの秘密鍵で公開鍵証明書に署名をする。また、必要に応じて、公開鍵証明書中に、当該公開鍵証明書の有効期限や、信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や、当該公開鍵証明書の有効性確認のために許容される最大パス長（パス上の許容最大認証局数）や、電子手続の取引額等で表した当該公開鍵証明書と対の秘密鍵による署名の信頼度（ポリシー）を記述する。そして、作成した公開鍵証明書と秘密鍵を、入出力部２７あるいは通信部２６を介して、郵送あるいは通信により、発行依頼主に渡す。また、この公開鍵証明書を公開鍵証明書データベース２３に登録すると共に、その発行先（つまり発行依頼主）の情報を、発行先管理リスト保持部２４に保持されている発行先管理リストに記述する。
【００３９】
また、制御部２８は、入出力部２７あるいは通信部２６を介して、公開鍵証明書の失効依頼を受け付けると、その旨を管理部２２に伝える。これを受けて、管理部２２は、失効対象の公開鍵証明書を公開鍵証明書データベース２３から削除すると共に、当該公開鍵証明書の発行先の情報を、発行先管理リスト保持部２４に保持されている発行先管理リストから削除する。そして、管理部２２は、失効依頼により公開鍵証明書データベース２３から削除した公開鍵証明書に関する情報が記述された失効証明書リスト（一般に、ＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）、ＡＲＬ（Ａｕｔｈｏｒｉｔｙ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）と呼ばれている）を、定期的に作成し、これを失効証明書リスト保持部２５に保持させる。なお、管理部２２は、作成した失効証明書リストに、次回の失効証明書リストの作成予定日時を記述するものとする。
【００４０】
また、制御部２８は、通信部２６を介して、他装置より公開鍵証明書の失効情報の問い合わせを受け取ると、失効証明書リスト保持部２５に保持されている失効証明書リストを検索して、問い合わせのあった公開鍵証明書が失効しているか否かを調べる。そして、その結果を、通信部２６を介して、問い合わせをした他装置に応答する（このような問い合わせと応答に用いる通信プロトコルとして、ＯＳＣＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｉｏｎ ｓｔａｔｕｓ ｐｒｏｔｏｃｏｌ）がある）。
【００４１】
なお、管理部２２は、公開鍵証明書データベース２３に格納されている各公開鍵証明書の有効期限を調査し、有効期限を過ぎている公開鍵証明書を公開鍵証明書データベース２３から削除すると共に、当該公開鍵証明書の発行先の情報を、発行先管理リスト保持部２４に保持されている発行先管理リストから削除する処理も行う。
【００４２】
次に、証明書有効性確認センタＶＣについて説明する。
【００４３】
図５は、証明書有効性確認センタＶＣの概略構成を示す図である。
【００４４】
図示するように、証明書有効性確認センタＶＣは、処理部３０ａと、記憶部３０ｂと、ネットワークＮＥＴを介して他装置と通信を行うための通信部３６と、公開鍵証明書等の入出力やユーザよりの指示の受付けを行う入出力部３７と、を有する。
【００４５】
処理部３０ａは、パス検索部３２と、パス検証部３３と、有効期限／失効状態調査部３４と、有効性確認部３５と、証明書有効性確認センタＶＣの各部を統括的に制御する制御部３８とを有する。また、記憶部３０ｂは、パスデータベース３１と、失効証明書リスト作成予定日時データベース３９とを有する。
【００４６】
パス検索部３１は、定期的に、ブリッジ認証局ＣＡｂｒｉｄｇｅからエンドエンティティＥＥに対して公開鍵証明書を発行した各端末収容認証局ＣＡまでのパスを検索する。
【００４７】
パス検証部３２は、パス検索部３１でパスの検索が行われる毎に、当該パス検索部３１で検出されたパスの検証を行う。そして、検証が成立したパスを、証明書有効性確認センタＶＣを上流とした場合に当該パス上の最下流に位置することとなる端末収容認証局ＣＡの名称と、当該パス上の各認証局ＣＡから入手した当該パス上の１つ下流側に位置する認証局ＣＡ（発行元の認証局ＣＡが端末収容認証局ＣＡの場合はエンドエンティティＥＥ）に対して発行した公開鍵証明書とに対応付けて、パスデータベース３１に登録する。
【００４８】
有効期限／失効状態調査部３４は、パスデータベース３１に登録されているパス各々について、当該パス上の各認証局ＣＡが当該パス上の１つ下流側に位置する認証局ＣＡ（発行元の認証局ＣＡが端末収容認証局ＣＡの場合はエンドエンティティＥＥ）に対して発行した公開鍵証明書の有効期限や失効の有無を調査する。そして、その結果に応じてパスデータベース３３を更新する。
【００４９】
また、有効期限／失効状態調査部３４は、各認証局ＣＡの失効証明書リスト保持部２５から入手した失効証明書リストに記述されている次回の失効証明書リスト作成予定日時を当該認証局ＣＡに対応付けて、失効証明書リスト作成予定日時データベース３９に登録する。
【００５０】
有効性確認部３５は、エンドエンティティＥＥからの依頼に従い、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡ以外の端末収容認証局ＣＡが発行した公開鍵証明書の、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡに対する有効性の確認を行う。
【００５１】
なお、図３〜図５に示すエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣの各々は、例えば、図６に示すような、ＣＰＵ６１と、メモリ６２と、ハードディスク等の外部記憶装置６３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体６９から情報を読み取る読取装置６４と、ネットワークを介して他装置と通信を行うための通信装置６５と、キーボードやマウス等の入力装置６６と、モニタやプリンタ等の出力装置６７と、これらの各装置間のデータ送受を行うインターフェース６８とを備えた、一般的な電子計算機において、ＣＰＵ６１がメモリ６２上にロードされた所定のプログラムを実行することにより、実現できる。すなわち、通信部１６、２６、３６は、ＣＰＵ６１が通信装置６６を利用することにより、入出力部１７、２７、３７は、ＣＰＵ６１が入力装置６６や出力装置６７や読取装置６４を利用することにより、そして、記憶部１０ｂ、２０ｂ、３０ｂは、ＣＰＵ６１がメモリ６２や外部記憶装置６３を利用することにより実現される。また、処理部１０ａ、２０ａ、３０ａは、ＣＰＵ６１上のプロセスとして実現される。
【００５２】
このような、電子計算機上にエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣを各々実現するための所定のプログラムは、読取装置６４を介して記憶媒体６９から読み出され、あるいは、通信装置６６を介してネットワーク経由で他のサーバからダウンロードされて、一旦、外部記憶装置６３に格納された後、そこからメモリ６２上にロードされて、あるいは、外部記憶装置６３に格納されることなく、直接メモリ６２上にロードされて、ＣＰＵ６１に実行されるようにすればよい。
【００５３】
次に、上記構成の証明書有効性確認センタＶＣの動作について説明する。
【００５４】
本実施形態の証明書有効性確認センタＶＣの動作は、パスの検索、検証および管理動作と、公開鍵証明書の有効性の確認動作とに分かれる。
【００５５】
まず、パスの検索・検証および管理動作について説明する。
【００５６】
図７〜図８は、本実施形態の証明書有効性確認センタＶＣで行われるパスの検索、検証および管理動作を説明するためのフロー図である。
【００５７】
制御部３８は、所定時間（例えば１日）を経過すると（ステップＳ１００１）、パス検索部３２にパス検索を依頼する。これを受けて、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを検索する（ステップＳ１００２）。
【００５８】
具体的には、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅの発行先管理リスト保持部２４にアクセスし、ブリッジ認証局ＣＡｂｒｉｄｇｅが発行した公開鍵証明書の発行先の情報を入手する。そして、入手した各発行先が認証局ＣＡの場合は、各発行先の認証局ＣＡの発行先管理リスト保持部２４にアクセスして、各認証局ＣＡが発行した公開鍵証明書の発行先をさらに調べる。この処理を、公開鍵証明書の発行先がエンドエンティティＥＥとなるまで続けることにより、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを検索する。ここで、パスのループにより上記の処理が無限に繰り返されるのを防止するため、ある認証局ＣＡの発行先管理リスト保持部２４から入手した発行先に、それまでに形成された部分パスの上流側に位置する認証局ＣＡが含まれる場合は、当該認証局ＣＡを発行先とした上記の処理を行わないものとする。
【００５９】
ステップＳ１００２でのパス検索処理を、各認証局ＣＡが図２に示す関係にある場合を例に取り、より具体的に説明する。
【００６０】
まず、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅの発行先管理リスト保持部２４にアクセスし、ブリッジ認証局ＣＡｂｒｉｄｇｅが発行した公開鍵証明書の発行先の情報として、認証局ＣＡ１１、ＣＡ２１、ＣＡ３１の情報を入手する。
【００６１】
次に、パス検索部３２は、ブリッジ認証局ＣＡｂｒｉｄｇｅから入手した発行先（認証局ＣＡ１１、ＣＡ２１、ＣＡ３１）のうちのいずれか１つに注目して、以下の処理を実行する。
【００６２】
すなわち、注目した発行先が認証局ＣＡ（以下、注目認証局ＣＡと呼ぶこととする）であるならば、ブリッジ認証局ＣＡｂｒｉｄｇｅ−注目認証局ＣＡ間に、ブリッジ認証局ＣＡｂｒｉｄｇｅ側を上流とする部分パスを設定する。そして、注目認証局ＣＡの発行先管理リスト保持部２４にアクセスして、当該注目認証局ＣＡが発行した公開鍵証明書の発行先の情報をさらに入手する。ここでは、注目した発行先が認証局ＣＡ１１であるとして、ブリッジ認証局ＣＡｂｒｉｄｇｅ−認証局ＣＡ１１間に部分パスを設定し、認証局ＣＡ１１から、発行先の情報として、認証局ＣＡｂｒｉｄｇｅ、ＣＡ１２、ＣＡ１３の情報を入手したものとする。
【００６３】
次に、パス検索部３２は、認証局ＣＡ１１から入手した発行先（認証局ＣＡｂｒｉｄｇｅ、ＣＡ１２、ＣＡ１３）に、部分パス上の認証局ＣＡ（以下、ループ認証局ＣＡと呼ぶこととする）が含まれているか否かを調べる。含まれている場合はその発行先を注目対象から除外する。したがって、ここでは、認証局ＣＡｂｒｉｄｇｅを注目対象から除外することになる。次に、パス検索部３２は、認証局ＣＡ１１から入手した発行先にエンドエンティティＥＥが含まれるか否を調べる。エンドエンティティＥＥが含まれている場合、認証局ＣＡ１１は端末収容認証局となる。しかし、認証局ＣＡ１１から入手した発行先にエンドエンティティＥＥは含まれていない。したがって、ブリッジ認証局ＣＡｂｒｉｄｇｅ−認証局ＣＡ１１間に設定した部分パスを、端末収容認証局ＣＡまで延長すべく、認証局ＣＡ１１から入手した、ループ認証局ＣＡを除く発行先（認証局ＣＡ１２、ＣＡ１３）のうちのいずれか１つに注目する。
【００６４】
注目した発行先が認証局ＣＡであるならば、それまでに設定した部分パスの下流側にこの注目認証局ＣＡを接続した部分パスを設定する。そして、この注目認証局ＣＡの発行先管理リスト保持部２４にアクセスして、当該注目認証局ＣＡが発行した公開鍵証明書の発行先の情報をさらに入手する。ここでは、注目した発行先が認証局ＣＡ１２であるとして、ブリッジ認証局ＣＡｂｒｉｄｇｅ−認証局ＣＡ１１−認証局ＣＡ１２間に部分パスを設定し、認証局ＣＡ１２から、発行先の情報として、エンドエンティティＥＥ１、ＥＥ２を入手したものとする。
【００６５】
次に、パス検索部３２は、認証局ＣＡ１２から入手した発行先（ＥＥ１、ＥＥ２）に、ループ認証局ＣＡが含まれているか否かを調べる。含まれている場合はその発行先を注目対象から除外する。ここでは、ループ認証局ＣＡは含まれないので、パス検索部３２は、次の処理へ移行し、端末収容認証局ＣＡ１２から入手した発行先にエンドエンティティＥＥが含まれるか否を調べる。ここで、入手した発行先はすべてエンドエンティティＥＥであるので、認証局ＣＡ１２は端末収容認証局である。そこで、この認証局ＣＡ１２を最下流とする部分パスを、ブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１２までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ１１−ＣＡ１２）として検出する。
【００６６】
次に、パス検索部３２は、検出したパス上の最下流側に位置する認証局ＣＡ１２から入手した発行先の情報の中に、未だ注目していない発行先（ループ認証局ＣＡ以外の認証局ＣＡ）があるか否かを調べ、そのような発行先があれば、これを注目認証局ＣＡとして、上記の処理を続ける。一方、そのような発行先がなければ、１つ上流側に位置する認証局ＣＡ１１から入手した発行先の情報の中に、未だ注目していない発行先（ループ認証局ＣＡ以外の認証局ＣＡ）があるか否かを調べる。そして、そのような発行先があれば、これを注目認証局ＣＡとして、上記の処理を続ける。ここでは、認証局ＣＡ１１から入手した発行先の情報のうち、認証局ＣＡ１３について未だ注目していないので、これを注目認証局ＣＡとして上記の処理を行うことにより、ブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１３までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ１１−ＣＡ１３）を検出する。
【００６７】
このように、パス検索部３２は、上記の処理を、検出したパス上に位置する全ての認証局ＣＡ各々について、当該認証局ＣＡから入手した発行先の情報の中に、未だ注目していない発行先（ループ認証局ＣＡ以外の認証局ＣＡ）がなくなるまで続けることにより、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを検出する。その結果、各認証局ＣＡが図２に示す関係にある場合、パス検索部３２により検出される、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスは、図９に示すとおりとなる。
【００６８】
さて、制御部３８は、パス検索部３２によりブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスが検出されると、パス検証部３３にパスの検証を依頼する。これを受けて、パス検証部３３は、パス検索部３２により検出されたパスの検証を行う（ステップＳ１００３）。
【００６９】
具体的には、パス検索部３２により検出されたパス各々について、以下の処理を行う。
【００７０】
すなわち、まず、パス検証部３３は、パス上の各認証局ＣＡの公開鍵証明書データベース２３にアクセスし、各認証局ＣＡが当該パス上の１つ下流側に位置する認証局ＣＡ（アクセス先認証局ＣＡが端末認証局ＣＡの場合はエンドエンティティＥＥ）に対して発行した公開鍵証明書を入手する。
【００７１】
次に、パス検証部３３は、パスの最下流に位置する端末収容認証局ＣＡが発行した公開鍵証明書の署名を、１つ上流側の認証局ＣＡが発行した公開鍵証明書で検証し、検証が成立した場合は当該１つ上流側の認証局ＣＡが発行した公開鍵証明書の署名をさらに１つ上流側の認証局ＣＡが発行した公開鍵証明書で検証する。この処理を、当該１つ上流側の認証局ＣＡがブリッジ認証局ＣＡｂｒｉｄｇｅとなるまで続けることにより、当該パスを仮検証する。
【００７２】
例えば、図２においてブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１３までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ１１−ＣＡ１３）を仮検証する場合、まず、端末収容認証局ＣＡ１３が発行した公開鍵証明書の署名を、端末収容認証局ＣＡ１３より１つ上流側の認証局ＣＡであるルート認証局ＣＡ１１が端末収容認証局ＣＡ１３に対して発行した公開鍵証明書を用いて検証する。そして、検証が成立した場合は、ルート認証局ＣＡ１１が発行した公開鍵証明書の署名を、ルート認証局ＣＡ１１より１つ上流側の認証局ＣＡであるブリッジ認証局ＣＡｂｒｉｄｇｅがルート認証局ＣＡ１１に対して発行した公開鍵証明書を用いて検証する。そして、この検証が成立した場合に、ブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ１３までのパスの仮検証が成立したものとする。
【００７３】
次に、パス検証部３３は、パスの仮検証が成立したならば、当該パス上の各認証局ＣＡから入手した公開鍵証明書中に、信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や当該公開鍵証明書の有効性確認のために許容される最大パス長（パス上の許容最大認証局数）などの制限の記述があるか否かを調べる。そのような記述がある場合は、当該パスがその制限を満たしているか否かを調べ、満たしている場合にのみ、当該パスの検証が成立したものとする。
【００７４】
例えば、図２においてブリッジ認証局ＣＡｂｒｉｄｇｅから端末収容認証局ＣＡ２６までのパス（ＣＡｂｒｉｄｇｅ−ＣＡ３１−ＣＡ２１−ＣＡ２２−ＣＡ２５−ＣＡ２６）の仮検証が成立した場合において、認証局ＣＡ２６から入手した公開鍵証明書中に信頼しない他の認証局の名称として認証局ＣＡ３１が記述されている場合、当該パスの検証は成立しなかったものとする。また、上記の場合において、認証局ＣＡ２６から入手した公開鍵証明書中にパス長として認証局数＝５が記述されている場合、当該パスの検証は成立しなかったものとする。
【００７５】
さて、制御部３８は、上記のようにして、パス検索部３２により検出されたパス各々に対するパス検証部３３での検証が終了したならば、パスデータベース３１の登録内容を一旦クリアし、それから、パス検証部３３での検証が成立したパス各々を、当該パス上の最下流に位置する端末収容認証局ＣＡと、当該パス上の各認証局ＣＡから入手した公開鍵証明書とに対応付けて、パスデータベース３１に登録する（ステップＳ１００４）。
【００７６】
一方、有効期限／失効状態調査部３４は、パスデータベース３１に登録されている公開鍵証明書の中に、有効期限切れの公開鍵証明書があるか否かを調べる（ステップＳ１００５）。有効期限切れの公開鍵証明書がある場合は、当該公開鍵証明書の発行元認証局ＣＡの公開鍵証明書データベース２３にアクセスして、当該公開鍵証明書の発行先に対して新たに発行された公開鍵証明書を検索する（ステップＳ１００６）。
【００７７】
そして、そのような公開鍵証明書が前記発行元認証局ＣＡの公開鍵証明書データベース２３中になければ、前記有効期限切れの公開鍵証明書に対応付けて登録されているパスに関する情報をパスデータベース３１から削除する（ステップＳ１００７）。一方、そのような公開鍵証明書が前記発行元認証局ＣＡの公開鍵証明書データベース２３中にあればこれを入手する。そして、前記有効期限切れの公開鍵証明書に対応付けてパスデータベース３１に登録されているパスの検証を、当該有効期限切れの公開鍵証明書の代わりに新たに入手した公開鍵証明書を用いて、上記のステップＳ１００３と同じ要領で行う（ステップＳ１００８）。
【００７８】
なお、ステップＳ１００８でのパス検証に代えて、新たに入手した公開鍵証明書の署名を、当該パス上において、当該公開鍵証明書の発行元認証局ＣＡより１つ上流側に位置する認証局ＣＡが発行した公開鍵証明書で検証し、検証が成立した場合に、当該パスの検証が成立したものとして扱うようにしてもよい。
【００７９】
さて、パスの検証が成立した場合（ステップＳ１００９でＹｅｓ）は、当該パスに対応付けられてパスデータベース３１に登録されている前記有効期限切れの公開鍵証明書を、新たに入手した公開鍵証明書に置き換える（ステップＳ１０１０）。一方、パスの検証が成立しなかった場合（ステップＳ１００９でＮｏ）は、前記有効期限切れの公開鍵証明書に対応付けて登録されているパスをパスデータベース３１から削除する（ステップＳ１０１１）。
【００８０】
次に、有効期限／失効状態調査部３４は、失効証明書リスト作成予定日時データベース３９を調べ、既に経過した失効証明書リスト作成予定日時に対応付けられている認証局ＣＡを検索する（ステップＳ１０１２）。そのような認証局ＣＡが存在する場合（ステップＳ１０１３でＹｅｓ）は、当該認証局ＣＡの失効証明書リスト保持部２５にアクセスして、当該認証局ＣＡが発行した最新の失効証明書リストを入手する（ステップＳ１０１４）。そして、失効証明書リスト作成予定日時データベース３９にて、当該認証局ＣＡに対応付けて登録されている失効証明書リスト作成予定日時を、入手した最新の失効証明書リストに記述されている失効証明書リスト作成予定日時に更新する（ステップＳ１０１５）。
【００８１】
それから、有効期限／失効状態調査部３４は、入手した最新の失効証明書リストに記述されている公開鍵証明書が、パスデータベース３１に登録されているか否かを調べ（ステップＳ１０１６）、登録されている場合は、当該公開鍵証明書に対応付けられているパスに関する情報をパスデータベース３１から削除する（ステップＳ１０１７）。
【００８２】
次に、公開鍵証明書の有効性の確認動作について説明する。
【００８３】
図１０〜図１１は、本実施形態の証明書有効性確認センタＶＣで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
【００８４】
制御部３８は、通信部３６を介して、エンドエンティティＥＥから、少なくとも当該エンドエンティティＥＥを収容する端末収容認証局ＣＡの名称を含んだ、当該端末収容認証局ＣＡ以外の端末収容認証局ＣＡが発行した公開鍵証明書の有効性の確認依頼を受け取ると（ステップＳ２００１）、その旨を有効性確認部３５に通知する。
【００８５】
これを受けて、有効性確認部３５は、依頼対象の公開鍵証明書の記述から特定される当該証明書を発行した端末収容認証局ＣＡに対応付けられたパスと、依頼主のエンドエンティティＥＥを収容する端末収容認証局ＣＡに対応付けられたパスとが、パスデータベース３１に登録されているか否かを調べる（ステップＳ２００２）。
【００８６】
その結果、依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡに対応付けられたパス、および、依頼主のエンドエンティティＥＥを収容する端末収容認証局ＣＡに対応付けられたパスの両方が、パスデータベース３１に登録されていないことが判明したならば、有効性確認部３５は、公開鍵証明書が有効でない旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００３）。
【００８７】
一方、依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡに対応付けられたパス、および、依頼主のエンドエンティティＥＥを収容する端末収容認証局ＣＡに対応付けられたパスの両方が、パスデータベース３１に登録されていることが確認できたならば、有効性確認部３５は、これら２つのパスのいずれかに対応付けられてパスデータベース３１に登録されている各公開鍵証明書中に、信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や当該公開鍵証明書の有効性確認のために許容される最大パス長（パス上の許容最大認証局数）などの制限の記述があるか否かをさらに調べる（ステップＳ２００４）。
【００８８】
そのような制限の記述がない場合、ステップＳ２００６に移行する。一方、そのような制限の記述がある場合は、ステップＳ２００５に移行して、これら２つのパスがその制限を満たしているか否か、すなわち、各公開鍵証明書中に、これら２つのパス上のいずれかの認証局を信頼しない旨が記述されているか否か、および、最大パス長として、これら２つのパス上の認証局数よりも少ない認証局数が記述されているか否かを調べる。
【００８９】
そして、そのような記述がある場合、有効性確認部３５は、これら２つのパスがその制限を満たしていないものと判断し、公開鍵証明書が有効性でない旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００３）。一方、そのような記述がない場合は、これら２つのパスがその制限を満たしているものと判断し、ステップＳ２００６に移行する。
【００９０】
ステップＳ２００６では、有効性確認部３５は、エンドエンティティＥＥから受け取った確認依頼に、当該エンドエンティティＥＥが行おうとしている電子手続の取引額等で示された信頼度（ポリシー）が含まれているか否かを調べる。電子手続の信頼度が含まれている場合は、これら２つのパスのいずれかに対応付けられてパスデータベース３１に登録されている各公開鍵証明書中に、前記電子手続の信頼度よりも低い信頼度の記述があるか否かをさらに調べる（ステップＳ２００７）。
【００９１】
そして、そのような記述がある場合は、これら２つのパスを、依頼主のエンドエンティティＥＥが行おうとしている電子手続のための公開鍵証明書の有効性確認に利用できないものと判断し、公開鍵証明書が有効でない旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００３）。
【００９２】
一方、エンドエンティティＥＥから受け取った確認依頼に当該エンドエンティティＥＥが行おうとしている電子手続の信頼度が含まれていない場合、あるいは、含まれていても、これら２つのパスのいずれかに対応付けられてパスデータベース３１に登録されている各公開鍵証明書中に記述されている信頼度が前記電子手続の信頼度よりも高い場合は、公開鍵証明書は有効であると判断し、公開鍵証明書が有効である旨を、通信部３６を介して、依頼主のエンドエンティティＥＥに通知する（ステップＳ２００８）。
【００９３】
以上、本発明の第１実施形態について説明した。
【００９４】
本実施形態では、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスの検索および検証を、エンドエンティティＥＥからの公開鍵証明書の有効性確認依頼とは独立して、定期的に行うようにしている。そして、あるエンドエンティティＥＥから公開鍵証明書の有効性確認依頼を受けた場合、予め検索、検証したパスを用いて、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡと依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡとの間に、ブリッジ認証局ＣＡｂｒｉｄｇｅを介したパスを構築することができるか否かを調べることで、当該公開鍵証明書が有効であるか否かを判断するようにしている。したがって、公開鍵証明書の有効性確認依頼を受けてから、当該有効性を確認するまでにかかる時間を短縮することができる。
【００９５】
また、本実施形態では、あるエンドエンティティＥＥから公開鍵証明書の有効性確認依頼を受けた場合、予め検索、検証したパスを用いて、当該エンドエンティティＥＥを収容する端末収容認証局ＣＡと依頼対象の公開鍵証明書を発行した端末収容認証局ＣＡとの間に、ブリッジ認証局ＣＡｂｒｉｄｇｅを介したパスを構築することができるか否かを調べ、できた場合に、当該パス上の認証局が発行した公開鍵証明書中に記述された制限（信頼しない他の認証局の名称（Ｎａｍｅ Ｃｏｎｓｔｒａｉｎｓ）や最大パス長（パス上の許容最大認証局数）や信頼度（ポリシー）等）を考慮して、依頼対象の公開鍵証明書が有効であるか否かを最終的に判断するようにしている。したがって、公開鍵証明書の有効性確認の判断をより正確に行うことが可能となる。
【００９６】
なお、本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【００９７】
例えば、上記の実施形態では、証明書有効性確認センタＶＣは、ブリッジ認証局ＣＡｂｒｉｄｇｅを起点認証局とし、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスの検索および検証を行うようにしている。しかし、本発明はこれに限定されない。他の任意の認証局ＣＡを起点認証局として、各端末収容認証局ＣＡまでのパスの検索および検証を行うこともできる。例えば、各認証局ＣＡが図２に示す関係にある場合、各セキュリティドメインＳＤのルート認証局ＣＡ１１、ＣＡ２１、ＣＡ３１のいずれかを起点認証局として、各端末収容認証局ＣＡまでのパスの検索および検証を行うようにしてもよい。
【００９８】
また、上記の実施形態では、説明をわかりやすくするため、図２に示すように、端末収容認証局ＣＡはエンドエンティティＥＥに対してのみ公開鍵証明書を発行し、その他の認証局ＣＡは認証局ＣＡに対してのみ公開鍵証明書を発行するものとしているが、本発明は、当然のことながら、エンドエンティティＥＥと認証局ＣＡの両方に対して公開鍵証明書を発行するような認証局ＣＡを含む場合でも、同様に適用できる。
【００９９】
【発明の効果】
以上説明したように、本発明によれば、公開鍵証明書の有効性確認を依頼してから、当該有効性が確認されるまでにかかる時間を短縮することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態が適用されたＰＫＩシステムの概略構成を示す図である。
【図２】図１に示すＰＫＩシステムでの各認証局ＣＡの関係の一例を示す図である。
【図３】図１に示すエンドエンティティＥＥの概略構成を示す図である。
【図４】図１に示す認証局ＣＡの概略構成を示す図である。
【図５】図１に示す証明書有効性確認センタＶＣの概略構成を示す図である。
【図６】図３〜図５に示すエンドエンティティＥＥ、認証局ＣＡおよび証明書有効性確認センタＶＣの各々のハードウエア構成例を示す図である。
【図７】図５に示す証明書有効性確認センタＶＣで行われるパスの検索、検証および管理動作を説明するためのフロー図である。
【図８】図５に示す証明書有効性確認センタＶＣで行われるパスの検索、検証および管理動作を説明するためのフロー図である。
【図９】各認証局ＣＡが図２に示す関係にある場合に、証明書有効性確認センタＶＣのパス検索部３２で検出される、ブリッジ認証局ＣＡｂｒｉｄｇｅから各端末収容認証局ＣＡまでのパスを示す図である。
【図１０】図５に示す証明書有効性確認センタＶＣで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
【図１１】図５に示す証明書有効性確認センタＶＣで行われる公開鍵証明書の有効性の確認動作を説明するためのフロー図である。
【図１２】従来のＰＫＩにおいて、認証局が複数ある場合における各認証局の関係の一例を示す図である。
【符号の説明】
ＣＡ…認証局、ＶＣ…証明書有効性確認センタ、ＥＥ…エンドエンティティ、ＳＤ…セキュリティドメイン、１０ａ，２０ａ，３０ａ…処理部、１０ｂ，２０ｂ，３０ｂ…記憶部、１１…電子文書保持部、１２…鍵保持部、１３…検証対象保持部、１４…署名生成部、１５…署名検証部、１６，２６，３６…通信部、１７，２７，３７…入出力部、１８，２８，３８…制御部、２１…発行部、２２…管理部、２３…公開鍵証明書データベース、２４…発行先リスト保持部、２５…失効証明書リスト保持部、３１…パスデータベース、３２…パス検索部、３３…パス検証部、３４…有効期限／失効状態調査部、３５…有効性確認部、３９…失効証明書リスト作成予定日時データベース、６１…ＣＰＵ、６２…メモリ、６３…外部記憶装置、６４…読取装置、６５…通信装置、６６…入力装置、６７…出力装置、６８…インターフェース、６９…記憶媒体
Claims (13)
- コンピュータが公開鍵証明書の有効性を確認する公開鍵証明書の有効性確認方法であって、
前記コンピュータは、
起点となる任意の認証局および端末に公開鍵証明書を発行する端末収容認証局間のパスを検索するパス検索ステップと、
前記パス検索ステップにより検索されたパスを検証するパス検証ステップと、
前記パス検証ステップにより検証されたパスをデータベースに登録するパス登録ステップと、
公開鍵証明書の有効性確認依頼を受け付け、前記データベースに登録されている検証されたパスに関する情報を用いて、前記端末収容認証局が発行した公開鍵証明書の有効性を確認する有効性確認ステップと、を行ない、
前記コンピュータは、前記パス検索ステップにおいて、
前記起点となる任意の認証局を発行元認証局とする第１のステップと、
前記発行元認証局の装置が発行した全ての公開鍵証明書の発行先を入手する第２のステップと、
前記第２のステップで入手した発行先各々について、当該発行先が認証局の場合は、当該発行先の認証局と前記発行元認証局との間にパスを設定して、当該発行先の認証局を新たな発行元認証局とし、当該発行先が端末の場合は、前記発行元認証局を端末収容認証局として、少なくとも１つの前記設定されたパスからなる、前記起点となる任意の認証局と前記端末収容認証局との間のパスを前記検索されたパスとする第３のステップと、
前記第２のステップで入手した発行先に認証局が含まれる場合は、前記第２のステップに戻る第４のステップと、を行い、
前記コンピュータは、前記パス検証ステップにおいて、
前記端末収容認証局を発行先認証局とする第５のステップと、
前記発行先認証局が発行した公開鍵証明書の署名を、前記検索されたパス上の前記発行元認証局が発行した公開鍵証明書で検証する第６のステップと、
前記署名を検証できた場合で、かつ、前記パス上の前記発行元認証局が前記起点となる任意の認証局でない場合は、当該発行元認証局を前記パス上の新たな発行先認証局として、第６のステップに戻り、前記署名を検証できた場合で、かつ、前記パス上の前記発行元認証局が前記起点となる任意の認証局の場合は、前記検索されたパスを検証されたパスとする第７のステップと、を行うこと
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記有効性確認ステップにおいて、前記起点となる任意の認証局と前記有効性確認の依頼元が信頼する認証局との間のパス、および、前記起点となる任意の認証局と前記端末収容認証局との間のパスが、前記データベースに登録されているパスに含まれているときに、前記端末収容認証局が発行した公開鍵証明書の有効性が確認されたものと判断すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項２記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記有効性確認ステップにおいて、前記有効性確認の依頼元が信頼する認証局が前記起点となる任意の認証局である場合、前記起点となる任意の認証局と前記端末収容認証局との間のパスが、前記データベースに登録されているときに、前記端末収容認証局が発行した公開鍵証明書の有効性が確認されたものと判断すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至３のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記第３のステップにおいて、前記第２のステップで入手した発行先各々について、当該発行先が認証局であり、且つ、当該認証局が既に設定されているパスに含まれている場合、当該認証局を発行先認証局としないこと
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至４のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記パス検索ステップを前記有効性確認ステップとは独立して実行し、前記パス検証ステップを前記パス検索ステップにより検索されたパスに対して実行し、
前記コンピュータは、前記パス登録ステップにおいて、前記データベースの登録内容を、前記パス検証ステップで検証できたパスで更新するステップを有すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至５のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、
前記パス登録ステップにより前記データベースに登録されている各々のパスについて、前記パス上の各認証局が発行した公開鍵証明書各々の有効期限を調べる有効期限調査ステップと、
前記有効期限調査ステップにより有効期限を過ぎていることが確認された公開鍵証明書の発行元認証局の装置から、当該公開鍵証明書の発行先に対する新たな公開鍵証明書の入手を試みる入手ステップと、
入手した新たな公開鍵証明書の署名を、前記発行元認証局を前記パス上で発行先の認証局とする認証局の装置が発行した公開鍵証明書で検証するパス再検証ステップと、をさらに行い、
前記コンピュータは、前記パス登録ステップにおいて、前記パス再検証ステップにて前記新たな公開鍵証明書の署名が検証できなかった場合、あるいは、前記入手ステップにおいて前記新たな公開鍵証明書を入手できなかった場合は、前記有効期限を過ぎていることが確認された公開鍵証明書を含むパスを、前記データベースから削除すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至６のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記パス登録ステップにより前記データベースに登録されている各々のパスについて、前記パス上の各認証局が発行した公開鍵証明書の失効情報を調査する失効情報調査ステップをさらに行い、
前記パス登録ステップは、前記失効情報調査ステップにおいて得た前記失効情報により失効していることが確認された公開鍵証明書を含むパスを前記データベースから削除すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至６のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記第６のステップにおける公開鍵証明書を失効情報で検証する失効情報調査ステップを行うこと
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項８に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記失効情報調査ステップにおいて、前記パス登録ステップにより前記データベースに登録されている各々のパスについて、
前記パス上の各認証局が発行した公開鍵証明書の失効情報各々の作成予定日時を過ぎているかを調査する失効情報作成予定日時調査ステップと、
前記失効情報作成予定日時調査ステップにより、作成日時が過ぎていることが確認された失効情報の発行元認証局の装置から、当該失効情報に対する新たな失効情報を入手する入手ステップと、
入手した新たな失効情報に記述されている公開鍵証明書が、前記データベースに登録されているか否かを調べる失効証明書調査ステップと、を行い、
前記コンピュータは、前記パス登録ステップにおいて、前記失効証明書長査ステップにより失効していることが確認された公開鍵証明書を含むパスを前記データベースから削除すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至９のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記有効性確認ステップにおいて、前記起点となる任意の認証局と前記有効性確認の依頼元との間のパスが、前記データベースに登録されている場合でも、前記パス上のいずれかの認証局が発行した公開鍵証明書中に、前記パス上のいずれかの他の認証局を信頼しない旨が記述されている場合は、前記公開鍵証明書の有効性が確認されなかったものと判断すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至１０のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記コンピュータは、前記有効性確認ステップにおいて、前記起点となる任意の認証局と前記有効性確認の依頼元との間のパスが、前記データベースに登録されている場合でも、前記パス上のいずれかの認証局が発行した、前記パス上の発行先認証局に対する公開鍵証明書中に記述されている前記パス上の許容最大認証局数が、前記パス上の合計認証局数が超えている場合は、前記公開鍵証明書の有効性が確認されなかったものと判断すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至１１のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記公開鍵証明書の有効性確認依頼が、電子手続に要求される信頼度の提示を伴う場合、前記コンピュータは、前記有効性確認ステップにおいて、
前記起点となる任意の認証局と前記有効性確認の依頼元との間のパスが、前記データベースに登録されている場合でも、前記パス上のいずれかの認証局が発行した、前記パス上の発行先認証局に対する公開鍵証明書中に記述されている信頼度が、前記電子手続に要求される信頼度よりも低い場合は、前記公開鍵証明書の有効性が確認されなかったものと判断すること
を特徴とする公開鍵証明書の有効性確認方法。 - 請求項１乃至１２のいずれか１項に記載の公開鍵証明書の有効性確認方法であって、
前記起点となる任意の認証局は、少なくとも２つのセキュリティドメインのルート認証局各々と相互認証を行っているブリッジ認証局であること
を特徴とする公開鍵証明書の有効性確認方法。
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000261065A JP3588042B2 (ja) | 2000-08-30 | 2000-08-30 | 証明書の有効性確認方法および装置 |
| DE60107634T DE60107634T2 (de) | 2000-08-30 | 2001-08-29 | Verfahren und Vorrichtung zur Authentifizierung der Gültigkeit eines Zertifikats |
| EP01120564A EP1185027B1 (en) | 2000-08-30 | 2001-08-29 | Certificate validity authentication method and apparatus |
| KR10-2001-0052476A KR100433439B1 (ko) | 2000-08-30 | 2001-08-29 | 증명서의 유효성 확인 방법 및 장치 |
| MYPI20014081 MY127188A (en) | 2000-08-30 | 2001-08-30 | Certificate validity authentication method and apparatus |
| CA002356410A CA2356410C (en) | 2000-08-30 | 2001-08-30 | Certificate validity authentication method and apparatus |
| US09/941,771 US7080251B2 (en) | 2000-08-30 | 2001-08-30 | Certificate validity authentication method and apparatus |
| SG200105266A SG100752A1 (en) | 2000-08-30 | 2001-08-30 | Certificate validity authentication method and apparatus |
| US11/452,299 US7409551B2 (en) | 2000-08-30 | 2006-06-14 | Certificate validity authentication method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000261065A JP3588042B2 (ja) | 2000-08-30 | 2000-08-30 | 証明書の有効性確認方法および装置 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2002072876A JP2002072876A (ja) | 2002-03-12 |
| JP3588042B2 true JP3588042B2 (ja) | 2004-11-10 |
| JP2002072876A5 JP2002072876A5 (ja) | 2004-11-25 |
Family
ID=18748978
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000261065A Expired - Lifetime JP3588042B2 (ja) | 2000-08-30 | 2000-08-30 | 証明書の有効性確認方法および装置 |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US7080251B2 (ja) |
| EP (1) | EP1185027B1 (ja) |
| JP (1) | JP3588042B2 (ja) |
| KR (1) | KR100433439B1 (ja) |
| CA (1) | CA2356410C (ja) |
| DE (1) | DE60107634T2 (ja) |
| MY (1) | MY127188A (ja) |
| SG (1) | SG100752A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7856412B2 (en) | 2007-01-05 | 2010-12-21 | Fujitsu Limited | Reliability evaluation program and reliability evaluation device |
| US8407150B2 (en) | 2006-05-15 | 2013-03-26 | Fujitsu Limited | Reliability evaluation device, reliability evaluation method, and computer program product |
Families Citing this family (77)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000048108A1 (en) | 1999-02-12 | 2000-08-17 | Mack Hicks | System and method for providing certification-related and other services |
| US20020029200A1 (en) | 1999-09-10 | 2002-03-07 | Charles Dulin | System and method for providing certificate validation and other services |
| ATE415670T1 (de) * | 1999-09-24 | 2008-12-15 | Identrust Inc | System und methode zur bereitstellung von zahlungsdienstleistungen im e-commerce |
| US7000105B2 (en) * | 2000-09-08 | 2006-02-14 | Identrus, Llc | System and method for transparently providing certificate validation and other services within an electronic transaction |
| WO2002032064A1 (en) * | 2000-09-08 | 2002-04-18 | Tallent Guy S | System and method for providing authorization and other services |
| US7046991B2 (en) * | 2001-07-16 | 2006-05-16 | Research In Motion Limited | System and method for supporting multiple certificate authorities on a mobile communication device |
| NO314379B1 (no) | 2001-11-28 | 2003-03-10 | Telenor Asa | Registrering og aktivering av elektroniske sertifikater |
| US7865720B2 (en) | 2002-03-20 | 2011-01-04 | Research In Motion Limited | System and method for supporting multiple certificate status providers on a mobile communication device |
| JP4582030B2 (ja) * | 2002-06-12 | 2010-11-17 | 株式会社日立製作所 | Ｃｒｌ発行通知機能付き認証基盤システム |
| JP5018849B2 (ja) * | 2002-06-12 | 2012-09-05 | 株式会社日立製作所 | Ｃｒｌ発行通知機能付き認証基盤システム |
| JP4474845B2 (ja) * | 2002-06-12 | 2010-06-09 | 株式会社日立製作所 | Ｃｒｌ発行通知機能付き認証基盤システム |
| GB0215590D0 (en) * | 2002-07-05 | 2002-08-14 | Hewlett Packard Co | Method and apparatus for generating a cryptographic key |
| GB0215524D0 (en) | 2002-07-05 | 2002-08-14 | Hewlett Packard Co | Method and apparatus for generating a cryptographic key |
| JP4698219B2 (ja) * | 2002-07-18 | 2011-06-08 | イーオリジナル インコーポレイテッド | 認定された文書の電子的送信、保存および読み出しシステム並びに方法 |
| KR100431210B1 (ko) * | 2002-08-08 | 2004-05-12 | 한국전자통신연구원 | 공개키 기반구조에서 인증서 정책 및 인증서 정책사상을이용한 인증서 검증서버에서의 인증서 검증방법 |
| KR100453685B1 (ko) * | 2002-11-05 | 2004-10-20 | 한국전자통신연구원 | 루트키 검증과 시알엘 선행 검증을 포함하는 변형된인증경로 검증장치및 방법 |
| JP2004214751A (ja) * | 2002-12-27 | 2004-07-29 | Hitachi Ltd | 証明書経路情報管理システム及び証明書経路管理方法 |
| JP2004234189A (ja) * | 2003-01-29 | 2004-08-19 | Mitsubishi Electric Information Systems Corp | 署名データ検証支援システム及び署名データ検証支援プログラム |
| US7370212B2 (en) | 2003-02-25 | 2008-05-06 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
| US7308573B2 (en) * | 2003-02-25 | 2007-12-11 | Microsoft Corporation | Enrolling / sub-enrolling a digital rights management (DRM) server into a DRM architecture |
| JP3894181B2 (ja) * | 2003-10-10 | 2007-03-14 | 株式会社日立製作所 | 公開鍵証明書検証の高速化方法、および装置 |
| KR20060097131A (ko) * | 2003-11-19 | 2006-09-13 | 코아스트리트 리미티드 | 분산 위임 인증 경로 획득 및 검증 |
| EP2112612A3 (en) | 2004-04-26 | 2011-08-03 | Google, Inc. | Method of verifying license compliance for a web application |
| US20050278778A1 (en) * | 2004-05-28 | 2005-12-15 | D Agostino Anthony | Method and apparatus for credential management on a portable device |
| JP2006074425A (ja) * | 2004-09-02 | 2006-03-16 | Mitsubishi Electric Corp | 公開鍵証明書検証装置及び公開鍵証明書検証方法及びプログラム |
| US7788483B1 (en) * | 2004-10-22 | 2010-08-31 | Winbond Electronics Corporation | Method and apparatus of identifying and enabling of functions of a trusted platform module device |
| US20060107326A1 (en) * | 2004-11-12 | 2006-05-18 | Demartini Thomas | Method, system, and device for verifying authorized issuance of a rights expression |
| US8438645B2 (en) | 2005-04-27 | 2013-05-07 | Microsoft Corporation | Secure clock with grace periods |
| JP2006287455A (ja) * | 2005-03-31 | 2006-10-19 | Nec Corp | 証明書検証装置及び方法並びに証明書検証サーバ |
| JP2006309659A (ja) * | 2005-05-02 | 2006-11-09 | Ntt Docomo Inc | 電子証明書管理システム |
| US20060265758A1 (en) | 2005-05-20 | 2006-11-23 | Microsoft Corporation | Extensible media rights |
| JP4694904B2 (ja) * | 2005-07-11 | 2011-06-08 | 三菱電機株式会社 | 検証サーバ及び検証プログラム |
| JP2007049311A (ja) * | 2005-08-08 | 2007-02-22 | Konica Minolta Business Technologies Inc | 電子証明書検証システム、電子証明書検証装置、クライアント、通信制御方法、およびコンピュータプログラム |
| CN1968086B (zh) * | 2005-11-17 | 2011-11-09 | 日电（中国）有限公司 | 用于通信网络的用户验证系统和方法 |
| JP4890867B2 (ja) * | 2006-01-17 | 2012-03-07 | キヤノン株式会社 | 情報処理装置およびその制御方法 |
| WO2007094036A1 (ja) * | 2006-02-13 | 2007-08-23 | Seiko Instruments Inc. | 情報処理システム |
| JP5052809B2 (ja) * | 2006-03-31 | 2012-10-17 | 株式会社エヌ・ティ・ティ・データ | 認証システム、認証サーバおよびプログラム |
| JP4529936B2 (ja) * | 2006-04-05 | 2010-08-25 | 株式会社日立製作所 | 公開鍵証明書検証の高速化方法、および装置 |
| JP2008028868A (ja) * | 2006-07-24 | 2008-02-07 | Nomura Research Institute Ltd | 通信代理システムおよび通信代理装置 |
| US8181227B2 (en) * | 2006-08-29 | 2012-05-15 | Akamai Technologies, Inc. | System and method for client-side authenticaton for secure internet communications |
| US7987375B2 (en) * | 2006-11-20 | 2011-07-26 | Canon Kabushiki Kaisha | Communication apparatus, control method thereof and computer readable medium |
| JP4488018B2 (ja) * | 2007-03-28 | 2010-06-23 | 株式会社日立製作所 | 公開鍵証明書検証システム |
| JP4985073B2 (ja) | 2007-04-19 | 2012-07-25 | 富士通株式会社 | 信頼性評価プログラム、信頼性評価方法および信頼性評価装置 |
| JP4594962B2 (ja) * | 2007-06-04 | 2010-12-08 | 株式会社日立製作所 | 検証サーバ、プログラム及び検証方法 |
| US20090038007A1 (en) * | 2007-07-31 | 2009-02-05 | Samsung Electronics Co., Ltd. | Method and apparatus for managing client revocation list |
| US8799648B1 (en) * | 2007-08-15 | 2014-08-05 | Meru Networks | Wireless network controller certification authority |
| JP5513410B2 (ja) * | 2008-01-18 | 2014-06-04 | アイデントラスト， インコーポレイテッド | 複数の信頼ドメインへのデジタル証明書のバインディング |
| US8768843B2 (en) | 2009-01-15 | 2014-07-01 | Igt | EGM authentication mechanism using multiple key pairs at the BIOS with PKI |
| KR20100100134A (ko) * | 2009-03-05 | 2010-09-15 | 한국전자통신연구원 | 네트워크 로봇 서비스를 위한 보안 서비스 방법 및 장치 |
| JP5131238B2 (ja) * | 2009-03-31 | 2013-01-30 | ブラザー工業株式会社 | 通信装置及びコンピュータプログラム |
| JP5452099B2 (ja) | 2009-07-01 | 2014-03-26 | 株式会社日立製作所 | 証明書の有効性確認方法、証明書検証サーバ、プログラム及び記憶媒体 |
| CN101674182B (zh) | 2009-09-30 | 2011-07-06 | 西安西电捷通无线网络通信股份有限公司 | 引入在线可信第三方的实体公钥获取、证书验证及鉴别的方法及系统 |
| US8327424B2 (en) * | 2009-12-22 | 2012-12-04 | Motorola Solutions, Inc. | Method and apparatus for selecting a certificate authority |
| JP5448892B2 (ja) * | 2010-02-03 | 2014-03-19 | 三菱電機株式会社 | 証明書検証システム、経路制約情報生成装置、証明書検証装置および証明書検証方法 |
| JP2011193416A (ja) * | 2010-03-17 | 2011-09-29 | Hitachi Ltd | 証明書の有効性確認方法、検証サーバ、プログラム及び記憶媒体 |
| JP5158125B2 (ja) * | 2010-04-20 | 2013-03-06 | 株式会社日立製作所 | 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体 |
| AU2012210978B2 (en) * | 2011-01-28 | 2015-11-26 | Royal Canadian Mint/Monnaie Royal Canadienne | Controlled security domains |
| US8701169B2 (en) | 2011-02-11 | 2014-04-15 | Certicom Corp. | Using a single certificate request to generate credentials with multiple ECQV certificates |
| US8726361B2 (en) * | 2011-08-15 | 2014-05-13 | Bank Of America Corporation | Method and apparatus for token-based attribute abstraction |
| US9253197B2 (en) | 2011-08-15 | 2016-02-02 | Bank Of America Corporation | Method and apparatus for token-based real-time risk updating |
| US8789143B2 (en) * | 2011-08-15 | 2014-07-22 | Bank Of America Corporation | Method and apparatus for token-based conditioning |
| US8910290B2 (en) * | 2011-08-15 | 2014-12-09 | Bank Of America Corporation | Method and apparatus for token-based transaction tagging |
| US8950002B2 (en) | 2011-08-15 | 2015-02-03 | Bank Of America Corporation | Method and apparatus for token-based access of related resources |
| US9055053B2 (en) | 2011-08-15 | 2015-06-09 | Bank Of America Corporation | Method and apparatus for token-based combining of risk ratings |
| US8752124B2 (en) | 2011-08-15 | 2014-06-10 | Bank Of America Corporation | Apparatus and method for performing real-time authentication using subject token combinations |
| US8572683B2 (en) | 2011-08-15 | 2013-10-29 | Bank Of America Corporation | Method and apparatus for token-based re-authentication |
| US8806602B2 (en) | 2011-08-15 | 2014-08-12 | Bank Of America Corporation | Apparatus and method for performing end-to-end encryption |
| US8539558B2 (en) | 2011-08-15 | 2013-09-17 | Bank Of America Corporation | Method and apparatus for token-based token termination |
| US9026789B2 (en) * | 2011-12-23 | 2015-05-05 | Blackberry Limited | Trusted certificate authority to create certificates based on capabilities of processes |
| JP5346111B2 (ja) * | 2012-07-24 | 2013-11-20 | 株式会社日立製作所 | 検証サーバ、プログラム及び検証方法 |
| JP5967822B2 (ja) * | 2012-10-12 | 2016-08-10 | ルネサスエレクトロニクス株式会社 | 車載通信システム及び装置 |
| US20140136838A1 (en) * | 2012-11-09 | 2014-05-15 | Timothy Mossbarger | Entity network translation (ent) |
| US9667616B2 (en) * | 2013-01-08 | 2017-05-30 | Mitsubishi Electric Corporation | Authentication processing apparatus, authentication processing system, authentication processing method and authentication processing program |
| JP6507854B2 (ja) * | 2015-05-28 | 2019-05-08 | 株式会社リコー | 情報処理システム、情報処理装置、電子証明書の管理方法、及びプログラム |
| EP4113335A4 (en) | 2020-02-28 | 2023-04-05 | Fujitsu Limited | Control method, control program, and information processing device |
| US11201741B2 (en) * | 2020-03-03 | 2021-12-14 | The Prudential Insurance Company Of America | System for improving data security |
| JP2021175016A (ja) * | 2020-04-20 | 2021-11-01 | 株式会社日立製作所 | デジタル署名の管理方法、デジタル署名の管理システム |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0872080B1 (en) | 1995-06-05 | 2010-12-15 | CQRCert LLC | Multi-step digital signature method and system |
| US5745574A (en) * | 1995-12-15 | 1998-04-28 | Entegrity Solutions Corporation | Security infrastructure for electronic transactions |
| JPH10215245A (ja) * | 1997-01-29 | 1998-08-11 | Nippon Telegr & Teleph Corp <Ntt> | 公開鍵認証方法 |
| US5996077A (en) * | 1997-06-16 | 1999-11-30 | Cylink Corporation | Access control system and method using hierarchical arrangement of security devices |
| US6226743B1 (en) * | 1998-01-22 | 2001-05-01 | Yeda Research And Development Co., Ltd. | Method for authentication item |
| US6134550A (en) * | 1998-03-18 | 2000-10-17 | Entrust Technologies Limited | Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths |
| JPH11328117A (ja) * | 1998-05-14 | 1999-11-30 | Hitachi Ltd | 認証システムにおけるユーザ管理方法 |
| JP3971890B2 (ja) * | 2000-11-01 | 2007-09-05 | 日本電信電話株式会社 | 署名検証支援装置、署名検証支援方法、及び電子署名検証方法 |
-
2000
- 2000-08-30 JP JP2000261065A patent/JP3588042B2/ja not_active Expired - Lifetime
-
2001
- 2001-08-29 DE DE60107634T patent/DE60107634T2/de not_active Expired - Lifetime
- 2001-08-29 KR KR10-2001-0052476A patent/KR100433439B1/ko not_active IP Right Cessation
- 2001-08-29 EP EP01120564A patent/EP1185027B1/en not_active Expired - Lifetime
- 2001-08-30 SG SG200105266A patent/SG100752A1/en unknown
- 2001-08-30 US US09/941,771 patent/US7080251B2/en not_active Expired - Lifetime
- 2001-08-30 MY MYPI20014081 patent/MY127188A/en unknown
- 2001-08-30 CA CA002356410A patent/CA2356410C/en not_active Expired - Fee Related
-
2006
- 2006-06-14 US US11/452,299 patent/US7409551B2/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8407150B2 (en) | 2006-05-15 | 2013-03-26 | Fujitsu Limited | Reliability evaluation device, reliability evaluation method, and computer program product |
| US7856412B2 (en) | 2007-01-05 | 2010-12-21 | Fujitsu Limited | Reliability evaluation program and reliability evaluation device |
Also Published As
| Publication number | Publication date |
|---|---|
| US7080251B2 (en) | 2006-07-18 |
| JP2002072876A (ja) | 2002-03-12 |
| EP1185027A3 (en) | 2002-11-13 |
| US20060242413A1 (en) | 2006-10-26 |
| DE60107634D1 (de) | 2005-01-13 |
| CA2356410C (en) | 2006-08-29 |
| US7409551B2 (en) | 2008-08-05 |
| EP1185027A2 (en) | 2002-03-06 |
| DE60107634T2 (de) | 2005-12-08 |
| EP1185027B1 (en) | 2004-12-08 |
| CA2356410A1 (en) | 2002-02-28 |
| MY127188A (en) | 2006-11-30 |
| SG100752A1 (en) | 2003-12-26 |
| KR20020018113A (ko) | 2002-03-07 |
| KR100433439B1 (ko) | 2004-05-31 |
| US20020046340A1 (en) | 2002-04-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3588042B2 (ja) | 証明書の有効性確認方法および装置 | |
| KR100625154B1 (ko) | 공개 키 증명서 검증의 고속화 방법, 및 장치 | |
| US8195933B2 (en) | Method and system for computing digital certificate trust paths using transitive closures | |
| JP5452099B2 (ja) | 証明書の有効性確認方法、証明書検証サーバ、プログラム及び記憶媒体 | |
| JP4474845B2 (ja) | Ｃｒｌ発行通知機能付き認証基盤システム | |
| KR102280061B1 (ko) | 블록체인 기반의 did를 이용한 법인 관련 증명서 발급 시스템 및 방법 | |
| US20030097566A1 (en) | Public key certificate generation method, validation method and apparatus thereof | |
| WO2019142428A1 (ja) | 情報処理装置およびその処理方法 | |
| JP2007110377A (ja) | ネットワークシステム | |
| KR100844436B1 (ko) | 지역적인 공개키 기반 구조를 갖는 지역분포형 로컬 씨에이시스템 | |
| JP2003348077A (ja) | 属性証明書検証方法および装置 | |
| JP2004248220A (ja) | 公開鍵証明書発行装置、公開鍵証明書記録媒体、認証端末装置、公開鍵証明書発行方法、及びプログラム | |
| JP4529936B2 (ja) | 公開鍵証明書検証の高速化方法、および装置 | |
| JP3901463B2 (ja) | 認証システムアクセス装置及び公開鍵証明証取得方法及び公開鍵証明証無効化確認方法及び、認証システムアクセスプログラム及び公開鍵証明証取得プログラム及び公開鍵証明証無効化確認プログラム及び認証システムアクセスプログラムを格納した記憶媒体及び公開鍵証明証取得プログラムを格納した記憶媒体及び公開鍵証明証無効化確認プログラムを格納した記憶媒体 | |
| JP5158125B2 (ja) | 公開鍵証明書の有効性確認方法、プログラムおよび記憶媒体 | |
| JP4582030B2 (ja) | Ｃｒｌ発行通知機能付き認証基盤システム | |
| JP5018849B2 (ja) | Ｃｒｌ発行通知機能付き認証基盤システム | |
| WO2022130507A1 (ja) | ユーザ情報管理システム、ユーザ情報管理方法、ユーザエージェントおよびプログラム | |
| JP2005328407A (ja) | 属性証明書検証方法及び装置 | |
| JP2007028061A (ja) | 証明発行依頼装置および証明発行プログラムおよび証明発行方法 | |
| JP2003058050A (ja) | 検証処理方法及びその実施システム並びにその処理プログラム | |
| JP2001265894A (ja) | 病院情報システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20031209 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20031209 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20040521 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20040601 |
|
| 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: 20040727 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040811 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3588042 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: 20070820 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080820 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080820 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090820 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100820 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100820 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110820 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120820 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130820 Year of fee payment: 9 |
|
| EXPY | Cancellation because of completion of term |
