ダイジェストアルゴリズムがCMS / PKCS7の2つの場所で指定されているのはなぜですか？
RFC5652 、暗号化メッセージ構文（CMS）、セクション5.3。 SignerInfo Type、id-sha256、id-sha1などの値を持つdigestAlgorithmフィールドがあります。
同じRFCのセクション5.1。SignedDataTypeには、私のテストでは一般的にdigestAlgorithmsフィールドがあります。 SignerInfoと同じ数のエントリが含まれています。
私の質問は...なぜdigestAlgorithmフィールドが2か所で指定されているのですか？不必要に冗長に見えます。
5.1が言うように（編集され、強調が追加されました）：
zygetAlgorithms ...は、すべての署名者が採用しているメッセージダイジェストアルゴリズムを任意の順序で一覧表示することを目的としていますワンパス署名検証を容易にします実装は、ダイジェストアルゴリズムを使用する署名の検証に失敗する場合がありますこのセットには含まれていません。 .。
言い換えると、受信者/検証者はメッセージの最初から開始でき、次のようになります。
digestAlgorithmsを読み、それらのアルゴリズムのコンテキストを設定しますencapContentInfoを読み取り、データを実行します。データは、ダイジェストによっては非常に大きくなる可能性があります。 SHA-1の場合は2 ^ 64、ダイジェストアルゴリズム、または並列アルゴリズムを介して、同時に必要に応じてデータを保存および/または処理および/または中継します。または、「切り離された」場合は、別の場所からデータを取得し、同様にダイジェストやその他の用途で実行します。存在する場合は
certificatesとcrlsを読み取り、必要に応じて手元に置いておきます。大きすぎず、ローカルですでに利用可能なデータを複製しないでください。 LDAPやAIA（OCSPを含む）などを使用して、必要に応じて再フェッチできることを条件として、必要に応じてそれらを破棄できます。signerInfosを読み取り、（関心のある）それぞれについて、計算済みの正しいダイジェストを選択して使用します。さらに、使用する場合はsignedAttrsを使用して、戻ることなくsignatureを確認します。データに
それほど明確に述べられていませんが、これが理由でもありますCMSの多くの（すべてではありません！）構造がBERとして指定されており、送信者の選択で使用できますDERの代わりに、長さが不定のエンコーディング。