特許 6644894 複数の暗号システムとのデジタル証明書の使用

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6644894

(24)【登録日】2020年1月10日

(45)【発行日】2020年2月12日

(54)【発明の名称】複数の暗号システムとのデジタル証明書の使用

(51)【国際特許分類】

   H04L 9/32 20060101AFI20200130BHJP

   G09C 1/00 20060101ALI20200130BHJP

【ＦＩ】

   H04L9/00 675D

   G09C1/00 640D

【請求項の数】30

【全頁数】44

(21)【出願番号】特願2018-533833(P2018-533833)

(86)(22)【出願日】2017年3月10日

(65)【公表番号】特表2019-509652(P2019-509652A)

(43)【公表日】2019年4月4日

(86)【国際出願番号】CA2017050317

(87)【国際公開番号】WO2018027300

(87)【国際公開日】20180215

【審査請求日】2018年6月21日

(31)【優先権主張番号】15/230,819

(32)【優先日】2016年8月8日

(33)【優先権主張国】US

【早期審査対象出願】

【前置審査】

(73)【特許権者】

【識別番号】518220637

【氏名又は名称】イサラ コーポレイション

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(72)【発明者】

【氏名】トルスコフスキー アレクサンデル

(72)【発明者】

【氏名】山田 淳

(72)【発明者】

【氏名】ブラウン マイケル ケネス

(72)【発明者】

【氏名】グトスキ グスタフ ミハエル

【審査官】 青木 重徳

(56)【参考文献】

【文献】 特開２００２−２０７４２７（ＪＰ，Ａ）

【文献】 特開２０１０−０８１１５４（ＪＰ，Ａ）

【文献】 国際公開第２００８／０５０７９２（ＷＯ，Ａ１）

【文献】 特開２０１１−０６６８３４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｇ０９Ｃ １／００

(57)【特許請求の範囲】

【請求項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】

前記第１の暗号システムは量子脆弱暗号システムを含み、前記第２の暗号システムは耐量子暗号システムを含む、
請求項２４に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

〔優先権の主張〕
本出願は、２０１６年８月８日に出願された「複数の暗号システムとのデジタル証明書の使用（Ｕｓｉｎｇ ａ Ｄｉｇｉｔａｌ Ｃｅｒｒｉｆｉｃａｔｅ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｃｒｙｐｔｏｓｙｓｔｅｍｓ）」という名称の米国特許出願第１５／２３０，８１９号に対する優先権を主張するものであり、この文献は引用により本明細書に組み入れられる。

【0002】

以下の説明は、例えば公開鍵基盤（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における複数の暗号化システム（「暗号システム（ｃｒｙｐｔｏｓｙｓｔｅｍ）」）と共にデジタル証明書を使用することに関する。

【背景技術】

【0003】

暗号化システムは、公開チャネルを介して安全に通信を行うために使用される。例えば、メッセージを暗号化することによって機密性を提供する暗号システムもあれば、デジタル署名を通じて真正性を提供する暗号システムもある。多くの暗号システムは、暗号鍵を使用するプロトコルを含む。例えば、公開鍵基盤（ＰＫＩ）では、暗号鍵が各エンティティの公開鍵及び秘密鍵を含み、認証局が、公開鍵を認証するデジタル証明書を発行することができる。

【図面の簡単な説明】

【0004】

【図1】通信システム例の態様を示すブロック図である。

【図2A】暗号システム間の移行を行う企業システム例を示すブロック図である。

【図2B】暗号システム間の移行を行うプロセス例を示すフロー図である。

【図3】複数の暗号システムのデジタル証明書を発行するプロセス例を示すフロー図である。

【図4】複数の暗号システムにおいてデジタル証明書を使用するプロセス例を示すフロー図である。

【図5】耐量子暗号システムの公開鍵を含むデジタル証明書例を示すブロック図である。

【図6】耐量子暗号システムの公開鍵を含むデジタル証明書を伴う証明書チェーン例を示すブロック図である。

【図7】耐量子暗号システムの認証局署名を含むデジタル証明書例を示すブロック図である。

【図8】耐量子暗号システムの認証局署名を含むデジタル証明書を伴う証明書チェーン例を示すブロック図である。

【図9】耐量子暗号システムの認証局署名及び公開鍵を含むデジタル証明書例を示すブロック図である。

【図10】耐量子暗号システムの認証局署名及び公開鍵を含むデジタル証明書を伴う証明書チェーン例を示すブロック図である。

【発明を実施するための形態】

【0005】

ここで説明する内容のいくつかの態様では、デジタル証明書を複数の暗号システムと共に使用することができる。デジタル証明書は、各暗号システムのコンポーネント（例えば、デジタル署名、公開鍵など）を含むことができる。いくつかの例では、このようなデジタル証明書を、企業インフラ内で新たな認証アルゴリズムを展開するという文脈で使用することができる。例えば、このような「ハイブリッド」なデジタル証明書は、様々なシステムコンポーネントを新たな暗号システムをサポートするようにアップグレードする際に、新たな暗号システムを徐々に運用開始する段階的方法において使用することができる。

【0006】

いくつかの実装では、例えば量子脆弱暗号システムから耐量子暗号システムへの移行中に、量子脆弱暗号システム（例えば、従来の量子脆弱暗号システム）とアップグレードされた耐量子暗号システムとがハイブリッドデジタル証明書を使用することができる。いくつかの例では、耐量子暗号システムのコンポーネント（例えば、耐量子公開鍵、耐量子デジタル署名など）と量子脆弱暗号システムのコンポーネント（例えば、量子脆弱公開鍵、量子脆弱デジタル署名など）とを１つの証明書内に配置することにより、単一の証明書チェーン構造又は符号化に、複数の有効な証明書チェーンを埋め込むことができる。このようなハイブリッド証明書を使用すると、レガシーなアプリケーションは量子脆弱暗号システムを使用し続ける一方で、アップグレードされたアプリケーションは耐量子暗号システムの使用を開始して、通信システム内に両暗号システムが共存できるようにすることができる。

【0007】

いくつかの実装では、暗号システム間の移行に多段階アップグレードを使用する。各移行段階では、追加のシステムコンポーネントをアップグレードして、アップグレードされた（例えば、耐量子）暗号システムへの依存度を高める。いくつかの例では、移行段階が、１又は２以上のアプリケーションをアップデートしてエンドエンティティ証明書を修正することを含む。いくつかの例では、別の移行段階が、公開鍵基盤（ＰＫＩ）をアップグレードしてＣＡ証明書を修正することを含む。いくつかの例では、別の移行段階が、残りの全てのアプリケーションをアップグレードして証明書の修正を排除することを含む。このような多段階アップグレードは、例えば量子脆弱暗号システムから耐量子暗号システムへの移行において、又は別のタイプの移行（例えば、より安全なデジタル署名アルゴリズムへのアップグレードなど）において使用することができる。

【0008】

ＰＫＩを使用する企業システムは複雑であり、広い地理的範囲又は組織的範囲に及ぶ多くのエンティティを伴う場合がある。例えば、いくつかの大規模組織（例えば、会社組織、政府機関など）は、数百万人ものユーザ及び関連するクレデンシャルを有していることもあり、（例えば、「ブリッジＣＡ」などのエンティティ又は他のタイプのエンティティを介して）信頼関係を維持する複数の系列グループにわたって展開されていることもある。これらの及びその他の例では、２つのエンティティが通信する際に、これらの間の信頼関係に、異なる組織内で維持されている多くの異なる認証局を行き来することが必要な場合もある。このような特徴及び複雑性を有するシステムは、例えば継続性及びセキュリティを保証するために多段階を用いて移行することができる。いくつかの実装では、エンティティが、１又は２以上の移行段階中に、例えばＰＫＩ及び関連するアプリケーションのアップグレード後に、古い暗号システム又は新しい暗号システムを用いて認証及び識別を行うことができる。

【0009】

図１は、通信システム例１００の態様を示すブロック図である。図１に示す通信システム例１００は、２つのエンティティノード１０２、１０４及び２つの認証局ノード１１２、１１４という４つのノードを含む。これらのノードは、ネットワーク１０６を介して互いに通信するために暗号スキームを使用する。図示の例では、量子対応の敵対者（ｑｕａｎｔｕｍ−ｅｎａｂｌｅｄ ａｄｖｅｒｓａｒｙ）１０８が、ネットワーク１０６、ネットワーク１０６上で交換される情報、又はこれらの両方にアクセスすることができる。いくつかの例では、量子対応の敵対者が、ネットワーク１０６上の情報を修正することもできる。通信システム１００は、さらなる又は異なる特徴を含むこともでき、通信システム内のコンポーネントは、図１に示すように又は別の方法で動作するように構成することができる。

【0010】

いくつかの実装では、通信システム１００内のノードがサーバ−クライアント関係を有することができる。例えば、ノード１０２をサーバとし、ノード１０４をサービスネットワーク内のクライアントとすることができ、或いはこれを逆にすることもできる。いくつかの実装では、通信システム１００内のノードがピアツーピア関係を有することができる。例えば、ノード１０２、１０４は、サービスネットワーク、ピアツーピアネットワーク、又は別のタイプのネットワーク内のピアとすることができる。ノードは、通信システム１００内で別のタイプの関係を有することもできる。

【0011】

図１に示す例では、通信システム１００が、暗号通信のための公開鍵基盤（ＰＫＩ）を使用する。典型的な公開鍵基盤（ＰＫＩ）では、エンティティが、信頼できる認証局によって発行された証明書に基づいて互いを認証することができる。ＰＫＩ内のエンティティ（例えば、ユーザ、ユーザアカウント、装置又は機械、ソフトウェアモジュール又はその他のタイプのエンティティ）は、それぞれがユーザアイデンティティと、公開鍵及び秘密鍵を含む鍵対とを有し、認証局は、公開鍵をエンティティのユーザアイデンティティに結び付けるデジタル証明書を発行することができる。

【0012】

いくつかのＰＫＩ例では、認証局（ＣＡ）証明書及びエンドエンティティ証明書という２つのタイプのデジタル証明書が存在する。ＣＡ証明書は、他の証明書を認証するために使用することができる。エンドエンティティ証明書は、エンティティ（証明書の所有者）を識別するために使用することができる。図１に示す例では、エンティティノード１０２、１０４の各々が、エンドエンティティ証明書を有するエンティティに関連することができ、認証局ノード１０２、１０４の各々が、ＣＡ証明書を有する認証局に関連することができる。

【0013】

いくつかのＰＫＩ例は、証明書チェーンを使用する。典型的な証明書チェーンでは、証明書チェーンの最上位にルートＣＡ証明書が存在し、証明書チェーンの最下位にエンドエンティティ証明書が存在し、証明書チェーンの中間（ルートＣＡ証明書とエンドエンティティ証明書との間）に１又は２以上の中間ＣＡ証明書が存在する。ルートＣＡ証明書はハードコード化され、ＰＫＩ内のエンティティはこれを明確に信頼することができる。エンドエンティティ証明書はＰＫＩ内のエンティティに発行され、エンティティのユーザアイデンティティを含むことができる。いくつかの例では、ルート認証局が、下位の認証局に中間ＣＡ証明書又はエンドエンティティ証明書を発行することができる。いくつかの例では、中間認証局が、下位の認証局に中間ＣＡ証明書又はエンドエンティティ証明書を発行することができる。一例として、図１の認証局ノード１１２は、ルートＣＡ証明書を有するルート認証局に関連することができ、ルート認証局は、他の認証局ノード１１４に関連する認証局に中間ＣＡ証明書を発行することができる。中間認証局は、エンティティノード１０２、１０４に関連するエンティティにエンドエンティティ証明書を発行することができる。

【0014】

標準化された公開鍵基盤の例に、Ｘ．５０９デジタル証明書を使用するＸ．５０９公開鍵基盤がある。通常、Ｘ．５０９証明書は、複数の基本フィールド（ｂａｓｉｃ ｆｉｅｌｄｓ）と、１又は２以上の拡張領域（ｅｘｔｅｎｓｉｏｎｓ）とを含む。Ｘ．５０９証明書の基本フィールドは、例えば署名値フィールド、発行者フィールド、有効期間フィールド、主体者フィールド、（「主体者公開鍵情報」フィールドとも呼ばれる）公開鍵フィールドなどを含むことができる。Ｘ．５０９証明書の署名値フィールドは、認証局が証明書に署名するために計算したデジタル署名を含むことができる。Ｘ．５０９証明書の発行者フィールドは、証明書の署名及び発行を行ったエンティティを識別する情報を含むことができる。Ｘ．５０９証明書の有効期間フィールドは、認証局が証明書の状態に関する情報を維持することを保証する期間を識別する情報を含むことができる。Ｘ．５０９証明書の主体者フィールドは、公開鍵フィールドに記憶された公開鍵に関連するエンティティ（証明書の所有者）を識別する情報（例えば、ユーザアイデンティティ）を含むことができる。Ｘ．５０９証明書の公開鍵フィールドは、エンティティの公開鍵を含むことができる。Ｘ．５０９の公開鍵フィールドは、公開鍵と共に使用される暗号アルゴリズムを識別する情報を含むこともできる。

【0015】

Ｘ．５０９証明書の拡張領域は、例えば標準拡張、プライベート拡張、及び場合によっては他のタイプの拡張を含むことができる。標準拡張は、例えば鍵識別子、鍵使用情報、証明書ポリシー、別名、制約、及びその他のタイプの情報を含むことができる。いくつかの実装では、Ｘ．５０９証明書を、標準拡張に含まれていないさらなる拡張を含むように修正することができる。例えば、Ｘ．５０９証明書は、別の署名値（例えば、認証局が別の暗号システムに関連する秘密鍵を用いて証明書に署名するために計算した別のデジタル署名）、エンティティの別の公開鍵（例えば、別の暗号システムに関連する公開鍵）を含むプライベート拡張を有するように修正することができる。Ｘ．５０９証明書は、他のタイプの情報及び他の拡張領域又はフィールドを含むこともできる。

【0016】

通信システム例１００内のノードは、セキュア通信モジュール（例えば、仮想プライベートネットワーク（ＶＰＮ）、セキュアウェブブラウジング、セキュアメールなど）、或いはＰＫＩを認証に使用し、関連する暗号鍵（例えば、デジタル署名ベースのゼロ知識証明又は別のタイプの識別機構）を識別に使用して、参加エンティティの信頼できるアイデンティティを確立する他のタイプのシステムコンポーネントを含む。このような認証及び識別機構のセキュリティは、１又は２以上の暗号化システム（「暗号システム（ｃｒｙｐｔｏｓｙｓｔｅｍ）」）に依拠することができる。暗号システムの例としては、様々なＲＳＡベースの暗号システム、ＥＣＣベースの暗号システム、格子ベースの暗号システムなどが挙げられる。通常、暗号システムは、暗号プロトコルの組と、暗号プロトコル内で使用されるパラメータの組とを定義する。

【0017】

いくつかの例では、通信システム１００が、例えばさらなるセキュリティ層を提供する目的で、１つの暗号システムから別の暗号システムに移行する目的で、新たな暗号システムをテストする目的で、又はその他の目的で、複数の暗号システムを使用することができる。一例として、通信システム１００は、セキュリティのために、ＥＣＣベースの暗号システムへの依拠から格子ベースの暗号システムへの依拠に移行することができる。別の例として、通信システム１００は、セキュリティのために、１つのタイプのＥＣＣベースの暗号システムへの依拠から別のタイプのＥＣＣベースの暗号システムへの依拠に移行することもできる。セキュア通信モジュールは、通信システム１００内の他のノードと相互作用するので、暗号システムは段階的に移行させることができる。例えば、新たな暗号システムは、新旧両方の暗号システムを利用できる１又は２以上の移行段階を通じて導入することができる。これらの移行段階は、サービスを大幅に中断することなく新たな暗号システムの導入を可能にすることができる。図２Ａ及び図２Ｂに多段階移行の例を示すが、暗号システムは、別の方法で移行させることもできる。

【0018】

図１に示す例では、通信システム１００を、初期の暗号システムからアップグレードされた暗号システムに移行させることができる。いくつかの例では、アップグレードされた暗号システムが初期暗号システムと同じ暗号プロトコルを使用し、これらのプロトコル内で異なるパラメータを使用する。例えば、ＥＣＣベースの暗号システムは、さらに優れたセキュリティを提供する新たな楕円曲線を使用するようにアップグレードすることができる。いくつかの例では、アップグレードされた暗号システムが、初期暗号システムが使用するものとは異なる暗号プロトコルを使用する。例えば、ＥＣＣベースの暗号システムは、さらに優れたセキュリティを提供する格子ベースの暗号システムに置き換えることができる。

【0019】

いくつかの例では、通信システム１００が、移行中にＰＫＩがユーザアイデンティティ毎に１つのデジタル証明書を使用できるような形で移行される。例えば、移行前、移行後及び移行中に、初期の暗号システム及びアップグレード後の暗号システムの両方において１つのデジタル証明書を使用することができる。ユーザアイデンティティ毎に１つのデジタル証明書を維持すると、例えば移行中のセキュアな通信に必要なリソースを抑えることによって移行を単純化することができる。例えば、システムによっては、使用しているクレデンシャル記憶のための物理的解決策が空間面で、及び（例えば、更新のための）リソースとの相互作用方法の面で制限されているものもあり、単一のエンドエンティティ証明書を維持することによって、このようなシステムコンポーネントをアップグレードするための単純な解決策を提供することができる。

【0020】

いくつかの例では、通信システム１００が、例えば量子脆弱暗号システムから耐量子暗号システムへの移行中に、量子脆弱暗号システムと耐量子暗号システムの両方を使用することができる。例えば、多くの従来の暗号システム（例えば、ＲＳＡ、ＤＳＡ又はＥＣＤＳＡなどの一部の古典的なデジタル署名アルゴリズム）は、量子コンピュータによる攻撃を受けやすい可能性があり、耐量子暗号システムにアップグレードすることでセキュリティを改善できることが知られている。いくつかの実装では、段階的移行を用いて通信システム１００を量子脆弱暗号システムから耐量子暗号システムに移行させることができる。この段階的移行は、セキュア通信モジュール（例えば、仮想プライベートネットワーク（ＶＰＮ）、セキュアウェブブラウジング、セキュアメールなど）又は他のタイプのシステムコンポーネントを量子脆弱暗号システムから耐量子暗号システムにスムーズに移行させるように設計することができる。

【0021】

図１に示す例では、例示的なエンティティノード１０２、１０４及び認証局ノード１１２、１１４が、それぞれ他のノードと通信するために使用される計算リソース（例えば、ハードウェア、ソフトウェア、ファームウェア）を有する。いくつかの実装では、通信システム１００内のノードを、例えばラップトップ、デスクトップ、ワークステーション、スマートフォン、タブレット、携帯情報端末、サーバ、サーバクラスタ、メインフレーム及びその他のタイプのコンピュータシステムなどの様々なシステムに実装することができる。図１に示すように、ノード例１０２は、メモリ１１０と、プロセッサ１１１と、インターフェイス１１３とを含む。エンティティノード１０２、１０４及び認証局ノード１１２、１１４の各々は、同じコンポーネント、さらなるコンポーネント、又は異なるコンポーネントを含むこともできる。エンティティノード１０２、１０４及び認証局ノード１１２、１１４は、図１に関して図示し説明するように構成することも、又は別の方法で動作するように構成することもできる。いくつかの例では、単一の装置が、エンティティノードと認証局ノードの両方として動作することができる。

【0022】

図１に示すノード例１０２では、メモリ１１０が、例えばランダムアクセスメモリ（ＲＡＭ）、記憶装置（例えば、書き込み可能リードオンリメモリ（ＲＯＭ）など）、ハードディスク、又は別のタイプの記憶媒体を含むことができる。メモリ例１１０は、オペレーティングシステム、コンピュータアプリケーション及びその他のリソースに関連する命令（例えば、コンピュータコード、コンピュータプログラムなど）を記憶することができる。メモリ１１０は、ノード１０２上で実行中の１又は２以上のアプリケーション又は仮想機械が解釈できるアプリケーションデータ及びデータオブジェクトを記憶することもできる。ノード１０２は、予めプログラムしておくことも、或いは別のソースから（例えば、ＤＶＤ−ＲＯＭ、取り外し可能メモリデバイス、リモートサーバ、データネットワークから又は別の方法で）プログラムをロードすることによってプログラム（及び再プログラム）することもできる。いくつかの例では、メモリ１１０が、プロセッサ１１１によって解釈又は実行される、ソフトウェアアプリケーション、スクリプト、プログラム、関数、実行ファイル又は他のモジュールのためのコンピュータ可読命令を記憶する。例えば、コンピュータ可読命令は、図３及び図４に示す動作のうちの１つ又は２つ以上を実行するように構成することができる。

【0023】

図１に示すノード例１０２では、プロセッサ１１１が、例えばデータ入力に基づいて出力データを生成する命令を実行することができる。例えば、プロセッサ１１１は、メモリ１１０に記憶されているソフトウェア、スクリプト、プログラム、関数、実行ファイル又はその他のモジュールを実行又は解釈することによってコンピュータプログラムを実行することができる。いくつかの例では、プロセッサ１１１が、図３及び図４に示す動作のうちの１つ又は２つ以上を実行することができる。

【0024】

図１に示すプロセッサ例１１１は、アナログ回路、デジタル回路又はこれらの組み合わせを含む１又は２以上のチップ又はチップセットを含むことができる。いくつかの例では、プロセッサ１１１が、例えば１又は２以上のメインプロセッサ及び１又は２以上のコプロセッサなどの複数のプロセッサ装置を含む。例えば、プロセッサ１１１は、いくつかの計算タスクを暗号コプロセッサに委任できるメインプロセッサを含むことができ、暗号コプロセッサは、計算タスクをメインプロセッサよりも効率的に、又は他のプロセッサ装置によって実行される他の計算タスクと並行して実行するように構成することができる。いくつかの例では、プロセッサ１１１が、例えばユーザインターフェイス、通信インターフェイス、周辺装置、及び場合によってはその他のコンポーネントなどの、ノード１０２の他のコンポーネントの動作を調整又は制御する。

【0025】

図１に示すノード例１０２では、インターフェイス１１３が他のノード又は装置との通信を提供する。いくつかの例では、インターフェイス１１３が、例えば、とりわけＢｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ、近距離通信（ＮＦＣ）、ＧＭＳ音声通話、ＳＭＳ、ＥＭＳ、又はＭＭＳメッセージング、無線標準規格（例えば、ＣＤＭＡ、ＴＤＭＡ、ＰＤＣ、ＷＣＤＭＡ（登録商標）、ＣＤＭＡ２０００、ＧＰＲＳ）などの様々な無線プロトコル下で無線通信を提供する無線通信インターフェイスを含む。このような通信は、例えば無線周波数トランシーバ又は別のタイプのコンポーネントを通じて行うことができる。いくつかの例では、インターフェイス１１３が、例えばキーボード、ポインティングデバイス、スキャナなどの１又は２以上の入力／出力装置に、或いは、例えばネットワークアダプタを通じてスイッチ又はルータなどのネットワーク装置に接続できる有線通信インターフェイス（例えば、ＵＳＢ、Ｅｔｈｅｒｎｅｔ）を含む。

【0026】

ネットワーク例１０６は、コネクタ、データ通信ネットワーク又は別のタイプの通信リンクの全部又は一部を含むことができる。例えば、ネットワーク１０６は、１又は２以上の有線又は無線接続、１又は２以上の有線又は無線ネットワーク、又は他の通信チャネルを含むことができる。いくつかの例では、ネットワーク１０６が、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、プライベートネットワーク、仮想プライベートネットワーク（ＶＰＮ）、公衆ネットワーク（インターネットなど）、ピアツーピアネットワーク、セルラーネットワーク、Ｗｉ−Ｆｉネットワーク、パーソナルエリアネットワーク（ＰＡＮ）（例えば、Ｂｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙ（ＢＴＬＥ）ネットワーク、ＺｉｇＢｅｅネットワークなど）、又は機械間（Ｍ２Ｍ）通信を含むその他の短距離ネットワーク、又は別のタイプのデータ通信ネットワークを含む。

【0027】

図示の例では、量子対応の敵対者１０８が量子計算リソースにアクセスすることができる。例えば、量子対応の敵対者１０８は、量子コンピュータ、量子情報プロセッサ、量子メモリ、量子通信インターフェイス、又はこれらの組み合わせ、及び場合によってはその他の量子技術とすることができ、これらを含むことができ、又はこれらにアクセスすることができる。いくつかの実装では、量子対応の敵対者１０８が、例えば古典的なフロントエンドプロセッサによって駆動される量子プロセッサを含むハイブリッドコンピュータシステム、又は別のタイプのハイブリッドコンピュータシステムを含むことができる。

【0028】

いくつかの例では、量子対応の敵対者１０８が、量子システムに情報を記憶して処理することができる。例えば、量子対応の敵対者１０８は、情報を量子ビット（「ｑｕｂｉｔ」）として符号化し、この量子ビットを操作することによって情報を処理することができる。情報は、物理量子ビット、論理量子ビット、又はこれらの組み合わせ、及びその他のタイプの量子ビット符号化の形で符号化することができる。いくつかの実装では、量子対応の敵対者１０８が、耐故障性レジーム内で、又は耐故障性レジームの下位で動作することができる。

【0029】

多くの公開鍵暗号システムは、拡張可能な量子コンピュータで武装した攻撃に対して安全でないことが知られている。例えば、ディフィー・ヘルマン（ＤＨ）鍵共有プロトコル及び楕円曲線ディフィー・ヘルマン（ＥＣＤＨ）鍵共有プロトコルは、量子対応の敵対者によるいくつかのタイプの攻撃を受けやすい。公開鍵暗号法に対する量子コンピュータの脅威は、量子攻撃を受けにくいと考えられる他の公開鍵暗号システムに切り替えることによって軽減することができる。例えば、量子脆弱と考えられているいくつかのＲＳＡベース又はＥＣＣベースの暗号システムの耐量子的な置換として、格子ベースの暗号システムが提案されている。

【0030】

いくつかの実装では、量子対応の敵対者例１０８が、量子計算アルゴリズム、量子計算回路又は量子通信プロトコル、或いは他のタイプの量子情報処理タスクを実行することができる。図示の例では、量子対応の敵対者１０８が、古典的なコンピュータ上では困難と考えられる問題を量子対応の敵対者が効率的に解けるようにするＳｈｏｒのアルゴリズムを実行する。例えば、量子対応の敵対者１０８は、Ｓｈｏｒのアルゴリズムを用いて大整数を因数分解し、離散対数を発見し、又は場合によっては計算効率の良い方法で他の問題を解くことができる。従って、量子対応の敵対者例１０８は、（例えば、公開情報に基づいて認証局又はその他のエンティティの秘密鍵を計算することによって）いくつかの量子脆弱暗号システムのセキュリティを損なうことができる。

【0031】

図１に示す量子対応の敵対者例１０８は、ネットワーク１０６上で交換される情報にアクセスすることができる。例えば、量子対応の敵対者１０８は、エンティティノード１０２、１０４間、又はエンティティノードと認証局ノードとの間で交換される情報の一部又は全部にアクセスすることができる。いくつかの例では、量子対応の敵対者１０８が、ネットワーク１０６上の通信を直接観察することができ、いくつかの例では、例えば別のエンティティ又はシステムがネットワーク１０６上で観察した情報を受け取ることによって、このような通信を間接的に取得する。

【0032】

いくつかの実装では、量子対応の敵対者１０８が、特定の暗号システムのセキュリティを損なうのに十分な速度で整数を因数分解し、離散対数を計算し、或いは従来は困難であった他の計算タスクを実行することができる。例えば、量子対応の敵対者１０８は、特定のＲＳＡ暗号規格を損なうのに十分な速度で素因数を計算し、或いは特定のＥＣＣ暗号規格を損なうのに十分な速度で離散対数を計算することができる。

【0033】

図１に示す例では、エンティティノード１０２、１０４及び認証局ノード１１２、１１４が、量子対応の敵対者例１０８が損なうことができない耐量子暗号システムを使用することができる。例えば、エンティティノード１０２、１０４は、Ｓｈｏｒのアルゴリズム、又はいくつかの従来の暗号規格のセキュリティを損なうことが分かっている他のタイプのアルゴリズムを効率的に実行できる量子コンピュータに対して安全な暗号システムを用いて通信することができる。いくつかの実装では、耐量子暗号システムを量子脆弱暗号システムと並行して使用することができる。例えば、通信システム１００は、１又は２以上の移行段階において量子脆弱暗号システムの使用から耐量子暗号システムの使用に移行することができ、移行段階中は両暗号システムを利用することができる。

【0034】

いくつかの実装では、ノード１０２、１０４が、各ノードが他のノードから受け取ったメッセージの真正性を検証できるようにするデジタル署名スキームを使用する。いくつかの実装では、ノード１０２、１０４が、各ノードが他のノードに機密メッセージを送信できるようにする暗号化スキームを使用する。このようなデジタル署名スキーム及び暗号化スキームはデジタル証明書を含むことができ、又はデジタル証明書に基づいて実行することができる。いくつかのスキーム例では、エンティティノード１０２、１０４及び認証局ノード１１２、１１４が、図２Ａ、図２Ｂ、図３、図４、図５、図６、図７、図８、図９又は図１０のうちのいずれか１つ又は２つ以上に示す、又はこれらの図に関して説明する技術例を使用することができ、或いはこれらの及びその他の技術の変形例を用いてネットワーク１０６内で通信することができる。いくつかの例では、例えば暗号システムの移行中に複数のデジタル署名スキーム又は複数の暗号化スキームが使用される。

【0035】

いくつかの実装では、エンティティノード１０２、１０４及び認証局ノード１１２、１１４が、ネットワーク１０６を介した通信において楕円曲線暗号（ＥＣＣ）スキームを使用する。いくつかのＥＣＣスキームでは、楕円曲線群内の楕円曲線点において情報が暗号化される。楕円曲線群については、例えば素数有限体又は標数２の拡大体などの有限体上の方程式の解を用いて説明することができる。楕円曲線群内の各点は、楕円曲線方程式の解に対応する一対のフィールド要素である。例えば、ＥＣＤＳＡ（楕円曲線デジタル署名アルゴリズム）、ＥＣＮＲ（楕円曲線Ｎｙｂｅｒｇ Ｒｕｅｐｐｅｌ），ＥＣＰＶＳ（楕円曲線Ｐｉｎｔｓｏｖ Ｖａｎｓｔｏｎｅ署名）、ＥＣＱＶ（楕円曲線Ｑｕ Ｖａｎｓｔｏｎｅ）及びＥｄＤＳＡ（エドワーズ曲線デジタル署名アルゴリズム）などの複数のＥＣＣデジタル署名アルゴリズムが標準化されている。いくつかのＥＣＣスキームは、量子攻撃を受けやすいと考えられている。

【0036】

いくつかの実装では、エンティティノード１０２、１０４及び認証局ノード１１２、１１４が、ネットワーク１０６を介した通信において格子ベースの暗号スキームを使用する。格子ベースの暗号スキームのセキュリティは、

内の点格子のいくつかの問題の見掛け硬さ（ａｐｐａｒｅｎｔ ｈａｒｄｎｅｓｓ）に基づくものである。いくつかの格子ベースの暗号スキームは、量子対応の敵対者に対して安全と考えられている。例えば、格子ベースの暗号において典型的に使用される難問のための効率的な量子アルゴリズムは存在しないと考えられている。格子ベースの暗号技術の例としては、ｒｉｎｇ−ｌｅａｒｎｉｎｇ−ｗｉｔｈ−ｅｒｒｏｒｓ−ｂａｓｅｄ（Ｒｉｎｇ−ＬＷＥ）鍵共有プロトコル、Ｒｉｎｇ−ＬＷＥ暗号化プロトコル、ＮＴＲＵアルゴリズム（例えば、ＮＴＲＵＥｎｃｒｙｐｔ、ＮＴＲＵＳｉｇｎなど）、バイモーダル格子署名スキーム（ＢＬＩＳＳ）、ＰＡＳＳアルゴリズム（例えば、ＰＡＳＳＳｉｇｎなど）、ＴＥＳＬＡ（Ｔｉｇｈｔｌｙ−ｓｅｃｕｒｅ，Ｅｆｆｉｃｉｅｎｔ ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅ ｆｒｏｍ Ｓｔａｎｄａｒｄ ＬＡｔｔｉｃｅｓ）プロトコル、及びｒｉｎｇ−ＴＥＳＬＡプロトコルなどが挙げられる。いくつかの格子ベースのスキームは、量子攻撃に耐性を示すと考えられている。

【0037】

図２Ａは、暗号システムの移行を行う企業システム例２００を示すブロック図である。図２Ａに示す企業システム例２００は、公開鍵基盤（ＰＫＩ）２０１と、アプリケーション２０２、２０４、２０６とを含む。図２Ａに示す企業システム例２００は、移行プロセス例２２０に従って移行する。いくつかの実装では、移行プロセス例２２０を用いて、中断を低減又は排除する形で企業インフラを完全にアップグレードすることができる。図２Ｂは、暗号システム間の移行を行うための、図２Ａにおいて使用する移行プロセス例２２０を示すフロー図である。いくつかの例では、別のタイプの移行プロセスを使用することもできる。

【0038】

図２Ａに示す企業システム２００のコンポーネントは、図１に示す通信システム例１００又は別のタイプのシステムに実装することができる。例えば、アプリケーション２０２、２０４、２０６の各々は、エンティティノード１０２、１０４及び認証局ノード１１２、１１４において実行することができる。アプリケーション２０２、２０４、２０６は、公開鍵基盤２０１を使用する様々なセキュア通信モジュールを含むことができる。一例として、アプリケーション２０２は、仮想プライベートネットワーク（ＶＰＮ）アプリケーションとすることができ、アプリケーション２０４は、セキュアウェブブラウジングアプリケーションとすることができ、アプリケーション２０６は、セキュアメールアプリケーションとすることができる。企業システム２００内のアプリケーションは、さらなる又は異なるタイプのソフトウェアアプリケーションを含むこともできる。

【0039】

図２Ａには、段階１アップグレード２２２、段階２アップグレード２２４及び段階３アップグレード２２６という、移行プロセス例２２０内の３つの段階を示す。図２Ｂには、各段階のいくつかの態様を示す。図示の例では、３つの段階の各々の最中に異なるタイプのデジタル証明書を使用する。移行プロセスは、これより少ない段階、さらなる段階、又は異なる段階を含むこともできる。例えば、これらの段階のうちの２つ又は３つ以上を１つの段階に組み合わせることも、或いは１つの段階を複数の段階に分割することもできる。一例として、段階１アップグレード２２２と段階２アップグレード２２４とを移行プロセス２２０の１つの段階として実行することも、或いは段階１アップグレード２２２を省いて段階２アップグレード２２４から移行プロセス２２０を開始することもできる。

【0040】

図２Ａ及び図２Ｂに示す例では、企業システム２００が、古い暗号システムから新しい暗号システムにアップグレードされる。一例として、古い暗号システムは量子脆弱暗号システムとすることができ、新しい暗号システムは耐量子暗号システムとすることができる。一般に、暗号システムは、プロトコルの組とパラメータの組とを定義する。通常、暗号システムによって定義されるプロトコルの組は、例えば署名アルゴリズム又は暗号化アルゴリズムでは、各エンティティによって実行されるステップを含む。通常、暗号システムによって定義されるパラメータの組は、プロトコル内で使用される値又は値の範囲を含む。

【0041】

暗号システムのアップグレードは、プロトコルの組の変更、パラメータの組の変更、又はこれらの両方を含むことができる。いくつかの例では、システムコンポーネントを、あるプロトコルの組内の第１のパラメータの組（例えば、第１の楕円曲線群など）を使用する暗号システムから、同じプロトコルの組内の第２のパラメータの組（例えば、異なる楕円曲線群など）を使用する別の暗号システムにアップグレードすることができる。いくつかの例では、システムコンポーネントを、第１のプロトコルの組（例えば、第１の署名アルゴリズムなど）内の１つのパラメータの組を使用する暗号システムから、第２のプロトコルの組（例えば、第２の署名アルゴリズムなど）内の同じパラメータを使用する別の暗号システムにアップグレードすることができる。いくつかの例では、システムコンポーネントを、第１のパラメータ及びプロトコルの組を使用する暗号システムから、異なるパラメータ及びプロトコルの組を使用する別の暗号システムにアップグレード（例えば、ＥＣＣベースの暗号システムから格子ベースの暗号システムにアップグレード）することができる。一例として、図２Ｂに示す移行プロセス２２０を用いて、いずれか２種類のデジタル署名スキーム間の（例えば、量子脆弱デジタル署名スキームから耐量子デジタル署名スキームへの）移行を行うことができる。

【0042】

図２Ｂに示すように、１又は２以上の個々のアプリケーションに段階１アップグレード２２２が適用される。図２Ａに示す例では、段階１アップグレード２２２がアプリケーション２０２及びアプリケーション２０４に適用され、アプリケーション２０６には適用されない。図２Ｂに示すように、段階１アップグレード２２２を適用すると、アップグレードされたアプリケーションのエンティティ証明書は、新旧の暗号システムの公開鍵を含み、アップグレードされたアプリケーションは、新たな暗号システムを用いて（例えば、デジタル署名プロセス、暗号化プロセス又はその他の識別機構を用いて）識別を行う。認証については、アップグレードされたアプリケーションもアップグレードされていないアプリケーションも古い暗号システムを使用し続ける。アップグレードされていないアプリケーションは、識別にも古い暗号システムを使用し続ける。

【0043】

一例として、企業システムに段階１アップグレード２２２を適用すると、ＶＰＮアプリケーションは企業システム全体を通じて（例えば、全ての企業ノード上で）アップグレードできるのに対し、他のアプリケーション（例えば、セキュアウェブブラウザアプリケーション）はアップグレードされない。段階１アップグレード２２２後、ＶＰＮアプリケーションは、（例えば、クライアントとサーバとの間の）ハンドシェイクチャレンジには新たな（例えば、耐量子）暗号システムを使用し、証明書チェーンの検証には古い（例えば、量子脆弱）暗号システムを使用することができる。いくつかの例では、アップグレードされたＶＰＮアプリケーションは、新たな暗号システムに関連する秘密鍵を用いてハンドシェイクチャレンジに署名できるのに対し、他のアプリケーションは、古い暗号システムに関連する秘密鍵を用いてハンドシェイクチャレンジに署名し続ける。アップグレードされたＶＰＮアプリケーションは、各々が古い暗号システム用と新たな暗号システム用の２つの公開鍵を含むデジタル証明書を使用することができる。例えば、アップグレードされたＶＰＮアプリケーションは、図５に示すデジタル証明書例５０２又は別のデジタル証明書を使用することができる。いくつかの例では、新たな暗号システムに関連する公開鍵は、アップグレードされたアプリケーションのデジタル証明書の拡張領域に挿入されるのに対し、古い暗号システムに関連する公開鍵及び証明書署名は、基本公開鍵及び署名値フィールド内にそれぞれ存在する。アップグレードされたアプリケーションのデジタル証明書を要求するには、例えば図５に関連して説明するような証明書署名要求（ＣＳＲ）を作成することができる。

【0044】

いくつかの実装では、段階１アップグレード２２２の後に、認証局が新たな暗号システムに関連する公開鍵を認識していなくてもよく、これを許容できる理由は、例えばＰＫＩのセキュリティが、段階２アップグレード２２４までは依然として古い暗号システムに関連する公開鍵に依拠しているからである。

【0045】

図２Ｂに示すように、公開鍵基盤に段階２アップグレード２２４が適用される。図２Ａに示す例では、段階２アップグレード２２４が公開鍵基盤２０１に適用される。図２Ｂに示すように、段階２アップグレード２２４を適用すると、エンティティ証明書及びＣＡ証明書は、新旧の暗号システムのための認証局署名を含み、アップグレードされたアプリケーション（すなわち、段階１アップグレード２２２においてアップグレードされたアプリケーション）は、新たな暗号システムを用いて識別及び認証を行う。他のアプリケーション（すなわち、段階１アップグレード２２２においてアップグレードされなかったアプリケーション）は、識別及び認証に古い暗号システムを使用し続ける。

【0046】

いくつかの実装では、段階２アップグレード２２４後に、依存プロトコル（ｒｅｌｙｉｎｇ ｐｒｏｔｏｃｏｌｓ）が全ての利用可能な暗号鍵及びデジタル署名を使用することができる。いくつかの例では、認証プロセスについては依存プロトコルを修正せずに実行することができ、識別プロセスについてはプロトコル修正が必要となり得る。いくつかの例では、認証プロセスについてもプロトコル修正が必要となり得る。

【0047】

（ＶＰＮアプリケーションに段階１アップグレード２２２を適用する）上記の例を続けると、企業システムに段階２アップグレード２２４を適用した場合、公開鍵基盤は企業システム全体を通じて（例えば、全企業ノード上で）アップグレードされるのに対し、いくつかの個々のアプリケーション（例えば、セキュアウェブブラウザアプリケーション）はアップグレードされない。段階２アップグレード２２４後、ＶＰＮアプリケーションは、（例えば、クライアントとサーバとの間の）ハンドシェイクチャレンジ及び証明書チェーンの検証に新たな（例えば、耐量子）暗号システムを使用することができる。いくつかの例では、アップグレードされたＶＰＮアプリケーションは、新たな暗号システムに関連する認証局署名を用いて証明書チェーンを検証できるのに対し、他のアプリケーションは、古い暗号システムに関連する認証局署名を用いて証明書チェーンを検証し続ける。段階２アップグレード２２４後、アップグレードされたＶＰＮアプリケーションは、各々が古い暗号システム用と新しい暗号システム用の２つの公開鍵と２つの認証局署名とを含むデジタル証明書を使用することができる。例えば、アップグレードされたＶＰＮアプリケーションは、図９に示すデジタル証明書例９０２又は別のデジタル証明書を使用することができる。いくつかの例では、新たな暗号システムに関連する公開鍵及び認証局署名は、いずれもアップグレードされたアプリケーションのデジタル証明書の拡張領域に挿入されるのに対し、古い暗号システムに関連する公開鍵及び証明書署名は、基本公開鍵及び署名値フィールド内にそれぞれ存在する。

【0048】

ＰＫＩのアップグレード後に、アップグレードされたアプリケーションのデジタル証明書を要求するには、例えば図９に関連して説明する証明書署名要求例に従って証明書署名要求（ＣＳＲ）を生成することができる。段階２アップグレード２２４後、認証局は、新たな暗号システムのためのプロトコルを実行することができる。従って、エンドエンティティは、証明書の要求時に、新旧の暗号システムに関連するデジタル署名を提供する。その後、認証局は、エンドエンティティが新旧両方の暗号システムに関連する公開鍵を所有していることを検証することができる。

【0049】

いくつかの実装では、ＰＫＩのアップグレード後に、認証局が、証明書署名要求（ＣＳＲ）に応答して、アップグレードされたアプリケーションのデジタル証明書を作成する。いくつかの例では、認証局が、まず新たな暗号システムの秘密鍵を用いてデジタル証明書に署名してこれをプライベート拡張領域に配置し、次に古い暗号システムの秘密鍵を用いてデジタル証明書に署名してこれを基本署名値フィールドに配置する。このような例では、署名階層化の順序により、（段階１アップグレード２２２において）アップグレードされていなかったアプリケーションが（段階２アップグレード２２４の）ＰＫＩアップグレード前のように動作し続けて証明書署名を検証できることを確実にすることができる。例えば、アップグレードされなかったアプリケーションは、証明書署名を検証するために証明書ハッシュを計算する際に全ての拡張領域を含めて証明書全体をハッシュ計算するのに対し、アップグレードされたアプリケーションは、証明書ハッシュを計算する際に基本署名値フィールドを除外してから、新たな暗号システムに関連する認証局署名を検証することができる。

【0050】

図２Ｂに示すように、段階１アップグレード２２２中にアップグレードされなかった残りのアプリケーションには、段階３アップグレード２２６が適用される。図２Ａに示す例では、他のアプリケーション２０２、２０４は既に段階１アップグレード２２２中にアップグレードされているので、アプリケーション２０６に段階３アップグレード２２６が適用される。図２Ｂに示すように、段階３アップグレード２２６を適用すると、エンティティ証明書及びＣＡ証明書は、全てが新たな暗号システムに合わせて構成され、全てのアプリケーションが新たな暗号システムを用いて識別及び認証を行う。

【0051】

いくつかの実装では、企業システムにおいて段階３アップグレード２２６を適用した後には、もはや企業システムにハイブリッド証明書は必要でなくなる。新たな暗号システムに関連するデータオブジェクト（例えば、公開鍵及び認証局署名）をデジタル証明書の基本公開鍵フィールド及び署名値フィールドに配置して、プライベート拡張領域は省略又は無視することができる。ハイブリッド証明書が置換されたら、セキュリティポリシーを用いて企業システム内のハイブリッド証明書サポートをオフにすることができる。

【0052】

いくつかの実装では、企業システムにおいて段階３アップグレード２２６を適用した後に、新たな暗号システムに関連する公開鍵及び署名がデジタル証明書のプライベート拡張領域に残る。いくつかの実装では、企業システムにおいて段階３アップグレード２２６を適用した後に、古い暗号システムに関連する公開鍵及び署名がデジタル証明書のプライベート拡張領域に移される。古い暗号システムに関連する公開鍵及び署名の保持は、例えばＳ／ＭＩＭＥを使用するセキュア電子メールアプリケーションの場合に有用となり得る。例えば、失効していないエンティティ証明書については、そのエンティティが署名したメッセージを証明書の失効まで認証するように意図することができる。新たな公開鍵でユーザ証明書を再発行する場合には、合致する（古い）秘密鍵によって署名されたユーザメッセージを引き続き認証できるように古い公開鍵も含めることができる。このような場合、古い公開鍵は、その元々の有効期限に関連することができる。

【0053】

いくつかの実装では、移行プロセス例２２０が、エンドエンティティ及び認証局が異なるデジタル署名アルゴリズムを使用するシナリオに対応することができる。例えば、認証局が（例えば、Ｌｅｉｇｈｔｏｎ Ｍｉｃａｌｉ Ｓｉｇｎａｔｕｒｅｓ又はＸＭＳＳなどの）ハッシュベースのデジタル署名アルゴリズムを用いてデジタル証明書に署名する一方で、エンドエンティティは別のタイプのデジタル署名アルゴリズムを用いてメッセージに署名することができる。

【0054】

いくつかの実装では、公開鍵基盤２０１がＸ．５０９証明書を使用し、このＸ．５０９証明書のプライベート拡張領域に、新たな暗号システムに関連するデータオブジェクト（例えば、公開鍵及び認証局署名）が挿入される。このような場合、アップグレードに気付いてないシステムコンポーネントはプライベート拡張領域を無視することができ、従って新たな暗号システムに関連するデータオブジェクトがこのようなシステムコンポーネントに影響を与えることはない。

【0055】

図３は、複数の暗号システムのデジタル証明書を発行するプロセス例３００を示すフロー図である。プロセス例３００は、例えばネットワークを介して情報を交換できるコンピュータシステムによって実行することができる。例えば、図１に示す通信システム例１００又は別のタイプのシステムでは、プロセス３００の動作をエンティティノードのいずれか（１０２又は１０４）、及び認証局ノードのいずれか（１１２又は１１４）が実行することができる。

【0056】

図３に示すプロセス例３００は、エンティティ３０２によって実行される動作と、認証局３０４によって実行される動作とを含む。図示の例では、エンティティ３０２及び認証局３０４が、公開鍵基盤（ＰＫＩ）内の２つの異なるエンティティを表す。認証局３０４は、例えばルート認証局又は下位の認証局とすることができる。エンティティ３０２は、下位の認証局、又はＰＫＩ内の他のいずれかのタイプのエンティティ（例えば、ユーザ、ユーザアカウント、装置又は機械、ソフトウェアモジュール又はその他のタイプのエンティティ）とすることができる。図３に示す例では、認証局３０４がエンティティ３０２にデジタル証明書を発行する。プロセス３００において発行されるデジタル証明書は、例えばエンドエンティティ証明書又はＣＡ証明書とすることができる。

【0057】

いくつかの実装では、プロセス例３００を用いて、第１の暗号システムのためのデータオブジェクト（例えば、公開鍵、認証局署名など）と、第２の異なる暗号システムのためのデータオブジェクト（例えば、公開鍵、認証局署名など）とを含むデジタル証明書を発行する。例えば、プロセス例３００を用いて、図５、図６、図７、図８、図９又は図１０に示すデジタル証明書又は別のタイプのデジタル証明書のうちの１つ又は２つ以上を発行することができる。プロセス例３００において発行されるデジタル証明書は、第１の暗号システムと第２の暗号システムとの間の１又は２以上の移行段階中に使用されるハイブリッドデジタル証明書とすることができる。例えば、プロセス例３００において発行されるデジタル証明書は、段階１アップグレード２２２、段階２アップグレード２２４又は別のタイプの移行段階後に、図２Ａに示すシステムコンポーネント例のうちの１つ又は２つ以上が使用することができる。いくつかの例では、第１の暗号システムが量子脆弱暗号システムであり、第２の暗号システムが耐量子暗号システムである。

【0058】

プロセス例３００は、さらなる又は異なるエンティティによって実行される動作を含むさらなる又は異なる動作を含むことができ、これらの動作は、図示の順序又は別の順序で実行することができる。いくつかの例では、図３に示す動作のうちの１つ又は２つ以上が、複数の動作、サブプロセス又は他のタイプのルーチンを含むプロセスとして実装される。いくつかの例では、動作を組み合わせ、並行して実行し、反復又は別様に繰り返し、或いは別の形で実行することもできる。

【0059】

いくつかの例では、プロセス３００の１又は２以上の態様が、例えば図１に示す量子対応の敵対者１０８などの量子対応の敵対者に対して安全である。例えば、いくつかの例では、プロセス例３００が、エンティティ３０２と認証局３０４との間で交換される公開情報にアクセスできる量子対応の敵対者が実行し得る特定のタイプの攻撃又はその他のプロセスに対して安全である。いくつかの例では、プロセス３００の１又は２以上の態様が、量子コンピュータ又は他の量子リソースにアクセスできない旧式対応の敵対者に対して安全である。

【0060】

３１０において、エンティティ３０２が、第１の暗号システムに関連する第１の鍵対（第１の秘密鍵及び第１の公開鍵）を取得する。３１２において、エンティティ３０２は、第２の暗号システムに関連する第２の鍵対（第２の秘密鍵及び第２の公開鍵）を取得する。一例として、エンティティ３０２は、３１０においてＥＣＣベースの暗号システムに関連する鍵対を取得することができ、３１２において格子ベースの暗号システムに関連する鍵対を取得することができる。これらの鍵対は、例えばメモリ又は遠隔装置から読み出すことによって、或いは鍵導出プロトコル又は別のタイプのプロセスを実行することによって取得することができる。

【0061】

３１４において、エンティティ３０２が証明書要求のフィールドに挿入を行う。証明書要求は、例えば証明書署名要求（ＣＳＲ）又は別のタイプの証明書要求とすることができる。例えば、エンティティ３０２は、図５、図７又は図９に示すタイプのＣＳＲ又は別のタイプのＣＳＲを生成することができる。いくつかの例では、証明書要求が、第１の暗号システムに関連する第１の公開鍵と、第２の暗号システムに関連する第２の公開鍵とを含む。第１の公開鍵は、証明書要求の公開鍵フィールドに含めることができ、第２の公開鍵は、証明書要求の拡張領域に含めることができる。公開鍵は、別の形で証明書要求に含めることもできる。いくつかの例では、証明書要求が、第２の暗号システムに関連する第２の公開鍵を含まない。

【0062】

３１６において、エンティティ３０２が証明書要求に署名する。いくつかの実装では、例えば図５又は図７に示すように単一のデジタル署名が証明書要求に適用される。例えば、エンティティ３０２は、第１の暗号システムに関連する第１の公開鍵及びデジタル署名アルゴリズムを用いて証明書要求署名を生成することができる。いくつかの実装では、例えば図９に示すように複数のデジタル署名が証明書要求に適用される。例えば、エンティティ３０２は、第２の暗号システムに関連する第２の公開鍵及びデジタル署名アルゴリズムを用いて第２の証明書要求署名を生成することができる。いくつかの例では、第１のデジタル署名を適用する前に第２のデジタル署名を適用することができる。

【0063】

３１８において、エンティティ３０２が証明書要求を認証局３０４に送信し、３２０において、認証局３０４がエンティティ３０２から証明書要求を受け取る。図３に示す例では、エンティティ３０２が直接認証局３０４に情報を送信することができ、或いはエンティティ３０２は、例えばサーバを通じて間接的に送信を開始することもできる。情報の全部又は一部は、公開チャネルを介して送信することができ、量子対応の敵対者又は別のタイプの敵対者はこれを観察することができる。

【0064】

３２２において、認証局３０４は、証明書要求上の１又は２以上の署名を検証する。証明書要求が単一の証明書要求署名を含む場合、認証局３０４は、エンティティ３０２の第１の公開鍵と、第１の暗号システムに関連するデジタル署名アルゴリズムとを用いて証明書要求署名を検証することができる。証明書要求が第２の証明書要求署名も含む場合、認証局３０４は、エンティティの第２の公開鍵と、第２の暗号システムに関連するデジタル署名アルゴリズムとを用いて第２の証明書要求署名を検証することができる。

【0065】

３２４において、認証局３０４がデジタル証明書のフィールドに挿入を行う。例えば、認証局３０４は、図５、図７又は図９に示すタイプのデジタル証明書、又は別のタイプのデジタル証明書を生成することができる。いくつかの例では、例えば証明書要求又はその他のデータオブジェクトに基づいて予め挿入された１又は２以上のフィールドを含むデジタル証明書が生成される。１又は２以上の未挿入のフィールドを含むデジタル証明書を生成し、後で認証局３０４がデジタル証明書のフィールドに挿入を行うこともできる。いくつかの例では、デジタル証明書が、第１の暗号システムに関連する第１の公開鍵と、第２の暗号システムに関連する第２の公開鍵とを含む。認証局３０４は、デジタル証明書の公開鍵フィールドにエンティティの第１の公開鍵を挿入し、デジタル証明書の拡張領域にエンティティの第２の公開鍵を挿入することができる。公開鍵は、別の形でデジタル証明書に含めることもできる。

【0066】

３２６において、認証局３０４がデジタル証明書に署名する。いくつかの実装では、例えば図５に示すように単一のデジタル署名がデジタル証明書に適用される。例えば、認証局３０４は、第１の暗号システムに関連する第１の認証局秘密鍵を用いてデジタル署名を生成することができる。いくつかの実装では、例えば図７又は図９に示すように複数のデジタル署名がデジタル証明書に適用される。例えば、認証局３０４は、第２の暗号システムに関連する第２の認証局秘密鍵を用いて（例えば、第１の認証局秘密鍵を用いて第１のデジタル署名を適用する前に）第２のデジタル署名を生成することができる。第１のデジタル署名はデジタル証明書の署名値フィールドに含めることができ、第２のデジタル署名はデジタル証明書の拡張領域に含めることができる。

【0067】

いくつかの実装では、３２６において、認証局３０４が第１の認証局秘密鍵を用いて第１のデジタル署名を生成し、この第１のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２の公開鍵を有するバージョンのデジタル証明書から生成される。第１のデジタル署名は、（例えば、図５に示す例における）第２のデジタル署名を含まないバージョンのデジタル証明書から生成することもできる。次に、認証局３０４は、デジタル証明書の署名値フィールドに第１のデジタル署名を挿入することができる。

【0068】

いくつかの実装では、３２６において、認証局３０４が、第２の認証局秘密鍵を用いて第２のデジタル署名を生成し、この第２のデジタル署名は、公開鍵フィールドに第１の公開鍵を有するバージョンのデジタル証明書から生成される。第２のデジタル署名は、（例えば、図７に示す例における）第２の公開鍵も第１のデジタル署名も含まないバージョンのデジタル証明書から生成することができる。次に、認証局３０４は、デジタル証明書の拡張領域に第２のデジタル署名を挿入し、第１の認証局秘密鍵を用いて第１のデジタル署名を生成することができる。この場合、第１のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２のデジタル署名を有するバージョンのデジタル証明書から生成され、その後、認証局３０４は、デジタル証明書の署名値フィールドに第１のデジタル署名を挿入することができる。

【0069】

いくつかの実装では、３２６において、認証局３０４が、第２の認証局秘密鍵を用いて第２のデジタル署名を生成し、この第２のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２の公開鍵を有するバージョンのデジタル証明書から生成される。次に、認証局３０４は、デジタル証明書の拡張領域に第２のデジタル署名を挿入し、第１の認証局秘密鍵を用いて第１のデジタル署名を生成することができる。この場合、第１のデジタル署名は、（例えば、図９に示す例における）公開鍵フィールドに第１の公開鍵を、拡張領域に第２の公開鍵と第２のデジタル署名とを有するバージョンのデジタル証明書から生成される。その後、認証局３０４は、デジタル証明書の署名値フィールドに第１のデジタル署名を挿入することができる。

【0070】

３２８において、認証局３０４がデジタル証明書をエンティティ３０２に送信し、３３０において、エンティティ３０２が認証局３０４からデジタル証明書を受け取る。３３２において、エンティティ３０２がデジタル証明書を使用する。例えば、エンティティ３０２は、図４に示す認定エンティティ４０２として、又は別の形でデジタル証明書を使用することができる。

【0071】

図４は、複数の暗号システムと共にデジタル証明書を使用するプロセス例４００を示すフロー図である。プロセス例４００は、例えばネットワークを介して情報を交換できるコンピュータシステムによって実行することができる。例えば、プロセス４００の動作は、図１に示す通信システム例１００又は別のタイプのシステム内のいずれかのノード（例えば、エンティティノード１０２、１０４）が実行することができる。

【0072】

図４に示すプロセス例４００は、認定エンティティ４０２によって実行される動作と、依存エンティティ４０４によって実行される動作とを含む。図示の例では、認定エンティティ４０２及び依存エンティティ４０４が、公開鍵基盤（ＰＫＩ）内の２つの異なるエンティティを表し、これらはＰＫＩにおけるいずれかのタイプのエンティティ（例えば、ユーザ、ユーザアカウント、装置又は機械、ソフトウェアモジュール又はその他のタイプのエンティティ）とすることができる。例えば、依存エンティティ４０４はサーバとすることができ、認定エンティティ４０２は、サーバによってサービスを提供されるクライアントとすることができ、或いはこの逆とすることもできる。別の例として、認定エンティティ４０２及び依存エンティティ４０４をネットワーク内のピアとすることもできる。

【0073】

プロセス例４００は、第１の暗号システムのためのデータオブジェクト（例えば、公開鍵、認証局署名など）と、第２の異なる暗号システムのためのデータオブジェクト（例えば、公開鍵、認証局署名など）とを使用する。いくつかの例では、第１の暗号システムが量子脆弱暗号システムであり、第２の暗号システムが耐量子暗号システムである。図４に示すプロセス４００において使用されるデジタル証明書は、例えば図３に示すプロセス３００において発行されるデジタル証明書、図５、図６、図７、図８、図９又は図１０に示すデジタル証明書のうちの１つ又は２つ以上、又は別のタイプのデジタル証明書とすることができる。プロセス例４００は、例えば第１の暗号システムと第２の暗号システムとの間の１又は２以上の移行段階中（例えば、図２Ａ及び図２Ｂに示す段階１アップグレード２２２又は段階２アップグレード２２４の後）に、ハイブリッドデジタル証明書を使用することができる。

【0074】

プロセス例４００は、さらなる又は異なるエンティティによって実行される動作を含むさらなる又は異なる動作を含むこともでき、これらの動作は、図示の順序又は別の順序で実行することができる。いくつかの例では、図４に示す動作のうちの１つ又は２つ以上が、複数の動作、サブプロセス又は他のタイプのルーチンを含むプロセスとして実装される。いくつかの例では、動作を組み合わせ、並行して実行し、反復又は別様に繰り返し、或いは別の形で実行することができる。

【0075】

いくつかの例では、プロセス４００の１又は２以上の態様が、例えば図１に示す量子対応の敵対者１０８などの量子対応の敵対者に対して安全である。例えば、いくつかの例では、プロセス例４００が、認定エンティティ４０２と依存エンティティ４０４との間で交換される公開情報にアクセスできる量子対応の敵対者が実行し得る特定のタイプの攻撃又は他のプロセスに対して安全である。いくつかの例では、プロセス４００の１又は２以上の態様が、量子コンピュータ又は他の量子リソースにアクセスできない旧式対応の敵対者に対して安全である。

【0076】

４０８において、認定エンティティ４０２がデジタル証明書を取得する。例えば、認定エンティティ４０２は、メモリ又は遠隔装置からデジタル証明書を読み出すことによって、或いは認証局にデジタル証明書を要求することなどによってデジタル証明書を取得することができる。いくつかの例では（例えば、図９に示す例では）、デジタル証明書の拡張領域が、エンティティの第２の公開鍵と認証局の第２のデジタル署名の両方を含む。いくつかの例では（例えば、図５に示す例では）、デジタル証明書の拡張領域が、エンティティの第２の公開鍵を含んで認証局の第２のデジタル署名を含まない。いくつかの例では（例えば、図７に示す例では）、デジタル証明書の拡張領域が、認証局の第２のデジタル署名を含んでエンティティの第２の公開鍵を含まない。

【0077】

認定エンティティ４０２がデジタル証明書を取得した後に、認定エンティティ４０２及び依存エンティティ４０４は、１又は２以上のサブプロセスを実行することができる。図４に示すように、認定エンティティ４０２及び依存エンティティ４０４は、デジタル署名プロセス４２０又は暗号化プロセス４３０（又はこれらの両方）を実行する前に認証プロセス４１０を実行することができる。サブプロセスは、図示の順序で実行することができ、又はいくつかの例では別の順序で実行することができる。いくつかの例では、デジタル署名プロセス４２０又は暗号化プロセス４３０（又はこれらの両方）を省略し、又は別の順序で実行することもできる。図４に示すサブプロセス例では、認定エンティティ４０２及び依存エンティティ４０４が互いに直接情報を送信することができ、或いはこれらのエンティティは、例えばサーバを通じて間接的に送信を開始することもできる。情報の全部又は一部は、公開チャネルを介して送信することができ、量子対応の敵対者又は別のタイプの敵対者はこれを観察することができる。

【0078】

認証プロセス例４１０を用いて、デジタル証明書が有効なエンティティに属することを確認することができる。図４に示すように、４１２において、認定エンティティ４０２が依存エンティティ４０４にデジタル証明書を送信し、４１４において、依存エンティティ４０４が認定エンティティ４０２からデジタル証明書を受け取る。依存エンティティ４０４は、認定エンティティ４０２を認証するために、４１６においてデジタル証明書を検証する。いくつかの例では、デジタル証明書が、第２の暗号システムに関連する認証局デジタル署名を含む拡張領域を含み、依存エンティティ４０４は、（例えば、図８又は図１０に関して適宜説明するように）第２の暗号システムに関連するアルゴリズムを用いてデジタル証明書を検証する。いくつかの例では、依存エンティティ４０４が、（例えば、図６に関して説明するように）第１の暗号システムに関連するアルゴリズムを用いてデジタル証明書を検証する。いくつかの実装では、４１６におけるデジタル証明書の検証が、証明書チェーンの検証、又は他の複数のタイプのチェックを行うことを含む。依存エンティティ４０４は、４１６においてデジタル証明書を検証した後、デジタル証明書内のユーザアイデンティティがＰＫＩ内の有効なエンティティに属することを確信する。

【0079】

いくつかの実装では、４１６において、依存エンティティ４０４が、デジタル証明書の拡張領域に少なくとも部分的に基づいて証明書概要を生成し、この証明書概要と認証局公開鍵とを用いてデジタル証明書を検証する。いくつかの例では、証明書概要と第１の暗号システムの認証局公開鍵とを用いてデジタル証明書が検証される。このような場合、証明書概要は、拡張領域に第２の認証局署名を含むバージョンのデジタル証明書に基づいて生成することができる。いくつかの例では、証明書概要と第２の暗号システムの認証局公開鍵とを用いてデジタル証明書が検証される。このような場合、証明書概要は、第１の認証局署名を含まない（例えば、この署名は、証明書概要の生成前に削除することができる）バージョンのデジタル証明書に基づいて生成することができる。

【0080】

デジタル署名プロセス例４２０又は暗号化プロセス例４３０は、認定エンティティ４０２が実際にデジタル証明書内の検証済みユーザアイデンティティの所有者であることを確認するための識別機構として使用することができる。認定エンティティ４０２は、依存エンティティ４０４にこのような確認を提供するために、デジタル証明書内の公開鍵に対応する秘密鍵を所有していることを依存エンティティ４０４に対して証明する。秘密鍵の所有は、例えばチャレンジ−応答プロトコル又は別のタイプの証明を用いて証明することができる。

【0081】

デジタル署名プロセス４２０は、認証された通信にデジタル署名アルゴリズムを使用することを含むことができる。いくつかの例では、デジタル署名アルゴリズムが第１の暗号システムに関連し、従って第１の暗号システムに関連する鍵対を使用する。いくつかの例では、デジタル署名アルゴリズムが第２の暗号システムに関連し、従って第２の暗号システムに関連する鍵対を使用する。いくつかの例では、デジタル署名プロセス４２０が、例えばＶＰＮアプリケーション、セキュアウェブブラウザアプリケーション、セキュアメールアプリケーション、又は別のタイプのアプリケーションなどの１又は２以上のアプリケーションによって実行される。

【0082】

図４に示すように、４２２において、認定エンティティ４０２がデジタル署名を生成する。デジタル署名は、デジタル署名アルゴリズムと秘密鍵とを用いてメッセージに基づいて生成することができる。いくつかの例では、デジタル証明書が、第２の暗号システムに関連する公開鍵を含む拡張領域を含み、認定エンティティ４０２は、（例えば、図５又は図９に関して適宜説明するように）第２の暗号システムに関連する秘密鍵を用いてデジタル署名を生成する。いくつかの例では、認定エンティティ４０２が、（例えば、図７に関して説明するように）第１の暗号システムに関連する秘密鍵を用いてデジタル署名を生成する。デジタル署名は、ランダム値、チャレンジ値又は別のタイプのデータオブジェクトに基づいて生成することができる。

【0083】

図４に示すように、４２４において、認定エンティティ４０２が依存エンティティ４０４にデジタル証明書を送信し、４２６において、依存エンティティ４０４が認定エンティティ４０２からデジタル証明書を受け取る。４２８において、依存エンティティ４０４がデジタル証明書を検証する。４２８におけるデジタル証明書の検証は、第１の暗号システム又は第２の暗号システムのいずれかに関連するデータオブジェクトを用いて実行することができる。いくつかの例では、デジタル証明書が、第２の暗号システムに関連する公開鍵を含む拡張領域を含み、依存エンティティ４０４は、（例えば、図５又は図９に関して適宜説明するように）第２の暗号システムに関連する公開鍵を用いてデジタル署名を検証する。いくつかの例では、依存エンティティ４０４が、（例えば、図７に関して説明するように）第１の暗号システムに関連する公開鍵を用いてデジタル署名を検証する。

【0084】

暗号化プロセス４３０は、暗号化アルゴリズムを機密通信に使用することを含むことができる。いくつかの例では、暗号化アルゴリズムが第１の暗号システムに関連し、従って第１の暗号システムに関連する鍵対を使用する。いくつかの例では、暗号化プロセス４３０を、例えばウェブブラウジング用途、電子メール用途、ボイスオーバＩＰ（ＶｏＩＰ）用途、又は別のタイプのインターネット用途で、トランスポート層セキュリティ（ＴＬＳ）プロトコル内で使用することができる。いくつかの例では、暗号化プロセス４３０を別のタイプのアプリケーション又はシステムにおいて使用することができる。

【0085】

いくつかの例では、暗号化アルゴリズムが第２の暗号システムに関連し、従って第２の暗号システムに関連する鍵対を使用する。いくつかの例では、暗号化プロセス４３０が、例えばＶＰＮアプリケーション、セキュアウェブブラウザアプリケーション、セキュアメールアプリケーション、又は別のタイプのアプリケーションなどの１又は２以上のアプリケーションによって実行される。

【0086】

図４に示す例では、４３２において、依存エンティティ４０４がメッセージを暗号化する。暗号化メッセージは、暗号化アルゴリズムと公開鍵とを用いて生成することができる。いくつかの例では、依存エンティティ４０４が、メッセージを対称鍵で暗号化し、対称鍵を公開鍵で暗号化することができる。いくつかの例では、依存エンティティ４０４が、第２の暗号システムに関連する公開鍵を用いて暗号化メッセージを生成する。いくつかの例では、依存エンティティ４０４が、第１の暗号システムに関連する公開鍵を用いて暗号化メッセージを生成する。

【0087】

図４に示すように、４３４において、依存エンティティ４０４が認定エンティティ４０２に暗号化メッセージを送信し、４３６において、認定エンティティ４０２が依存エンティティ４０４から暗号化メッセージを受け取る。４３８において、認定エンティティ４０２が秘密鍵を用いてメッセージを復号する。いくつかの例では、認定エンティティ４０２が、対称鍵を秘密鍵で復号した後に、対称鍵でメッセージを復号することができる。依存エンティティ４０４が認定エンティティ４０２の第１の公開鍵を用いてメッセージを暗号化した場合、認定エンティティ４０２は、第１の暗号システムに関連する秘密鍵を用いてメッセージを復号する。依存エンティティ４０４が認定エンティティ４０２の第２の公開鍵を用いてメッセージを暗号化した場合、認定エンティティ４０２は、第２の暗号システムに関連する秘密鍵を用いてメッセージを復号する。

【0088】

デジタル署名プロセス４２０及び暗号化プロセス４３０は、様々な暗号鍵又は共有秘密鍵を使用することができる。いくつかの例では、デジタル証明書からの認定エンティティの（第１の暗号システム又は第２の暗号システムに関連する）長期公開鍵を用いて、４２８において署名を検証し、又は４３２においてメッセージを暗号化し、認定エンティティの対応する長期秘密鍵を用いて、４２２において署名を生成し、又は４３８においてメッセージを復号する。いくつかの例では、（短期秘密鍵及び短期公開鍵を含む）短期鍵対を導出し、デジタル署名プロセス４２０又は暗号化プロセス４３０において使用することができる。いくつかの例では、暗号化プロセス４３０において対称鍵を生成して使用することができる。

【0089】

いくつかの例では、デジタル署名プロセス４２０において署名される、又は暗号化プロセス４３０において暗号化されるメッセージが、ソフトウェアアプリケーションによって読み込み、編集、レンダリング、操作又は別様に処理することができる電子メールメッセージ、電子文書又は電子ファイルである。いくつかの例では、このメッセージが、例えば他のメッセージの暗号ハッシュ又は別のタイプの概要などの、別のメッセージの概要である。いくつかの例では、このメッセージが、ハードウェアによって読み込み、編集、レンダリング、操作又は別様に処理することができるデータパケット又はデータオブジェクトである。例えば、このメッセージは、ハードウェア又はファームウェアに実装されたシグナリングシステムによって処理することができる。例えば、このメッセージは、チャレンジ値、ランダム値、電子メール、短期鍵、対称セッション鍵、プリマスタシークレット、又は別のタイプのメッセージとすることができる。

【0090】

図５は、認証局が証明書署名要求（ＣＳＲ）に基づいて生成するデジタル証明書例５０２を示すブロック図である。図５に示すデジタル証明書例５０２は、別の（例えば、量子脆弱）暗号システムの公開鍵に加えて、耐量子暗号システムの公開鍵を含む。

【0091】

デジタル証明書５０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する第１の公開鍵５１６と、第２の異なる暗号システムに関連する第２の公開鍵５２０とを含む証明書要求に基づいて生成される。図示の例では、第２の暗号システムが耐量子（ＱＲ）暗号システムである。証明書要求は、基本フィールドと拡張領域とを含むことができる。証明書要求の基本フィールドは、主体者フィールドに主体者情報（例えば、ユーザアイデンティティ）を、発行者フィールドに発行者情報（例えば、認証局アイデンティティ）を、有効期間フィールドに有効期間情報を、及び公開鍵フィールドに第１の公開鍵５１６を含むことができる。証明書要求の拡張領域は、第２の（ＱＲ）公開鍵５２０を含むことができる。証明書要求を生成するエンティティは、第１の暗号システムを用いて証明書要求に署名することができる。例えば、第１の公開鍵５１６に関連する秘密鍵を用いて、証明書要求に適用されるデジタル署名を生成することができる。

【0092】

図５に示すデジタル証明書５０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する第１の公開鍵５１６と、第２の異なる暗号システムに関連する第２の公開鍵５２０とを含むデジタル証明書の例である。図示の例では、第２の暗号システムが耐量子（ＱＲ）暗号システムである。

【0093】

図５に示すように、デジタル証明書５０２は、基本フィールド５０４と拡張領域５０６とを含む。基本フィールド５０４は、主体者フィールドに主体者情報５１０（例えば、ユーザアイデンティティ）を、発行者フィールドに発行者情報５１２（例えば、認証局アイデンティティ）を、有効期間フィールドに有効期間情報５１４を、公開鍵フィールドに第１の公開鍵５１６を、及び署名値フィールドに認証局署名５３０を含む。拡張領域５０６は、証明書要求からの第２の（ＱＲ）公開鍵５２０を含む。デジタル証明書５０２は、さらなる又は異なるフィールド、拡張領域又はその他の情報を含むこともできる。

【0094】

図５に示すデジタル証明書例５０２は、認証局が証明書要求例に応答して生成する。図５の左側に示すように、認証局は、公開鍵フィールドに第１の公開鍵５１６を、拡張領域に第２の公開鍵５２０を含むバージョンのデジタル証明書５０２に基づいて認証局署名５３０を生成する。その後、図５の右側に示すように、デジタル証明書５０２の署名値フィールドに認証局署名５３０を挿入する。

【0095】

いくつかの例では、デジタル証明書５０２が、要求者及び発行者によって実行される証明書要求及び作成プロセスにおいて生成され、いくつかの例では、このプロセスが以下のように進行することができる。要求者は、第１の公開鍵５１６及び関連する第１の秘密鍵を含む、第１の暗号システムに関連する第１の鍵対を生成する。要求者は、ＱＲ公開鍵５２０及び関連するＱＲ秘密鍵を含む、第２の（耐量子）暗号システムに関連する第２の（ＱＲ）鍵対を生成する。要求者は、証明書署名要求（ＣＳＲ）の拡張領域にＱＲ公開鍵５２０を挿入する。要求者は、ＣＳＲの基本フィールドの公開鍵フィールドに第１の公開鍵５１６を挿入する。要求者は、ＣＳＲの他の標準的な基本フィールド及び拡張領域に挿入を行う。要求者は、挿入済みのＣＳＲに基づいて、要求者の第１の秘密鍵を用いてデジタル署名を生成する。要求者は、署名済みＣＳＲを発行者に送信する。発行者は、要求者から署名済みＣＳＲを受け取って要求者を調べる。発行者は、要求者のデジタル署名を検証して、要求者が第１の公開鍵５１６に合致する秘密鍵を所有していることを確認する。発行者は、ＣＳＲの他の全ての属性を検証して更新を適用することができる。発行者は、公開鍵フィールドに第１の公開鍵５１６を挿入し、拡張領域５０６にＱＲ公開鍵５２０を挿入することを含め、デジタル証明書５０２の１又は２以上のフィールドに挿入を行う。次に、発行者は、第１の暗号システムに関連する認証局秘密鍵を用いて、デジタル証明書５０２に基づいて認証局署名５３０を生成する。発行者は、基本フィールド５０４の署名値フィールドに認証局署名５３０を挿入する。いくつかの例では、証明書要求及び作成プロセスがさらなる又は異なるステップを含むことも、或いは別の形で進行することもできる。

【0096】

いくつかの例では、デジタル証明書５０２、又はデジタル証明書５０２からの情報が、例えば図４に示すデジタル署名プロセス４２０などのデジタル署名プロセスにおいて使用される。図５に示すデジタル証明書例５０２が、証明書所有者と別のエンティティとの間のデジタル署名プロセスの基礎である場合、いくつかの例では、識別プロセスが以下のように進行することができる。証明書所有者は、デジタル証明書５０２内の２つの公開鍵の一方に関連する証明書所有者の秘密鍵でメッセージに署名する。次に、結果として得られたデジタル署名が他方のエンティティに送信され、他方のエンティティは、適切な公開鍵（第１の公開鍵５１６又はＱＲ公開鍵５２０のいずれか）を用いてデジタル署名を検証する。いくつかの例では、デジタル署名が、証明書所有者によって第２の（耐量子）暗号システム及びＱＲ公開鍵５２０に関連する証明書所有者のＱＲ秘密鍵を用いて生成され、このような場合、他方のエンティティは、ＱＲ公開鍵５２０を用いてデジタル署名を検証する。いくつかの例では、デジタル署名が、第１の暗号システム及び第１の公開鍵５１６に関連する証明書所有者の第１の秘密鍵を用いて生成され、このような場合、他方のエンティティは、第１の公開鍵５１６を用いてデジタル署名を検証する。いくつかの例では、デジタル証明書５０２、又はデジタル証明書５０２からの情報を用いて、別のタイプのデジタル署名プロセスを実行することもできる。

【0097】

いくつかの例では、デジタル証明書５０２、又はデジタル証明書５０２からの情報が、例えば図４に示す暗号化プロセス４３０などの暗号化プロセスにおいて使用される。図５に示すデジタル証明書例５０２が暗号化プロセスの基礎である場合、プロセスは以下のように進行することができる。暗号化を行うエンティティは、デジタル証明書５０２内の２つの公開鍵の一方を用いてメッセージを暗号化する。次に、この暗号化メッセージが証明書所有者に送信され、証明書所有者が、（第１の公開鍵５１６又はＱＲ公開鍵５２０のいずれかに関連する）適切な秘密鍵を用いてメッセージを復号する。いくつかの例では、メッセージがＱＲ公開鍵５２０を用いて暗号化され、第２の（耐量子）暗号システムに関連する、証明書所有者の関連するＱＲ秘密鍵を用いて復号される。いくつかの例では、メッセージが第１の公開鍵５１６を用いて暗号化され、第１の暗号システムに関連する、証明書所有者の関連する第１の秘密鍵を用いて復号される。いくつかの例では、暗号化を行うエンティティが、メッセージを対称鍵で暗号化した後に一方の公開鍵で対称鍵を暗号化し、この場合、証明書所有者は、秘密鍵で対称鍵を復号し、この対称鍵でメッセージを復号することができる。いくつかの例では、デジタル証明書５０２、又はデジタル証明書５０２からの情報を用いて、別のタイプの暗号化プロセスを実行することもできる。

【0098】

図６は、別の（例えば、量子脆弱）暗号システムの公開鍵に加えて、耐量子暗号システムの公開鍵を含むデジタル証明書を伴う証明書チェーン例６００を示すブロック図である。図６に示す証明書チェーン例６００は、ルートＣＡ証明書６０２、中間ＣＡ証明書６０４、及びエンドエンティティ証明書６０６という３つのデジタル証明書を含む。エンドエンティティ証明書６０６は、図５に示すデジタル証明書例５０２として作成してフォーマットできるデジタル証明書の例である。いくつかの例では、図６に示すデジタル証明書のうちの１つ又は２つ以上を別の形で作成してフォーマットすることもできる。図６に示す例では、ルートＣＡ証明書６０２が、ルート認証局の独自の公開鍵を用いて検証できる自己署名証明書であり、中間ＣＡ証明書６０４及びエンドエンティティ証明書６０６が、適切な認証局公開鍵を用いて検証できるＣＡ署名証明書である。

【0099】

図６に示す例では、ルートＣＡ証明書６０２がルート認証局に属する。ルート認証局は、第１の暗号システムに関連する第１の鍵対を有する。第１の鍵対は、第１の認証局秘密鍵６２０と第１の認証局公開鍵６１４とを含む。ルートＣＡ証明書例６０２は、発行者情報６１０（ルートＣＡのアイデンティティ）と、主体者情報６１２（ルートＣＡのアイデンティティ）と、第１の認証局公開鍵６１４と、第１の暗号システムに関連する第１の認証局署名６１６と、拡張領域６１８とを含む。図６に示すように、第１の認証局秘密鍵６２０を用いて第１の認証局署名６１６を生成する。ルートＣＡ証明書６０２は、さらなる又は異なる情報を含むこともできる。

【0100】

図６に示す例では、中間ＣＡ証明書６０４が中間認証局に属する。中間認証局は、第１の暗号システムに関連する第２の鍵対を有する。第２の鍵対は、第２の認証局秘密鍵６４０と、第２の認証局公開鍵６３４とを含む。中間ＣＡ証明書例６０４は、発行者情報６３０（ルートＣＡのアイデンティティ）と、主体者情報６３２（中間ＣＡのアイデンティティ）と、第２の認証局公開鍵６３４と、第１の暗号システムに関連する第２の認証局署名６３６と、拡張領域６３８とを含む。図６に示すように、第１の認証局秘密鍵６２０を用いて第２の認証局署名６３６を生成する。中間ＣＡ証明書６０４は、さらなる又は異なる情報を含むこともできる。

【0101】

図６に示す例では、エンドエンティティ証明書６０６がＳＳＬサーバエンティティに属する。ＳＳＬサーバエンティティは、第１の暗号システムに関連する第３の鍵対と、第２の（耐量子）暗号システムに関連する第４の鍵対とを有する。第３の鍵対は、第１のエンティティ秘密鍵６６０と、第１のエンティティ公開鍵６５４とを含む。第４の鍵対は、第２の（ＱＲ）エンティティ秘密鍵６６１と、第２の（ＱＲ）エンティティ公開鍵６５８とを含む。

【0102】

エンドエンティティ証明書例６０６は、発行者情報６５０（中間ＣＡのアイデンティティ）と、主体者情報６５２（ＳＳＬサーバエンティティのアイデンティティ）と、第１のエンティティ公開鍵６５４と、第１の暗号システムに関連する第３の認証局署名６５６と、第２の（ＱＲ）エンティティ公開鍵６５８とを含む。図６に示すように、第２の認証局秘密鍵６４０を用いて第３の認証局署名６５６を生成する。エンドエンティティ証明書６０６は、さらなる又は異なる情報を含むこともできる。

【0103】

図６に示す例では、ルートＣＡ証明書６０２が、ルート認証局の独自の公開鍵を用いて検証できる自己署名証明書であり、中間ＣＡ証明書６０４及びエンドエンティティ証明書６０６が、適切な認証局公開鍵を用いて検証できるＣＡ署名証明書である。

【0104】

いくつかの例では、エンドエンティティ証明書６０６、又はエンドエンティティ証明書６０６からの情報が、例えば図４に示す認証プロセス例４１０などの認証プロセスにおいて使用される。図６に示すエンドエンティティ証明書例６０６が認証プロセスの基礎である場合、認証プロセスは、第１の暗号システムを用いて以下のように進行することができる。依存エンティティは、エンドエンティティ証明書６０６内の発行者情報６５０と、中間ＣＡ証明書６０４内の主体者情報６３２とを照合する。次に、依存エンティティは、エンドエンティティ証明書６０６内の第３の認証局署名６５６を除く一部又は全部の情報の証明書概要を作成する。次に、依存エンティティは、中間ＣＡ証明書６０４からの第２の認証局公開鍵６３４を用いて、第３の認証局署名６５６を概要に照らして検証する。次に、依存エンティティは、以下と同様の方法で中間ＣＡ証明書６０４を検証することができる。依存エンティティは、中間ＣＡ証明書６０４内の発行者情報６３０と、ルートＣＡ証明書６０２内の主体者情報６１２とを照合する。次に、依存エンティティは、中間ＣＡ証明書６０４内の第２の認証局署名６３６を除く一部又は全部の情報の証明書概要を作成する。次に、依存エンティティは、ルートＣＡ証明書６０２からの第１の認証局公開鍵６１４を用いて、第２の認証局署名６３６を概要に照らして検証する。いくつかの例では、ルートＣＡ証明書６０２を明確に信頼することができ、従って依存エンティティが検証する必要はない。いくつかの例では、ルートＣＡ証明書６０２からの第１の認証局公開鍵６１４を用いてルートＣＡ証明書６０２を検証することができる。いくつかの例では、エンドエンティティ証明書６０６、又はエンドエンティティ証明書６０６からの情報を用いて、別のタイプの認証プロセスを実行することもできる。

【0105】

図７は、認証局が証明書署名要求（ＣＳＲ）に基づいて生成するデジタル証明書例７０２を示すブロック図である。図７に示すデジタル証明書例７０２は、別の（例えば、量子脆弱）暗号システムのための認証局署名に加えて、耐量子暗号システムのための認証局署名を含む。

【0106】

デジタル証明書７０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する公開鍵５１６を含む証明書要求に基づいて生成される。証明書要求は、基本フィールドと拡張領域とを含むことができる。証明書要求の基本フィールドは、主体者フィールドに主体者情報（例えば、ユーザアイデンティティ）を、発行者フィールドに発行者情報（例えば、認証局アイデンティティ）を、有効期間フィールドに有効期間情報を、及び公開鍵フィールドに公開鍵７１６を含むことができる。証明書要求を生成するエンティティは、第１の暗号システムを用いて証明書要求に署名することができる。例えば、公開鍵７１６に関連する秘密鍵を用いて、証明書要求に適用されるデジタル署名を生成することができる。

【0107】

図７に示すデジタル証明書７０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する第１の認証局署名７４０と、第２の異なる暗号システムに関連する第２の認証局署名７３０とを含むデジタル証明書の例である。図７に示す例では、公開鍵７１６及び関連する秘密鍵が第１の暗号システムに関連し、第２の暗号システムは耐量子（ＱＲ）暗号システムである。

【0108】

図７に示すように、デジタル証明書７０２は、基本フィールド７０４と拡張領域７０６とを含む。基本フィールド７０４は、主体者フィールドに主体者情報７１０（例えば、ユーザアイデンティティ）を、発行者フィールドに発行者情報７１２（例えば、認証局アイデンティティ）を、有効期間フィールドに有効期間情報７１４を、公開鍵フィールドに公開鍵７１６を、及び署名値フィールドに第１の認証局署名７４０を含む。拡張領域７０６は、第２の認証局署名７３０を含む。デジタル証明書７０２は、さらなる又は異なるフィールド、拡張領域又はその他の情報を含むこともできる。

【0109】

図７に示すデジタル証明書例７０２は、認証局が証明書要求例に応答して生成する。図７の左側に示すように、第２の（ＱＲ）認証局署名７３０は、第１の認証局署名７４０の前に生成される。認証局は、公開鍵フィールドに第１の公開鍵７１６を含むバージョンのデジタル証明書７０２に基づいて第２の（ＱＲ）認証局署名７３０を生成した後に、デジタル証明書７０２の拡張領域７０６に第２の（ＱＲ）認証局署名７３０を挿入する。次に、認証局は、公開鍵フィールドに第１の公開鍵７１６を、拡張領域７０６に第２の（ＱＲ）認証局署名７３０を含むバージョンのデジタル証明書７０２に基づいて第１の認証局署名７４０を生成した後に、図７の右側に示すように、デジタル証明書７０２の署名値フィールドに第１の認証局署名７４０を挿入する。

【0110】

いくつかの例では、デジタル証明書７０２が、要求者及び発行者によって実行される証明書要求及び作成プロセスにおいて生成され、いくつかの例では、このプロセスが以下のように進行することができる。要求者は、公開鍵７１６及び関連する秘密鍵を含む、第１の暗号システムに関連する鍵対を生成する。要求者は、証明書署名要求（ＣＳＲ）の基本フィールドの公開鍵フィールドに公開鍵７１６を挿入する。要求者は、ＣＳＲの他の標準的な基本フィールド及び拡張領域に挿入を行う。要求者は、挿入済みのＣＳＲに基づいて、要求者の秘密鍵を用いてデジタル署名を生成する。要求者は、署名済みＣＳＲを発行者に送信する。発行者は、署名済みＣＳＲを要求者から受け取って要求者を調べる。発行者は、要求者のデジタル署名を検証して、要求者が公開鍵７１６に合致する秘密鍵を所有していることを確認する。発行者は、ＣＳＲの他の全ての属性を検証して更新を適用することができる。発行者は、公開鍵フィールドに公開鍵７１６を挿入することを含め、デジタル証明書７０２の１又は２以上のフィールドに挿入を行う。次に、発行者は、第２の（耐量子）暗号システムに関連する第２の認証局秘密鍵を用いて、デジタル証明書７０２に基づいて第２の（ＱＲ）認証局署名７３０を生成する。発行者は、拡張領域７０６に第２の（ＱＲ）認証局署名７３０を挿入する。次に、発行者は、第１の暗号システムに関連する第１の認証局秘密鍵を用いて、デジタル証明書７０２に基づいて別の署名（第１の認証局署名７４０）を生成する。発行者は、基本フィールド７０４の署名値フィールドに第１の認証局署名７４０を挿入する。いくつかの例では、証明書要求及び作成プロセスがさらなる又は異なるステップを含むことも、或いは別の形で進行することもできる。

【0111】

いくつかの例では、デジタル証明書７０２、又はデジタル証明書７０２からの情報が、例えば図４に示すデジタル署名プロセス例４２０などのデジタル署名プロセスにおいて使用される。図７に示すデジタル証明書例７０２が、証明書所有者と他のエンティティとの間のデジタル署名プロセスの基礎である場合、いくつかの例では、デジタル署名プロセスが以下のように進行することができる。証明書所有者は、デジタル証明書７０２内の公開鍵７１６に関連する証明書所有者の秘密鍵でメッセージに署名する。次に、結果として得られたデジタル署名が他方のエンティティに送信され、他方のエンティティは、公開鍵７１６を用いてデジタル署名を検証する。いくつかの例では、デジタル証明書７０２、又はデジタル証明書７０２からの情報を用いて、別のタイプのデジタル署名プロセスを実行することもできる。

【0112】

いくつかの例では、デジタル証明書７０２、又はデジタル証明書７０２からの情報が、例えば図４に示す暗号化プロセス４３０のような暗号化プロセスにおいて使用される。図７に示すデジタル証明書例７０２が暗号化プロセスの基礎である場合、いくつかの例では、プロセスが以下のように進行することができる。暗号化を行うエンティティは、デジタル証明書７０２からの公開鍵７１６でメッセージを暗号化する。次に、この暗号化メッセージが証明書所有者に送信され、証明書所有者が、公開鍵７１６に関連する秘密鍵を用いてメッセージを復号する。いくつかの例では、デジタル証明書７０２又はデジタル証明書７０２からの情報を用いて、別のタイプのセキュア電子メールプロセスを実行することもできる。

【0113】

図８は、別の（例えば、量子脆弱）暗号システムのための認証局署名に加えて、耐量子暗号システムのための認証局署名を含むデジタル証明書を伴う証明書チェーン例８００を示すブロック図である。図８に示す証明書チェーン例８００は、ルートＣＡ証明書８０２、中間ＣＡ証明書８０４、及びエンドエンティティ証明書８０６という３つのデジタル証明書を含む。中間ＣＡ証明書８０４は、図９に示すデジタル証明書例９０２として作成してフォーマットできるデジタル証明書の例である。エンドエンティティ証明書８０６は、図７に示すデジタル証明書例７０２として作成してフォーマットできるデジタル証明書の例である。いくつかの例では、図８に示すデジタル証明書のうちの１つ又は２つ以上を別の形で作成してフォーマットすることもできる。図８に示す例では、ルートＣＡ証明書８０２が、ルート認証局の独自の公開鍵を用いて検証できる自己署名証明書であり、中間ＣＡ証明書８０４及びエンドエンティティ証明書８０６が、適切な認証局公開鍵を用いて検証できるＣＡ署名証明書である。

【0114】

図８に示す例では、ルートＣＡ証明書８０２がルート認証局に属する。ルート認証局は、第１の暗号システムに関連する第１の鍵対と、第２の（耐量子）暗号システムに関連する第２の鍵対とを有する。第１の鍵対は、第１の認証局秘密鍵８２０と第１の認証局公開鍵８１４とを含む。第２の鍵対は、第２の（ＱＲ）認証局秘密鍵８２１と第２の（ＱＲ）認証局公開鍵８１８とを含む。

【0115】

ルートＣＡ証明書例８０２は、発行者情報８１０（ルートＣＡのアイデンティティ）と、主体者情報８１２（ルートＣＡのアイデンティティ）と、第１の認証局公開鍵８１４と、第１の暗号システムに関連する第１の認証局署名８１６と、第２の（ＱＲ）認証局公開鍵８１８と、第２の暗号システムに関連する第２の（ＱＲ）認証局署名８１９とを含む。図８に示すように、第１の認証局秘密鍵８２０を用いて第１の認証局署名８１６を生成し、第２の（ＱＲ）認証局秘密鍵８２１を用いて第２の（ＱＲ）認証局署名８１９を生成する。ルートＣＡ証明書８０２は、さらなる又は異なる情報を含むこともできる。

【0116】

図８に示す例では、中間ＣＡ証明書８０４が中間認証局に属する。中間認証局は、第１の暗号システムに関連する第３の鍵対と、第２の（耐量子）暗号システムに関連する第４の鍵対とを有する。第３の鍵対は、第３の認証局秘密鍵８４０と、第３の認証局公開鍵８３４とを含む。第４の鍵対は、第４の（ＱＲ）認証局秘密鍵８４１と、第４の（ＱＲ）認証局公開鍵８３８とを含む。

【0117】

中間ＣＡ証明書例８０４は、発行者情報８３０（ルートＣＡのアイデンティティ）と、主体者情報８３２（中間ＣＡのアイデンティティ）と、第３の認証局公開鍵８３４と、第１の暗号システムに関連する第３の認証局署名８３６と、第４の（ＱＲ）認証局公開鍵８３８と、第２の暗号システムに関連する第４の（ＱＲ）認証局署名８３９とを含む。図８に示すように、第１の認証局秘密鍵８２０を用いて第３の認証局署名８３６を生成し、第２の（ＱＲ）認証局秘密鍵８２１を用いて第４の（ＱＲ）認証局署名８３９を生成する。中間ＣＡ証明書８０４は、さらなる又は異なる情報を含むこともできる。

【0118】

図８に示す例では、エンドエンティティ証明書８０６がＳＳＬサーバエンティティに属する。ＳＳＬサーバエンティティは、第１の暗号システムに関連する第５の鍵対を有する。第５の鍵対は、第１のエンティティ秘密鍵８６０と、第１のエンティティ公開鍵８５４とを含む。

【0119】

エンドエンティティ証明書例８０６は、発行者情報８５０（中間ＣＡのアイデンティティ）と、主体者情報８５２（ＳＳＬサーバエンティティのアイデンティティ）と、第１のエンティティ公開鍵８５４と、第１の暗号システムに関連する第５の認証局署名８５６と、第２の暗号システムに関連する第６の（ＱＲ）認証局署名８５９とを含む。図８に示すように、第３の認証局秘密鍵８４０を用いて第５の認証局署名８５６を生成し、第４の（ＱＲ）認証局秘密鍵８４１を用いて第６の（ＱＲ）認証局署名８５９を生成する。エンドエンティティ証明書８０６は、さらなる又は異なる情報を含むこともできる。

【0120】

図８に示す例では、ルートＣＡ証明書８０２が、ルート認証局の独自の公開鍵を用いて検証できる自己署名証明書であり、中間ＣＡ証明書８０４及びエンドエンティティ証明書８０６が、適切な認証局公開鍵を用いて検証できるＣＡ署名証明書である。

【0121】

いくつかの例では、エンドエンティティ証明書８０６、又はエンドエンティティ証明書８０６からの情報が、例えば図４に示す認証プロセス例４１０のような認証プロセスにおいて使用される。図８に示すエンドエンティティ証明書例８０６が認証プロセスの基礎である場合、認証プロセスは、第１の暗号システムに関連するデータオブジェクト（８１４、８１６、８３４、８３６、８５４、８５６）を用いて、図６に示す証明書チェーン例６００に関して説明した認証プロセスに類似する形で進行することができる。これに加えて、又はこれとは別に、図８に示すエンドエンティティ証明書例８０６が認証プロセスの基礎である場合、認証プロセスは、第２の（耐量子）暗号システムを用いて以下のように進行することもできる。依存エンティティは、エンドエンティティ証明書８０６内の発行者情報８５０と、中間ＣＡ証明書８０４内の主体者情報８３２とを照合する。次に、依存エンティティは、エンドエンティティ証明書８０６内の第５の認証局署名８５６と第６の（ＱＲ）認証局署名８５９とを除く一部又は全部の情報の証明書概要を作成する。次に、依存エンティティは、中間ＣＡ証明書８０４からの第４の（ＱＲ）認証局公開鍵８３８を用いて、第６の（ＱＲ）認証局署名８５９を概要に照らして検証する。次に、依存エンティティは、以下と同様の方法で中間ＣＡ証明書８０４を検証することができる。依存エンティティは、中間ＣＡ証明書８０４内の発行者情報８３０と、ルートＣＡ証明書８０２内の主体者情報８１２とを照合する。次に、依存エンティティは、中間ＣＡ証明書８０４内の第３の認証局署名８３６と第４の（ＱＲ）認証局署名８３９とを除く一部又は全部の情報の証明書概要を作成する。次に、依存エンティティは、ルートＣＡ証明書８０２からの第２の（ＱＲ）認証局公開鍵８１８を用いて、第４の（ＱＲ）認証局署名８３９を概要に照らして検証する。いくつかの例では、ルートＣＡ証明書８０２を明確に信頼することができ、従って依存エンティティが検証する必要はない。いくつかの例では、ルートＣＡ証明書８０２からの第２の（ＱＲ）認証局公開鍵８１８を用いてルートＣＡ証明書８０２を検証することができる。いくつかの例では、エンドエンティティ証明書８０６、又はエンドエンティティ証明書８０６からの情報を用いて、別のタイプの認証プロセスを実行することもできる。

【0122】

図９は、認証局が証明書署名要求（ＣＳＲ）に基づいて生成するデジタル証明書例９０２を示すブロック図である。図９に示すデジタル証明書例９０２は、別の（例えば、量子脆弱）暗号システムのための認証局署名及び公開鍵に加えて、耐量子暗号システムのための認証局署名及び公開鍵を含む。

【0123】

デジタル証明書９０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する第１の公開鍵９１６と、第２の異なる暗号システムに関連する第２の公開鍵９２０と、第１の暗号システムに関連する第１のデジタル署名と、第２の暗号システムに関連する第２のデジタル署名とを含む証明書要求に基づいて生成される。図示の例では、第２の暗号システムが耐量子（ＱＲ）暗号システムである。証明書要求は、基本フィールドと拡張領域とを含むことができる。証明書要求の基本フィールドは、主体者フィールドに主体者情報（例えば、ユーザアイデンティティ）を、発行者フィールドに発行者情報（例えば、認証局アイデンティティ）を、有効期間フィールドに有効期間情報を、及び公開鍵フィールドに第１の公開鍵９１６を含むことができる。証明書要求の拡張領域は、第２の（ＱＲ）公開鍵９２０を含むことができる。証明書要求を生成するエンティティは、第１の暗号システム又は第２の暗号システム（又はこれらの両方）を用いて証明書要求に署名することができる。例えば、第１の公開鍵９１６に関連する秘密鍵を用いて、証明書要求に適用されるデジタル署名を生成することができ、或いはＱＲ公開鍵９２０に関連する秘密鍵を用いて、証明書要求に適用される（ＱＲ）デジタル署名を生成することもできる。

【0124】

図９に示すデジタル証明書９０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する第１の公開鍵９１６と、第２の異なる暗号システムに関連する第２の公開鍵９２０とを含むデジタル証明書の例である。図９に示すデジタル証明書９０２は、第１の暗号システム（例えば、量子脆弱暗号システム）に関連する第１の認証局署名９４０と、第２の異なる暗号システムに関連する第２の認証局署名９３０とを含むデジタル証明書の例でもある。図示の例では、第２の暗号システムが耐量子（ＱＲ）暗号システムである。

【0125】

図９に示すように、デジタル証明書９０２は、基本フィールド９０４と拡張領域９０６とを含む。基本フィールド９０４は、主体者フィールドに主体者情報９１０（例えば、ユーザアイデンティティ）を、発行者フィールドに発行者情報９１２（例えば、認証局アイデンティティ）を、有効期間フィールドに有効期間情報９１４を、公開鍵フィールドに第１の公開鍵９１６を、及び署名値フィールドに第１の認証局署名９４０を含む。拡張領域９０６は、第２の（ＱＲ）公開鍵９２０と第２の（ＱＲ）認証局署名９３０とを含む。デジタル証明書９０２は、さらなる又は異なるフィールド、拡張領域又はその他の情報を含むこともできる。

【0126】

図９に示すデジタル証明書例９０２は、認証局が証明書要求例に応答して生成する。図９の左側に示すように、第２の（ＱＲ）認証局署名９３０は、第１の認証局署名９４０の前に生成される。認証局は、公開鍵フィールドに第１の公開鍵９１６を、拡張領域９０６に第２の（ＱＲ）公開鍵９２０を含むバージョンのデジタル証明書９０２に基づいて第２の（ＱＲ）認証局署名９３０を生成した後に、拡張領域９０６に第２の（ＱＲ）認証局署名９３０を挿入する。次に、認証局は、公開鍵フィールドに第１の公開鍵９１６を、拡張領域９０６に第２の（ＱＲ）公開鍵９２０を、拡張領域９０６に第２の（ＱＲ）認証局署名９３０を含むバージョンのデジタル証明書９０２に基づいて第１の認証局署名９４０を生成した後に、図９の右側に示すように、デジタル証明書９０２の署名値フィールドに第１の認証局署名９４０を挿入する。

【0127】

いくつかの例では、デジタル証明書９０２が、要求者及び発行者によって実行される証明書要求及び作成プロセスにおいて生成され、いくつかの例では、このプロセスが以下のように進行することができる。要求者は、第１の公開鍵９１６と関連する第１の秘密鍵とを含む、第１の暗号システムに関連する鍵対を生成する。要求者は、ＱＲ公開鍵９２０と関連するＱＲ秘密鍵とを含む、第２の（耐量子）暗号システムに関連する第２の（ＱＲ）鍵対を生成する。要求者は、証明書署名要求（ＣＳＲ）の拡張領域にＱＲ公開鍵９２０を挿入する。要求者は、ＣＳＲの基本フィールドの公開鍵フィールドに第１の公開鍵９１６を挿入する。要求者は、他の標準的な基本フィールド及び拡張領域に挿入を行う。要求者は、挿入済みのＣＳＲに基づいて、要求者の各秘密鍵を用いてデジタル署名を生成する。要求者は、署名済みＣＳＲを発行者に送信する。発行者は、署名済みＣＳＲを要求者から受け取って要求者を調べる。発行者は、署名を検証して、要求者が第１の公開鍵９１６及びＱＲ公開鍵９２０に合致する秘密鍵を所有していることを確認する。発行者は、ＣＳＲの他の全ての属性を検証して更新を適用することができる。発行者は、公開鍵フィールドに公開鍵９１６を挿入し、拡張領域９０６をＱＲ公開鍵９２０を挿入することを含め、デジタル証明書９０２の１又は２以上のフィールドに挿入を行う。次に、発行者は、第２の（耐量子）暗号システムに関連する第２の認証局秘密鍵を用いて、デジタル証明書９０２に基づいて第２の（ＱＲ）認証局署名９３０を生成する。発行者は、拡張領域９０６に第２の（ＱＲ）認証局署名９３０を挿入する。次に、発行者は、第１の暗号システムに関連する第１の認証局秘密鍵を用いて、デジタル証明書９０２に基づいて別の認証局署名（第１の認証局署名９４０）を生成する。発行者は、基本フィールド９０４の署名値フィールドに第１の認証局署名９４０を挿入する。いくつかの例では、証明書要求及び作成プロセスがさらなる又は異なるステップを含むことも、或いは別の形で進行することもできる。

【0128】

いくつかの例では、デジタル証明書９０２、又はデジタル証明書９０２からの情報が、例えば図４に示すデジタル署名プロセス例４２０などのデジタル署名プロセスにおいて使用される。図９に示すデジタル証明書例９０２が、証明書所有者と他のエンティティとの間のデジタル署名プロセスの基礎である場合、デジタル署名プロセスは、図５に示すデジタル証明書例５０２に関して説明したデジタル署名プロセスに類似する形又はその他の形で進行することができる。

【0129】

いくつかの例では、デジタル証明書９０２、又はデジタル証明書９０２からの情報が、例えば図４に示す暗号化プロセス４３０などの暗号化プロセスにおいて使用される。図９に示すデジタル証明書例９０２が、暗号化プロセスの基礎である場合、プロセスは、図５に示すデジタル証明書例５０２に関して説明した暗号化プロセスに類似する形又はその他の形で進行することができる。

【0130】

図１０は、別の（例えば、量子脆弱）暗号システムのための認証局署名及び公開鍵に加えて、耐量子暗号システムのための認証局署名及び公開鍵を含むデジタル証明書を伴う証明書チェーン例１０００を示すブロック図である。図１０に示す証明書チェーン例１０００は、ルートＣＡ証明書１００２、中間ＣＡ証明書１００４、及びエンドエンティティ証明書１００６という３つのデジタル証明書を含む。中間ＣＡ証明書１００４及びエンドエンティティ証明書１００６は、図９に示すデジタル証明書例９０２として作成してフォーマットできるデジタル証明書の例である。いくつかの例では、図１０に示すデジタル証明書のうちの１つ又は２つ以上を別の形で作成してフォーマットすることもできる。図１０に示す例では、ルートＣＡ証明書１００２が、ルート認証局の独自の公開鍵を用いて検証できる自己署名証明書であり、中間ＣＡ証明書１００４及びエンドエンティティ証明書１００６が、適切な認証局公開鍵を用いて検証できるＣＡ署名証明書である。

【0131】

図１０に示す例では、ルートＣＡ証明書１００２がルート認証局に属する。ルート認証局は、第１の暗号システムに関連する第１の鍵対と、第２の（耐量子）暗号システムに関連する第２の鍵対とを有する。第１の鍵対は、第１の認証局秘密鍵１０２０と第１の認証局公開鍵１０１４とを含む。第２の鍵対は、第２の（ＱＲ）認証局秘密鍵１０２１と第２の（ＱＲ）認証局公開鍵１０１８とを含む。

【0132】

ルートＣＡ証明書例１００２は、発行者情報１０１０（ルートＣＡのアイデンティティ）と、主体者情報１０１２（ルートＣＡのアイデンティティ）と、第１の認証局公開鍵１０１４と、第１の暗号システムに関連する第１の認証局署名１０１６と、第２の（ＱＲ）認証局公開鍵１０１８と、第２の暗号システムに関連する第２の（ＱＲ）認証局署名１０１９とを含む。図１０に示すように、第１の認証局秘密鍵１０２０を用いて第１の認証局署名１０１６を生成し、第２の（ＱＲ）認証局秘密鍵１０２１を用いて第２の（ＱＲ）認証局署名１０１９を生成する。ルートＣＡ証明書１００２は、さらなる又は異なる情報を含むこともできる。

【0133】

図１０に示す例では、中間ＣＡ証明書１００４が中間認証局に属する。中間認証局は、第１の暗号システムに関連する第３の鍵対と、第２の（耐量子）暗号システムに関連する第４の鍵対とを有する。第３の鍵対は、第３の認証局秘密鍵１０４０と、第３の認証局公開鍵１０３４とを含む。第４の鍵対は、第４の（ＱＲ）認証局秘密鍵１０４１と、第４の（ＱＲ）認証局公開鍵１０３８とを含む。

【0134】

中間ＣＡ証明書例１００４は、発行者情報１０３０（ルートＣＡのアイデンティティ）と、主体者情報１０３２（中間ＣＡのアイデンティティ）と、第３の認証局公開鍵１０３４と、第１の暗号システムに関連する第３の認証局署名１０３６と、第４の（ＱＲ）認証局公開鍵１０３８と、第２の暗号システムに関連する第４の（ＱＲ）認証局署名１０３９とを含む。図１０に示すように、第１の認証局秘密鍵１０２０を用いて第３の認証局署名１０３６を生成し、第２の（ＱＲ）認証局秘密鍵１０２１を用いて第４の（ＱＲ）認証局署名１０３９を生成する。中間ＣＡ証明書１００４は、さらなる又は異なる情報を含むこともできる。

【0135】

図１０に示す例では、エンドエンティティ証明書１００６がＳＳＬサーバエンティティに属する。ＳＳＬサーバエンティティは、第１の暗号システムに関連する第５の鍵対と、第２の（耐量子）暗号システムに関連する第６の鍵対とを有する。第５の鍵対は、第１のエンティティ秘密鍵１０６０と、第１のエンティティ公開鍵１０５４とを含む。第６の鍵対は、第２の（ＱＲ）エンティティ秘密鍵１０６１と、第２の（ＱＲ）エンティティ公開鍵１０５８とを含む。

【0136】

エンドエンティティ証明書例１００６は、発行者情報１０５０（中間ＣＡのアイデンティティ）と、主体者情報１０５２（ＳＳＬサーバエンティティのアイデンティティ）と、第１のエンティティ公開鍵１０５４と、第１の暗号システムに関連する第５の認証局署名１０５６と、第２の（ＱＲ）エンティティ公開鍵１０５８と、第２の暗号システムに関連する第６の（ＱＲ）認証局署名１０５９とを含む。図１０に示すように、第３の認証局秘密鍵１０４０を用いて第５の認証局署名１０５６を生成し、第４の（ＱＲ）認証局秘密鍵１０４１を用いて第６の（ＱＲ）認証局署名１０５９を生成する。エンドエンティティ証明書１００６は、さらなる又は異なる情報を含むこともできる。

【0137】

図１０に示す例では、ルートＣＡ証明書１００２が、ルート認証局の独自の公開鍵を用いて検証できる自己署名証明書であり、中間ＣＡ証明書１００４及びエンドエンティティ証明書１００６が、適切な認証局公開鍵を用いて検証できるＣＡ署名証明書である。

【0138】

いくつかの例では、エンドエンティティ証明書１００６、又はエンドエンティティ証明書１００６からの情報が、例えば図４に示す認証プロセス例４１０などの認証プロセスにおいて使用される。図１０に示すエンドエンティティ証明書例１００６が認証プロセスの基礎である場合、認証プロセスは、第１の暗号システムに関連するデータオブジェクト（１０１４、１０１６、１０３４、１０３６、１０５４、１０５６）を用いて、図６に示す証明書チェーン例６００に関して説明した認証プロセスに類似する形で進行することができる。これに加えて、又はこれとは別に、図１０に示すエンドエンティティ証明書例１００６が認証プロセスの基礎である場合、認証プロセスは、第２の（耐量子）暗号システムを用いて以下のように進行することもできる。依存エンティティは、エンドエンティティ証明書１００６内の発行者情報１０５０と、中間ＣＡ証明書１００４内の主体者情報１０３２とを照合する。次に、依存エンティティは、エンドエンティティ証明書１００６内の第５の認証局署名１０５６と第６の（ＱＲ）認証局署名１０５９とを除く一部又は全部の情報の証明書概要を作成する。次に、依存エンティティは、中間ＣＡ証明書１００４からの第４の（ＱＲ）認証局公開鍵１０３８を用いて、第６の（ＱＲ）認証局署名１０５９を概要に照らして検証する。次に、依存エンティティは、以下と同様の方法で中間ＣＡ証明書１００４を検証することができる。依存エンティティは、中間ＣＡ証明書１００４内の発行者情報１０３０と、ルートＣＡ証明書１００２内の主体者情報１０１２とを照合する。次に、依存エンティティは、中間ＣＡ証明書１００４内の第３の認証局署名１０３６と第４の（ＱＲ）認証局署名１０３９とを除く一部又は全部の情報の証明書概要を作成する。次に、依存エンティティは、ルートＣＡ証明書１００２からの第２の（ＱＲ）認証局公開鍵１０１８を用いて、第４の（ＱＲ）認証局署名１０３９を概要に照らして検証する。いくつかの例では、ルートＣＡ証明書１００２を明確に信頼することができ、従って依存エンティティが検証する必要はない。いくつかの例では、ルートＣＡ証明書１００２からの第２の（ＱＲ）認証局公開鍵１０１８を用いてルートＣＡ証明書１００２を検証することができる。いくつかの例では、エンドエンティティ証明書１００６、又はエンドエンティティ証明書１００６からの情報を用いて、別のタイプの認証プロセスを実行することもできる。

【0139】

本明細書で説明した主題及び動作の一部は、本明細書で開示した構造及びこれらの構造的同等物、或いはこれらの１又は２以上の組み合わせを含め、デジタル電子回路で実装することも、或いはコンピュータソフトウェア、ファームウェア又はハードウェアで実装することもできる。本明細書で説明した主題及び動作の一部は、１又は２以上のコンピュータプログラムとして、すなわちデータ処理装置によって実行される、又はデータ処理装置の動作を制御する、コンピュータ記憶媒体上に符号化されたコンピュータプログラム命令の１又は２以上のモジュールとして実装することができる。コンピュータ記憶媒体は、コンピュータ可読記憶装置、コンピュータ可読記憶基板、ランダム又はシリアルアクセスメモリアレイ又はデバイス、或いはこれらのうちの１つ又は２つ以上の組み合わせとすることも、又はこれらに含めることもできる。さらに、コンピュータ記憶媒体は伝搬信号ではなく、人工的に生成された伝搬信号の形で符号化されたコンピュータプログラム命令の発信元又は宛先とすることができる。コンピュータ記憶媒体は、１又は２以上の別個のコンポーネント又は媒体（例えば、複数のＣＤ、ディスク又はその他の記憶装置）とすることも、或いはこれらに含めることもできる。

【0140】

本明細書で説明した動作の一部は、例えば１又は２以上のコンピュータ可読記憶装置に記憶された、又は他のソースから受け取られたデータに対してデータ処理装置が実行する動作として実装することができる。

【0141】

「データ処理装置」という用語は、データを処理する全ての種類の装置、機器及び機械を含み、一例としてプログラマブルプロセッサ、コンピュータ、システムオンチップ、又は複数のシステムオンチップ、又はこれらの組み合わせを含む。この装置は、例えばＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）などの専用論理回路を含むこともできる。この装置は、ハードウェアに加えて、例えばプロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォームランタイム環境、仮想マシン、又はこれらのうちの１つ又は２つ以上の組み合わせを構成するコードなどの、対象とするコンピュータプログラムの実行環境を形成するコードを含むこともできる。

【0142】

（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト又はコードとしても知られている）コンピュータプログラムは、コンパイラ型言語又はインタープリタ型言語、宣言型言語又は手続き型言語を含むあらゆる形のプログラミング言語で書くことができ、スタンドアロンプログラム、又はモジュール、コンポーネント、サブルーチン、オブジェクト、又はコンピュータ環境で使用するのに適した他のユニットとしての形を含むあらゆる形で展開することができる。コンピュータプログラムは、必須ではないが、ファイルシステム内のファイルに対応することができる。プログラムは、プログラム専用の単一のファイル内の、又は複数の連動するファイル（例えば、１又は２以上のモジュール、サブプログラム、又はコードの一部を記憶するファイル）内の、他のプログラム又はデータ（例えば、マークアップ言語リソースに記憶された１又は２以上のスクリプト）を保持するファイルの一部に記憶することができる。コンピュータプログラムは、１つのコンピュータ上で実行されるように展開することも、或いは１つのサイトに位置する、又は複数のサイトに分散して通信ネットワークによって相互接続された複数のコンピュータ上で実行されるように展開することもできる。

【0143】

本明細書で説明したプロセス及びロジックフローの一部は、１又は２以上のコンピュータプログラムを実行する１又は２以上のプログラマブルプロセッサによって、入力データに作用して出力を生成することによって動作を行うように実行することができる。プロセス及びロジックフローは、例えばＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）などの専用論理回路によって実行することもでき、装置をこのような専用論理回路として実装することもできる。

【0144】

コンピュータプログラムを実行するのに適したプロセッサとしては、一例として、汎用マイクロプロセッサ及び専用マイクロプロセッサの両方、並びにあらゆる種類のデジタルコンピュータのプロセッサが挙げられる。一般に、プロセッサは、リードオンリメモリ又はランダムアクセスメモリ、或いはこれらの両方から命令及びデータを受け取る。コンピュータの要素は、命令に従って動作を実行するプロセッサと、命令及びデータを記憶する１又は２以上のメモリデバイスとを含む。コンピュータは、例えば非磁気ドライブ（例えば、半導体ドライブ）、磁気ディスク、光磁気ディスク、光学ディスクなどの、データを記憶する１又は２以上の大容量記憶装置を含むこともでき、或いはこのような記憶装置との間でのデータの受け取り及びデータの転送、又はこれらの両方を行うように動作可能に結合することもできる。しかしながら、コンピュータは、このような装置を有していなくてもよい。さらに、コンピュータは、例えば電話機、電子機器、モバイルオーディオプレーヤ又はビデオプレーヤ、ゲーム機、全地球測位システム（ＧＰＳ）受信機、モノのインターネット（ＩｏＴ）装置、機械間（Ｍ２Ｍ）センサ又はアクチュエータ、又はポータブル記憶装置（例えば、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ）などの別の装置に組み込むこともできる。コンピュータプログラム命令及びデータの記憶に適した装置としては、一例として、半導体メモリデバイス（例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリデバイスなど）、磁気ディスク（例えば、内部ハードディスク又はリムーバブルディスクなど）、磁気光学ディスク、並びにＣＤ ＲＯＭ及びＤＶＤ−ＲＯＭディスクを含む全ての形態の不揮発性メモリ、媒体及びメモリデバイスが挙げられる。いくつかの例では、プロセッサ及びメモリを専用論理回路によって補完することも、又は専用論理回路に組み込むこともできる。

【0145】

動作は、ユーザとの相互作用をもたらすために、ディスプレイ装置（例えば、モニタ、又は別のタイプのディスプレイ装置）と、ユーザがコンピュータに入力を提供できるようにするキーボード及びポインティングデバイス（例えば、マウス、トラックボール、タブレット、タッチセンサ式画面、又は別のタイプのポインティングデバイス）とを有するコンピュータ上で実行することができる。他の種類の装置を使用してユーザとの相互作用をもたらすこともでき、例えばユーザに提供されるフィードバックは、視覚的フィードバック、聴覚的フィードバック又は触覚的フィードバックなどのあらゆる形の感覚的フィードバックとすることができ、ユーザからの入力は、音響入力、音声入力又は触覚入力を含むあらゆる形で受け取ることができる。また、コンピュータは、例えばウェブブラウザから受け取られた要求に応答してユーザのクライアント装置上のウェブブラウザにウェブページを送信することなどの、ユーザが使用する装置との間で文書を送受信することによってユーザと相互作用することもできる。

【0146】

コンピュータシステムは、単一のコンピュータ装置を含むことも、或いは互いに近接して、又は一般的には離れて動作して、通常は通信ネットワークを通じて相互作用する複数のコンピュータを含むこともできる。通信ネットワークの例としては、ローカルエリアネットワーク（「ＬＡＮ」）及びワイドエリアネットワーク（「ＷＡＮ」）、インターネットワーク（例えば、インターネット）、衛星リンクを含むネットワーク、及びピアツーピアネットワーク（例えば、アドホックピアツーピアネットワーク）が挙げられる。クライアントとサーバとの関係は、それぞれのコンピュータ上で動作して互いにクライアント−サーバの関係を有するコンピュータプログラムによって生じることができる。

【0147】

ここで説明した例の一般的態様では、複数の暗号システムが使用される。

【0148】

第１の例では、デジタル証明書が発行される。エンティティの第１の公開鍵を含む証明書要求が受け取られる。第１の公開鍵は、第１の暗号システムに関連する。認証局の第１の秘密鍵を用いて、証明書要求内の情報に基づいて第１のデジタル署名を生成する。第１の秘密鍵は、第１の暗号システムに関連する。デジタル証明書が作成される。デジタル証明書は、エンティティの第１の公開鍵を含む公開鍵フィールドを含む。デジタル証明書は、第１のデジタル署名を含む署名値フィールドを含む。デジタル証明書は、拡張領域を含む。拡張領域は、エンティティの第２の公開鍵、第２のデジタル署名、又はこれらの両方を含む。第２の公開鍵は、第２の暗号システムに関連する。第２のデジタル署名は、証明書要求内の情報に基づいて、認証局の第２の秘密鍵を用いて生成される。認証局の第２の秘密鍵は、第２の暗号システムに関連する。

【0149】

第１の例のいくつかの実装では、デジタル証明書が、データ処理装置と、データ処理装置によって実行された時にデジタル証明書を発行する動作を実行する命令を記憶するコンピュータ可読媒体とを含むコンピュータシステムによって発行される。

【0150】

第１の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。デジタル証明書は、暗号で保護された通信において使用できるように認証局が発行することができる。発行されたデジタル証明書では、拡張領域が、第２のデジタル署名を含まずにエンティティの第２の公開鍵を含むことができる。発行されたデジタル証明書では、拡張領域が、エンティティの公開鍵を含まずに第２のデジタル署名を含むことができる。発行されたデジタル証明書では、拡張領域が、第２のデジタル署名とエンティティの公開鍵とを含むことができる。

【0151】

第１の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。証明書要求は、証明書要求署名を含むことができ、証明書要求署名は、エンティティの第１の公開鍵を用いて検証することができる。証明書要求は、エンティティの第２の公開鍵と、第１の証明書要求署名と、第２の証明書要求署名とを含むことができる。第１の証明書要求署名は第１の暗号システムに関連し、第２の証明書要求署名は第２の暗号システムに関連する。第１の証明書要求署名は、エンティティの第１の公開鍵を用いて検証することができる。第２の証明書要求署名は、エンティティの第２の公開鍵を用いて検証することができる。

【0152】

第１の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。１又は２以上の未挿入のフィールドを含むデジタル証明書を生成することができる。デジタル証明書の公開鍵フィールドに、エンティティの第１の公開鍵を挿入することができる。デジタル証明書の拡張領域に、エンティティの第２の公開鍵を挿入することができる。認証局の第１の秘密鍵を用いて第１のデジタル署名を生成することができる。第１のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２の公開鍵を有するデジタル証明書から生成することができる。デジタル証明書の署名値フィールドに、第１のデジタル署名を挿入することができる。

【0153】

第１の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。１又は２以上の未挿入のフィールドを含むデジタル証明書を生成することができる。デジタル証明書の公開鍵フィールドに、エンティティの第１の公開鍵を挿入することができる。認証局の第２の秘密鍵を用いて第２のデジタル署名を生成することができる。第２のデジタル署名は、公開鍵フィールドに第１の公開鍵を有するデジタル証明書から生成することができる。デジタル証明書の拡張領域に、第２のデジタル署名を挿入することができる。認証局の第１の秘密鍵を用いて第１のデジタル署名を生成することができる。第１のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２のデジタル署名を含むデジタル証明書から生成することができる。デジタル証明書の署名値フィールドに、第１のデジタル署名を挿入することができる。

【0154】

第１の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。１又は２以上の未挿入のフィールドを含むデジタル証明書を生成することができる。デジタル証明書の公開鍵フィールドに、エンティティの第１の公開鍵を挿入することができる。デジタル証明書の拡張領域に、エンティティの第２の公開鍵を挿入することができる。認証局の第２の秘密鍵を用いて第２のデジタル署名を生成することができる。第２のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２の公開鍵を含むデジタル証明書から生成することができる。デジタル証明書の拡張領域に、第２のデジタル署名を挿入することができる。認証局の第１の秘密鍵を用いて第１のデジタル署名を生成することができる。第１のデジタル署名は、公開鍵フィールドに第１の公開鍵を、拡張領域に第２の公開鍵を、及び拡張領域に第２のデジタル署名を含むデジタル証明書から生成することができる。デジタル証明書の署名値フィールドに、第１のデジタル署名を挿入することができる。

【0155】

第１の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。第１の暗号システムは量子脆弱暗号システムとすることができ、第２の暗号システムは耐量子暗号システムとすることができる。デジタル証明書は、認証局システムからエンティティに関連するノードに送信することができる。

【0156】

第２の例では、デジタル証明書が認証される。デジタル証明書が受け取られる。デジタル証明書は、エンティティの第１の公開鍵を含む公開鍵フィールドを含む。エンティティの第１の公開鍵は、第１の暗号システムに関連する。デジタル証明書は、認証局の第１のデジタル署名を含む署名値フィールドを含む。第１のデジタル署名は、第１の暗号システムに関連する。デジタル証明書は、拡張領域を含む。拡張領域は、エンティティの第２の公開鍵、認証局の第２のデジタル署名、又はこれらの両方を含む。第２の公開鍵は、第２の暗号システムに関連する。第２のデジタル署名は、第２の暗号システムに関連する。拡張領域に少なくとも部分的に基づいて証明書概要が生成される。証明書概要及び認証局の公開鍵を用いて、認証局の第１のデジタル署名又は認証局の第２のデジタル署名を検証する。

【0157】

第２の例のいくつかの実装では、デジタル証明書が、データ処理装置と、データ処理装置によって実行された時に、例えば暗号プロトコルの動作を実行する命令を記憶するコンピュータ可読媒体とを含むコンピュータシステムによって受け取られる。

【0158】

第２の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。デジタル証明書が受け取られた時に、拡張領域は、第２のデジタル署名を含まずにエンティティの第２の公開鍵を含むことができる。デジタル証明書が受け取られた時に、拡張領域は、エンティティの公開鍵を含まずに第２のデジタル署名を含むことができる。デジタル証明書が受け取られた時に、拡張領域は、第２のデジタル署名とエンティティの公開鍵とを含むことができる。

【0159】

第２の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。メッセージと、エンティティのデジタル署名とを受け取ることができる。エンティティを識別するために、エンティティの第２の公開鍵を用いてエンティティのデジタル署名を検証することができる。エンティティを識別するために、エンティティの第１の公開鍵を用いてエンティティのデジタル署名を検証することができる。

【0160】

第２の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。エンティティの第２の公開鍵を用いて、エンティティ宛てのメッセージを暗号化することができる。エンティティの第１の公開鍵を用いて、エンティティ宛てのメッセージを暗号化することができる。

【0161】

第２の例の実装は、以下の特徴のうちの１つ又は２つ以上を含むことができる。認証局の公開鍵は、認証局の第１のデジタル署名を検証するために使用され、第１の暗号システムに関連する。認証局の公開鍵は、認証局の第２のデジタル署名を検証するために使用され、第２の暗号システムに関連する。第１の暗号システムは量子脆弱暗号システムとすることができ、第２の暗号システムは耐量子暗号システムとすることができる。

【0162】

本明細書は多くの詳細を含んでいるが、これらの詳細は、特許請求できる内容の範囲に対する限定ではなく、むしろ特定の例に固有の特徴の説明として理解されたい。別個の実装の文脈で本明細書において説明した又は図面に示したいくつかの特徴は組み合わせることもできる。これとは逆に、単一の実装の文脈で説明又は図示した様々な特徴は、複数の実施形態において別個に実装することも、或いはあらゆる好適な部分的組み合わせで実装することもできる。

【0163】

同様に、図面には特定の順序で動作を示しているが、これについては、望ましい結果を達成するためにこのような動作を図示の特定の順序又は順番で実施し、又は図示の動作を全て実施する必要があると理解すべきでない。いくつかの状況では、マルチタスク及び並行処理が有利な場合もある。さらに、上述した実装において様々なシステムコンポーネントを分離していても、このような分離が全ての実装において必要であると理解すべきではなく、説明したプログラムコンポーネント及びシステムを単一の製品に一般的に統合し、又は複数の製品にパッケージ化することもできると理解されたい。

【0164】

複数の実装について説明した。それでもなお、様々な修正を行うことができると理解されるであろう。従って、以下の特許請求の範囲には、他の実施形態も含まれる。

【符号の説明】

【0165】

３００ プロセス例
３０２ エンティティ
３０４ 認証局
３１０ 第１の暗号システムのための第１の鍵対を取得
３１２ 第２の暗号システムのための第２の鍵対を取得
３１４ 証明書要求のフィールドに挿入
３１６ 証明書要求に署名
３１８ 送信
３２０ 受信
３２２ 署名を検証
３２４ 証明書のフィールドに挿入
３２６ 証明書に署名
３２８ 送信
３３０ 受信
３３２ 証明書を使用

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】