web-dev-qa-db-ja.com

単一のPKIで異なるアルゴリズムを使用する

次の公開鍵インフラストラクチャを想定します。

|ルートCA（RSA）
|-サブCA（RSA）
|-サブCA（ECC）

これが許容できる実装ではない理由を説明する合理的なものはありますか？

推奨される実装は、RSAのPKIとECCの別のPKIですか？

certificatespublic-key-infrastructurersaecc
5
Mike Soule

X.509 のとおり、問題ありません。アルゴリズムは自由に組み合わせることができます。各署名は独立しています。

（X.509には、CAがDSSを使用し、DSSグループパラメータ。この場合、発行された証明書はグループパラメータを省略できます。これは「パラメータの継承」と呼ばれます。これは実際には使用されず、ではありません可能性があり、明らかにある時点で想定されていたとしても、ECDSAに移植されました。これは、チェーンのさまざまなレベルの署名アルゴリズムが互いに関係している唯一のケースです（私の知る限り）。

ただし、、いくつかの異なるアルゴリズムを使用することで、「証明書利用者」（これらのチェーンを検証する必要があるシステム）にそれらのすべてを実装させることを理解する必要があります。これは通常、デスクトップシステム、サーバー、およびスマートフォンでは問題になりませんが、コードサイズを節約する必要があり、RSAのコードおよびECDSAの場合。

この種の問題は具体化されています。 [〜＃〜] ssl [〜＃〜] の場合、クライアントとサーバーは、証明書の署名を検証するためにサポートするアルゴリズムの種類を相互に通知します（たとえば、 Certificate Request メッセージ）。これは、小さなコードスペースで小さなデバイスをより適切にサポートするためのものです。証明書チェーンにRSAとECDSAを混在させると、その原則に少し矛盾します。状況に応じて、これは重要な場合とそうでない場合があります（おそらくは重要ではありません）。

いずれの場合でも、そのような混合チェーンはtransitionで想定されます。完全なRSAの世界から始めると仮定します。ルートCAはすべてのクライアントシステムに配布されています（多額のコストがかかる可能性があります）。ここで、クライアントソフトウェアはそれで問題ないため（たとえば、通常のOS /ブラウザーの更新に付属）、ECDSAへの切り替えを決定しますが、新しいECDSAルートを作成してすべてのクライアントにプッシュするには、かなりの時間がかかります。そのため、インストールベースを壊すことなくECDSAの使用を開始するには、相互認証を作成します。

  • oldRootはRSAキーを使用します。
  • newRootはECDSAキーを使用します。
  • 信頼できるルートとしてnewRootを知らない場合でも、newRootによって発行された証明書を検証できるようにするために、newRootの名前と公開鍵を含むクロス証明書が発行されますが、oldRootによって署名されます。

この相互証明書により、信頼されたルートとしてnewRootを知っているシステムは、パス「newRoot-> cert」を使用して証明書を検証でき、oldRootのみを知っているシステムは、「oldRoot-> newRoot-> cert」を使用します（後者の場合、相互認証を通過します）。つまり、newRootには2つの証明書があり、1つは自己署名（ECDSAを使用）、もう1つはoldRootによって署名されています（newRootを中間CAにします）。

これは、主要な変更を伴う更新を処理するためのかなり標準的な方法ですが、RSAからECDSAへの移行の場合、混合アルゴリズムチェーンを意味します。したがって、あなたが説明する状況はサポートされているだけでなく、期待されています。

要約すると：完全に別個のPKIを使用すると、単一アルゴリズムのPKIが可能になり、組み込みデバイスに役立ちます（実装するアルゴリズムは1つだけ）。ただし、混合アルゴリズムPKIは通常のものであり、十分にサポートされており、PKI全体にわたる新しいアルゴリズムへの移行の場合に期待されます。

7
Thomas Pornin

私の知る限りでは、下位CAのアルゴリズムには、ルートCAが強制したいアルゴリズム以外の要件はありません。

実際、なぜそれが受け入れられないのかという理由を探すのではなく、なぜそれが受け入れられるのかという理由を調べます。下位のCA証明書はすべて、ルートCAによって署名されている必要があります。そして、ルートCAは究極の信頼を表しています。ルートCAが下位CAをECC/RSA /アルゴリズム証明書で信頼している場合は、問題ありません。ルートCAは証明書に署名し、その信頼を拡張します。

ただし、おそらくCAポリシーを提供する必要があります。これにより、クライアントとして、ルートCAを信頼するかどうかをクライアントが評価できるように、CAとして承認する内容を記述します。非推奨となっているアルゴリズムや壊れているアルゴリズムを確認し、証明書でそれらを受け入れないでください。

2
M'vy