JP5275536B2 - 証明書確認及び他のサービスを提供するためのシステム及び方法 - Google Patents
証明書確認及び他のサービスを提供するためのシステム及び方法 Download PDFInfo
- Publication number
- JP5275536B2 JP5275536B2 JP2001522463A JP2001522463A JP5275536B2 JP 5275536 B2 JP5275536 B2 JP 5275536B2 JP 2001522463 A JP2001522463 A JP 2001522463A JP 2001522463 A JP2001522463 A JP 2001522463A JP 5275536 B2 JP5275536 B2 JP 5275536B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- certificate
- request
- transaction coordinator
- coordinator
- 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 - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
本発明は、1999年9月13日出願の米国仮特許出願第60/153,726号「Transaction Coordinator for Certificate Status Checking and Other Services」、1999年9月13日出願の米国仮特許出願第60/153,724号「Transaction Coordinator Requirements and High Level Design」、及び1999年9月10日出願の米国仮特許出願第60/153,203号「System and Process for Certification in Electronic Commerce」の優先権を主張し、これらの開示内容は、引用により本明細書に組み込まれている。
本発明は、一般的に、公開鍵インフラストラクチャーによるサービスを提供することによって、電子商取引を容易にする技術分野に関する。
電子商取引の世界では、契約当事者間の関係を証明する新しい試みがなされてきた。これらの試みは、当事者は取引に関して互いに顔を合わせたり声を聞いたりできず、又は簡単に互いの身元や取引の権限を確認できないことから行われている。
この問題に対する1つの解決策は、各々の契約当事者に、送信メッセージに署名するための秘密鍵を与えることである。署名した当事者は、当事者の秘密鍵を署名したメッセージを復号化する関連の公開鍵を利用できるようにするので、受け取った当事者は、送信者の身元を確認できる。
時として、受信者は、認証機関の公開鍵に慣れていない場合があり、又は受信者は、証明書が依然として有効か否かが分からない場合がある。この場合、受信者は、信任をおこなうエンティティを用いて証明書の信憑性と有効性を調べようとする。公知の1つのプロトコルとして、証明書のステータスを調べるためのオンライン証明書ステータスプロトコル(OCSP)がある。
本発明は、証明書の検証及び保証を含む証明書関連サービス及び他のサービスを安全に提供することによって、電子商取引を容易にするシステム及び方法を開示する。好適な実施形態において、このサービスは、4コーナー信用モデルのコンテキスト内で提供される。4コーナーモデルは、オンライン取引に従事する、申込取引先(subscribing customer)と呼ばれる買い手と、信用取引先(relying customer)と呼ばれる売り手とを含んでいる。買い手は、発行関係先(issuing participant)と呼ばれる第1の金融機関の取引先である。発行関係先は、買い手の証明機関としての機能を果たし、買い手に秘密鍵及び発行関係先が署名したデジタル証明書を含むハードウェア・トークンを発行する。売り手は、信用関係先(relying participant)と呼ばれる第2の金融機関の取引先である。信用関係先は、売り手に対する証明機関としての機能を果たし、買い手に秘密鍵及び信用関係先が署名したデジタル証明書を含むハードウェア・トークンを発行する。
これらのサービスを提供する詳細なメッセージフローは以下の詳細な説明に示されている。
本発明の前述及び他の目的、特徴、及び利点は、以下の詳細な説明及び添付図面を参照することにより理解できる。
本発明は、金融機関が取引先に対して電子証明書ステータス照合及び他のサービスを安全に実行することを容易にするシステムに関する。好適な実施形態において、本発明のシステムは、これらのサービスを提供するためのコーナー信用モデルを使用する。図1は、本発明で使用する4コーナー信用モデルの好適な実施形態を示す。
図1に示すように、4コーナーモデルは、第1の機関102と第2の機関104とを含んでいる。第1の機関102は、本システムの関係先であり、取引先にスマートカードを発行するという理由で、以下では「発行関係先」と呼ぶ。第2の機関104は、本システムの関係先であり、取引先は発行関係先102及び発行関係先102の取引先によってなされる表示を信用するという理由で、以下では「信用関係先」と呼ぶ。
スマートカードに関する好適な仕様、その製造方法、及びその内容は、2000年8月14日に出願された係属中の米国特許仮出願第60/224,994号「Signing Interface Requirements, Smart Card Compliance Requirements, and Additional Disclosure」に説明されており、その開示内容は、引用により本明細書に組み込まれている。
請求書発行コンポーネント322は、取引コーディネーター202が受け取ったメッセージ(応答及びリクエスト)に対する請求書発行履歴を生成して格納することである。このモジュール及びコンポーネントの好適な操作を以下に詳細に説明する。
ステップ4008で、認証モジュール408は、取引コーディネーター202の署名コンポーネント324を呼び出して、即ちハードウェア218を呼び出してリクエスタを認証する。署名コンポーネント324の好適な構造及び操作は以下に詳細に説明する。
ステップ4010で、認証モジュール408は、証明書ステータス照合モジュール414を呼び出し、次にOCSPレスポンダ204を呼び出してリクエスタに関する証明書ステータス照合を行う。証明書ステータス照合モジュール414の好適な構造及び操作を以下に詳細に説明する。
ステップ4014で、リクエストマネージャ304は、提供されたサービスに対する適切な請求書に必要な、任意の請求書発行データを請求書発行コンポーネント322に送り、請求書発行ログへ記録する。
ステップ4022で、サービスリクエストルータ426は、ステップ4020で呼び出したサービスモジュールからサービス応答を受け取る。サービスリクエストルータ426は、サービス応答をリクエストマネージャ304へ戻し、次にサービス応答を転送サービスコンポーネント306へ送る。転送サービスコンポーネント306は、サービス応答を、サービスリクエストを作るエンティティへ送る。
図5において、ステップ5002で、署名コンポーネント324は、リクエストを受け取ると、署名リクエストであるか又は検証リクエストであるかを決定する。検証リクエストの場合、署名コンポーネント324は、検証リクエストをハードウェア・セキュリティ・モジュール218へ送る(ステップ5004)。ステップ5008で、ハードウェア・セキュリティ・モジュール218は、このリクエストに応答して検証を行い、署名検証応答を署名コンポーネント324へ戻す。
ローカル取引先ハンドラ602がリクエストを引き渡す場合には、システムはステップ6008を実行し、ローカル取引先ハンドラ602は、証明書照合リクエストを証明書照合サービスモジュール312へ送る。次に、証明書ステータス照合コンポーネント312は、関連のOCSPレスポンダ204(即ち、証明書ステータス照合コンポーネント312として同じ取引コーディネーター202に属する)から、照合すべき証明書に関する証明書ステータスを取得する。この場合のフローは以下のステップ6032に進む。
ステップ6022で、OCSPリクエスト定式化モジュール608は、応答を非ローカル取引先ハンドラ610へ送る。ステップ6024で、非ローカル取引先ハンドラ610は、未処理応答データを否認防止目的の未処理取引ログ212へ記録する。
ステップ6028で、非ローカル取引先ハンドラ610は、ステップ6012から6024を繰り返すことによって発行関係先102の取引コーディネーター証明書を検証すが、ステップ6014で生成されたOCSPリクエストを、発行関係先102ではなくルート・エンティティ110へ送る。
ステップ6032で、非ローカル取引先ハンドラ610が受け取った、又はローカル取引先ハンドラ602が生成した証明書照合応答データは、応答に署名を行う署名コンポーネント324へ送る。ステップ6034で、署名付き応答は、証明書照合サービスモジュール312に戻され、次に証明書照合サービスモジュール312はこの応答をサービス要求ルータ426へ送る。
ステップ7022で、取引コーディネーター202RPは、信用取引先の証明書含むOCSPリクエストを発生して、それに署名を行いOCSPレスポンダ204へ送る。もしくは、取引コーディネーター及びOCSPレスポンダが同じ場所に配置される場合は、リクエストに関する署名を必要としないこともある。ステップ7024で、OCSPレスポンダ204は、リクエストの署名を検証し、ローカルリポジトリーを照合して信用取引先の証明書の有効性を決定し、証明書のステータスに関連する応答を取引コーディネーター202RPへ戻す。
好適な実施形態において、本システムでは、この問題を、他の関係先が発行した証明書に関するOCSPリクエストを受け取る各々の関係先が、リクエストを証明書に関する発行関係先へ送るようにさせることによって解決する。特にステップ7026において、信用関係先104は、申込取引先の発行関係先を決定する。申込取引先が別の関係先の取引先である場合、信用関係先104は、申込取引先の証明書に関する署名付き検証リクエストを発生し、それを自身の証明書と共に確認済み発行関係先102へ送る。もしくは、検証リクエストに署名するのではなく、代わりに信用関係先は、発行関係先102に対するクライアント側認証手段を備えることもでき、例えば、以下に説明するOCSPプロキシ中心モデルである。
ステップ7028で、発行関係先102は、その取引コーディネーター202RPを照合して、リクエストを行うことが認定されているエンティティがリクエストに署名したことを確認する。ステップ7030で、発行関係先102は、受け取った未処理データ(即ち、未解析リクエスト、署名、及び付随の信用取引先証明書)を未処理取引ログ212RPへ格納する。ステップ7032で、発行関係先102は、リクエストに対する関連の請求書発行データを請求書発行ログ208へ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。
ステップ7056で、信用関係先104の取引コーディネーター202RPは、発行関係先102から受け取った未処理応答データを否認防止目的のための未処理取引ログ212RPへ格納する。ステップ7058で、取引コーディネーター202RPは、信用関係先の取引コーディネーター証明書(リクエストと共に送られた)と、ルート公開鍵(ハードウェア・セキュリティ・モジュール218RPに格納できる)とを用いて、取引コーディネーター202IPの応答に関する署名を検証する。ステップ7060で、取引コーディネーター202RPは、信用関係先の取引コーディネーター証明書に対する署名付きOCSPリクエストを発生し、それをルート・エンティティ110へ送る。
ステップ7074で、取引コーディネーター202RPは、ここで応答即ち申込取引先の証明書の後半部を、署名付きOCSPリクエストを発生して、それをルート・エンティティ110へ送ることで処理する。
ステップ7080で、取引コーディネーター202Rは、リクエストに関する署名を検証し、そのリクエストをOCSPレスポンダ204Rへ送る。ステップ7082で、OCSPレスポンダ204Rは、ローカルリポジトリーを照合して対象の証明書のステータスを決定し、応答を取引コーディネーター202Rへ戻す。ステップ7084で、取引コーディネーター202Rは、署名付き応答を取引コーディネーター202RPへ送る。
前述のステップ7092から7104に関連して、システム操作の一部として、信用取引先108は、典型的に、信用関係先の取引コーディネーター証明書のステータスを取得することを必要とする点に留意されたい。4コーナーモデル内で、発行関係先102及び信用関係先104の取引コーディネーター及びOCSPレスポンダ証明書は、ルート・エンティティ110により署名される。ルート・エンティティ110はOCSPレスポンダを操作するが、このサービスは、関係先だけが利用できる。結果的に、信用取引先108は、信用関係先の証明書の検証をルート・エンティティ110に要求できない。
図8に示すように、ステップ8002で、申込取引先106は、申込取引先106と信用取引先108との間のデータ・ハッシュを生成し、このハッシュを署名用のスマートカード226へ送る。ステップ8004で、スマートカード226は、データに署名し、署名を信用関係先の証明書及び信用関係先の証明書と共に戻す。随意的に、このメッセージは、カード及び署名セキュリティデータ(CSSD)を含んでもよく、重複メッセージに対する保護といった追加的なセキュリティを与えるようになっている。
ステップ8014で、信用関係先104の取引コーディネーター202RPは、取引先データ・データベース214RPを照合して、リクエストを処理する前に、実在の取引先がリクエストに署名したことを確認する。ステップ8016で、取引コーディネーター202RPは、取引に関する(即ち「未解析」リクエスト、署名、及び付随の証明書)未処理取引データを未処理取引ログ212RPへ格納する。ステップ8018で、取引コーディネーター202RPは、関連の請求書発行データを請求書発行ログ208RPへ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。
ステップ8024で、取引コーディネーター202RPは、リスクマネージャ216RPを呼び出し、信用取引先108が保証リクエストを行うことが金融上認可されているか否かを決定する。認可されていれば、次に、ステップ8026で、取引コーディネーター202RPは、申込取引先106に対する保証リクエストに応じることについての関係先の責任を決定する。本実施例において、このエンティティは、発行関係先102である。次に、取引コーディネーター202RPは、申込取引先106に対する保証リクエストを生成し、それに署名し、自身の証明書と共に発行関係先102へ送る。申込取引先及び信用取引先の両者が同じ関係先の取引先である場合には、代わりに保証リクエストを関係先でローカル処理してもよい点に留意されたい。
ステップ8060で、信用関係先104の取引コーディネーター202RPは、未処理応答を否認防止目的のための未処理取引ログ212へ格納する。ステップ8062で、取引コーディネーター202RPは、取引コーディネーター202IPの証明書(リクエストと共に送られた)、及びルート公開鍵(ハードウェア・セキュリティ・モジュール218RPに格納できる)を用いて、応答に関する取引コーディネーター202IPの署名を検証する。次に、取引コーディネーター202RPは、発行関係先の取引コーディネーター証明書に対する署名付きOCSPリクエストを生成し、それをルート・エンティティ110へ送る。
ステップ8088で、取引コーディネーター202RPは、リクエストに関する署名を検証し、応答をOCSPレスポンダ204RPに送り、信用取引先108の取引コーディネーター証明書が無効になっていないことを保証する。ステップ8090で、ローカルOCSPレスポンダ204RPは、その証明書に対するOCSPリクエストを取引コーディネーター202Rへ送る。
ステップ8096で、取引コーディネーター202RPは、取引コーディネーター202Rから受け取った応答を信用取引先108へ送る。ステップ8098で、信用取引先108は、確認通知を申込取引先106へ送る。
(1)高性能なメッセージ受け渡しエンジン。
(2)クライアント及びサーバーが分散取引に参加して、アプリケーションに意識させないで2元コミットプロセスを管理することを可能にする、分散取引管理。
(3)ハードウェア・ホスティング・プログラムに無関係に、開発者がBEA TUXEDOアプリケーションを書き込むことを可能にする、取引マネージャインターフェイス用アプリケーション。
(4)自動的にアプリケーションの並列コピーを生成して管理し、それらを平等に利用することを保証する、動的作業負荷平衡化。
(5)分散アプリケーションが非同期、非結合様式で同時に作動するのを可能にし、メッセージのコンテキスト、内容、及び日時に基づいてキューに優先順位をつける、取引キューイング。
(6)最もデータを有効に利用できる場所で取引を処理することを可能にするデータ依存ルーチン。
(7)サーバーマネージャが異常処理を再起動して、進行中であった取引をロールバックする、アプリケーション異常、取引異常、ネットワーク異常、及びノード異常からの自動回復。
(1)完全なCOMコンポーネントのサポート。
(2)様々なプログラム言語(例えば、Visual C++、Visual J++)からのアクセス。
(3)進化したメッセージキューイング利点をもたらす、5つ(オープン、クローズ、送信、受信、位置指定)のAPI。
(4)スライド・ウインドウ・プロトコル、回復可能ストレージ、メッセージ配信のための動的経路指定、定期的で順序正しいメッセージ配信。
(5)データベース更新等の他の作動を有する取引内に含むことができる能力。
(6)他のリソースに関する操作を委ねる又は中止して、取引中のデータ保全性を維持する能力。
(7)組み込みメッセージ暗号化、保全性、及び署名サポート。
(8)何れのMSMQイベントが、WindowsNT(登録商標)セキュリティログの検査記録を生成する必要があるかの指示能力をもつ管理者。
(1)多種多様なシステムを統合する分散取引処理手続きアプリケーションを可能にする相互運用性。
(2)X/OpenXAアプリケーション・プログラム・インターフェイスを介し、メインフレームに付加的なソフトウェアを必要とすることなく、sync−level0,1,2サービスを含むメインフレームLU6.2同時使用を提供する、Oracle、Ingres、Infomix、又はSybase等の多重XAコンプライアントデータベース又はリソースマネージャの同時使用。
(3)取引処理手続きアプリケーションが必要とする性能及び信頼性。
(4)有効な完全分散型2元コミット機構。
(5)性能を高め単点故障を排除する、自動負荷平衡化及びアプリケーション複製サービス。
(6)クライアント及びサーバーの両者が、取引の関係先の身元及び権限を検証することを可能にする、基本的DCEの遺伝性セキュリティ機構。
(7)自動認証照合を含み、検査記録構造を与えるのを容易にする、追加的なセキュリティ機構。
(8)多数のユーザ及び大量のデータをサポートするための企業的拡張性。
(9)有効な管理を可能にするのを容易にする集中管理。
(1)堅固なミドルウェア
(2)分散取引管理
(3)クライアント/サーバー相互作用
(4)信頼性の高いファイル転送
(5)動的作業負荷平衡化
(6)回復可能取引キューイング
(7)アプリケーション並列化
(8)2元コミット処理手続き
(9)自動回復
(10)メッセージ依存ルーチン
(11)多重データベースサポート(MicrosoftSQLサーバー、Oracle、及びSybase)
(12)インターネット・アプリケーションの拡張性及び有用性
好適な実施形態において、取引コーディネーターは、ルート・エンティティ110により定義されるPKIに基づくPKIX認証を利用する。本システム以外のサービスに関する他の認証機構は、取引コーディネーターを操作するエンティティにより決定されるのと同様にサポートできる。
好適な実施形態において、セキュア・ソケット・レイヤー(SSL)プロトコルは、セッションレベルの認証をもたらす。セキュア・ソケット・レイヤー・プロコルは2つのフェーズからなる。即ち、サービス側認証と随意的なクライアント側認証とである。所定の取引コーディネーター202は、取引先又は他の取引コーディネーターからのリクエストを受け取る場合にはサーバーとして、他の取引コーディネーターヘリクエストを送る場合にはクライアントとしての機能を果たす。
ステップ1108で、認証モジュール408は、OCSPレスポンダ204を呼び出し、ハードウェア・セキュリティ・モジュール218に格納された証明書以外の、発信者のチェーンの証明書が無効になっていないことを確認する。
好適な実施形態において、取引コーディネーター202は、セキュア・ソケット・レイヤー(SSL)を用いてセッション・セキュリティを提供する。典型的に、SSLは、3段階のセッション・セキュリティを提供する。即ち、機密性、データ保全性、及びセッション認証である。取引コーディネーター202からの、又は取引コーディネーター202への通信は、SSLを用いて暗号化することが好ましい。
前述のように、デジタル署名は、署名プロセス中に生成されるハッシュ又はメッセージ・ダイジェストを使用して、データ保全性をもたらすことが好ましい。メッセージ・ダイジェストは、署名付きデータの何れかのビットが変更されると、別の「指紋」が生じてデータの受信者が署名を検証できないようになったデータの「指紋」を与える。
好適な実施形態において、各々の取引コーディネーター202は、ログ内の実行サービスの否認防止を保証し、これらのログの保全性を保証するのに必要な全てのデータを記録する。例えば、信用関係先104は、信用取引先108に対して実行する全てのサービスに関するそのような否認防止を提供することが好ましい。つまり、各々の実行サービスに対して、取引コーディネーター202RPは、信用取引先108への応答のみならず、サービスの実行に関係するどのパーティも提供サービスを拒否できないことを保証するのに必要な全てのデータを保持する。
ステップ1208で、リクエストマネージャ304は、リクエストに関する署名が要求されているかを確認する。ステップ1210で、リクエストマネージャ304が、リクエストには署名の必要がないことを確認すると、リクエストマネージャ304は、クライアントのユーティリティ証明書を用いて取引先認証照合モジュール54を呼び出す。
署名コンポーネント324は、メッセージ・セキュリティをもたらし、セッション及びメッセージ認証サービスをサポートすることが好ましい。署名コンポーネント324は、ハードウェア・セキュリティ・モジュール218と相互作用して暗号化機能を果たす。ルート・エンティティ110は、全ての取引に対して使用されるデジタル署名方法の仕様を定めることが好ましい。署名コンポーネント324は、ハードウェア・セキュリティ・モジュール218と相互作用して署名検証プロセスに含まれる暗号化機能を果たすことが好ましい。
ステップ1218で、取引先認証モジュール110は、取引先の保証証明書を用いて取引先認証照合モジュール418を呼び出す。ステップ1220で、取引先認証照合モジュール418は、取引先データベース214を照合して、取引先からのリクエストが、要求サービスを取得することの認定がなされているのを確認する。ステップ1222で、認定に関するリクエストは、リクエストマネージャ304へ戻され、前述のようにサービスが提供されたシステムの処理が継続する。
信用取引先108が信用関係先104に対する実在の取引先であるか否かを確認する。また、取引コーディネーター202RPは、認定を行って、要求されているサービスの形式又はレベルを受け取ることが認定されているか否か確認できる。信用取引先108は、資格があるサービスを列挙する取引先データベース214RPに関する入口を有することが好ましい。信用取引先108は、セキュア・ソケット・レイヤー・サーバー側セッション認証が採用される場合、識別名によって保証証明書に存在することが確認でき、また、その識別名によってユーティリティ証明書に存在することが確認できるのが好ましい。この取引コーディネーター態様は、COTSアクセス制御/認証パッケージと一体であってもよい。
典型的に、信用取引先108と取引コーディネーター202RPとの間で交換されるメッセーはデジタル署名される。取引コーディネーター202RPは、受け取った全ての署名付きメッセージを証明し、証明書チェーンを検証し、チェーン内の証明書が無効になっていないことを保証するのが好ましい。更に、取引コーディネーター202RPは、信用取引先108へ送る全てのメッセージに署名する。
しかし、これらのコンポーネントが同じ場所に配置されていない場合は、通信の機密性又は保全性を危うくするネットワーク攻撃に対して通信を保護することが好ましい。この保護をもたらすSSLを利用することが好ましい。
信用関係先104が同様に該当証明書の発行関係先102であり、OCSPリクエストが、例えば証明書に対する検証リクエスト中に取引先証明書の証明を照合するサービス提供処理の一環である場合にのみ記録される。
関係先は、他の取引コーディネーターからその取引コーディネーターへ送られた全てのリクエストが署名付きであることを要求する場合もある。その代わりに、関係先は、セキュア・ソケット・レイヤー・クライアント側セッション証明書を要求とする場合もある。取引コーディネーター202IP、202RP、202Rは、他の取引コーディネーターへ送られる全ての応答に署名することが好ましい。
取引コーディネーター202IP、202RP、202Rが受け取った、サービスに対するリクエストを記録できることが好ましい。これによりシステム管理者は、システムに対する潜在的な攻撃を検出でき、また、システム管理者は、鍵漏えいが発生した後でサービスに対するリクエストを受け取ったか否かを確認できる。また、リクエスト検査は、起こり得るどんな請求書発行係争をもサポートするのに利用できる。
取引コーディネーターのコンポーネントは、専用のソフトウェアコードとして実現するのが好ましいが、他のソフトウェア製品も本明細書で説明するように利用できる。このコードに加えて、関係先は、前述の証明書ステータス照合サービスに関する彼ら自身のビジネス仕様ルールや、4コーナーモデルによりもたらされる他のサービスを書き込んで実行できる。
(1)レポート、データ分析、意志決定、及びデータモデル化に不可欠な複数の情報を有効に分析するためのオンライン分析処理(OLAP)
(2)ディスク格納アーキテクチャ
(3)マルチフェーズ・クエリ・オプチマイザー
(4)クエリ・オプチマイザーが最新情報を利用してクエリ効率を高めるようにできる自動統計
(5)運用システムへの影響を最低限にした状態で高性能オンラインバックアップをもたらすアクティブ・バックアップ
(6)ユーザが単独で作業して後で結合することを可能にするマージ複製
(7)マージ競合を解決するための組み込み優先順位ベース競合解決
(8)ウェブへのデータ公開能力
(9)複数の異質のソースからのデータを取り込んで変換するデータ変換サービス
(10)物理的及び論理的データベース一貫性照合能力
(11)動的列レベル固定
(12)統計的収集を管理し効率的方法を保証するクエリ・オプチマイザー
(13)性能を高めるための、単一クエリの各々のステップが並行実行されて最適な応答時間をもたらす、複数のプロセッサを横切る単一クエリのクエリ内並行実行
(14)意志決定サポート、データウェアハウス、及びオンライン分析処理アプリケーションに見られる、大きなデータベース及び複雑なクエリを上手くサポートする、再設計されたクエリプロセッサ
(15)ソート速度
(16)テーブル毎の複数トリガー及びトリガーの直接反復
(17)最適なメモリ割り当て及び使用のための動的メモリ、及び動的メモリ管理
(18)並行バックアップ及び素子速度でのユーティリティスケールの修復
(19)性能向上及び手動調整の必要のないスマート先読みロジック
(20)重要な構成のランタイムチェック
TymeServe Network Time Server
(“TYMSYNC”)登録商標が使用されている。TYMSYNCは、米国海軍天文台によって管理されている、協定世界時間に対する最も近いマイクロ秒まで、完全な正確性をもって、ナブスター全地球位置把握システムの衛星の配置から時間を読み取る、時間同期パッケージである。この製品は、ワークステーションを、TCP/IP(transmission control protocol over internet protocol)およびLAN(local area network)ネットワークで同期させるように適応していてもよい。好ましくは、ネットワーク・タイム・プロトコル(Network Time Protocol)を用いて、ネットワーク内で時間を配分する。
TYMSYNCは、コンピュータ・システムのクロックを、継続的に、協定世界時間に同期させるように構成されてもよい。要求ならびに応答が生成され、およびメッセージが受信され、ならびに送信される時間は、好ましくは、否認防止目的、および監査目的で記憶される。
S/MIMEメッセージを送信するためのSMTPを用いて、およびSSLv3接続(HTTPS)を介してHTTPプロトコルを通して通信し、パブリック・インターネットでメッセージを受信し、および送信することができる。すなわち、各トランザクション・コーディネータは、好ましくは、以下の二つの通信モードをサポートするように適応する:
・ 安全ソケット・レイヤ(SSLv3)を介したHTTP−同期通信(すなわちHTTPS)のためのものである。HTTPSは、ウェブ・ページを安全に転送するために、ウェブ・サーバとウェブ・ブラウザとの間の、安全ソケット・レイヤを統合する、ハイパーテキスト転送プロトコルである。HTTPキープ・アライブ(HTTP keep alive)の使用が推奨される。
・ S/MIMEv2−SMTPを使用した非同期通信のためのものである。
ハードウェアおよびソフトウェア・アベイラビリティ製品に加えて、アプリケーションおよびネットワークを監視するために、好ましくは、モニタリング・インフラストラクチャが使用される。
CICS、IMS、および他のレガシー・システム等、現存のオペレーショナル・システムとの統合をサポートするように適応してもよい。
Windows NT(登録商標)4.0/2000,Sun Solaris,および
Hewlett Packard HP−UXに基づいて、サーバ上でサポートされることができるように、プラットフォーム独立である。実装は、好ましくはJAVA(登録商標)でなされるが、コード化は、同様にC/C++でなされてもよいものもある。
Visual SourceSafe6.0は、ソース・コントロールのために使用されてもよい。SymantecのVisual Cafe
Professional Edition3.0(Java(登録商標)
Version1.2)が、開発のために使用されてもよい。RSA
Security SystemsのSSL/J SDKは、安全ソケット・レイヤ実装のために使用されてもよく、XETIのJKIXによっても求められる。
Code Warrierは、ポータブルC/C++開発の、開発のために使用されてもよい。コード・ポータビリティ(code portability)を検査するためのコード完全性チェックを実行するために、CodeIntegrityが使用されてもよい。
Microsoft Windows NT(登録商標)4.0/2000、Sun Solaris およびHewlett Packard HP−UX)にポートされる。これによって関係先は、サポートされたプラットフォームのリストから、自らのハードウェア・プラットフォームを選択することができる。好ましくは、トランザクション・コーディネータが、サポートされたプラットフォームの各々に、円滑にインストールされることを確証するためのテストが実行される。そのような、適切なハードウェアをテストすることを可能にすることが、通常求められる。
Windows NT(登録商標)マシンにインストールされ、およびアンインストールされることを確証するためのテストが実行される。
・ SSLを使用した暗号通信
・ 要求と応答の両方のための、未処理トランザクションのロギング
・ 応答を伴う証明書チェーンの供給
・ 好ましくは、HSMを使用した、要求への署名の確認
・ 要求を伴う証明書チェーンの認可(その一部は、ローカル・データベースまたはHSMに記憶されていてもよい)
・ 次のものに基づいた新しい要求の作成
・受信された要求の、サービス・ロケータ(service lacator)要求拡張における値
・応答を伴う証明書における、オーソリティ情報アクセス拡張
・応答が、これらの他の新しく作成された要求において受信されるまでの、要求での処理の延期。すなわち、要求への応答を同期させる機能。
・適切なときの、転送の応答
この代替的実施形態は、新しいサービスを追加する柔軟性を与えることなく、証明書ステータス・チェック・サービスの一部のみを供給する。また、請求は、この代替的実施形態においては実行されない。さらに、この代替的実施形態は、ベンダ・ロッキング(vendor locking)を生じさせるかもしれない。この代替的実施形態の賛否両論の詳細が以下に列挙されている。
1 申込取引先(subscribing customer, SC)は、署名されたデータ、署名、 SCおよびIP証明書(任意でCSSD)を、信用取引先
(relying customer, RC)に送信する。
2 RCは、SCによって送信されたデータの署名を確認し、SCの証明書チェーンを認可し、それからSC証明書番号を含むOCSP要求を作成する。このデータは、署名のために、HSMに送信される。
3 RCによって署名された、SCの証明書に対するOCSP要求は、RCの証明書チェーンとともに、信用関係先(relying participant, RP)OCSPレスポンダ(OR)に送信される。証明書チェーン全体が、メッセージとともに渡されなければならない。
4 RP OCSPレスポンダは、そのOCSPログに、要求をログする。
RP OCSPレスポンダは、要求における署名を確認し、およびRCの証明書チェーンを認可する。すべての確認はソフトウェアで実行される。チェーン全体(ルートを含む)は、署名/証明書チェーンの確認が実行されるように、メッセージとともに渡されなければならない。RCの証明書が取り消されなかったことを確証するためのチェックは、実行されない。
5 RP OCSPレスポンダは、RCから受信された単一の要求を含む、新しい要求を作成し、そのHSMを用いてそれに署名する。金融機関の間での、署名された要求は、必要とされない。その代わり、ルート・エンティティ(ROOT)は、確認/認可/取引先検索が、SSL接続と関連する証明書に基づいているような場合である、SSLクライアント側認証を要求してもよい。
6 RP OCSPレスポンダは、受信された要求の、サービス・ロケータ要求拡張における値に基づいて、署名されたOCSP要求を、適切な発行関係先のOCSPレスポンダに送信する。
7 IP OCSPレスポンダは、そのOCSPログに、要求をログする。IP OCSPレスポンダは、要求における署名を検査し、RP ORの証明書チェーンを認可する。すべての検査はソフトウェアで実行される。チェーン全体(ルートを含む)は、署名/証明書チェーンの検査が実行されるようにするために、メッセージとともに渡されなければならない。
8 IP OCSPレスポンダは、RP OCSPレスポンダの証明書番号を含むOCSP要求を作成し、およびそのHSMを用いてそれに署名する。
9 IP OCSPレスポンダはそれから、ステップ4において受信された要求における署名に関連した証明書におけるオーソリティ情報アクセス拡張に基づいて、ROOT OCSPレスポンダに要求を送信する。IP
OCSPレスポンダは、SCの証明書における応答を発行する前に、RP OCSPレスポンダの証明書に関するROOTからの応答を待つ。IPがSSLクライアント側認証のみを要求し、署名されたOCSP要求を求めない場合、このステップは必要ではないかもしれない。
10 ROOT OCSPレスポンダは、そのOCSPログに、要求をログする。ROOT OCSPレスポンダは、要求における署名を確認し、IP OCSPレスポンダの証明書チェーンを認可する。金融機関の間で署名された要求は求められない。その代わり、ROOTは、確認/認可/取引先検索が、SSL接続に関連する証明書に基づいている場合である、
SSLクライアント側認証を求めるかもしれない。
11 ROOT OCSPレスポンダは、RP OCSPレスポンダの証明書のステータスを決めるために、そのローカル・データベースを調べ、それから応答を生成し、およびそのHSMを用いてそれに署名をする。
12 ROOT OCSPレスポンダは、それから応答をIP OCSPレスポンダに返す。
13 IP OCSPレスポンダは、そのOCSPログに、応答をログする。IP OCSPレスポンダは、要求における署名を確認し、およびルートのOCSPレスポンダ証明書チェーンを認可する。しかしながら、否認防止をサポートするのに十分な情報が、ログに維持されていないかもしれないことが注目される。
証明書チェーン全体は、メッセージとともに渡されなければならない。
14 IP OCSPレスポンダは、それから、SCの証明書のステータスを決めるために、そのローカル・データベースを調べる。IP OCSPレスポンダは、応答を生成し、およびそのHSMを用いてそれに署名をする。
15 IP OCSPレスポンダは、署名された応答を、RP OCSPレスポンダに送信する。
16 RP OCSPレスポンダは、OCSPログに、OCSP応答をログする。RP OCSPレスポンダは、応答における署名を確認し、および
IPのOCSPレスポンダ証明書チェーンを認可する。証明書チェーン全体は、メッセージとともに渡されなければならない。
17 RP OCSPレスポンダは、IP OCSPレスポンダの証明書の番号を含むOCSP要求を作成し、およびそのHSMを用いてそれに署名をする。
18 RP OCSPレスポンダはそれから、ステップ14で受信された応答における署名に関連する証明書におけるオーソリティ情報アクセス拡張に基づいて、ROOT OCSPレスポンダに要求を送信する。
19 ROOT OCSPレスポンダは、そのOCSPログに、未処理要求をログする。ROOT OCSPレスポンダは、要求における署名を確認し、およびRP OCSPレスポンダの証明書チェーン全体を認可する。証明書チェーン全体は、メッセージとともに渡されなければならない。
20 ROOT OCSPレスポンダは、IP OCSPレスポンダの証明書のステータスを決めるために、そのローカル・データベースを調べ、それから応答を生成し、およびそのHSMを用いてそれに署名をする。
21 ROOT OCSPレスポンダは、署名された応答を、OCSPレスポンダに送信する。
22 RP OCSPレスポンダは、そのOCSPログに、応答をログする。RP OCSPレスポンダは、応答における署名を確認し、およびルートのOCSPレスポンダ証明書チェーンを認可する。証明書チェーンは、メッセージとともに送信されてもよく、またはチェーンの一部は、HSMか、または証明書確認データベースにあってもよい。
23 RP OCSPレスポンダは、それがステップ2において(例えば、一回だけ)受信した情報、およびステップ14においてそれが受信したSCの証明書に関するステータス情報を含むRCに関する応答を作成し、およびそのHSMを用いてそれに署名をする。
24 RP OCSPレスポンダは、RCに応答を返す。
25 RCは、応答における署名を確認するため、およびRPのOCSPレスポンダ証明書チェーンを認可するために、そのHSMを使用する。証明書チェーンは、メッセージとともに渡されてもよく、またはチェーンの一部がHSMにあってもよい。
26 RCは、IPの証明書番号を含むOCSP要求を作成する。このデータは、署名のために、HSMに送信される。
27 RCによって署名された、IPの証明書に対するOCSP要求は、RCの証明書チェーンとともに、信用関係先(RP)
OCSPレスポンダ(OR)に送信される。証明書チェーン全体は、メッセージとともに渡される必要がある。
28 RP OCSPレスポンダは、そのOCSPログに、要求をログする。RP OCSPレスポンダは、要求における署名を確認し、およびRCの証明書チェーンを認可する。すべての確認はソフトウェアで実行される。チェーン全体(ルートを含む)は、署名/証明書チェーンの確認が実行されるようにするために、メッセージとともに渡されなければならない。
RCの証明書が取り消されなかったことを確証するためのチェックは実行されない。
29 RP OCSPレスポンダは、RCから受信された単一の要求を含む、新しい要求を作成し、およびそのHSMを用いてそれに署名をする。金融機関の間で署名された要求は、必要とされない。その代わり、ROOTは、確認/認可/取引先検索が、SSL接続に関連する証明書に基づいている場合である、SSLクライアント側認証を求めてもよい。
30 RP OCSPレスポンダは、受信された要求のサービス・ロケータ要求拡張における値に基づいて、署名されたOCSP要求を、ROOT
OCSPレスポンダに送信する。
31 ROOT OCSPレスポンダは、そのOCSPログに、要求をログする。ROOT OCSPレスポンダは、要求における署名を確認し、およびRP ORの証明書チェーンを認可する。すべての確認は、ソフトウェアで実行される。チェーン全体(ルートを含む)は、署名/証明書チェーンの確認が実行されるようにするために、メッセージとともに渡されなければならない。
32 ROOT OCSPレスポンダは、RP OCSPレスポンダの証明書のステータスを決めるために、そのローカル・データベースを調べ、それから応答を生成し、およびそのHSMを用いて、それに署名する。
33 ROOT OCSPレスポンダはそれから、RP OCSPレスポンダに応答を返す。
34 RP OCSPレスポンダは、そのOCSPログに、応答をログする。RP OCSPレスポンダは、応答における署名を確認し、および
ROOTのOCSPレスポンダ証明書チェーンを認可する。否認防止をサポートするのに十分な情報が、ログにないかもしれないことが注目される。証明書チェーン全体は、メッセージとともに渡されなければならない。
好ましい実施形態において、各OCSPレスポンダ204は、オンライン証明書ステータス・プロトコル(Online Certificate Status Protocol)(OCSP)にしたがって動作する。
OCSPレスポンダに移すのに十分な根拠を有していない。
好ましい実施形態において、各OCSPレスポンダ204は、そのプライベート・キーを、ルート・エンティティ110によって確立された要件に適合するハードウェア・セキュリティ・モジュールに記憶する。
好ましい実施形態において、各OCSPレスポンダ204は、機関によって強くなったプラットフォーム・コンフィギュレーションで動作することができる。機関が強化したプラットフォームは、機関のファイアウォール内の使用に関して承認された、試験をし、およびテストをしたプラットフォームである。
好ましい実施形態において、各OCSPレスポンダ204は、すべての署名された要求および応答、すべての例外またはエラー、およびすべての管理およびコンフィギュレーション動作の詳細なログを維持する。
好ましい実施形態において、各OCSPレスポンダ204は、すべての管理トランザクションに対してエンティティを認証するために、安全ソケット・レイヤ・クライアント認証等、強い認証を使用する。
好ましい実施形態において、各OCSPレスポンダ204は、ルート・エンティティ110によって確立された、最小限のセキュリティ要件に適合する。さらに、OCSPレスポンダを維持する機関は、追加のOCSPレスポンダ・セキュリティ規則を特定してもよい。
好ましい実施形態において、各OCSPレスポンダ204は、反復した方法で、高度に利用可能で、および採用可能になるように構成される。さらに、各OCSPレスポンダは、好ましくは、1秒より少ない時間で、すべての要求に応答する。
OCSPレスポンダは、通常、ユーティリティ証明書のチェックを実行することを求められない。しかしながら、OCSPレスポンダは、リクエスタに、ユーティリティ証明書のステータスへの、認証されていないアクセスを許可するように構成されているかもしれない。
好ましい実施形態において、各OCSPレスポンダは、機関のレポジトリへの認証されたインターフェースとして機能するように求められるかもしれない。この好ましい実施形態の実装の詳細は、OCSPレスポンダを維持するエンティティに委ねられてもよい。
OCSPレスポンダは、好ましくは、システムおよびイベント・ログを外部に出すための、機関によって定義された標準インターフェースを具備してもよい。各OCSPレスポンダはまた、請求アプリケーションのための情報を外部に出すためのインターフェースを具備してもよい。請求データは、ログを含むあらゆる形式で外部に出されも良いが、好ましくは、リクエスタが、要求の種類およびボリュームを決定することができるようにする。
好ましい実施形態において、レベル2関係先も、それらの認証局アーキテクチャのハードウェアおよびソフトウェア・コンフィギュレーションの真実の、および正確な記録を維持する。各レベル2関係先は、以下の三つのロケーションにおいて、そのコンフィギュレーション・ドキュメントの、少なくとも三つのコピーを準備し、保持し、および維持する:(1)レベル2認証局と同じ物理的ロケーションであり、それによって、動作上の変更が生じたときに、それらが記録されるようにする;(2)レベル2認証局の物理的ロケーションの外部にある安全ロケーションであるが、制御されたコンテナである;および(3)レベル2認証局のバックアップおよびアーカイブ記録を伴うオフサイト・ロケーションである。さらに、各レベル2関係先は、好ましくは、そのコンフィギュレーション・ベースラインを、その保証しているレベル1認証局に供給する。
Claims (1)
- 信用関係先の第1のトランザクション・コーディネータとして構成された第1のサーバと、
通信ネットワークを介して前記第1のサーバと通信可能に結合した、発行関係先の第2のトランザクション・コーディネータとして構成された第2のサーバと、を有し、
前記信用関係先の前記第1のトランザクション・コーディネータは、
前記発行関係先の前記第2のトランザクション・コーディネータと通信するための、トランザクション・コーディネータ・リクエスト・マネージャ・コンポーネント及び転送サービス・コンポーネントを含むインターフェース・モジュールであって、前記転送サービス・コンポーネントは、前記転送サービス・コンポーネントからサービス・リクエストを受信し、前記サービス・リクエストを1つ以上の一組のサービス・モジュール又はコア・コンポーネントに転送するために、前記トランザクション・コーディネータ及び前記トランザクション・コーディネータ・リクエスト・マネージャ・コンポーネントに単一の入口点を与えるものであるインターフェース・モジュールと、を有し、
申込取引先と信用取引先の間のトランザクションとして、前記申込取引先及び前記信用取引先の電子証明書を検証するための電子証明書ステータス照合モジュールであって、前記信用取引先の前記電子証明書はルート局からのルート公開鍵を用いて検証され、前記申込取引先の前記電子証明書は前記発行関係先の前記第2のトランザクション・コーディネータへのリクエストを通じて検証され、前記信用取引先は前記信用関係先の取引先であり、前記申込取引先は前記発行関係先の取引先である電子証明書ステータス照合モジュール、前記発行関係先の前記第2のトランザクション・コーディネータに保証リクエストを送信し、前記発行関係先の前記第2のトランザクション・コーディネータから前記リクエストへの署名された応答であって、担保裏書保証が発行されたかどうかを示す応答を受信することによって、前記トランザクションに関係する電子通信に署名する前記申込取引先の身元を保証する前記担保裏書保証を要求するための保証サービス・モジュール、及び前記信用関係先に、前記発行関係先から支払保証を受信することによって前記申込取引先と前記信用取引先の間のトランザクションに関連する前記申込取引先の金融責務の履行能力の確認を提供する支払い保証モジュールを含む、前記インターフェース・モジュールと結合した一組のサービス・モジュールと、を含み、
前記一組のコア・コンポーネントは、否認防止及びセキュリティ検査の目的のために前記サービス・リクエストをロギングするロギング・コンポーネントを含むものであり、
前記信用関係先の前記第1のトランザクション・コーディネータによって受信されたレスポンス及びリクエストに対するトランザクション請求履歴を生成して記憶するための請求コンポーネントと、
電子署名を確認するための暗号化処理を使用するハードウェア・セキュリティ・モジュールとインターフェースするための署名コンポーネントと、
取引処理ライブラリを介して、前記一組のコア・コンポーネントの動作と、一つ以上のトランザクションのための少なくとも一つの前記サービス・モジュールの動作とを組み合わせるための、トランザクション処理モニタと、
を具備するトランザクション処理システムであって、前記一つ以上のトランザクションは、トランザクションを終了するのに必要な全てのアクションが成功するか又は全て失敗すること、すなわちそれぞれのトランザクションは分割できない作業単位であるという原子性、トランザクションの実行後に、前記システムが正しい安定状態となるか又はそうでなければ前記システムが前記トランザクションの開始前の状態に戻るという一貫性、各々のトランザクションが同時に実行されている他のトランザクションによって影響されないという分離性、およびそれぞれのトランザクションの結果は前記トランザクションが実行された後に不変であるという耐久性の属性を有する、前記システム。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15320399P | 1999-09-10 | 1999-09-10 | |
US60/153,203 | 1999-09-10 | ||
US15372499P | 1999-09-13 | 1999-09-13 | |
US15372699P | 1999-09-13 | 1999-09-13 | |
US60/153,726 | 1999-09-13 | ||
US60/153,724 | 1999-09-13 | ||
PCT/US2000/024663 WO2001018721A1 (en) | 1999-09-10 | 2000-09-08 | System and method for providing certificate validation and other services |
Related Child Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011254357A Division JP5670296B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するための方法 |
JP2011254358A Division JP5670297B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するためのシステム |
JP2011254356A Division JP5670295B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するための方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003509746A JP2003509746A (ja) | 2003-03-11 |
JP5275536B2 true JP5275536B2 (ja) | 2013-08-28 |
Family
ID=27387400
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001522463A Expired - Fee Related JP5275536B2 (ja) | 1999-09-10 | 2000-09-08 | 証明書確認及び他のサービスを提供するためのシステム及び方法 |
JP2011254357A Expired - Fee Related JP5670296B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するための方法 |
JP2011254356A Expired - Fee Related JP5670295B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するための方法 |
JP2011254358A Expired - Fee Related JP5670297B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するためのシステム |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011254357A Expired - Fee Related JP5670296B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するための方法 |
JP2011254356A Expired - Fee Related JP5670295B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するための方法 |
JP2011254358A Expired - Fee Related JP5670297B2 (ja) | 1999-09-10 | 2011-11-21 | 証明書確認及び他のサービスを提供するためのシステム |
Country Status (6)
Country | Link |
---|---|
EP (1) | EP1221120A4 (ja) |
JP (4) | JP5275536B2 (ja) |
AU (1) | AU764840B2 (ja) |
CA (1) | CA2384158A1 (ja) |
HK (1) | HK1045001A1 (ja) |
WO (1) | WO2001018721A1 (ja) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7134021B2 (en) * | 1999-10-22 | 2006-11-07 | Hitachi, Ltd. | Method and system for recovering the validity of cryptographically signed digital data |
US20030229811A1 (en) * | 2001-10-31 | 2003-12-11 | Cross Match Technologies, Inc. | Method that provides multi-tiered authorization and identification |
GB2386802A (en) * | 2002-03-18 | 2003-09-24 | Hewlett Packard Co | Auditing of secure communication sessions over a communication network |
US20050039016A1 (en) * | 2003-08-12 | 2005-02-17 | Selim Aissi | Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution |
KR20060123470A (ko) * | 2004-01-09 | 2006-12-01 | 코아스트리트 리미티드 | OCSP 및 분산 OCSP를 위한 서명-효율적인RTC(Real Time Credentials) |
CN100448239C (zh) * | 2006-02-28 | 2008-12-31 | 西安西电捷通无线网络通信有限公司 | 鉴别服务实体的安全接入协议符合性测试的方法及其系统 |
US20080114689A1 (en) * | 2006-11-03 | 2008-05-15 | Kevin Psynik | Patient information management method |
EP2518670A4 (en) * | 2010-09-07 | 2015-02-25 | Zte Corp | SYSTEM AND METHOD FOR REMOTE PAYMENT BASED ON MOBILE TERMINALS |
KR101544722B1 (ko) * | 2014-11-13 | 2015-08-18 | 주식회사 엘지씨엔에스 | 부인 방지 방법, 이를 위한 결제 관리 서버 및 사용자 단말기 |
CN111242705B (zh) * | 2019-12-31 | 2023-12-26 | 航天信息股份有限公司企业服务分公司 | 一种发票数据的获取方法和装置 |
GB2604104A (en) * | 2021-02-18 | 2022-08-31 | Nchain Holdings Ltd | Digital security systems and methods |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5920847A (en) * | 1993-11-01 | 1999-07-06 | Visa International Service Association | Electronic bill pay system |
US5677955A (en) * | 1995-04-07 | 1997-10-14 | Financial Services Technology Consortium | Electronic funds transfer instruments |
US5903882A (en) * | 1996-12-13 | 1999-05-11 | Certco, Llc | Reliance server for electronic transaction system |
US6285991B1 (en) * | 1996-12-13 | 2001-09-04 | Visa International Service Association | Secure interactive electronic account statement delivery system |
JP3919041B2 (ja) * | 1997-02-06 | 2007-05-23 | 富士通株式会社 | 決済システム |
US6085168A (en) * | 1997-02-06 | 2000-07-04 | Fujitsu Limited | Electronic commerce settlement system |
US6125349A (en) * | 1997-10-01 | 2000-09-26 | At&T Corp. | Method and apparatus using digital credentials and other electronic certificates for electronic transactions |
US5913210A (en) * | 1998-03-27 | 1999-06-15 | Call; Charles G. | Methods and apparatus for disseminating product information via the internet |
CA2361053A1 (en) * | 1999-01-29 | 2000-08-03 | Richard Ankney | Reliance manager for electronic transaction system |
AU2878800A (en) * | 1999-02-12 | 2000-08-29 | Allen Freudenstein | System and method for providing certification-related and other services |
-
2000
- 2000-09-08 CA CA002384158A patent/CA2384158A1/en not_active Abandoned
- 2000-09-08 EP EP00961672A patent/EP1221120A4/en not_active Ceased
- 2000-09-08 AU AU73592/00A patent/AU764840B2/en not_active Ceased
- 2000-09-08 JP JP2001522463A patent/JP5275536B2/ja not_active Expired - Fee Related
- 2000-09-08 WO PCT/US2000/024663 patent/WO2001018721A1/en active IP Right Grant
-
2002
- 2002-08-27 HK HK02106302.8A patent/HK1045001A1/zh unknown
-
2011
- 2011-11-21 JP JP2011254357A patent/JP5670296B2/ja not_active Expired - Fee Related
- 2011-11-21 JP JP2011254356A patent/JP5670295B2/ja not_active Expired - Fee Related
- 2011-11-21 JP JP2011254358A patent/JP5670297B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
WO2001018721A8 (en) | 2001-10-11 |
JP5670296B2 (ja) | 2015-02-18 |
WO2001018721A1 (en) | 2001-03-15 |
AU764840B2 (en) | 2003-09-04 |
JP2012038350A (ja) | 2012-02-23 |
JP2012053918A (ja) | 2012-03-15 |
JP2003509746A (ja) | 2003-03-11 |
JP2012059283A (ja) | 2012-03-22 |
AU7359200A (en) | 2001-04-10 |
EP1221120A1 (en) | 2002-07-10 |
HK1045001A1 (zh) | 2002-11-08 |
CA2384158A1 (en) | 2001-03-15 |
JP5670295B2 (ja) | 2015-02-18 |
WO2001018721A9 (en) | 2002-10-03 |
EP1221120A4 (en) | 2009-07-15 |
JP5670297B2 (ja) | 2015-02-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8818903B2 (en) | Transaction coordinator for digital certificate validation and other services | |
JP5670295B2 (ja) | 証明書確認及び他のサービスを提供するための方法 | |
US11025435B2 (en) | System and method for blockchain-based cross-entity authentication | |
US11533164B2 (en) | System and method for blockchain-based cross-entity authentication | |
WO2021000419A1 (en) | System and method for blockchain-based cross-entity authentication | |
EP1540881B1 (en) | System and method for the transmission, storage and retrieval of authenticated documents | |
US7949871B2 (en) | Method for creating virtual service connections to provide a secure network | |
EP3788523A1 (en) | System and method for blockchain-based cross-entity authentication | |
Vogler et al. | Distributed transaction processing as a reliability concept for mobile agents | |
WO2001020513A9 (en) | System and method for providing certificate validation and other services | |
Gritzalis, D. Gritzalis, C. Moulinos, J. Iliadis | An integrated architecture for deploying a virtual private medical network over the Web | |
Torres et al. | An implementation of a trusted and secure DRM architecture | |
WO2000045564A1 (en) | Reliance manager for electronic transaction system | |
Billard | Transactional services for the internet | |
Kantola et al. | Rosetta Net vs. ebXML–Security Solutions and Exception Handling | |
EP1238506A1 (en) | Reliance manager for electronic transaction system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070910 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100408 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100708 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100715 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101008 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101202 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110209 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110217 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110602 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110721 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111121 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120110 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120127 |
|
A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20120202 |
|
A912 | Removal of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20120427 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20121211 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20121218 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20130115 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20130118 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130516 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |