web-dev-qa-db-ja.com

ルートが別のPKIの相互認証に使用されている場合、AIAまたはCRLはルートCAで有用/必要ですか？

使用されているいくつかの独立したPKIがあるとします。

  • 2つの内部PKI：1つはSHA1で、もう1つはSuite Bアルゴリズムでサポートされます。

  • 私が信頼し、ポリシーマップを持っているパートナー。

両方のPKIにオフラインルートがあり、チェーン検証中にルートは計算された「チェーン」の真ん中にあります（誰がどの証明書を検証しているかに応じて）、オフラインルートにAIAまたはCRLが必要ですか？

certificatespublic-key-infrastructurecertificate-revocationcertificate-authority
8
goodguys_activate

Authority Information Access拡張子は、特定の証明書で公開するために使用されます。

  • 発行者の証明書のコピーをダウンロードできる場所;
  • oCSPサーバーが見つかる可能性のあるアドレス/URL。AIAを含む証明書に関する失効情報が新たに生成されます。

RFC 528 のセクション4.2.2.1を参照してください。

どちらの使用法も、発行者を含むことを意図した証明書、つまり、検証パスの最初の証明書notである証明書でのみ意味があります。パスの最初の証明書は「トラストアンカー」、別名「ルートCA」です。これは、発行者からの委任のためではなく、「定義上」信頼する名前+キーです。そのため、トラストアンカーには発行者も失効ステータスもありません（上位CAによって失効させることはできません。せいぜい、手動で信頼を停止することを決定します）。トラストアンカー（ルートCA）は、伝統的な証明書として表現されます。拡張機能が通常具現化するものとはまったく異なるセマンティックで）。

回避するために学習する必要がある混乱の可能性があります。a[〜＃〜] ca [〜＃〜]はCA証明書と同じものではありません。証明機関はname（X.500識別名）とkeyを持つエンティティです。その名前とその公開鍵はseveral個別の証明書にコピーできます。これは、2つの階層PKIが「相互に信頼する」ことを決定する状況では一般的です。 （想像を超えて）「A」と「B」と呼ばれる2つのPKIについて考えます。各PKIは以下で構成されます。

  • ルートCA（それぞれ「root_A」および「root_B」と呼ばれます）。これは ハードウェアセキュリティモジュール を備えたオフラインシステムとして想像できます。
  • 下位CA（それぞれ「sub_A」および「sub_B」と呼ばれます）。これはonlineシステムであり、おそらくHSMも備え、エンドエンティティ証明書を発行します。
  • エンドエンティティ証明書。

オンラインでもオフラインでも、各CAは定期的に失効情報を公開する必要があるため、オフラインCAであっても、適切なCRLが手動の手順で（またはおそらく自動的に）プッシュされる場所にオンラインサーバーがあると想定する必要があります。ルートからオンラインサーバーへの一方向のネットワークリンクがある場合-リンクの一方向性により、CAのオフライン性を維持できます。

PKI AとBが相互に信頼することを決定する前に、以下の特性を持ついくつかの証明書が存在します。

  • Root_Aの名前とキーは自己署名証明書として公開されており、その証明書のコピーはhttp://serverA.com/root_A.cerで入手できます。
  • Sub_Aの名前とキーは、root_A.cerが利用できるURLをポイントするAIAとともに、root_Aによって署名された証明書として公開されます。 sub_Aの証明書のコピーはhttp://serverA.com/sub_A.cerで入手できます。
  • Sub_Aによって発行された各エンドエンティティ証明書には、sub_A.cerが存在するURLを含むAIAがあります。
  • PKI Bについても同様です。

したがって、PKI Aからのエンドエンティティ証明書を検証する検証者は、AIA拡張機能に従って、必要なすべての証明書、つまりsub_A.cerをダウンロードします。ベリファイアmayもroot_A.cerをダウンロードしますが、検証が成功するにはベリファイアがalreadyこの自己署名証明書のコピーを持っている必要があるため、これはほとんど必要ありません。 OCSPサーバー（AIAでも）へのポインターとCRL（CRL配布ポイント拡張として）へのポインターは同じパターンに従いますが、その場合、root_AからのCRL/OCSPへのポインターは不要ではありません（検証機能must sub_Aが取り消されていないことを確認してください）。

AとBが運命を結び、血を交わし、一般に永遠に親友になることを決定する契約がここに来ます。そのため、PKI AとPKIは「マージ」されるか、少なくとも「ブリッジCA」として通常知られているものとリンクされます。ポイントは、root_Aを信頼する人がPKI Bからのエンドエンティティ証明書を有効として自動的に受け入れることを許可することです。これを実現するには、主に4つの方法があります。

  1. Root_Aはroot_Bの新しい証明書を発行します：証明書にはroot_Bの名前とキーが含まれていますが、この証明書は自己署名されていません。代わりに、root_Aによって署名されます。この新しい証明書をbridge_AB.cerと呼びましょう。 root_Aによって発行されたこの証明書には、root_A.cerをポイントするAIAと、root_Aによって発行された証明書の失効ステータスを維持するOCSPサーバーが含まれています。

    既存の証明書はいかなる方法でも変更または失効または廃止されていないため、root_B（トラストアンカーとして）を信頼する人々は、以前と同様に、PKI BからのEE証明書の検証を続行できます。そのようなEE証明書の場合、検証するパスは、root_Bをトラストアンカーとして使用しているユーザーの場合、root_B-> sub_B.cer-> EEになります。トラストアンカーとしてroot_Aのみを使用している場合、パスはroot_A-> bridge_AB.cer-> sub_B.cer-> EEになります。

    このプロセスが自動的に機能するためには、関連する証明書に、両方のチェーンの再構築を可能にするAIA拡張が含まれている必要があります。その場合は、root_B.cer（serverB.comサーバー上）をbridge_AB.cerのコピーに、root_B.cerという名前で置き換えるだけで十分です。したがって、sub_B.cerのAIAは、bridge_AB.cerの単一ビットを変更する必要なく、sub_B.cerを指すようになりました。 root_Bを信頼する人はそれを直接使用できます。sub_B.cerでAIAを見ることさえありません（少なくともパスの再構築のため）。 root_Aを信頼する人は、AIAのみに従い、root_Aで始まるパスを再構築します。すべて順調。

    root_B.cerをブリッジ証明書で置き換えることは、PKIが2つしかない場合にのみ機能します。 3番目のPKI Cがménage-à-troisに参加する場合、より一般的な方法を採用する必要があります。新しい証明書がsub_Bに対して発行されます。その証明書にはall証明書を指すAIAが含まれますroot_Bの場合：古い自己署名証明書、bridge_AB.cer、bridge_CB.cerなど。 AIA形式では、複数のURIを含めることができます。そのsub_Bの新しい証明書は、以前の証明書を置き換えるsub_B.cerとして公開できます。

  2. Root_Aはsub_Bの新しい証明書を発行します。この新しい証明書はroot_Aによって発行されるため、root_A.cerを指すAIAが含まれています。この新しい証明書をsub_AB.cerと呼びましょう。

    その時点で、私たちはパス構築に関して問題を抱えています。 PKI BからのEE証明書には、サーバーsub_B.cer上のserverB.comを指すAIAがまだ含まれています。 sub_B.cerをroot_Aによって発行された新しい証明書（sub_AB.cer）で置き換えると、root_Aでパスの構築が終了し、root_Bにプラグインする可能性がなくなります。root_Bのみを信頼するユーザーの検証が失敗します。一般的な解決策は、-all EE証明書を再発行することです。新しいAIAはboth sub_Bの証明書を指します（root_Bによって発行された証明書、and）。 = root_Aが発行したもの）。ただし、大量再発行には費用がかかります。別の方法は、証明書を検証したい人にsub_AB.cerを「利用可能にする」ことです。そのための証明書ストアがWindowsにあります（「中間CA」と呼ばれます）。この証明書はAIAで参照されませんが、ソフトウェアすべき必要に応じて使用できるほどスマートです。中間CAは先験的信頼されていないため、このような証明書の大量展開は、新しいトラストアンカーを展開するよりも問題が少なくなります。

  3. Sub_Aはroot_Bの証明書を発行します。治療は症例1と同様です。

  4. Sub_Aはsub_Bの証明書を発行します。治療は症例2と同様です。

これらの4つの方法は、PKI AからPKI Bへの信頼を委任するためのものであり、root_Aを信頼する人々がPKI BからのEE証明書を検証できるようにします。フルブリッジの場合、反対方向も実行する必要があります（root_Bを信頼する人々は、 PKIからのEE証明書を検証するA）。両方のブリッジが同じトポロジをたどる必要はありません（ただし、手に負えないほど、全体がわかりにくくなります）。

salient pointsは次のとおりです。

  • どのCAも、同じ名前とキーを含む複数の証明書を持つことができます。特定の証明書（EEまたはCA）には単一のissuer（証明書に署名したエンティティ）がありますが、その発行者の名前とキーを含む証明書は、パスのその時点でプラグインできます。これに対応して、証明書のパスがマージされる場合があります（X.509は完全なループを明示的に禁止しています）。

  • AIA拡張機能は、発行者のpotential証明書をポイントすることにより、パスの構築に役立ちます。これらの証明書の使用は必須ではありません。中間CA証明書の大量展開は実行可能な代替手段です（少なくとも、Active Directoryサーバーなどの機能を提供する組織化されたネットワークでは）。

  • これは、ポリシーマッピングの影響を受けません。これは逆の方法です。PKIAとBが証明書ポリシーを使用し、両方に独自の個別のOIDがある場合、ブリッジはマッピングを含める必要があるため、検証者はが構築するすべてのパスを通じてポリシーに従うことができます。

8
Thomas Pornin

自己署名ルート証明書にはAIAを含めないでください。PKIX準拠の実装によってチェックされるCRLはありません。

独自のルートによって発行された証明書を使用するサービスがあるが、他のCAのみを使用して検証可能でなければならない場合、中間体にはAIA拡張が必要です。これはルート証明書ではなくなります。

説明するには（アーキテクチャを間違って理解している場合は修正してください）：

 + --------- + + ---------- + 
 | SHA-1 CA | | Suite-B CA | 
 | | | | 
 |公開| |公開| 
 |キー| |キー| 
 + --- + ----- + + ---- + ----- + 
 | | 
 | | 
 | | 
 | | 
 + --- + ------ + + ---- + ----- + 
 |サーバーA | |サーバーB | 
 |証明書| |証明書| 
 | | | | 
 |公開鍵| |公開キー| 
 + ---------- + + ---------- +

次に、クライアントがServer A CAのみを信頼する場合に、Suite-B証明書を検証できるようにします。 Server BとSHA-1 CAでも同じ

そのためには、実際には、両方のCAに2つの証明書が必要です。最初の証明書は自己署名されており、2番目の証明書は他のCAによって署名されています。問題は、両方が同じDNを持ち、同じ公開鍵を使用する必要があることです。他の問題は、サーバーがクライアントにCA証明書を提示せず、そのクライアントがストアにCA証明書を持っている必要がある（かなり通常の状況）and他のCA証明書の中間バージョン（ない典型的な状況）。この中間証明書には、他のCA CRL DPを指すAIAが必要です。

したがって、Suite-Bクライアントの場合、アーキテクチャは次のようになります。

 + ---------- + 
 | Suite-B CA | 
 | | 
 |公開| 
 |キー| 
 + ---- + ----- + 
 ,-〜 '' | 
、-〜 '| 
 +- ----〜 '-+ | 
 | SHA-1 CA | | 
 | （サブCA）| | 
 |公開| | 
 |キー| | 
 +-、-'----- + | 
、-〜 '| 
、-' | 
 + ---、-〜 '--- + + ---- + ----- + 
 |サーバーA | |サーバーB | 
 |証明書| |証明書| 
 | | | | 
 |公開鍵| |公開キー| 
 + ---------- + + ---------- +

この場合、SHA-1 CA証明書には、Suite-B CAのAIAおよび発行者情報が含まれます。検証者の観点から見ると、このサブCA証明書は最初の図の証明書とはまったく異なります。

2
Hubert Kario