web-dev-qa-db-ja.com

ルート証明書のキーの使用法（非自己署名エンドエンティティ）

このディスカッションには、Webサーバーやメールサーバーなどのホストの自己署名エンドエンティティ証明書は含まれません。

OpenSSLのCA証明書のデフォルト構成には、次のkeyUsageがあります。

  • cRLSign
  • keyCertSign

連邦公開鍵インフラストラクチャ（PKI）X.509証明書およびCRL拡張プロファイル には次のkeyUsageがあります。

  • cRLSign
  • keyCertSign

Microsoftは、ルート証明書に次を使用します（ スタンドアロン証明機関の作成方法 から）：

  • 証明書の署名
  • オフラインCRL署名
  • CRL署名

RFC528 CAまたはCRL発行者の証明書キーの使用ビットを定義し、次のように記述します[〜＃〜] may [〜＃〜]RSAを使用してCAルートに存在する：

  • デジタル署名
  • 否認防止
  • keyEncipherment
  • dataEncipherment
  • keyCertSign
  • cRLSign

RFC528 のDSAキーの場合、次の[〜＃〜] [〜＃〜]を設定できます：

  • デジタル署名
  • 否認防止
  • keyCertSign
  • cRLSign

RFC528 の下のECDSAキー、次の[〜＃〜] [〜＃〜]を設定できます：

  • デジタル署名
  • 否認防止
  • keyAgreement
  • keyCertSign
  • cRLSign。

そして RFC528 はECDSAに関して次のように続けます：

keyUsage拡張機能がkeyAgreementをアサートする場合は、encipherOnlyまたはdecipherOnlyのいずれかをアサートできます（MAY）

なぜIETFはキーの使用法がそれほど速くてゆるいのですか？

RSAルート証明書にkeyEnciphermentおよびdataEnciphermentが許可されているのはなぜですか？

ECDSA証明書で鍵合意の使用が許可されるのはなぜですか？

IETFの使用は、標準が既存のプラクティスに適合するように作成されたケースですか？

public-key-infrastructurecertificate-authorityx.509
11
user29925

Key Usage 拡張が存在する場合は、公開鍵で許可されている使用タイプの完全なリストが含まれています。システムが証明書を処理する場合、証明書は所定の目的で処理されるため、Key Usage拡張が存在する場合は、その使用が許可されていることを確認する必要があります。具体的には、システムがCA証明書を分析し、その公開鍵を使用して別の証明書（CAが発行したとされる）の署名を検証する場合、これは「証明書署名」の使用法です。したがって、CA証明書にKey Usage拡張が含まれている場合、システムは拡張にkeyCertSignフラグが含まれている必要があります。

Key Usage拡張がotherフラグを含むことを妨げるものは何もありません！検証はポジティブのみです。システムは、必要なフラグが実際にそこにあるかどうかをチェックします。彼らは自分たちが望まないフラグがないことを決してチェックしない。

CAは証明書とCRLを発行することになっているため、一般的にはkeyCertSignフラグとcRLSignフラグが必要です。これら2つのフラグはsufficientです。 CAが独自のCRLに署名する予定がない場合は、cRLSignフラグを省略できます。ただし、keyCertSignフラグのないCAはほとんど意味がありません。 CAキーが他のことも行うことを意図している場合は、他のフラグを含めることもできます（ただし、これはお勧めできません。一般的な規則は、暗号化キーは1つの目的にのみ使用することです）。たとえば、発行された証明書の秘密鍵をCAの公開鍵で暗号化してkey escrowingを実行すると、特定の条件下でCAが秘密鍵を回復できるようになります（これは、ユーザーのキーがデータの暗号化を目的としている場合は、悪い考えではありません）。

したがって、Key Usage拡張機能が他のフラグを含むことを妨げるものはありません。または、Key Usage拡張子がまったくない場合もあります。これは、「許可されているすべての使用」に相当します。

マイクロソフトの「オフラインCRL署名」は、「CRL署名」の別名です。実際、リンク先のページには次のように書かれています。

CA証明書が要求された場合にこのキー使用法を適用するには、コマンドプロンプトで次のように入力し、Enterキーを押します。

echo 03 02 01 06> File_Name.txt

ここでは、ビット5と6がセットされ、ビット0〜4がクリアされた、長さ7ビットのBIT STRINGのASN.1/DERエンコーディングを認識しています。これは、フラグkeyCertSignおよびcRLSignを使用したKey Usage拡張のエンコードです。 Microsoftは独自の用語を使用していますが、実際にはその時点の標準に準拠しています（「オフラインCRL署名」用の新しい非標準のキー使用法フラグを発明していません）。

上記はすべて、certificatesの通常の解釈です。規格に関する限り、「ルートCA証明書」が存在しない場合があります。 「ルート」はトラストアンカーと呼ばれ、ほとんどが名前（DN）と公開鍵で構成されます。トラストアンカーを「証明書」としてエンコードするのは伝統的です。つまり、証明書のエンコードルールに従うバイトのシーケンスです（このような証明書は、多くの場合、自己署名です。 「署名」用のオプションのスロットがないため、そのスロットには何かが必要です）。

これは非標準であるため、このような証明書のような構造での証明書拡張の解釈は、ローカルバリアントに対して開かれています。一部の実装では、ルート証明書のKey Usage拡張を上記で説明した方法で解釈します。一部では、その拡張機能を完全に無視しています。

一般に、ルートCA証明書に、トラストアンカー用の便利なエンコードベッセルではなく、その「証明書」が実際のものである場合に完全に有効なコンテンツを入力しても安全です（相互運用性）。

8
Thomas Pornin