JP2022552420A - 証明書認証用の分散台帳に基づく方法およびシステム - Google Patents

Abstract

分散台帳との間で役割および証明書を追加および除去ための取引、および２つの接続されたサーバの証明書を認証するための取引を公表するための方法およびシステムを開示する。役割は、役割を有するどのサーバが、証明書および役割に関するどのタイプの取引を公表できるかを指定する。役割が要求されたとき、役割および発行者証明書を追加するための２つの取引が分散台帳に公表される。どんな役割も有しないサーバの証明書が要求されたとき、証明書を追加するための取引だけは、分散台帳に公表される。すべての取引は、証明書要求サーバと、証明書発行サーバと、分散台帳を維持している分散台帳ネットワークとの間の動作を通して公表される。２つの接続されたサーバは、それらの相手側の識別の真正性を、分散台帳から受信した、分散台帳技術の証明書不変性および可用性の利益を有する証明書を用いて検証できる。【選択図】図２

Description

本発明は、認証された接続を確立するための方法およびシステムに関し、より詳細には分散台帳技術を採用して、認証された接続を確立する方法およびシステムに関する。

安全なネットワークを保証するために、相互認証は、実際の接続が行われる前に実体が互いに認証するセキュリティ処理である。この相互認証は、ネットワーク環境では、クライアントとサーバの両方がデジタル証明書を提供してクライアントおよびサーバの識別を証明しなければならないことを要求する。相互認証処理のために、クライアントおよびサーバが互いの証明書を交換し、検証し、信頼する場合だけ接続を行うことができる。ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ、トランスポート層セキュリティ）プロトコルおよびその前にあったＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）プロトコルは、そのような証明書の交換および検証に取り組むために開発されてきた。ＳＳＬ／ＴＬＳプロトコルは、Ｘ．５０９規格によりフォーマットが規定される公開鍵証明書であるＸ．５０９証明書の最も一般的なタイプの１つを採用する。Ｘ．５０９証明書はウェブサイト、個人、または組織などの識別と暗号鍵対を安全に関連づける。

しかしながら、Ｘ．５０９証明書は証明書不変性、証明書可用性、および証明書履歴に関する限り、決して完全ではない。証明書不変性に対する影響は、ハッカーの攻撃がＸ．５０９証明書に不正な変更を加えることにある。ルート証明書、または認証局（ｃｅｒｔｉｆｉｃａｔｅ ａｕｔｈｏｒｉｔｙ、ＣＡ）のいずれかが危険にさらされると、システムセキュリティは、危険にさらされる。証明書可用性の他の欠点は、あらゆるサーバが自身の証明書データベースを維持しなければならないことであり、その結果、証明書データベースの間に不整合が発生する。証明書履歴のマイナス面に関しては、追加および取消しを含むすべての記録は、前述の２つの問題のためにＸ．５０９証明書のデータベースに存在するわけではない。

本発明の目的は、発行者資格および発行者証明書を公表するため、分散台帳にサーバ証明書を公表するため、および証明書認証のための方法およびシステムを提供することであり、これにより、分散台帳ネットワークにより維持された分散台帳でサーバの証明書を追加および除去して、分散台帳で証明書を検証することになったときに証明書不変性および証明書可用性を改善する。

前述の目的を達成するために、互いに通信状態にある証明書発行ノード（ｃｅｒｔｉｆｉｃａｔｅ－ｉｓｓｕｉｎｇ ｎｏｄｅ、ＣＩ）および証明書要求サーバ（ｃｅｒｔｉｆｉｃａｔｅ－ｒｅｑｕｅｓｔｉｎｇ ｓｅｒｖｅｒ、ＣＲ）を通して、ＣＩを含む分散台帳ネットワークにより維持された分散台帳に発行者資格および発行者証明書を公表するための方法は、（ａ）ＣＩは、ＣＲから資格関連情報を受信するステップと、（ｂ）ＣＩは、発行者資格取引に署名して、分散台帳に発行者資格取引を提出するステップと、（ｃ）ＣＲおよびＣＩの一方は、ＣＲに関する発行者証明書を作成し、発行者証明書に署名し、発行者証明書の署名者がＣＲではないときにＣＲに発行者証明書を送信するステップと、（ｄ）分散台帳で発行者資格取引が作成された後、発行者証明書を有するＣＲおよびＣＩの任意の一方は、発行者証明書取引に署名して、分散台帳に発行者証明書取引を提出するステップと、を含む。

前述の目的を達成するために、互いに通信状態にある証明書発行サーバ（ＣＩ）および証明書要求サーバ（ＣＲ）を通して、ＣＩを含む分散台帳ネットワークにより維持された分散台帳にサーバ証明書を公表するための方法は、（ａ）ＣＩは、ＣＲから証明書関連情報を受信するステップと、（ｂ）ＣＩは、ＣＲに関するサーバ証明書を作成し、サーバ証明書に署名し、ＣＲにサーバ証明書を送信するステップと、（ｃ）ＣＩは、サーバ証明書取引に署名して、分散台帳にサーバ証明書取引を提出するステップと、 を含む。

前述の目的を達成するために、分散台帳を維持している分散台帳ネットワークに互いに通信可能に接続された接続サーバ（ｃｏｎｎｅｃｔｉｎｇ ｓｅｒｖｅｒ、ＣＳ）および受信サーバ（ｒｅｃｅｉｖｉｎｇ ｓｅｒｖｅｒ、ＲＳ）の証明書を認証するための方法は、（ａ）ＲＳは、ＣＳと識別を交換するステップと、（ｂ）ＲＳは、ＣＳ識別に基づき分散台帳からＣＳの証明書およびＣＳ証明書発行者の公開鍵を取り出すステップと、（ｃ）ＲＳは、ＣＳ証明書発行者の公開鍵を用いてＣＳの証明書が真正であるかどうかを検証するステップと、（ｄ）ＣＳの証明書が真正であることが検証された後、ＲＳは、ＣＳがＲＳから秘密情報を受信するように認証されていると判断するステップと、を含む。

前述の目的を達成するために、発行者資格および発行者証明書を公表するための分散台帳に基づくシステムは、証明書要求サーバ（ＣＲ）および分散台帳ネットワークを含む。

分散台帳を維持している分散台帳ネットワークは、ＣＲに通信可能に接続され、証明書発行ノード（ＣＩ）を含む。ＣＩは、ＣＲから資格関連情報を受信し、発行者資格取引に署名し、分散台帳に発行者資格取引を提出する。ＣＲおよびＣＩの一方は、ＣＲに関する発行者証明書をさらに作成し、発行者証明書の署名者がＣＲではないときにＣＲに発行者証明書を送信する。分散台帳で発行者資格取引が作成された後、発行者証明書を有するＣＲおよびＣＩの一方は、発行者証明書取引に署名し、分散台帳に発行者証明書取引を提出する。

前述の目的を達成するために、分散台帳にサーバ証明書を公表するための分散台帳に基づくシステムは、証明書要求サーバ（ＣＲ）および分散台帳ネットワークを含む。

分散台帳ネットワークは、分散台帳を維持し、ＣＲに通信可能に接続され、証明書発行サーバ（ＣＩ）を含む。ＣＩは、ＣＲから証明書関連情報を受信し、ＣＲに関するサーバ証明書を作成し、サーバ証明書に署名し、ＣＲにサーバ証明書を送信し、サーバ証明書取引に署名して分散台帳にサーバ証明書取引を提出する。

前述の目的を達成するために、証明書認証用の分散台帳に基づくシステムは、分散台帳ネットワーク、接続サーバ（ＣＳ）、および受信サーバ（ＲＳ）を含む。

分散台帳ネットワークは、分散台帳を維持する。

ＣＳは、分散台帳ネットワークに通信可能に接続される。

ＲＳは、分散台帳ネットワークに通信可能に接続され、ＣＳと識別を交換し、ＣＳ識別に基づき分散台帳からＣＳの証明書およびＣＳ証明書発行者の公開鍵を取り出してＣＳの証明書が真正であるかどうかを検証し、ＣＳの証明書が真正であることを検証したとき、ＣＳがＲＳから秘密情報を受信するように認証されていると判断する。

前記によれば、役割を有する、または役割をまったく有しないすべてのサーバは、分散台帳との間で権限を与えられたサーバにより追加または除去される、サーバ自体の証明書を有する。分散台帳での役割は、役割を有するどのサーバがどのタイプの役割および証明書を追加する権限を与えられているかを規制する権限を指定し、その結果、権限のない実体が証明書、および分散台帳での役割を破壊するのを防止する。
分散台帳は本来、分散させられる。これにより、悪意のある活動によって標的にする、集中化した実体がまったく存在しないので、セキュリティの層が追加される。複製された形態で分散台帳を大域に広げることが可能であるので、単一の点故障を回避できる。その結果、分散台帳に公表された役割および証明書はまた、分散台帳の不変性により利益を得ることが可能である。分散台帳での証明書および役割は、合意機構に基づき絶えずかつ迅速に更新できるので、分散台帳での証明書および役割に関する不整合は、問題にならないように思われる。その結果、本発明の方法およびシステムにより分散台帳に追加された証明書は、サーバが証明書認証のために信頼を互いに確認することを要求することを提供でき、これは、サーバ間の安全な通信できわめて重要である。
さらに、透明性もまた、分散台帳技術の利点と考えることが可能である。分散台帳は、記憶された情報すべてに容易にかつ自由にアクセスできるようにし、これにより、サーバに接続したときに証明書認証に非常に大きな所望の透明性を追加できる。

本発明の他の目的、利点、および新規な特徴は、添付の図面と併せて解釈されたときに以下の詳細な説明からより明らかになるであろう。

本発明による、サーバの役割とサーバにより作成された証明書の間の関係を示す構成図である。 本発明による、分散台帳に発行者資格および発行者証明書を公表する方法を示す流れ図である。 証明書要求サーバ（ＣＲ）が受託者（ｔｒｕｓｔｅｅ）の役割を要求し、かつ証明書発行サーバ（ＣＩ）が受託者定足数（ｑｕｏｒｕｍ）の役割を担うときの、図２の方法を示すシーケンス図である。 ＣＲが運用者の役割を要求し、かつＣＩが受託者の役割を担うときの、図２の方法の実施形態を示すシーケンス図である。 ＣＲが運用者の役割を要求し、かつＣＩが受託者の役割を担うときの、図２の方法の別の実施形態を示すシーケンス図である。 図２の方法の、発行者証明書を作成するためのステップを示す流れ図である。 本発明による、分散台帳にサーバ証明書を公表するための方法を示すシーケンスである。 本発明による、接続サーバ（ＣＳ）および受信サーバの証明書を認証するための方法の実施形態を示すシーケンス図である。 図８の方法の別の実施形態を示すシーケンス図である。 本発明による、発行者資格および発行者証明書を公表するための分散台帳に基づくシステムの実施形態を示すネットワークアーキテクチャ図である。 図９のシステム用の分散台帳に基づくシステムおよびサーバ証明書を公表するための分散台帳に基づくシステムの別の実施形態を示すネットワークアーキテクチャ図である。 証明書認証用の分散台帳に基づくネットワークを示すネットワークアーキテクチャ図である。

以下で提示する記述で使用する専門用語は、技術のある種の特有の実施形態についての詳細な記述に関連して使用されるとしても、その用語の最も広い合理的な手法で解釈されることが意図される。ある種の用語は、以下で強調される場合さえあるが、しかしながら、任意の制限された手法で解釈されることを意図されるどんな専門用語も、この「発明を実施するための形態」の節でそのようなものとして具体的に規定される。

以下で紹介する実施形態は、ソフトウェアおよび／もしくはファームウェアによりプログラムされ、または構成されたプログラム可能回路により、または完全に専用回路により、またはそのような形態の組合せで実装できる。そのような専用回路は（もしあれば）、たとえば１つまたは複数の特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）、プログラム可能論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、フィールド・プログラマブル・ゲート・アレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）などの形態をとることができる。

本発明での各サーバは、分散台帳ネットワークにより維持された分散台帳に記憶された自身の識別として証明書を所有する。第１のサーバに関する証明書は、証明書の真正性を検証するために、自身に関連する第２のサーバに提出される。証明書が検証された後、第２のサーバは、第１のサーバを信頼し、第１のサーバに秘密情報を自発的に送信する。同様に、そのようなシナリオは、第２のサーバが検証のために第１のサーバに自身の証明書を提供するときに逆に適用できる。
分散台帳との間で証明書を追加または除去するために、発行者の資格を有するサーバだけがそうすることができるようになる。そのためには、発行者の資格はまた、分散台帳との間で追加または除去されて、どのサーバがどの種類の発行者の資格および証明書を追加および除去できるかを常に把握すべきである。サーバの発行者の資格のタイプ、および他のサーバの発行者の資格および証明書を追加および除去する、または取り消す、対応する取引を指定する分散台帳規則が存在する。

簡潔に述べると、記述する実施形態は、分散台帳で発行者の資格および証明書を公表するための、証明書認証用の１つまたは複数の方法およびシステムに関する。任意の２つのサーバが接続するときに証明書認証を確実にするために、サーバの識別および交換されたサーバ証明書に基づき分散台帳から取り出された証明書は、取り出された証明書が利用可能であるかどうか、または取り出された証明書が、認証された情報転送をサーバ間で開始する基礎として採用できる交換された証明書と調和するかどうかを確かめるために検証できる。
分散台帳に基づく解決策は、証明書の信頼および不変性で改善が予見されるので採用される。解決手段は、分散台帳で多数の発行者の資格および証明書を中に記憶する証明書ストアにある。その名前が反映するように、発行者の資格は、分散台帳との間で他のサーバの発行者の資格および証明書を追加および除去できる発行権限を有するサーバにより所有される。発行者の資格または発行者の役割を有するサーバはまた、分散台帳に自身の証明書を有することができ、一方、どの発行者の資格も有しないサーバは、分散台帳に自身の証明書だけを有することが可能である。
発行者の役割を有するサーバを追加するために、サーバの証明書を追加する取引およびサーバの発行者の役割を追加する取引は、分散台帳と、分散台帳ネットワークの多数のサーバの中の２つである証明書要求サーバ（ＣＲ）および証明書発行ノード（ＣＩ）との間の対話を通して分散台帳に公表される。どんな発行者の役割も有しないサーバを追加するために、サーバの証明書を追加する取引は、分散台帳に公表される。取引を公表する他に、ここでの動作はまた、取引に署名し取引を検証するための台帳鍵対の使用、および証明書に署名し証明書を検証するための証明書鍵対の使用を伴う。発行者の役割または証明書が分散台帳から除去され、または取り消されたとき、発行者の役割を除去する、または証明書を取り消す取引は、分散台帳に公表される。方法およびシステムに関する詳細について、以下でさらに詳しく述べる。

本発明の目標は、発行者だけが証明書に署名し、証明書を公表できることを重要視する。目標を達成するために、受託者および運用者である２つのタイプの発行者の役割、ならびにルート証明書、管理者証明書、およびサーバ証明書である３つのタイプの証明書について述べる。すべての証明書は、分散台帳に公表されなければならないが、認可された分散台帳ネットワークでは、あらゆるサーバではなく発行者の役割を有するサーバは、他のサーバに関する証明書および発行者の役割を公表できる。受託者および運用者という発行者の役割はそれぞれ、信頼の起源、ならびにサイトですべてのサーバを運用して証明書および発行者の役割を公表する権限を与えられている各サイトの管理者を表す。簡潔にするために、用語「役割」は、本明細書で以後「発行者の役割」に取って代わる。
受託者の役割を有するサーバ、運用者の役割を有するサーバ、および役割なしのサーバはそれぞれルート証明書、管理者証明書、およびサーバ証明書を所有する。名前の違いにもかかわらず、３つのタイプの証明書は、検証のために証明書の公開鍵を使用する方法以外は、証明書の共通のデータフィールドに関する限り基本的に同じである。ルート証明書および管理者証明書は、公開鍵を使用して発行者の証明書の発行者により署名された証明書を検証できる発行者の証明書に関係し、一方、サーバ証明書を有するサーバがどんな証明書も発行する権限を与えられておらず、かつサーバ証明書を用いてサーバにより署名された証明書が存在しないというだけの理由で、サーバ証明書での公開鍵を使用して他の証明書を検証できない。

あらゆる証明書とその署名者の証明書の間の署名関係を考慮すると、その関係を言い換える簡略化された方法は、発行者の証明書は、証明書に署名し、発行者により署名された証明書を検証するということである。検証用に任意の証明書を与えられると、証明書に署名している発行者の証明書を分散台帳から再帰的に識別して証明書を検証でき、そのような検証処理は、ルート証明書である最上位の証明書まで遡ることが可能である。
証明書タイプ、および発行者の役割を有する実体の例を示す図１を参照する。左側のブロックは、分散台帳ネットワークで発行者の役割を有するサーバを示し、右側のブロックは、権限を与えられたサーバにより分散台帳に公表される３つのタイプの証明書を示す。図１に示すように、運用者の役割を有するサーバは、発行者の役割をまったく有することなく自身の管理者証明書および他のサーバのサーバ証明書を分散台帳に追加する取引を公表する資格を与えられ、受託者の役割を有するサーバは、分散台帳に自身のルート証明書を追加する取引を公表する資格を与えられる。
図１の右側には、分散台帳での３つのタイプの証明書を示す。各管理者証明書を使用して、管理者証明書により署名されたサーバ証明書を検証でき、ルート証明書を使用して、ルート証明書を公表しているサーバにより署名された管理者証明書を検証できる。証明書の検証処理は、サーバ証明書または管理者証明書が配置されたどこからでも開始してよく、利用可能である場合には、サーバ証明書または管理者証明書とルート証明書の間にある、順次検証される他の中間的な管理者証明書を伴うルート証明書で終了してよい。その間、検証処理は、ルート証明書まで進む必要はなく、条件が満たされた、または満たされないときに終了できる。条件は、事前に承認されたリストの中に検証中の証明書があるか、または検証が開始した証明書で検証が終了するかどうかを含むがそれに限定されない。それにもかかわらず、受託者および運用者の役割を有するサーバの数、ルート証明書、管理者証明書、およびサーバ証明書の数、ならびに証明書の階層構造は、図１に示すものに限定されない。

どの役割がどのタイプの取引を分散台帳に公表できるかに関する分散台帳規則を示す以下の表は、役割と証明書の間の関係をより深く掘り下げている。

表によれば、受託者の役割を有するサーバは、運用者の役割、ルート証明書、および他のサーバに関連する管理者証明書を追加および削除する取引を分散台帳に公表する資格を有する。受託者の役割を有するサーバは、別のサーバのサーバ証明書を追加または取り消す資格がないことに留意する。受託者の役割を有するサーバは、分散台帳で受託者の役割を有する唯一のサーバではない限り、単体で他のサーバの受託者の役割を追加および除去する取引を公表する資格がない。その代わり、受託者の役割を有する、分散台帳で少なくとも１つのサーバの圧倒的多数のための集合的役割となるように規定された、受託者定足数の役割を有するサーバは、受託者の役割を有するサーバを追加および除去する取引を公表する資格がある。
受託者の役割とは対照的に、運用者の役割を有するサーバは、運用者の役割、管理者証明書、および他のサーバのサーバ証明書を追加および除去、または取り消す取引を分散台帳に公表する資格がある。受託者の役割を有するサーバおよび運用者の役割を有するサーバは、いずれも運用者の役割およびサーバの管理者証明書を追加、除去、および取り消す取引を公表できることに留意する。役割をなにも有しないサーバについては、サーバは、どんな取引も公表する資格がない。

発行者の役割および証明書を包含する分散台帳での証明書ストアは、互いに関連する２つのサーバの証明書認証にとって基本であるので、役割および証明書を追加および除去するための取引を公開する方法は、最初に導入される。証明書ストアは、最初に構築されたとき、自身に公表された開始取引から開始して、受託者の役割を有する一番初めのサーバを作成する。開始取引は、受託者の分散型識別子（ｄｅｃｅｎｔｒａｌｉｚｅｄ ｉｄｅｎｔｉｆｉｅｒ、ＤＩＤ）、受託者により公表される任意の取引の分散台帳署名を検証するための公開鍵、および受託者の役割を含む。

図２を参照する。本発明による、分散台帳に発行者資格および発行者証明書を公表する方法の実施形態が提供される。本実施形態での方法は、いずれも分散台帳ネットワークの一部である証明書要求サーバ（ＣＲ）および証明書発行ノード（ＣＩ）を伴う。ＣＩは、１つまたは複数のサーバを含んでよい。方法は、ＣＩが分散台帳で受託者定足数および受託者の役割を有するノードであるときに適用され、ＣＲは、ＣＩにより分散台帳に受託者または運用者の役割で追加されるように要求する。この方法では、役割およびサーバ証明書を有しないサーバは、方法の議論から除外される。分散に公表される取引は、役割および証明書を追加または除去することを意図することがあるので、役割および証明書を追加するためのステップＳ２１０～Ｓ２４０から以下のステップを含む。

ステップＳ２００：ＣＩは、公表される取引のタイプを決定する。取引のタイプは、役割および証明書を追加すること、役割を除去すること、証明書を取り消すことを含む。

ステップＳ２１０：役割および証明書を追加するという取引タイプを決定したとき、ＣＩは、ＣＲから資格関連情報を受信する。資格関連情報は、分散台帳に順次に追加される取引でＣＲの発行者資格または役割を追加するために必要とされ、ＣＲのＤＩＤ、台帳公開鍵、および役割を含む。基本的に、証明書ストアで役割を有する各サーバは、いずれも非対称鍵対に関係する台帳鍵対および証明書鍵対を有する。台帳対は、台帳公開鍵および台帳秘密鍵を有し、証明書対は、証明書公開鍵および証明書秘密鍵を有する。
サーバに関連する台帳秘密鍵は、サーバで記憶され、証明書ストアに公表される任意の取引に署名するサーバにより使用される。サーバに関連する台帳公開鍵は、ＣＲを追加するための現在のステップで言及する取引など、サーバを追加するための取引のために分散台帳に送信される。その結果、分散台帳は、サーバの台帳公開鍵を用いてサーバにより署名されるその後の任意の取引を検証できる。一方では、サーバによりサーバの証明書秘密鍵を使用して、管理者証明書およびサーバ証明書の一方であってよい別のサーバの証明書に署名する。サーバの証明書公開鍵は、サーバにより署名された他のサーバの証明書を検証するためにサーバの証明書に含まれる。

ステップＳ２２０：ＣＩは、発行者資格取引に署名して、分散台帳に発行者資格取引を提出する。発行者資格取引は、分散台帳にＣＲを搭載するのに役立ち、ＣＲのＤＩＤおよび台帳公開鍵、ＣＩのＤＩＤ、ならびに分散台帳に追加されるＣＲの役割を含み、ＣＩの台帳秘密鍵により署名される。分散台帳規則からなる前述の表から、ＣＲは、受託者または運用者の役割で追加されるように要求してよく、一方、ＣＩは、受託者定足数または受託者の役割を担ってよい。ＣＲが受託者の役割を要求するとき、ＣＩは、受託者定足数の役割を担うべきであり、少なくとも１つのサーバを含む。ＣＲが運用者の役割を要求するとき、ＣＩは、受託者または運用者の役割を担ってよく、個々のサーバである。

ステップＳ２３０：ＣＲおよびＣＩの一方は、ＣＲに関する発行者証明書を作成し、発行者証明書に署名し、発行者証明書の署名者がＣＲではないときにＣＲに発行者証明書を送信する。ＣＲが受託者の役割を要求するとき、発行者証明書を作成し、発行者証明書に署名するのはＣＲであり、発行者証明書は、ルート証明書である。ＣＲが運用者の役割を要求するとき、発行者証明書を作成し、発行者証明書に署名するのはＣＩであり、発行者証明書は、管理者証明書である。
発行者証明書は、ＣＲにより要求される役割に応じて、発行者証明書を作成するＣＲおよびＣＩの一方の証明書秘密鍵により署名される。発行者証明書の作成者がＣＩである場合、ＣＩは、発行者証明書を記憶して後で検証するために、ＣＲに発行者証明書を送信しなければならない。

ステップＳ２４０：分散台帳で発行者資格取引が作成された後、発行者証明書を有するＣＲおよびＣＩの任意の一方は、発行者証明書取引に署名して、分散台帳に発行者証明書取引を提出する。発行者資格取引は、分散台帳で作成された後に初めて署名され、分散台帳に提出されるべきである。ＣＲは、受託者の役割を要求するとき、自分自身のルート証明書を作成し、ルート証明書を有する唯一のＣＲであり、その結果、図３に示すように、発行者証明書取引に署名し、分散台帳に発行者証明書取引を提出するのはＣＲである。ＣＲが運用者の役割を要求するとき、ＣＩは、ＣＲに関する管理者証明書を作成し、管理者証明書に署名し、ＣＲに管理者証明書をさらに送信するので、ＣＩもＣＲも管理者証明書を有し、したがって、ＣＩおよびＣＲのいずれか一方は、図４および図５に示すように、発行者証明書取引に署名して分散台帳に発行者証明書取引を提出できる。
発行者証明書取引については、発行者証明書取引は、提出者のＤＩＤ、証明書ＩＤ、発行者証明書、および提出者の署名を含む。提出者は、発行者証明書を有するＣＲおよびＣＩの任意の一方であってよい。証明書ＩＤは、発行者証明書のハッシュ値である。発行者証明書は、ＣＲの識別および証明書公開鍵、ＣＲの任意選択の役割、および発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含む。ＣＲの識別は、ウェブアドレス、たとえばｗｗｗ．ｔｂｃａｓｏｆｔ．ｃｏｍであってよいサブジェクト代替名（ｓｕｂｊｅｃｔ ａｌｔｅｒｎａｔｉｖｅ ｎａｍｅ、ＳＡＮ）である。ＣＲの役割は、発行者証明書を所有するサーバに関連する発行者証明書の役割を検証および利用することを必要とするアプリケーションに提供されてよいので、任意選択である。発行者証明書取引を公表する前に、発行者証明書取引の提出者は、自身の台帳秘密鍵を用いて発行者証明書取引に署名する。

証明書要求サーバの役割に応じて、ステップＳ２３０は、ＣＲの役割によって変わる異なるステップを含んでよい。ＣＲの役割が受託者であるとき、図３は、ＣＲが受託者の役割を要求するためのシーケンス図を示し、図４および図５は、ＣＲが運用者の役割を要求するためのシーケンス図を示す。図６を参照する。ＣＲが要求する役割に適合させるために、ステップＳ２３０は、以下のステップを含む。

ステップＳ２３１：ＣＲにより要求された役割が受託者であるとき、ＣＲは、ルート証明書を作成する。受託者の役割を有するサーバだけがルート証明書を追加できることを指定する分散台帳規則により、ルート証明書を作成するのはＣＲである。

ＣＲの役割が運用者であるとき、ステップＳ２３０は、以下のステップを含む。

ステップＳ２３２：ＣＲにより要求された役割が運用者であるとき、ＣＲは、管理者証明書署名リクエスト（ｃｅｒｔｉｆｉｃａｔｅ ｓｉｇｎｉｎｇ ｒｅｑｕｅｓｔ、ＣＳＲ）をＣＩに送信する。管理者ＣＳＲは、運用者情報、およびＣＲの証明書公開鍵を含む。運用者情報は、ＣＲのＳＡＮ、商号、部署名、市、州、国、および連絡先電子メールからなるフィールドを含む。

ステップＳ２３３：ＣＩは、管理者ＣＳＲを用いて管理者証明書を作成し、ＣＩの証明書公開鍵を用いて管理者証明書に署名し、管理者証明書を作成し、ＣＲに管理者証明書を送信する。受託者および運用者の役割を有するサーバが管理者証明書を追加できることを指定する分散台帳規則のために、管理者証明書を作成するのはＣＩである。

図４と図５の違いは、発行者証明書取引を公表するサーバである。発行者証明取引を公表するための役割をサーバが有する限り、ＣＲまたはＣＩが発行者証明書取引を公表するかどうかは問題とすべきではない。公表される役割は運用者であるので、図４で受託者または運用者の役割を有するＣＩおよび図５で運用者の役割を有するＣＲのいずれか一方は、発行者証明書取引を公表できる。

証明書ストアで任意のサーバを除去、または任意の証明書を取り消すことを意図するとき、サーバを除去するための取引、または証明書を取り消すための取引は、分散台帳に公表できる。それに応じて、前述の方法は、分散台帳で役割を有するサーバを除去するため、および証明書を取り消すための以下のステップをさらに含む。図２を参照する。前述の方法は、役割および証明書を除去、および取り消すための以下のステップをさらに含む。

ステップＳ２５０：役割を除去、および受託者の役割を有するサーバを除去するタイプを決定するとき、受託者の役割を有する少なくとも１つのサーバの圧倒的多数は、受託者除去取引を生成してサーバを除去し、受託者除去取引に署名し、分散台帳に受託者除去取引を提出する。現在のステップは、受託者の役割を有するサーバを除去するための動作を伴う。受託者除去取引は、サーバのＤＩＤ、および少なくとも１つのサーバの圧倒的多数に対応する少なくとも１つのＤＩＤを含み、少なくとも１つのサーバの圧倒的多数の少なくとも１つの台帳秘密鍵により署名される。

ステップＳ２６０：役割を除去し、運用者の役割を有する第１のサーバを除去するタイプを決定するとき、受託者または運用者の役割を有し、分散台帳に第１のサーバを追加する第２のサーバは、運用者除去取引を生成して分散台帳から第１のサーバを除去し、運用者除去取引に署名し、分散台帳に運用者除去取引を提出する。現在のステップは、運用者の役割を有するサーバを除去するための動作を伴う。運用者除去取引は、第２のサーバのＤＩＤおよび第１のサーバのＤＩＤを含み、第２のサーバの台帳秘密鍵により署名される。

ステップＳ２７０：分散台帳で証明書を取り消し、受託者または運用者の役割を有する第１のサーバの発行者証明書を取り消すタイプを決定するとき、受託者または運用者の役割を有し、発行者証明書を追加する第２のサーバは、証明書取消取引を生成して分散台帳で発行者証明書を取り消し、証明書取消取引に署名し、分散台帳に証明書取消取引を提出する。
第１のサーバが受託者の役割を担うとき、第２のサーバは、同様に受託者の役割を担うべきであり、第１のサーバが運用者の役割を担うとき、第２のサーバは、受託者または運用者の役割を担ってよいことに留意する。現在のステップは、第１のサーバが受託者の役割を担い、かつ第２のサーバが受託者の役割を担うときに発行者証明書、多くの場合、ルート証明書、または第１のサーバが運用者の役割を担い、かつ第２の役割が受託者または運用者の役割の一方を担うときに管理者証明書を除去するための動作を伴う。運用者取消取引は、発行者証明書の証明書ＩＤおよび第２のサーバのＤＩＤを含み、第２のサーバの台帳秘密鍵により署名される。

分散台帳にサーバ証明書を追加するための取引が１つだけ存在するので、分散台帳にサーバ証明書を公表するための方法は、発行者資格取引がない状態で発行者の資格および証明書を公表するための前述の方法と異なる。
シーケンス図である図７は、本発明による、分散台帳にサーバ証明書を公開するための方法が以下のステップを含むことを示す。分散台帳は、分散台帳ネットワークにより維持される。分散台帳ネットワークは、多数のサーバを含み、多数のサーバのうち２つは、証明書発行ノード（ＣＩ）および証明書要求サーバ（ＣＲ）である。

ステップＳ６１０：ＣＩは、ＣＲから証明書関連情報を受信する。サーバ証明書だけが作成される必要があるので、証明書関連情報は、ＣＩがＣＲから必要とするすべてである。証明書関連情報は、サーバ情報および認証公開鍵を含む。サーバ情報は、ＣＲのインターネット・プロトコル（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ、ＩＰ）・アドレスおよびホスト名を含む。

ステップＳ６２０：ＣＩは、ＣＲに関するサーバ証明書を作成し、サーバ証明書に署名し、ＣＲにサーバ証明書を送信する。サーバ証明書は、ＣＲのＳＡＮおよび認証公開鍵を含み、ＣＩの秘密鍵により署名される。

ステップＳ６３０：ＣＩは、サーバ証明書取引に署名して、分散台帳にサーバ証明書取引を提出する。サーバ証明書取引は、サーバ証明書の証明書ＩＤ、サーバ証明書、およびＣＩのＤＩＤを含み、ＣＩの台帳秘密鍵により署名される。証明書ＩＳは、サーバ証明書のハッシュ値である。

分散台帳に追加されたサーバ証明書を取り消すために、分散台帳にサーバ証明書を公表するための方法は、以下のステップをさらに含む。

運用者の役割を有し、サーバ証明書を追加するサーバは、証明書取消取引を生成して分散台帳でサーバ証明書を取り消し、証明書取消取引に署名し、分散台帳に証明書取消取引を提出する。証明書取消取引は、サーバ証明書の証明書ＩＤ、およびサーバ証明書を追加するサーバのＤＩＤを含み、発行者証明書を追加するサーバの台帳秘密鍵により署名される。

分散台帳に役割および証明書を追加および除去する方法を実装後、関心のある次の主題は、互いに関連するサーバに関する証明書を使用して互いのサーバ証明書の真正性を検証して、相互認証された情報交換を確立する方法である。図８を参照する。本発明による、分散台帳を維持している分散台帳ネットワークで接続サーバ（ＣＳ）および受信サーバ（ＲＳ）の証明書を認証するための方法は、ＲＳの側から以下のステップを含む。

ステップＳ７１０：ＲＳおよびＣＳは、自身の識別を交換する。ＲＳの識別は、ＲＳのＳＡＮであり、ＣＳの識別は、ＣＳのＳＡＮである。ＲＳおよびＣＳは、互いに自身のＳＡＮを交換する。識別に加えて、一実施形態では、ＲＳおよびＣＳは、図９に示すように自身の証明書をさらに交換できる。

ステップＳ７２０：ＲＳは、ＣＳ識別に基づき分散台帳からＣＳの証明書およびＣＳ証明書発行者の公開鍵を取り出す。ＣＳ識別を使用して、分散台帳からＣＳの証明書、およびＣＳ証明書発行者の公開鍵を有するＣＳ証明書発行者の証明書を取り出すことが可能である。ＣＳ証明書発行者の公開鍵は、ＣＳ証明書発行者の証明書を有する、ＣＳ証明書発行者により署名されたＣＳの証明書を検証するのに役立つ。ＲＳの識別を用いて分散台帳から証明書をまったく取り出すことができない場合、分散台帳は、ＲＳの証明書が、時間のかからない簡単な方法で真正ではないことを信号で伝えることが可能である。

ステップＳ７３０：ＲＳは、ＣＳ証明書発行者の公開鍵を用いてＣＳの証明書が真正であるかどうかを検証する。ＣＳの証明書、およびＣＳ証明書発行者の公開鍵は、ＲＳに利用可能になると、ＣＳの証明書が真正であることを直接に検証するために使用できる。選択肢として他の検証取り組み方法が利用できる。交換された証明書を使用する一検証取り組み方法では、ＲＳは、交換されたＣＳの証明書と取り出されたＣＳの証明書の両方がＣＳ証明書発行者の公開鍵と調和するかどうかをさらに検証する。別の検証取り組み方法では、ＲＳは、ＣＳの証明書を現在の証明書として初期化し、ループして、次の証明書の証明書発行者の秘密鍵を用いて現在の証明書に署名する次の証明書を取り出して、次の証明書での公開鍵を用いて現在の証明書を検証して、現在の証明書が妥当であるか、または検証条件が満たされたときにＣＳの証明書が真正であると検証されたと判断し、そうではない場合、現在の証明書を次の証明書に更新する。たとえば、検証条件は、検証される証明書が事前に承認されたリストにあるかどうかであってよい。

ＣＳの証明書が真正であると検証された後、そのことは、ＲＳの側での片側だけの証明書認証がうまく検証され、ＣＳが、情報交換するのに信頼できるサーバであり、ＲＳがＣＳとの間で秘密情報を自発的に送受信することを意味する。

方法は、以下のようにＲＳの証明書を認証するための類似ステップをさらに含む。

ステップＳ７４０：ＣＳは、ＲＳ識別に基づき分散台帳からＲＳの証明書およびＲＳ証明書発行者の公開鍵を取り出す。

ステップＳ７５０：ＣＳは、ＲＳ証明書発行者の公開鍵を用いてＲＳの証明書が真正であるかどうかを検証する。

同様に、ＲＳの証明書が真正であると検証された後、そのことは、ＣＳの側での片側だけの証明書認証がうまく検証され、ＲＳが、情報を交換するのに信頼できるサーバであり、ＣＳがＲＳとの間で秘密情報を自発的に送受信することを意味する。

ＲＳの証明書の認証とＣＳの証明書の認証との間には重複があるため、ステップＳ７４０およびＳ７５０に関する詳細な説明を繰り返さない。

前述の方法について詳しく述べたので、前述の方法を遂行するためのシステムが、次に論じる主題である。分散台帳に発行者資格および発行者証明書を公表するための方法、分散台帳にサーバ証明書を公表するための方法、および分散台帳ネットワークで２つのサーバの証明書を認証するための方法という３つの方法が存在するので、３つのシステムは、それぞれの方法に対応、すなわち分散台帳に発行者資格および発行者証明書を公表するための分散台帳に基づくシステム、分散台帳にサーバ証明書を公表するための分散台帳に基づくシステム、および証明書認証用の分散台帳に基づくシステムとすることが可能である。

発行者資格および発行者証明書を公表するための分散台帳に基づくシステムに関与するのは、ＣＲ、ＣＩ、および分散台帳ネットワークである。ＣＲおよびＣＩは、それぞれサーバおよびノードである。ノードであるので、ＣＩは、受託者定足数の役割を有するときには少なくとも１つのサーバを含んでよく、受託者または運用者の役割を有するときには１つのサーバに過ぎなくてよい。ＣＲおよびＣＩは、両方とも分散台帳に取引を公表する必要があるかどうかに応じて分散台帳ネットワークの一部であっても、そうではなくてもよい。ＣＲ１０が受託者の役割を要求し、かつＣＩ２０が受託者定足数の役割を担うとき、ＣＲ１０およびＣＩ２０はすべて、ＣＲ１０もＣＩ２０もルート証明書、および受託者の役割を有するＣＲ１０を分散台帳に追加するための取引を公表するので、図１０に示すように分散台帳ネットワーク３０の中に留まらなければならない。
ＣＲ１０が運用者の役割を要求し、かつＣＩ２０が受託者の役割を担うとき、ＣＩ２０は、分散台帳ネットワーク３０の中に常に留まっていなければならず、一方、ＣＲ１０は、発行者証明書取引がＣＲ１０またはＣＩ２０により公表されてよいので分散台帳ネットワーク３０の中に留まっても、留まらなくともよい。発行者証明書取引がＣＲ１０により公表されたとき、ＣＲ１０はまた、図１０に示すように分散台帳ネットワーク３０の中に留まらなければならない。発行者証明書取引がＣＩにより公表されたとき、ＣＲは、図１１に示すように分散台帳ネットワーク３０の外に留まってよいが、分散台帳ネットワーク３０に接続する必要がある。
図１１に示すように、サーバ証明書を公表するための分散台帳に基づくシステムはまた、それぞれサーバであるＣＲ１０およびＣＩ２０を含む。分散台帳にサーバ証明書を公開できる役割を有する唯一のサーバであるので、システムのＣＩ２０は、分散台帳ネットワーク３０の中に留まるべきである。ＣＩ２０と異なり、ＣＲ１０は、どんな取引も公表する役割がないので、分散台帳ネットワーク３０の中にそのように留まる必要はない。しかしながら、ＣＲ１０は、分散台帳ネットワークに接続されるべきである。
図１２に示す、証明書認証用の分散台帳に基づくシステムについて、システムに伴う接続サーバ（ＣＳ）４０および受信サーバ（ＲＳ）５０は、分散台帳ネットワーク３０に接続されたままでいる必要がある。証明書認証は、任意の取引を公表することに関係しない主題であるが、接続サーバ（ＣＳ）４０も受信サーバ（ＲＳ）も、検証処理中に分散台帳から読み出さなければならない。それに加えて、接続サーバ（ＣＳ）４０および受信サーバ（ＲＳ）は、互いに接続状態にあると考えられる。

本発明での方法およびシステムは第一に、分散台帳が不変であり、かつ単一の集中化した権限の制御を受けることなく共用されるという事実から生じる証明書不変性を提供するという点で有利であり、分散台帳解決策は、証明書認証に非常によく調和するようになる。第二に、証明書の発行および取消しの履歴もまた、分散台帳に記録される。証明書可用性について、分散台帳ネットワークでの分散台帳は、分散台帳ネットワークでのすべての分散台帳全体にわたって整合性を保証するために合意機構により絶えず維持されるので、分散台帳ネットワークでのサーバは、分散台帳ネットワークで分散台帳を管理する必要がない。

本発明の数多くの特徴および利点が、本発明の構造および機能の詳細と共に前述の説明で示されたとしても、本開示は例示でしかない。添付の特許請求の範囲が表現する用語の広い一般的な意味により示される最大限の範囲まで、本発明の原理の範囲内で特に部分の形状、サイズ、および配置に関して詳細に変更を行ってよい。

Claims (32)

1. 分散台帳を維持している分散台帳ネットワークに通信可能に互いに接続された接続サーバ（ｃｏｎｎｅｃｔｉｎｇ ｓｅｒｖｅｒ、ＣＳ）および受信サーバ（ｒｅｃｅｉｖｉｎｇ ｓｅｒｖｅｒ、ＲＳ）の証明書を認証するための方法であって、
   （ａ）前記ＲＳは、前記ＣＳと識別を交換するステップと、
   （ｂ）前記ＲＳは、ＣＳ識別に基づき前記分散台帳からＣＳの証明書およびＣＳ証明書発行者の公開鍵を取り出すステップと、
   （ｃ）前記ＲＳは、前記ＣＳ証明書発行者の公開鍵を用いて前記ＣＳの証明書が真正であるかどうかを検証するステップと、
   （ｄ）前記ＣＳの証明書が真正であることが検証された後、前記ＲＳは、前記ＣＳが前記ＲＳから秘密情報を受信するように認証されていると判断するステップと、を備える、
   方法。
2. （１）前記ＣＳは、ＲＳ識別に基づき前記分散台帳からＲＳの証明書およびＲＳ証明書発行者の公開鍵を取り出し、（２）前記ＣＳは、前記ＲＳ証明書発行者の公開鍵を用いて前記ＲＳの証明書が真正であるかどうかを検証し、（３）前記ＲＳの証明書が検証された後、前記ＣＳは、前記ＲＳが前記ＣＳから秘密情報を受信するように認証されていると判断することを特徴とする、請求項１に記載の方法。
3. 前記ステップ（ａ）で、前記ＲＳは、前記ＣＳと証明書をさらに交換することを特徴とする、請求項２に記載の方法。
4. 前記ステップ（ｃ）および前記ステップ（２）で、前記ＲＳは、交換された前記ＣＳの証明書と取り出された前記ＣＳの証明書の両方が前記ＣＳ証明書発行者の公開鍵と調和するかどうかをさらに検証し、前記ＣＳは、交換された前記ＲＳの証明書と取り出された前記ＲＳの証明書の両方が前記ＲＳ証明書発行者の公開鍵と調和するかどうかをさらに検証することを特徴とする、請求項３に記載の方法。
5. 前記ＣＳ識別は、前記ＣＳのサブジェクト代替名であり、前記ＲＳ識別は、前記ＲＳのサブジェクト代替名であることを特徴とする、請求項１に記載の方法。
6. 前記ステップ（ｃ）で、前記ＲＳは、前記ＣＳの証明書を現在の証明書として初期化し、ループして、次の証明書の証明書発行者の秘密鍵を用いて前記現在の証明書に署名する前記次の証明書を取り出して、前記次の証明書での公開鍵を用いて前記現在の証明書を検証して、前記現在の証明書が検証された、または検証条件が満たされたときに前記ＣＳの証明書が真正であると検証されたと判断し、そうではない場合、前記現在の証明書を前記次の証明書に更新し、前記ステップ（２）で、前記ＣＳは、前記ＲＳの証明書を現在の証明書として初期化し、ループして、次の証明書の証明書発行者の秘密鍵を用いて前記現在の証明書に署名する前記次の証明書を取り出して、前記次の証明書での公開鍵を用いて前記現在の証明書を検証して、前記現在の証明書が検証された、または前記検証条件が満たされたときに前記ＲＳの証明書が真正であると検証されたと判断し、そうではない場合、前記現在の証明書を前記次の証明書に更新することを特徴とする、請求項１に記載の方法。
7. 互いに通信状態にある証明書発行ノード（ｃｅｒｔｉｆｉｃａｔｅ－ｉｓｓｕｉｎｇ ｎｏｄｅ、ＣＩ）および証明書要求サーバ（ｃｅｒｔｉｆｉｃａｔｅ－ｒｅｑｕｅｓｔｉｎｇ ｓｅｒｖｅｒ、ＣＲ）を通して、前記ＣＩを含む分散台帳ネットワークにより維持された分散台帳に発行者資格および発行者証明書を公表するための方法であって、
   （ａ）前記ＣＩは、前記ＣＲから資格関連情報を受信するステップと、
   （ｂ）前記ＣＩは、発行者資格取引に署名して、前記分散台帳に前記発行者資格取引を提出するステップと、
   （ｃ）前記ＣＲおよび前記ＣＩの一方は、前記ＣＲに関する発行者証明書を作成し、前記発行者証明書に署名し、前記発行者証明書の署名者が前記ＣＲではないときに前記ＣＲに前記発行者証明書を送信するステップと、
   （ｄ）前記分散台帳で前記発行者資格取引が作成された後、前記発行者証明書を有する前記ＣＲおよび前記ＣＩの任意の一方は、発行者証明書取引に署名して、前記分散台帳に前記発行者証明書取引を提出するステップと、を備える、
   方法。
8. 前記資格関連情報は、前記ＣＲの分散型識別子（ｄｅｃｅｎｔｒａｌｉｚｅｄ ｉｄｅｎｔｉｆｉｅｒ、ＤＩＤ）、台帳公開鍵、および役割を含むことを特徴とする、請求項７に記載の方法。
9. 前記発行者資格取引は、前記ＣＲのＤＩＤおよび台帳公開鍵、前記ＣＩのＤＩＤ、ならびに前記分散台帳に追加されるＣＲの役割を含むことを特徴とする、請求項７に記載の方法。
10. 前記ＣＩは、ＣＩの台帳秘密鍵を用いて前記発行者資格取引に署名することを特徴とする、請求項７に記載の方法。
11. 前記発行者証明書取引は、提出者のＤＩＤ、証明書ＩＤ、前記発行者証明書、および前記提出者の署名を含み、前記証明書ＩＤは、前記発行者証明書のハッシュ値であり、前記発行者証明書は、前記ＣＲの識別および証明書公開鍵、前記ＣＲの任意選択の役割、ならびに前記発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含むことを特徴とする、請求項９に記載の方法。
12. 前記ＣＲの識別は、サブジェクト代替名であることを特徴とする、請求項１１に記載の方法。
13. 発行者証明書取引提出者は、自身の台帳秘密鍵を用いて前記発行者証明書取引に署名し、前記発行者証明書取引が前記ＣＲにより提出されたとき、前記分散台帳ネットワークは、前記ＣＲを含み、前記発行者証明書取引が前記ＣＩにより提出されたとき、前記分散台帳ネットワークは、前記ＣＲを含まないことを特徴とする、請求項７に記載の方法。
14. 前記分散台帳に追加される前記ＣＲの役割は、受託者であり、前記分散台帳での前記ＣＩの役割は、受託者定足数であり、前記受託者定足数は、前記分散台帳内の少なくとも１つのサーバの圧倒的多数が前記受託者の役割を有する発行役割であると規定され、前記ＣＩは、前記少なくとも１つのサーバの前記圧倒的多数を含むことを特徴とする、請求項９に記載の方法。
15. 前記分散台帳に追加される前記ＣＲの役割は、運用者であり、前記分散台帳での前記ＣＩの役割は、前記受託者または前記運用者であることを特徴とする、請求項１４に記載の方法。
16. 前記ステップ（ｃ）で、前記ＣＲは、前記発行者証明書を作成し、前記ＣＲの前記証明書公開鍵と対をなす前記ＣＲの証明書秘密鍵を用いて前記発行者証明書に署名することを特徴とする、請求項１４に記載の方法。
17. 前記ステップ（ｃ）で、前記ＣＩは、前記ＣＲから発行者証明書署名リクエスト（ｃｅｒｔｉｆｉｃａｔｅ ｓｉｇｎｉｎｇ ｒｅｑｕｅｓｔ、ＣＳＲ）を受信し、前記発行者ＣＳＲを用いて前記発行者証明書に署名し、前記ＣＩの前記証明書公開鍵と対をなす前記ＣＩの証明書秘密鍵を用いて前記発行者証明書に署名し、前記発行者ＣＳＲは、運用者情報、および前記ＣＲの証明書公開鍵を含むことを特徴とする、請求項１５に記載の方法。
18. 前記運用者情報は、前記ＣＲのサブジェクト代替名、商号、部署名、市、州、国、および連絡先電子メールからなるフィールドを含むことを特徴とする、請求項１７に記載の方法。
19. 互いに通信状態にある証明書発行サーバ（ＣＩ）および証明書要求サーバ（ＣＲ）を通して、前記ＣＩを含む分散台帳ネットワークにより維持された分散台帳にサーバ証明書を公表するための方法であって、
    （ａ）前記ＣＩは、前記ＣＲから証明書関連情報を受信するステップと、
    （ｂ）前記ＣＩは、前記ＣＲに関するサーバ証明書を作成し、前記サーバ証明書に署名し、前記ＣＲに前記サーバ証明書を送信するステップと、
    （ｃ）前記ＣＩは、サーバ証明書取引に署名して、前記分散台帳に前記サーバ証明書取引を提出するステップと、を備える、
    方法。
20. 前記証明書関連情報は、サーバ情報および認証公開鍵を含み、前記サーバ情報は、前記ＣＲのインターネット・プロトコル（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ、ＩＰ）・アドレスおよびホスト名を含むことを特徴とする、請求項１９に記載の方法。
21. 前記サーバ証明書取引は、前記サーバ証明書の証明書ＩＤ、前記サーバ証明書、および前記ＣＩのＤＩＤを含み、前記ＣＩの台帳秘密鍵により署名され、前記サーバ証明書は、前記ＣＲのサブジェクト代替名、および前記認証公開鍵を含み、前記ＣＩの証明書秘密鍵により署名され、前記証明書ＩＤは、前記サーバ証明書のハッシュ値であることを特徴とする、請求項２０に記載の方法。
22. 前記分散台帳でサーバ証明書を取り消すとき、前記運用者の役割を有し前記サーバ証明書を追加するサーバは、証明書取消取引を生成して前記分散台帳で前記サーバ証明書を取り消し、前記証明書取消取引に署名し、前記分散台帳に前記証明書取消取引を提出し、前記証明書取消取引は、前記サーバ証明書の前記証明書ＩＤ、および前記サーバ証明書を追加する前記サーバのＤＩＤを含み、前記発行者証明書を追加する前記サーバの台帳秘密鍵により署名されることを特徴とする、請求項１９に記載の方法。
23. 証明書認証用の分散台帳に基づくシステムであって、
    分散台帳を維持する分散台帳ネットワークと、
    前記分散台帳ネットワークに通信可能に接続された接続サーバ（ＣＳ）と、
    前記分散台帳ネットワークに通信可能に接続された受信サーバ（ＲＳ）であって、前記ＣＳと識別を交換し、ＣＳ識別に基づき前記分散台帳からＣＳの証明書およびＣＳ証明書発行者の公開鍵を取り出して前記ＣＳの証明書が真正であるかどうかを検証し、前記ＣＳの証明書が真正であることを検証したときに前記ＣＳが前記ＲＳから秘密情報を受信するように認証されていると判断するＲＳと、を備える、
    システム。
24. 前記ＣＳは、ＲＳ識別に基づき前記分散台帳からＲＳの証明書およびＲＳ証明書発行者の公開鍵を取り出して前記ＲＳの証明書が真正であるかどうかを検証し、前記ＲＳの証明書が真正であることを検証したときに前記ＲＳが前記ＣＳから秘密情報を受信するように認証されていると判断することを特徴とする、請求項２３に記載のシステム。
25. 前記ＲＳは、前記ＣＳと証明書をさらに交換することを特徴とする、請求項２４に記載のシステム。
26. 前記ＲＳは、交換された前記ＣＳの証明書と取り出された前記ＣＳの証明書の両方が前記ＣＳ証明書発行者の公開鍵と調和するかどうかを検証し、前記ＣＳは、交換された前記ＲＳの証明書と取り出された前記ＲＳの証明書の両方が前記ＲＳ証明書発行者の公開鍵と調和するかどうかを検証することを特徴とする、請求項２５に記載のシステム。
27. 発行者資格および発行者証明書を公表するための分散台帳に基づくシステムであって、
    証明書要求サーバ（ＣＲ）と、
    分散台帳を維持し、前記ＣＲに通信可能に接続され、証明書発行ノード（ＣＩ）を含む分散台帳ネットワークと、を備え、
    前記ＣＩは、前記ＣＲから資格関連情報を受信し、発行者資格取引に署名し、分散台帳に前記発行者資格取引を提出し、
    前記ＣＲおよび前記ＣＩの一方は、前記ＣＲに関する発行者証明書をさらに作成し、前記発行者証明書の署名者が前記ＣＲではないときに前記ＣＲに前記発行者証明書を送信し、
    前記分散台帳で前記発行者資格取引が作成された後、前記発行者証明書を有する前記ＣＲおよび前記ＣＩの一方は、発行者証明書取引に署名して、前記分散台帳に前記発行者証明書取引を提出する、ことを特徴とする、
    システム。
28. 前記資格関連情報は、前記ＣＲの分散型識別子（ＤＩＤ）、台帳公開鍵、および役割を含むことを特徴とする、請求項２７に記載のシステム。
29. 前記発行者資格取引は、前記ＣＲのＤＩＤおよび台帳公開鍵、ＣＩのＤＩＤ、ならびに前記分散台帳に追加されるＣＲの役割を含むことを特徴とする、請求項２７に記載のシステム。
30. 前記ＣＩは、ＣＩの台帳秘密鍵を用いて前記発行者資格取引に署名することを特徴とする、請求項２７に記載のシステム。
31. 前記発行者証明書取引は、提出者のＤＩＤ、証明書ＩＤ、前記発行者証明書、および前記提出者の署名を含み、前記証明書ＩＤは、前記発行者証明書のハッシュ値であり、前記発行者証明書は、前記ＣＲの識別および証明書公開鍵、前記ＣＲの任意選択の役割、ならびに前記発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含むことを特徴とする、請求項３０に記載のシステム。
32. 発行者証明書取引提出者は、自身の台帳秘密鍵を用いて前記発行者証明書取引に署名し、前記発行者証明書取引が前記ＣＲにより提出されたとき、前記分散台帳ネットワークは、前記ＣＲを含み、前記発行者証明書取引が前記ＣＩにより提出されたとき、前記分散台帳ネットワークは、前記ＣＲを含まないことを特徴とする、請求項２７に記載のシステム。

Images