公開鍵はCSRにどのように含まれていますか?

Aug 21 2020

1つの記事がすべての側面をカバーしているのを見つけることは非常にまれなので、PKIとデジタル証明書のトピックに関する多くの記事を読みました。また、このトピックは最初は混乱しています(この美しい質問は私の最後の読み物です:暗号化、ハッシュ、および署名に関して証明書はどのように機能しますか?)。

私は私の理解のポイントからこのグラフを描きました: https://i.stack.imgur.com/sI7Od.png

2つの質問があります:

  1. 公開鍵と暗号文がどのように「パッケージ化」されているのか実際にはわかりません(次のステップに進むために考えられる最善の方法です!)。最後に、*。csrファイルは単なるプレーンです。 base64テキスト、それらは一緒に暗号化されているので、図面のステップの順序は不正確ですか?

  2. 送信者のIDを(たとえばWebブラウザーから)確認するには、CSRのコピーが必要ですが、私の理解によれば、証明書にはそのハッシュしかありませんか?

編集:

  1. このビデオは、ANS.1エンコーディングを理解するのに役立つ可能性があります。 https://www.youtube.com/watch?v=EccHushRhWs

  2. 私はマルクの答え以下、図を修正し、ここで、とこことでスペックIETF /基本証明書のフィールド:

回答

5 Marc Aug 21 2020 at 21:35

ダイアグラムにはいくつかの誤解があります。

最も重要なのは、両方encryptボックスが間違っているということsignです、彼らは言うべきです。その後、CAに送信されるCSRには、さまざまなフィールド(サブジェクトを含む)とサブジェクトの公開鍵が含まれ、プレーンデータと署名だけを含む暗号文はありません。

RFC2986:PKCS#10:証明書要求構文では、CSRを構築する手順について詳しく説明しています。

The process by which a certification request is constructed involves the following steps:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

        3. The CertificationRequestInfo value, a signature algorithm
           identifier, and the entity's signature are collected together
           into a CertificationRequest value, defined below.

サブジェクト(あなたの場合:申請者)の公開鍵は、サブジェクト情報と同様に、CSRに逐語的に含まれています。これは、サブジェクトの公開鍵とCAに送信されるすべてのものを使用して署名されます。

ダイアグラム形式ではありませんが、CSRを構築する手順と含まれるデータは次のとおりです。CSRを構築するための正しい手順(ダイアグラム形式ではありません)は次のとおりです。

  • CertificationRequestInfoを使用して構築します。
    • Subject Distinguished Name
    • Subject Public Key
    • Other attributes
  • 使用および特定のアルゴリズムにSignature署名しCertificationRequestInfoて取得しSubject Public KeyますSignature Algorithm
  • 以下CSRを含めてオブジェクトを作成します。
    • CertificationRequestInfo
    • Signature
    • Signature Algorithm
  • このCSRblobをCAに送信します。

CSRにはまだ平文CertificationRequestInfoとが含まれていることに注意してくださいSubject Public Key

を受信するCSRと、CAは多かれ少なかれ次のことを行います。

  • CSRを解析する
  • サブジェクトの公開鍵を使用して、署名がCSRのフィールドと一致することを確認します
  • さまざまなフィールドが要件に一致していることを確認します(例:CN=google.comドメインを所有していることを証明せずに要求することはできません)
  • CSRの一部のフィールド、それ自体のフィールドを使用して証明書を作成する
  • (発行者の)秘密鍵を使用して証明書に署名する

最終的な証明書には、サブジェクトフィールドとサブジェクトの公開鍵が引き続き含まれています。

2つの質問に具体的に答えるには:

  1. 対象者の公開鍵はCSRのフィールドの一つです。暗号化されるものはなく、署名されるだけです。
  2. サブジェクトフィールドが最後の証明書にコピーされているすべてのクライアントが参照するために、彼らはそこにあります。

RFC5280で証明書フィールドのリストを確認できます。CSRの必要がないため、CSRのハッシュはありません。すべての関連情報は、証明書の独自のフィールドにコピーされました。